AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:
CFG:
PT:0
S:andy.sharp@lsi.com
RQ:
SSV:mhbs.lsil.com
NSV:
SSH:
R:<David.Olien@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	6C678488C5CEE74F813A4D1948FD2DC7B7BF91FE@cosmail02.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Thu, 1 Apr 2010 15:42:23 -0700
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Olien, David" <David.Olien@lsi.com>
Subject: Re: sorry about those crap attatchments yesterday
Message-ID: <20100401154223.4e800e88@ripper.onstor.net>
In-Reply-To: <6C678488C5CEE74F813A4D1948FD2DC7B7BF91FE@cosmail02.lsi.com>
References: <6C678488C5CEE74F813A4D1948FD2DC7B7BF8D8B@cosmail02.lsi.com>
	<20100331122203.179628ed@ripper.onstor.net>
	<6C678488C5CEE74F813A4D1948FD2DC7B7BF8E73@cosmail02.lsi.com>
	<20100331143656.080acd4c@ripper.onstor.net>
	<6C678488C5CEE74F813A4D1948FD2DC7B7BF8EF9@cosmail02.lsi.com>
	<20100331175158.32ff11c3@ripper.onstor.net>
	<6C678488C5CEE74F813A4D1948FD2DC7B7BF8F37@cosmail02.lsi.com>
	<20100331182629.50478ae5@ripper.onstor.net>
	<6C678488C5CEE74F813A4D1948FD2DC7B7BF8F3A@cosmail02.lsi.com>
	<20100401110229.1b639ef6@ripper.onstor.net>
	<DEC609CD0E54B2448DAF023C89AE9755EB50C541@cosmail02.lsi.com>
	<6C678488C5CEE74F813A4D1948FD2DC7B7BF91B7@cosmail02.lsi.com>
	<20100401134901.496259b5@ripper.onstor.net>
	<6C678488C5CEE74F813A4D1948FD2DC7B7BF91CB@cosmail02.lsi.com>
	<20100401141115.7bd5b807@ripper.onstor.net>
	<6C678488C5CEE74F813A4D1948FD2DC7B7BF91FE@cosmail02.lsi.com>
Organization: LSI
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 1 Apr 2010 15:42:12 -0600 "Olien, David" <David.Olien@lsi.com>
wrote:

> Thanks!  I'll look these over!
> 
> I'll have to find out more about how our network at
> The Beaverton office is configured.
> 
> I've been kind of surprised.  LSI isn't
> THAT big a company. But they have a lot of
> Big-company policies.  For example, I'm
> Not allowed to bring in my own desk lamp.
> Apparently it's a fire hazard. I had no
> Idea a lamp could be so dangerous.
> 
> So I take the approach, if you want to
> Do something, don't ask.  You can always
> Apologize later if someone calls you for some
> Violation or other.

I was gonna say, I take the attitude that "company policy" is
advisory only.  In other words, follow it unless you know better.

> Other than these strange policies, I feel LSI
> Is a relatively well-run company for its size.

Yeah, it's got a decent amount of top down direction compared to many
companies it's size.  That said, some of the direction from the near top
is complete s@%$@#&.  But like a lot of similar companies, the folks
at the bottom usually manage to fix things.  Corporate IT is a perfect
example, at least for us.  The big wigs are n00bs, but our local part
time guy has a real laid back "whatever I can do for you" attitude.


> dave
> 
> -----Original Message-----
> From: Andrew Sharp [mailto:andy.sharp@lsi.com]
> Sent: Thursday, April 01, 2010 2:11 PM
> To: Olien, David
> Subject: Re: sorry about those crap attatchments yesterday
> 
> Well, then feel free to use it from work too ~:^)  They might have a
> faster local internet connection there in B-town than they do
> dedicated line between the sites.  The result would be a lot faster,
> and more convenient, than !@$^%! VNC.
> 
> Over the fullness of time, I've cooked up a whole series of scripts to
> automate creating screen sessions which then telnet into my consoles,
> and then create a terminal window on any X session anywhere in the
> world, or right on my workstation, no loss of history or context.  In
> the blink of an eye. And of course all screen sessions are logged for
> extra convenience ~:^)
> 
> If you're curious, just take a gander at
> ~andys/bin/{screen,telnet,extra_consoles}.*
> 
> Cheers,
> 
> a
> 
> On Thu, 1 Apr 2010 14:57:00 -0600 "Olien, David" <David.Olien@lsi.com>
> wrote:
> 
> > Great!  I bet that'll work a LOT better.
> >
> > I just upgraded my home internet to 12 megabits.
> > So I might get faster access from home than I do
> > From work!
> >
> > I tend to work weekends a lot, so this'll be
> > Really useful.
> >
> > dave
> >
> > -----Original Message-----
> > From: Andrew Sharp [mailto:andy.sharp@lsi.com]
> > Sent: Thursday, April 01, 2010 1:49 PM
> > To: Olien, David
> > Cc: Scheer, Larry; Fong, Rendell
> > Subject: Re: sorry about those crap attatchments yesterday
> >
> > Use the ssh gateway.  You can view the instructions at
> >
> > http://wiki.onstor.net/wiki/Using_SSH
> >
> > Pass it on to your friends.
> >
> > The VPN s#cks.
> >
> > On Thu, 1 Apr 2010 14:43:55 -0600 "Olien, David"
> > <David.Olien@lsi.com> wrote:
> >
> > > OK, thanks for the info.  Looks like I should update my source and
> > > rebuild, to pick up the new module.  Andy has pointed out some
> > > additional things to fix in my setup.
> > >
> > > I'm working remotely today, had a little trouble with my vpn.
> > > Looks like I'm connected through Allentown.  Probably not
> > > optimal.  I'm going to fix that next.
> > >
> > > Thanks!
> > > dave
> > >
> > > -----Original Message-----
> > > From: Scheer, Larry
> > > Sent: Thursday, April 01, 2010 12:25 PM
> > > To: Sharp, Andy; Olien, David
> > > Cc: Fong, Rendell
> > > Subject: RE: sorry about those crap attatchments yesterday
> > >
> > > The TXRX has some user level daemons that need to run. There is a
> > > process manager daemon (pm) that runs on the TXRX  that watches
> > > and keeps alive the other two daemons cm and ipmd. So you do need
> > > to start pm, cm and ipmd which is done from the onstor-start rc
> > > script.
> > >
> > > I am loading a set of modules that are "Max approved"  I think the
> > > modules file I initially gave you had too many modules in it. One
> > > thing that Rendell and I are doing that Max says is needed is to
> > > build and install the RMC module. We added that to our
> > > Makefile.tuxstor.
> > >
> > > This is what my M list looks like in my Makefile.tuxstor it
> > > contains the stuff that Max and Rendell are building:
> > >
> > > M=$(CURDIR)/code \
> > >     $(addprefix $(CURDIR)/code/,sm-esm sm-thread sm-scsi
> > > sm-sanm-dm \ sm-hash sm-evm-srvr sm-fs sm-scsiio sm-swapfile
> > > sm-simtape sm-ipm \ sm-sanm-agent sm-elog sm-sdm-agent sm-ndmp
> > > sm-file sm-stats sm-event \ sm-rmc sm-tests sm-utils
> > > sm-icu-common smoo-linux)
> > >
> > > Here is the modules file that contains the "Max approved" modules
> > > to load at boot time:
> > >
> > > # /etc/modules: kernel modules to load at boot time.
> > > #
> > > # This file contains the names of kernel modules that should be
> > > loaded # at boot time, one per line. Lines beginning with "#" are
> > > ignored. softdog
> > >
> > > # needed for reading seep
> > > i2c_dev
> > > i2c_sibyte
> > > eeprom
> > >
> > > tpl-mod
> > > neteee2
> > > neteee-ui
> > > #hash_mod
> > > elog_mod
> > > rmc_mod
> > > event_mod
> > > ipm_mod
> > >
> > > kpi_mod
> > > utils_mod
> > > icu_common_mod
> > > esm-threads
> > > thread_mod
> > > stubs_mod
> > > sdm-agent_mod
> > > sanm-dm_mod
> > >
> > > ________________________________________
> > > From: Andrew Sharp [andy.sharp@lsi.com]
> > > Sent: Thursday, April 01, 2010 11:02 AM
> > > To: Olien, David
> > > Cc: Scheer, Larry; Fong, Rendell
> > > Subject: Re: sorry about those crap attatchments yesterday
> > >
> > > All of this is only relevant on the SSC side.  I think.  L/R?
> > >
> > > The modules I'm talking about are our out-of-tree kernel modules
> > > built from the nfx-tree directory, which I'm assuming is why these
> > > duplicate symbols thing is happening, although I thought that was
> > > impossible.  I thought a module would fail to load if it had a
> > > duplicate symbol in it.
> > >
> > >
> > > On Wed, 31 Mar 2010 19:32:38 -0600 "Olien, David"
> > > <David.Olien@lsi.com> wrote:
> > >
> > > > Attached is my /etc/modules file.  I think I got
> > > > This from Larry.  He also gave me the files listed:
> > > >
> > > > /etc/onstor/pmtab
> > > > /etc/init.d/onstor
> > > >
> > > > And instructions to run
> > > >
> > > > "update-rc.d onstor start 98 2 3 4 5 . stop 21 0 1 6 ."
> > > >
> > > > dave
> > > >
> > > > -----Original Message-----
> > > > From: Andrew Sharp [mailto:andy.sharp@lsi.com]
> > > > Sent: Wednesday, March 31, 2010 6:26 PM
> > > > To: Olien, David
> > > > Subject: Re: sorry about those crap attatchments yesterday
> > > >
> > > > ah. well, you know, even a blind squirrel....
> > > >
> > > > On Wed, 31 Mar 2010 19:20:37 -0600 "Olien, David"
> > > > <David.Olien@lsi.com> wrote:
> > > >
> > > > > You were right about the MAC address problem.
> > > > > That was my mistake.  This output was from before
> > > > > I put the original driver back.  Here's the
> > > > > MAC addresses that the driver finds NOW.
> > > > > This looks better.
> > > > >
> > > > > dave
> > > > >
> > > > > will not detect link failures! see bonding.txt for details.
> > > > > eth0: enabling TCP rcv checksum
> > > > > eth0: SiByte Ethernet at 0x10064000, address:
> > > > > 00:07:34:07:86:90 eth1: enabling TCP rcv checksum
> > > > > eth1: SiByte Ethernet at 0x10065000, address:
> > > > > 00:07:34:07:86:91 eth2: enabling TCP rcv checksum
> > > > > eth2: SiByte Ethernet at 0x10066000, address:
> > > > > 00:07:34:07:86:92 eth3: enabling TCP rcv checksum
> > > > > eth3: SiByte Ethernet at 0x10067000, address:
> > > > > 00:07:34:07:86:93 tun: Universal TUN/TAP device driver, 1.6
> > > > >
> > > > > -----Original Message-----
> > > > > From: Andrew Sharp [mailto:andy.sharp@lsi.com]
> > > > > Sent: Wednesday, March 31, 2010 5:52 PM
> > > > > To: Olien, David
> > > > > Subject: Re: sorry about those crap attatchments yesterday
> > > > >
> > > > >
> > > > > > Type ctrl-e to stop autoload.
> > > > > > Waiting for TXRX image to be loaded...done
> > > > > > Linux version 2.6.22-tx (dolien@dolien-debian) (gcc version
> > > > > > 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #2 SMP Wed
> > > > > > Mar 31 14:51:15 PDT 2010 Booting Linux kernel...Mips64
> > > > > > TuxRx CPU revision is: 01041100 FPU revision is: 000f0103
> > > > > > Broadcom SiByte BCM1480 B1 (pass3) @ 900 MHz (SB-1A rev 0)
> > > > > > Board type: ONStor TuxRx
> > > > > > This kernel optimized for ONStor Cougar TuxStor System
> > > > > > without CFE Determined physical RAM map:
> > > > > >  memory: 0000000010000000 @ 0000000000000000 (usable)
> > > > > >  memory: 0000000020000000 @ 0000000080000000 (usable)
> > > > > >  memory: 0000000010000000 @ 00000000c0000000 (usable)
> > > > > >  memory: 00000000c0000000 @ 0000000140000000 (usable)
> > > > > > Detected 3 available secondary CPU(s)
> > > > > > Built 1 zonelists.  Total pages: 2068480
> > > > > > Kernel command line: console=duart0,57600n8 root=/dev/nfs
> > > > > > nfsroot=10.0.0.132:/home/dolien/g12r208-tuxrx-root,v3,tcp
> > > > > > ip=10.3.208.240:10.0.0.132:10.3.0.1:255.255.0.0:g12r208tx:eth0:none
> > > > > > -s Primary instruction cache 32kB, 4-way, linesize 32 bytes.
> > > > > > Primary data cache 32kB, 4-way, linesize 32 bytes. Secondary
> > > > > > cache 1024kB, 8-way, linesize 32 bytes. Synthesized TLB
> > > > > > refill handler (41 instructions). Synthesized TLB load
> > > > > > handler fastpath (54 instructions). Synthesized TLB store
> > > > > > handler fastpath (54 instructions). Synthesized TLB modify
> > > > > > handler fastpath (53 instructions). Not waiting for GDB
> > > > > > client... rcon not initialized yet Not waiting for gdb
> > > > > > client... rcon not initialized yet PID hash table entries:
> > > > > > 4096 (order: 12, 32768 bytes) Using 1.000 MHz high
> > > > > > precision timer. Dentry cache hash table entries: 1048576
> > > > > > (order: 11, 8388608 bytes) Inode-cache hash table entries:
> > > > > > 524288 (order: 10, 4194304 bytes) Memory: 4046080k/4194304k
> > > > > > available (2388k kernel code, 147824k reserved, 945k data,
> > > > > > 148k init, 0k highmem) Mount-cache hash table entries: 256
> > > > > > Checking for the multiply/shift bug... no. Checking for the
> > > > > > daddi bug... no. Checking for the daddiu bug... no. CPU
> > > > > > revision is: 03041100 FPU revision is: 000f0103
> > > > > > Primary instruction cache 32kB, 4-way, linesize 32 bytes.
> > > > > > Primary data cache 32kB, 4-way, linesize 32 bytes.
> > > > > > Secondary cache 1024kB, 8-way, linesize 32 bytes.
> > > > > > Synthesized TLB refill handler (41 instructions).
> > > > > > CPU revision is: 05041100
> > > > > > FPU revision is: 000f0103
> > > > > > Primary instruction cache 32kB, 4-way, linesize 32 bytes.
> > > > > > Primary data cache 32kB, 4-way, linesize 32 bytes.
> > > > > > Secondary cache 1024kB, 8-way, linesize 32 bytes.
> > > > > > Synthesized TLB refill handler (41 instructions).
> > > > > > CPU revision is: 07041100
> > > > > > FPU revision is: 000f0103
> > > > > > Primary instruction cache 32kB, 4-way, linesize 32 bytes.
> > > > > > Primary data cache 32kB, 4-way, linesize 32 bytes.
> > > > > > Secondary cache 1024kB, 8-way, linesize 32 bytes.
> > > > > > Synthesized TLB refill handler (41 instructions).
> > > > > > Brought up 4 CPUs
> > > > > > NET: Registered protocol family 16
> > > > > > registering PCI controller with io_map_base unset
> > > > > > registering PCI controller with io_map_base unset
> > > > > > Request for iomem region ONStor Mgmtbus (0x1f0000000 -
> > > > > > 0x1f0ffffff) granted PCI: shared SSC PCI space
> > > > > > 0x90000000ae000000, addr 0x00000001f0000000 Time: MIPS
> > > > > > clocksource has been installed. NET: Registered protocol
> > > > > > family 2 IP route cache hash table entries: 262144 (order:
> > > > > > 9, 2097152 bytes) TCP established hash table entries: 131072
> > > > > > (order: 9, 3145728 bytes) TCP bind hash table entries: 65536
> > > > > > (order: 8, 1048576 bytes) TCP: Hash tables configured
> > > > > > (established 131072 bind 65536) TCP reno registered
> > > > > > Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> > > > > > io scheduler noop registered
> > > > > > io scheduler anticipatory registered
> > > > > > io scheduler deadline registered
> > > > > > io scheduler cfq registered (default)
> > > > > > SiByte User Watchdog: timeout is 8.3 secs
> > > > > > RAMDISK driver initialized: 16 RAM disks of 4096K size 1024
> > > > > > blocksize Ethernet Channel Bonding Driver: v3.1.3 (June 13,
> > > > > > 2007) bonding: Warning: either miimon or arp_interval and
> > > > > > arp_ip_target module parameters must be specified, otherwise
> > > > > > bonding will not detect link failures! see bonding.txt for
> > > > > > details. 00:00:00<7>sbmac: configuring MAC at 10064000 eth0:
> > > > > > enabling TCP rcv checksum eth0: SiByte Ethernet at
> > > > > > 0x10064000, address: 00:07:34:00:00:00 eth1: enabling TCP
> > > > > > rcv checksum eth1: SiByte Ethernet at 0x10065000, address:
> > > > > > 00:07:34:00:00:00 eth2: enabling TCP rcv checksum eth2:
> > > > > > SiByte Ethernet at 0x10066000, address: 00:07:34:00:00:00
> > > > > > eth3: enabling TCP rcv checksum eth3: SiByte Ethernet at
> > > > > > 0x10067000, address: 00:07:34:00:00:00
> > > > >                                                 ^^^^^^^^^^^^^^^^^
> > > > > This looks like the txrx node is not getting the proper info
> > > > > from the SSC about what it's MAC address is.  Which means that
> > > > > quite a few other things are missing as well, including a
> > > > > matching mgmtbus driver.  It's a miracle you booted this far.
> > > > > Unless this is a result of the mods you [shouldn't] have made
> > > > > to the sb_mac driver ~:^)
> > > > >
> > > > > > tun: Universal TUN/TAP device driver, 1.6
> > > > > > tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
> > > > > > mgmtbus_init: ringConfAddr ssc_pci_base 0x0000000060000000
> > > > > > mgmtbus_init: ssc_base_offset 0x0000000060000000,
> > > > > > ssc_base_phy_addr 0x0000001060000000 mgmtbus_init: ssc
> > > > > > <virt,pci_base> 0x9000001060000000, 0x0000000060000000
> > > > > > mgmtbus_init: txrx_pci_virt 0x90000001f0000000,
> > > > > > txrx_pci_base 0x000000001a000000 mgmtbus_init: fp_pci_virt
> > > > > > 0x900000101b000000, fp_pci_base 0x000000001b000000 mgmtbus:
> > > > > > using irq 59 mgmtbus_init: mgmtbus registered net device:
> > > > > > mgmtbus rcon_init rcon_init: RingConfig 0x9000001060000000,
> > > > > > txrx_rcon_pci_offset 0x000000001a000000,
> > > > > > txrx_rcon_pci_address 0x90000001f0000000 rcon_init: LOCAL my
> > > > > > queue's queue_start 0x90000001f0000000, txrx_rcon_pci_offset
> > > > > > 0x000000001a000000, txrx_rcon_pci_address
> > > > > > 0x90000001f0000000<6>rcon_init: PEER txrx_queue PHY
> > > > > > 0x9000001060000120, fp_queue PHY 0x9000001060000a20prom_init
> > > > > > from_init: DEV_29LV033 sector size = 65536 size = 4194304
> > > > > > from_init: DEV_29LV040 sector size = 65536 size = 524288 TCP
> > > > > > cubic registered NET: Registered protocol family 1 NET:
> > > > > > Registered protocol family 17 802.1Q VLAN Support v1.8 Ben
> > > > > > Greear <greearb@candelatech.com> All bugs added by David S.
> > > > > > Miller <davem@redhat.com> eee_init: ENTRY
> > > > > > eee_initFixedFwdQueues: Initialize eee.rcv_queue[]
> > > > > > eee_initFixedFwdQueues: EXIT eee_initFWDQueues: Initialize
> > > > > > eee.fwd_queue[] eee_initFwdQueues() eee.fwd_queue[0]
> > > > > > fwd_start 0xa8000001ffba9b80, end 0xa8000001ffba9c80
> > > > > > eee_initFwdQueues() eee.fwd_queue[0] fwd_head
> > > > > > 0xa8000001ffba9b80, tail 0xa8000001ffb8da08
> > > > > > eee_initFwdQueues() eee.fwd_queue[1] fwd_start
> > > > > > 0xa8000001ffba3000, end 0xa8000001ffba4000
> > > > > > eee_initFwdQueues() eee.fwd_queue[1] fwd_head
> > > > > > 0xa8000001ffba3000, tail 0xa8000001ffb8d9d0
> > > > > > eee_initFwdQueues() eee.fwd_queue[2] fwd_start
> > > > > > 0xa8000001ffbbf000, end 0xa8000001ffbc0000
> > > > > > eee_initFwdQueues() eee.fwd_queue[2] fwd_head
> > > > > > 0xa8000001ffbbf000, tail 0xa8000001ffb8d998
> > > > > > eee_initFWDQueues EXIT eee_app_init: ENTRY/EXIT eee_thread:
> > > > > > enter eee_init: EXIT NET: Registered protocol family 30
> > > > > > eee_thread: enter ACPU daemon; core 3 eth0: found phy 4,
> > > > > > vendor 000818 part 0b eth0: Link speed: 1000BaseT FDX
> > > > > > IP-Config: Complete: device=eth0, addr=10.3.208.240,
> > > > > > mask=255.255.0.0, gw=10.3.0.1, host=g12r208tx, domain=,
> > > > > > nis-domain=(none), bootserver=10.0.0.132,
> > > > > > rootserver=10.0.0.132, rootpath= Looking up port of RPC
> > > > > > 100003/3 on 10.0.0.132 Looking up port of RPC 100005/3 on
> > > > > > 10.0.0.132 VFS: Mounted root (nfs filesystem) readonly.
> > > > > > Freeing unused kernel memory: 148k freed INIT: version 2.86
> > > > > > booting Starting the hotplug events dispatcher: udevd.
> > > > > > Synthesizing the initial hotplug events...done. Waiting
> > > > > > for /dev to be fully populated...done. Setting parameters
> > > > > > of disc: (none). Activating swap...done.
> > > > > > Setting the system clock..
> > > > > > Cannot access the Hardware Clock via any known method.
> > > > > > Use the --debug option to see the details of our search for
> > > > > > an access method. Cleaning up ifupdown....
> > > > > > Loading kernel modules...i2c /dev entries driver
> > > > > > i2c-swarm.o: i2c SMBus adapter module for SiByte board
> > > > > > neteee2: module license 'unspecified' taints kernel.
> > > > > > neteee2: exports duplicate symbol eee_allocateApplicationId
> > > > > > (owned by kernel)
> > > > >
> > > > > That's ugly.  I would not try to load the out-of-tree kernel
> > > > > modules right now, except for ones that Max explicitly says
> > > > > are compatible with the perforce tree.
> > > > >
> > > > > > tpl_mod: exports duplicate symbol tpl_close (owned by
> > > > > > kernel) neteee2: exports duplicate symbol
> > > > > > eee_allocateApplicationId (owned by kernel) neteee2:
> > > > > > exports duplicate symbol eee_allocateApplicationId (owned
> > > > > > by kernel) neteee_ui: exports duplicate symbol
> > > > > > nfx_shell_prompt (owned by kernel) neteee2: exports
> > > > > > duplicate symbol eee_allocateApplicationId (owned by
> > > > > > kernel) neteee2: exports duplicate symbol
> > > > > > eee_allocateApplicationId (owned by kernel) tpl_mod:
> > > > > > exports duplicate symbol tpl_close (owned by kernel) rmc:
> > > > > > rmc_init(): RMC version 2.0.2 - myapp_id[79] neteee2:
> > > > > > exports duplicate symbol eee_allocateApplicationId (owned
> > > > > > by kernel) tpl_mod: exports duplicate symbol tpl_close
> > > > > > (owned by kernel) event_mod: disagrees about version of
> > > > > > symbol rmc_free_msg event_mod: Unknown symbol rmc_free_msg
> > > > > > event_mod: disagrees about version of symbol
> > > > > > rmc_server_init event_mod: Unknown symbol rmc_server_init
> > > > > > event_mod: disagrees about version of symbol
> > > > > > rmc_copy_buf_into_msg event_mod: Unknown symbol
> > > > > > rmc_copy_buf_into_msg event_mod: disagrees about version of
> > > > > > symbol rmc_reply event_mod: Unknown symbol rmc_reply
> > > > > > event_mod: no version for "rmc_server_close" found: kernel
> > > > > > tainted. event_mod: disagrees about version of symbol
> > > > > > rmc_msg_buf event_mod: Unknown symbol rmc_msg_buf
> > > > > > event_mod: disagrees about version of symbol
> > > > > > rmc_client_init event_mod: Unknown symbol rmc_client_init
> > > > > > event_mod: disagrees about version of symbol rmc_send
> > > > > > event_mod: Unknown symbol rmc_send event_mod: disagrees
> > > > > > about version of symbol rmc_client_close event_mod: Unknown
> > > > > > symbol rmc_client_close event_mod: disagrees about version
> > > > > > of symbol rmc_alloc_msg event_mod: Unknown symbol
> > > > > > rmc_alloc_msg event_mod: disagrees about version of symbol
> > > > > > rmc_init_ex event_mod: Unknown symbol rmc_init_ex neteee2:
> > > > > > exports duplicate symbol eee_allocateApplicationId (owned
> > > > > > by kernel) tpl_mod: exports duplicate symbol tpl_close
> > > > > > (owned by kernel) event_mod: disagrees about version of
> > > > > > symbol rmc_free_msg event_mod: Unknown symbol rmc_free_msg
> > > > > > event_mod: disagrees about version of symbol
> > > > > > rmc_server_init event_mod: Unknown symbol rmc_server_init
> > > > > > event_mod: disagrees about version of symbol
> > > > > > rmc_copy_buf_into_msg event_mod: Unknown symbol
> > > > > > rmc_copy_buf_into_msg event_mod: disagrees about version of
> > > > > > symbol rmc_reply event_mod: Unknown symbol rmc_reply
> > > > > > event_mod: disagrees about version of symbol rmc_msg_buf
> > > > > > event_mod: Unknown symbol rmc_msg_buf event_mod: disagrees
> > > > > > about version of symbol rmc_client_init event_mod: Unknown
> > > > > > symbol rmc_client_init event_mod: disagrees about version
> > > > > > of symbol rmc_send event_mod: Unknown symbol rmc_send
> > > > > > event_mod: disagrees about version of symbol
> > > > > > rmc_client_close event_mod: Unknown symbol rmc_client_close
> > > > > > event_mod: disagrees about version of symbol rmc_alloc_msg
> > > > > > event_mod: Unknown symbol rmc_alloc_msg event_mod:
> > > > > > disagrees about version of symbol rmc_init_ex event_mod:
> > > > > > Unknown symbol rmc_init_ex ipm_mod: Unknown symbol
> > > > > > event_postEvent done.
> > > > > > Loading device-mapper support.
> > > > > > Checking file systems...fsck 1.40-WIP (14-Nov-2006)
> > > > > > done.
> > > > > > Setting kernel variables...done.
> > > > > > Mounting local filesystems...done.
> > > > > > Activating swapfile swap...done.
> > > > > > Setting up networking....
> > > > > > Configuring network interfaces...+ '[' no '!=' '' ']'
> > > > > > + '[' lo '!=' lo ']'
> > > > > > + exit 0
> > > > > > done.
> > > > > > Starting portmap daemon....
> > > > > > Starting system log daemon: syslogd.
> > > > > > Give root password for maintenance
> > > > > > (or type Control-D to continue):
> > > > > > INIT: Entering runlevel: 2
> > > > > > Starting system log daemon: syslogd.
> > > > > > Starting kernel log daemon: klogd.
> > > > > > Setting NIS domainname to: agilestorage.
> > > > > > Starting NIS services: ypbind.
> > > > > > Starting portmap daemon...Already running..
> > > > > > Starting automounter: done.
> > > > > > Starting HTTP server: boagethostbyname:: Success
> > > > > > Starting MTA: exim4.
> > > > > > * Not starting internet superserver: no services enabled.
> > > > > > Starting OpenBSD Secure Shell server: sshdNET: Registered
> > > > > > protocol family 10 .
> > > > > > Starting NFS common utilities: statd.
> > > > > > Starting NTP server: ntpd.
> > > > > > Starting deferred execution scheduler: atdStarting periodic
> > > > > > command scheduler: crond.
> > > > > >
> > > > > > Debian GNU/Linux 4.0 tuxrx0 duart0
> > > > > >
> > > > > > tuxrx0 login: warning: rmc_eee_rcv(): Cannot find listener
> > > > > > app[18]. warning: rmc_eee_rcv(): Cannot find listener
> > > > > > app[18].
> > > > >
> > > > >
> > > > > Might just be the out-of-tree kernel modules that are screwing
> > > > > you up. The mgmtbus driver seems to be initializing and not
> > > > > panicing, so maybe you do have the right SSC kernel.  I'm not
> > > > > fully sure.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, 31 Mar 2010 17:15:09 -0600 "Olien, David"
> > > > > <David.Olien@lsi.com> wrote:
> > > > >
> > > > > > OK, I'm looking at some other issues right  now.
> > > > > > But maybe you can give me some information on the
> > > > > > Errors that are in this console output.
> > > > > >
> > > > > > See attached.
> > > > > >
> > > > > > dave
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Andrew Sharp [mailto:andy.sharp@lsi.com]
> > > > > > Sent: Wednesday, March 31, 2010 2:37 PM
> > > > > > To: Olien, David
> > > > > > Subject: Re: sorry about those crap attatchments yesterday
> > > > > >
> > > > > > Feel free to send me the complete console log.  I'm sitting
> > > > > > here in a pointless, interminable, conference call.  About
> > > > > > to die of boredom.
> > > > > >
> > > > > > On Wed, 31 Mar 2010 14:46:57 -0600 "Olien, David"
> > > > > > <David.Olien@lsi.com> wrote:
> > > > > >
> > > > > > > Sorry being slow to reply.  Just got back
> > > > > > > From a farewell lunch for a former co-worker.
> > > > > > >
> > > > > > > I believe you about the driver.
> > > > > > >
> > > > > > > That's why I haven't sent a patch.
> > > > > > >
> > > > > > > I assumed you have a lot of history with
> > > > > > > These drivers, they're not new code.
> > > > > > >
> > > > > > > I had difficulty seeing how the change we made
> > > > > > > Should really fix anything.
> > > > > > >
> > > > > > > I was perplexed when it actually booted after
> > > > > > > We rebuilt with the change.
> > > > > > >
> > > > > > > Most likely it's a configuration issue.
> > > > > > >
> > > > > > > I'll get back to you with more info later.
> > > > > > >
> > > > > > > dave
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Andrew Sharp [mailto:andy.sharp@lsi.com]
> > > > > > > Sent: Wednesday, March 31, 2010 12:22 PM
> > > > > > > To: Olien, David
> > > > > > > Subject: Re: sorry about those crap attatchments yesterday
> > > > > > >
> > > > > > > Trust me, there's no change needed for the driver.  See my
> > > > > > > other email.
> > > > > > >
> > > > > > > On Wed, 31 Mar 2010 11:23:18 -0600 "Olien, David"
> > > > > > > <David.Olien@lsi.com> wrote:
> > > > > > >
> > > > > > > > Andy,
> > > > > > > >
> > > > > > > > Having both to involve both Linux and windows systems to
> > > > > > > > send attachments Like that is a nuisance.  I made a
> > > > > > > > couple stupid goofs yesterday sending those
> > > > > > > > attachments.  I'll watch That more carefully next time.
> > > > > > > >
> > > > > > > > I'm going to look over more carefully why the changes
> > > > > > > > Sam and I made To the Ethernet driver made the panic go
> > > > > > > > away. I'll probably email a patch To whoever owns the
> > > > > > > > driver once I'm satisfied with the change.
> > > > > > > >
> > > > > > > > Then I'll go onto the module loading issue.
> > > > > > > >
> > > > > > > > Hopefully by the end of today we will have worked
> > > > > > > > through the issues.
> > > > > > > >
> > > > > > > > Getting serial console was critical.
> > > > > > > >
> > > > > > > > dave
