X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C81D92.F6ABA198@onstor-exch02.onstor.net>; Fri, 2 Nov 2007 12:57:22 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: rcon is working
Date: Fri, 2 Nov 2007 12:57:22 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E06540D52@onstor-exch02.onstor.net>
In-Reply-To: <20071102135405.1c545e47@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: rcon is working
Thread-Index: AcgdkoHxjXlSiD0DRpiB4Eo3OkwltgAAB4LA
References: <BB375AF679D4A34E9CA8DFA650E2B04E06540AB6@onstor-exch02.onstor.net><20071102105058.23185e09@ripper.onstor.net><BB375AF679D4A34E9CA8DFA650E2B04E06540B69@onstor-exch02.onstor.net><20071102113410.26e3488b@ripper.onstor.net><BB375AF679D4A34E9CA8DFA650E2B04E06540C8D@onstor-exch02.onstor.net><20071102131457.020010b0@ripper.onstor.net><BB375AF679D4A34E9CA8DFA650E2B04E06540CF0@onstor-exch02.onstor.net><20071102133157.6f7209c2@ripper.onstor.net><BB375AF679D4A34E9CA8DFA650E2B04E06540D3B@onstor-exch02.onstor.net> <20071102135405.1c545e47@ripper.onstor.net>
From: "Maxim Kozlovsky" <maxim.kozlovsky@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>

This will also work. Nobody is rushing to build Linux kernels anyway.

>-----Original Message-----
>From: Andy Sharp
>Sent: Friday, November 02, 2007 1:54 PM
>To: Maxim Kozlovsky
>Subject: Re: rcon is working
>
>Understood.  I'm going to check in what I have then.  Asking kenny
>(who-killed-?) to make me a branch and wondering when that will happen
>is bullsh!t I don't want to deal with.  I will just tell everyone they
>should not build this current kernel until your fixes go in.  Unless
>they want to help test it, in which case they should save their current
>kernel because this one might not be working yet.
>
>On Fri, 2 Nov 2007 13:45:35 -0700 "Maxim Kozlovsky"
><maxim.kozlovsky@onstor.com> wrote:
>
>> Yes it is a fucking mess. It should be uncached address in the end
>> whatever it is the txrx is passing. I am going to make it a little
>> more sane for cougar, unfortunately nothing can be done for bobcat
>> linux because the same image needs to be compatible with BSD kernel
>> and I don't want to be fixing that as well.
>>
>> >-----Original Message-----
>> >From: Andy Sharp
>> >Sent: Friday, November 02, 2007 1:32 PM
>> >To: Maxim Kozlovsky
>> >Subject: Re: rcon is working
>> >
>> >I think part of the problem is this (cut and pasted from the
comments
>> >I put in mgmt-bus.c:
>> >
>> >/*
>> > * actually, what's going on is that we are getting a cached virtual
>> > * address 0x9axxxxxx plugged into a spot
>> > * (t->table[src][MGMTBUS_ADDR_SSC].avail_ring_address - line 687)
>> which
>> > * should a physical address in it 0x1axxxxxx.  And the virtual
>> > address
>> > * shouldn't be the cached one anyway, it should be the uncached one
>> > * 0xbaXXXXXX
>> > *
>> > * so, to fix this bug (it's probably an issue in the txrx/fp
runtime
>> code
>> > * i'm guessing, since it isn't in this driver), we just add the
>> missing
>> > * 0x20000000 to the virtual address to make it an uncached address
>> > * instead of a cached one.  but we're probably still going to have
>> >problems.
>> > */
>> >//# define MGMTBUS_PHYS2VIRT(phys) phys_to_virt((unsigned long)phys)
>> >
>> ># define MGMTBUS_PHYS2VIRT(phys) ((phys < (void
>> >*)0x50000000) ?       \
>> >				phys_to_virt((unsigned
>> >	long)phys) :   \ (void *)((unsigned) phys | 0x20000000))
>> >
>> >
>> >On Fri, 2 Nov 2007 13:17:55 -0700 "Maxim Kozlovsky"
>> ><maxim.kozlovsky@onstor.com> wrote:
>> >
>> >> There is a line in /etc/syslog.conf which turns out kprintfs. Let
>> >> me take it I'll see why it is complaining about the link.
>> >>
>> >> >-----Original Message-----
>> >> >From: Andy Sharp
>> >> >Sent: Friday, November 02, 2007 1:15 PM
>> >> >To: Maxim Kozlovsky
>> >> >Subject: Re: rcon is working
>> >> >
>> >> >Well, I'm not getting any panics, but I'm getting so many
messages
>> >> >from txrx console that I'm losing the watchdog.  I'm getting this
>> >> >continuously:
>> >> >
>> >> >tx1:
>> >> >tx1:
>> >> >tx1:
>> >> >tx1: 3: luc_link_up:301: lport fp1.0 UP
>> >> >tx1:
>> >> >tx1: 4: Port : fp1.1 is UP
>> >> >tx1:
>> >> >tx1: 5: luc_link_up:301: lport fp1.1 UP
>> >> >tx1:
>> >> >tx1: 6: Port : fp1.2 is DOWN
>> >> >tx1:
>> >> >tx1: 7: luc_link_down: 359: lport fp1.2 DOWN.
>> >> >tx1:
>> >> >tx1: 8: luc_link_down:381: Spurious link down notification. Port
>> >> >fp1.2. tx1:
>> >> >tx1: 9: Port : fp1.3 is DOWN
>> >> >tx1:
>> >> >tx1: 10: luc_link_down: 359: lport fp1.3 DOWN.
>> >> >tx1:
>> >> >tx1: 11: luc_link_down:381: Spurious link down notification. Port
>> >> fp1.3.
>> >> >
>> >> >Then eventually the watchdog bites.
>> >> >
>> >> >
>> >> >On Fri, 2 Nov 2007 12:31:52 -0700 "Maxim Kozlovsky"
>> >> ><maxim.kozlovsky@onstor.com> wrote:
>> >> >
>> >> >> Sure please try. It would be great if you could check in
>> something.
>> >> >>
>> >> >> >-----Original Message-----
>> >> >> >From: Andy Sharp
>> >> >> >Sent: Friday, November 02, 2007 11:34 AM
>> >> >> >To: Maxim Kozlovsky
>> >> >> >Subject: Re: rcon is working
>> >> >> >
>> >> >> >I think I found the source of the problem.  If so, I could
>> >> >> >check in the new kernel, which would make things easier for
>> >> >> >you, no? Do you mind if I try my changes one last time?
>> >> >> >
>> >> >> >Cheers,
>> >> >> >
>> >> >> >a
>> >> >> >
>> >> >> > On Fri, 2 Nov 2007 10:55:02 -0700 "Maxim Kozlovsky"
>> >> >> ><maxim.kozlovsky@onstor.com> wrote:
>> >> >> >
>> >> >> >> Ok, I'll do that. At least the rcon works now. Could you
>> >> >> >> please
>> >> >> remind
>> >> >> >> me where is your tree?
>> >> >> >>
>> >> >> >> >-----Original Message-----
>> >> >> >> >From: Andy Sharp
>> >> >> >> >Sent: Friday, November 02, 2007 10:51 AM
>> >> >> >> >To: Maxim Kozlovsky
>> >> >> >> >Subject: Re: rcon is working
>> >> >> >> >
>> >> >> >> >Well, I'm not sure what to do now as you've been making
lots
>> of
>> >> >> >> >changes, and I've been making, well, a few (much fewer)
>> >> >> >> >changes, and it doesn't seem productive for both of us to
be
>> >> >> >> >working on the same code making incompatible changes.
>> >> >> >> >
>> >> >> >> >So, do you want to take what you've done already and make
it
>> >> >> >> >work on Bobcat as well?  Or do you want me to continue to
>> >> >> >> >try and get
>> >> >> what
>> >> >> >> >I've got working on Bobcat?  Here is a current trace of
>> >> >> >> >output
>> >> I'm
>> >> >> >> >getting.
>> >> >> >> >
>> >> >> >> >OnStor Bobcat: Board Assembly Rev. A4
>> >> >> >> >
>> >> >> >> >NET: Registered protocol family 16
>> >> >> >> >per_cpu_mappings: mvmemregion.va_start =3D c0000000
>> >> >> >> >per_cpu_mappings: marvel_base=3Dbc000000
>> >> >> >> >bobcat_pci1_init: io_base =3D 0x18000000, io_size =3D =
0x800000
>> >> >> >> >bobcat_pci1_init: mem0_base =3D 0x1a000000, mem0_size =3D
>> 0x2000000
>> >> >> >> >bobcat_pci1_init: mem1_base =3D 0x19000000, mem1_size =3D
>> 0x1000000
>> >> >> >> >bobcat_pci1_init: mem2_base =3D 0x18800000, mem2_size =3D
>> >> >> >> >0x800000 bobcat_pci1_init: mem_base =3D 0x18800000, =
mem_size
>> >> >> >> >=3D 0x1800000 bobcat_pci1_init: mv_io_base =3D 0x0, =
mv_io_size
>> >> >> >> >=3D 0x0 bobcat_pci1_init: mv_io_base =3D 0x18000000, =
mv_io_size
>> >> >> >> >=3D 0x800000 bobcat_pci_init: pci io_v_base =3D 0xb8000000
>> >> >> >> >
>> >> >> >> >bobcat_pci_init: mips_io_port_base =3D 0xb8000000
>> >> >> >> >
>> >> >> >> >bobcat_pci_init: pci_probe_only=3D1
>> >> >> >> >Time: MIPS clocksource has been installed.
>> >> >> >> >
>> >> >> >> >i2c /dev entries driver
>> >> >> >> >MGMTBUS: registered net device mgmtbus @ c2000000 on irqs
>> >> >> >> >36, 38, 5 rcon device will be in the hizzy sizzy @ c20000e0
>> >> >> >> >TCP cubic registered
>> >> >> >> >NET: Registered protocol family 1
>> >> >> >> >NET: Registered protocol family 17
>> >> >> >> >NET: Registered protocol family 30
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >INIT: version 2.86 booting
>> >> >> >> >Starting the hotplug events dispatcher: udevd.
>> >> >> >> >Synthesizing the initial hotplug events...done.
>> >> >> >> >udevd-event[697]: rename_netif: error changing netif name
>> >> >> >> >eth0 to eth2: Device or resource busy
>> >> >> >> >Waiting for /dev to be fully populated...fp0:
>> >> >> >> >[dp_proxy_init]: pass
>> >> >> 1
>> >> >> >> >tx0: [dp_proxy_init]: pass 1
>> >> >> >> >fp0: pte_setup, region =3D 2, phys_offset =3D 0x20000000, =
virt
=3D
>> >> >> >> 0x2000000000,
>> >> >> >> >psize =3D 20000000, vsize =3D 20000000, pgsize =3D 8000000,
>> >> >> >> >readwrite_size =3D 0x20000000
>> >> >> >> >tx0: pte_setup, region =3D 4, phys_offset =3D 0x28000000, =
virt
=3D
>> >> >> >> 0x4000000000,
>> >> >> >> >psize =3D 18000000, vsize =3D 18000000, pgsize =3D 8000000,
>> >> >> >> >readwrite_size =3D 0x18000000
>> >> >> >> >tx0: pte_setup, region =3D 7, phys_offset =3D 0x28000000, =
virt
=3D
>> >> >> >> 0x7000000000,
>> >> >> >> >psize =3D 18000000, vsize =3D 18000000, pgsize =3D 8000000,
>> >> >> >> >readwrite_size =3D 0x18000000
>> >> >> >> >tx0: Zeroing the WKA area, 0x73000000
>> >> >> >> >fp0: pte_setup, region =3D 6, phys_offset =3D 0x20000000, =
virt
=3D
>> >> >> >> 0x6000000000,
>> >> >> >> >psize =3D 20000000, vsize =3D 20000000, pgsize =3D 8000000,
>> >> >> >> >readwrite_size =3D 0x20000000
>> >> >> >> >fp0: Zeroing the WKA area, 0x73000000
>> >> >> >> >fp0: unusable buffer, 0x4007fff800, phys_base =3D 9ffff800,
>> >> >> >> >phys_end =3D c0001a00
>> >> >> >> >done.
>> >> >> >> >Activating swap...done.
>> >> >> >> >fp0: [dp_proxy_init]: pass 2
>> >> >> >> >fp0: sb1250dm_initModule: sb1250dmCfg[0]=3D0x1000207e00
>> >> >> >> >fp0: sb1250dm_initModule: sb1250dmCfg[1]=3D0x1000207c80
>> >> >> >> >fp0: sb1250dm_initModule: sb1250dmCfg[2]=3D0x1000207b00
>> >> >> >> >fp0: sb1250dm_initModule: sb1250dmCfg[3]=3D0x1000207980
>> >> >> >> >fp0: esm_stackInit(): Enter
>> >> >> >> >fp0: esm_stackInit(): Leave
>> >> >> >> >fp0: bmc12500_install_allocators: install RUNTIME
allocators
>> >> >> >> >fp0: bmc12500Eth_initModule w/AUTO TX Retrans enabled
>> >> >> >> >fp0: bcm12500Eth_initModule SEQ RRX Retrans enabled
>> >> >> >> >fp0: isModel2280: Model 2220/40/60
>> >> >> >> >fp0: rmc: rmc_init(): RMC version 2.0.2 - myslot[1]
mycpu[2]
>> >> >> >> myapp_id[79]
>> >> >> >> >fp0: fs_initModule
>> >> >> >> >Setting the system clock..
>> >> >> >> >CPU 0 Unable to handle kernel paging request at virtual
>> address
>> >> >> >> 1a7004a0,
>> >> >> >> >epc =3D=3D 8316d90c, ra =3D=3D 8316d8fc
>> >> >> >> >Oops[#1]:
>> >> >> >> >Cpu 0
>> >> >> >> >$ 0   : 00000000 b000ef00 00000000 00000000
>> >> >> >> >$ 4   : fffffffe 832a2098 832a20b8 b000ef00
>> >> >> >> >$ 8   : ffffffba 00000000 00000000 00000000
>> >> >> >> >$12   : 00000020 00000006 00000003 0000006b
>> >> >> >> >$16   : 1a7004a0 835172c0 c00dd360 c00dd340
>> >> >> >> >$20   : 00000000 1a700480 c2000030 00000001
>> >> >> >> >$24   : 00000002 83002174
>> >> >> >> >$28   : 8fae0000 8fae1cf8 00000002 8316d8fc
>> >> >> >> >Hi    : 00000352
>> >> >> >> >Lo    : 000303a4
>> >> >> >> >epc   : 8316d90c mgmtbus_intr+0x174/0x22c     Not tainted
>> >> >> >> >ra    : 8316d8fc mgmtbus_intr+0x164/0x22c
>> >> >> >> >Status: b000ef03    KERNEL EXL IE
>> >> >> >> >Cause : 00001008
>> >> >> >> >BadVA : 1a7004a0
>> >> >> >> >PrId  : 00003440
>> >> >> >> >Modules linked in:
>> >> >> >> >Process hwclock (pid: 1344, threadinfo=3D8fae0000,
>> task=3D835bac00)
>> >> >> >> >Stack : b9000000 b9000000 fff9e586 ffffffff 8353d800
>> >> >> >> >00000000 00000000 00000001
>> >> >> >> >        00000026 00000000 00000000 00000000 00000000
>> >> >> >> > 8316ec6c 83290000
>> >> >> >> >00000000
>> >> >> >> >        8fae1d38 8fae1d38 8304891c 83298e2c 0000000a
>> >> >> >> > 832a0000 00000001
>> >> >> >> >8329a91c
>> >> >> >> >        83261d88 00000026 40247009 8fe73de0 00000001
>> >> >> >> > 8304a860 b000ef00
>> >> >> >> >8fae1e80
>> >> >> >> >        40247009 8fe73de0 00400000 8fae1e80 83000ed4
>> >> >> >> > 83026dfc 40247009
>> >> >> >> >8fe73de0
>> >> >> >> >        ...
>> >> >> >> >Call Trace:
>> >> >> >> >[<8316d90c>] mgmtbus_intr+0x174/0x22c
>> >> >> >> >[<8316ec6c>] mgmtbus_pci_intr+0x4c/0x70
>> >> >> >> >[<8304891c>] handle_IRQ_event+0x6c/0xcc
>> >> >> >> >[<8304a860>] handle_level_irq+0x90/0x130
>> >> >> >> >[<83000ed4>] ll_bc_mv64440_irq+0x120/0x1b0
>> >> >> >> >[<83002a14>] ret_from_irq+0x0/0x4
>> >> >> >> >[<83001494>] ds1511_get_rtctime+0xbc/0x1e4
>> >> >> >> >[<83002394>] ds1511_ioctl+0x220/0x42c
>> >> >> >> >[<83080e0c>] vfs_ioctl+0x6c/0x34c
>> >> >> >> >[<8308113c>] sys_ioctl+0x50/0x94
>> >> >> >> >[<8300a5e0>] stack_done+0x20/0x3c
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >On Fri, 2 Nov 2007 09:46:25 -0700 "Maxim Kozlovsky"
>> >> >> >> ><maxim.kozlovsky@onstor.com> wrote:
>> >> >> >> >
>> >> >> >> >> ... which is an indication that management traffic will
>> >> probably
>> >> >> >> >> work as well soon. If only fp and txrx stopped crashing,
>> >> >> >> >> we would find out if it does.
>> >> >> >> >>
>> >> >> >> >> starting periodic command scheduler: crond
>> >> >> >> >> mgmtbus_mailbox_intr
>> >> >> >> >> mgmtbus_mailbox_intr
>> >> >> >> >> rcon_intr
>> >> >> >> >> mgmtbus_mailbox_intr
>> >> >> >> >> rcon_intr
>> >> >> >> >> fp0: Autoreboot "off", stopping in debug mode
>> >> >> >> >> rcon_intr
>> >> >> >> >> tx0: Autoreboot "off", stopping in debug mode
>> >> >> >> >>
>> >> >> >> >> Debian GNU/Linux 4.0 cax duart0
>> >> >> >> >>
>> >> >> >> >> cax:~# rcon-new /dev/rcon0
>> >> >> >> >>
>> >> >> >> >> rcon_intr
>> >> >> >> >>
>> >> >> >> >> DEBUG-TXRX0:2 >
>> >> >> >> >> rcon_intr
>> >> >> >> >>
>> >> >> >> >> DEBUG-TXRX0:2 >
>> >> >> >> >> rcon_intr
>> >> >> >> >>
>> >> >> >> >> DEBUG-TXRX0:2 >
>> >> >> >> >> rcon_intr
