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	6C678488C5CEE74F813A4D1948FD2DC7B7BF91CB@cosmail02.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Thu, 1 Apr 2010 14:11:15 -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: <20100401141115.7bd5b807@ripper.onstor.net>
In-Reply-To: <6C678488C5CEE74F813A4D1948FD2DC7B7BF91CB@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>
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

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
