Newer kernel for N4100?

[Bill Gatliff]

Guys:


Simultaneous with latest dist-upgrade, my N4100's RAID5 array went south (by
now, you'd think I would have learned to not mess with what wasn't broke).  I
don't know if there's a connection, but two simultaneous drive "failures"
without warning have me feeling somewhat suspicious about a false-positive.
Anyway...

Now I have to figure out how to stand this box back up, hopefully without losing
the data on the array (some of which would be a _major_ pain to recover).
Suggestions are more than welcome, and will be reciprocated with the beverages
of your choice.  :)

My strategy at the moment is to debootstrap an arm tree on an NFS server, and
use that as my rootfs while I sort out my md problems.

Anyone know of a recent kernel for the n4100?  I was using the 2.6.17.8 sources
from wpkg.org, which are a bit out of date.  Is anyone else paying any attention
to this platform?

I am, but perhaps not for much longer... :(


b.g.
--
Bill Gatliff
bgat@...


--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Riku Voipio-2]

On Sat, Jul 12, 2008 at 10:49:09AM -0500, Bill Gatliff wrote:
> Anyone know of a recent kernel for the n4100?  I was using the 2.6.17.8 sources
> from wpkg.org, which are a bit out of date.  Is anyone else paying any attention
> to this platform?

What patches does the "wpkg.org 2.6.17.8" add to the kernel? Are these
in mainline kernels already? If they are, the -iop32x kernel should
probably work just fine. If they are not, it should not be a big job.
N4100 is almost identical to n2100. Similar enough that it would be
a pity if support were lost. However, it needs someone with the actual
hardware to make it possible.




--
"rm -rf" only sounds scary if you don't have backups

[Bill Gatliff]

Riku Voipio wrote:

> On Sat, Jul 12, 2008 at 10:49:09AM -0500, Bill Gatliff wrote:
>> Anyone know of a recent kernel for the n4100?  I was using the 2.6.17.8 sources
>> from wpkg.org, which are a bit out of date.  Is anyone else paying any attention
>> to this platform?
>
> What patches does the "wpkg.org 2.6.17.8" add to the kernel? Are these
> in mainline kernels already? If they are, the -iop32x kernel should
> probably work just fine. If they are not, it should not be a big job.
> N4100 is almost identical to n2100. Similar enough that it would be
> a pity if support were lost. However, it needs someone with the actual
> hardware to make it possible.

I just built mainline 2.6.26 with iop32x_defconfig and arm-linux-gnueabi-gcc
(GCC) 4.2.4 (Debian 4.2.4-2).  Booting on my n4100, I get this:

RedBoot> exec -c "console=ttyS0,115200 mem=256M@0xa0000000 panic=5 root=nfs
nfsroot=192.168.2.10:/exports/arm
ip=192.168.2.8:192.168.2.10:192.168.2.1:255.255.255.0:n4100:eth0:off init=/bin/sh"
Using base address 0x00200000 and length 0x00200594
i82544_stop
i82544_stop 0 flg 17
Uncompressing Linux...............................................................
..................................................................... done,
booting the kernel.
Linux version 2.6.26 (bgat@mercury) (gcc version 4.2.4 (Debian 4.2.4-2)) #9 Mon
Jul 14 11:41:31 CDT 2008
CPU: XScale-80219 [69052e30] revision 0 (ARMv5TE), cr=0000397f
Machine: Intel IQ31244
...
scsi0 : sata_vsc
scsi1 : sata_vsc
scsi2 : sata_vsc
scsi3 : sata_vsc
ata1: SATA max UDMA/133 mmio m4096@0x80080000 port 0x80080200 irq 27
ata2: SATA max UDMA/133 mmio m4096@0x80080000 port 0x80080400 irq 27
ata3: SATA max UDMA/133 mmio m4096@0x80080000 port 0x80080600 irq 27
ata4: SATA max UDMA/133 mmio m4096@0x80080000 port 0x80080800 irq 27
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: qc timeout (cmd 0x27)
ata1.00: failed to read native max address (err_mask=0x4)
ata1.00: HPA support seems broken, skipping HPA handling
ata1: failed to recover some devices, retrying in 5 secs
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: configured for UDMA/100
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: qc timeout (cmd 0x27)
ata2.00: failed to read native max address (err_mask=0x4)
ata2.00: HPA support seems broken, skipping HPA handling
ata2: failed to recover some devices, retrying in 5 secs
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: configured for UDMA/100
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: qc timeout (cmd 0x27)
ata3.00: failed to read native max address (err_mask=0x4)
ata3.00: HPA support seems broken, skipping HPA handling
ata3: failed to recover some devices, retrying in 5 secs
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: configured for UDMA/100
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata4.00: qc timeout (cmd 0x27)
ata4.00: failed to read native max address (err_mask=0x4)
ata4.00: HPA support seems broken, skipping HPA handling
ata4: failed to recover some devices, retrying in 5 secs
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata4.00: configured for UDMA/100
scsi 0:0:0:0: Direct-Access     ATA      WDC WD3000JD-00K 08.0 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 586072368 512-byte hardware sectors (300069 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
sd 0:0:0:0: [sda] 586072368 512-byte hardware sectors (300069 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
 sda:<3>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: hard resetting link
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: configured for UDMA/100
...
...
...

It repeats this over and over and over again, as far as I can tell it tries
UDMA/133, then UDMA/100, ... until it gets to UDMA/33.  For each device.  It
takes an *age*.

After that, it apparently gives up and moves through the rest of the boot
process (which I haven't finished yet--- I had to restart because I forgot the
ip= parameter needed for nfsroot).

Interestingly, the above does contain the right information for the drive(s) in
question: WDC WD3000JD-00K.  So the drives are at least still talking.

Not knowing much about SATA, though, I can't tell what all the above means---
either for the kernel's functionality on this platform, or the health of the
drives running in it.


b.g.
--
Bill Gatliff
bgat@...


--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Arnaud Patard (Rtp)]

Bill Gatliff <bgat@...> writes:

Hi,

> Riku Voipio wrote:
>> On Sat, Jul 12, 2008 at 10:49:09AM -0500, Bill Gatliff wrote:
>>> Anyone know of a recent kernel for the n4100?  I was using the 2.6.17.8 sources
>>> from wpkg.org, which are a bit out of date.  Is anyone else paying any attention
>>> to this platform?
>>
>> What patches does the "wpkg.org 2.6.17.8" add to the kernel? Are these
>> in mainline kernels already? If they are, the -iop32x kernel should
>> probably work just fine. If they are not, it should not be a big job.
>> N4100 is almost identical to n2100. Similar enough that it would be
>> a pity if support were lost. However, it needs someone with the actual
>> hardware to make it possible.
>
> I just built mainline 2.6.26 with iop32x_defconfig and arm-linux-gnueabi-gcc
> (GCC) 4.2.4 (Debian 4.2.4-2).  Booting on my n4100, I get this:
>
> RedBoot> exec -c "console=ttyS0,115200 mem=256M@0xa0000000 panic=5 root=nfs
> nfsroot=192.168.2.10:/exports/arm
> ip=192.168.2.8:192.168.2.10:192.168.2.1:255.255.255.0:n4100:eth0:off init=/bin/sh"
> Using base address 0x00200000 and length 0x00200594
> i82544_stop
> i82544_stop 0 flg 17
> Uncompressing Linux...............................................................
> ..................................................................... done,
> booting the kernel.
> Linux version 2.6.26 (bgat@mercury) (gcc version 4.2.4 (Debian 4.2.4-2)) #9 Mon
> Jul 14 11:41:31 CDT 2008
> CPU: XScale-80219 [69052e30] revision 0 (ARMv5TE), cr=0000397f
> Machine: Intel IQ31244

IQ31244 ? Looks weird. I wouldn't be surprised that the vendor kept
IQ31244 machine id in redboot but did some incompatible changes.

> ...
> scsi0 : sata_vsc
> scsi1 : sata_vsc
> scsi2 : sata_vsc
> scsi3 : sata_vsc
> ata1: SATA max UDMA/133 mmio m4096@0x80080000 port 0x80080200 irq 27
> ata2: SATA max UDMA/133 mmio m4096@0x80080000 port 0x80080400 irq 27
> ata3: SATA max UDMA/133 mmio m4096@0x80080000 port 0x80080600 irq 27
> ata4: SATA max UDMA/133 mmio m4096@0x80080000 port 0x80080800 irq 27
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: qc timeout (cmd 0x27)
> ata1.00: failed to read native max address (err_mask=0x4)
> ata1.00: HPA support seems broken, skipping HPA handling
> ata1: failed to recover some devices, retrying in 5 secs

"qc timeout" is a good sign that there's something wrong
somewhere. I'm far from being a sata dev but iirc, this may be caused by
things like :
- wrong i/o address
- wrong irq
- wrong irq and i/o address

It would  be interesting to see a boot log or 'lspci -v' with a working
kernel (in case you have it somewhere on a harddrive). One can try to
find what's wrong with a working kernel source  but it'll be harder to
than reading a kernel boot log.


Arnaud


--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Riku Voipio-2]

On Mon, Jul 14, 2008 at 12:35:21PM -0500, Bill Gatliff wrote:
> I just built mainline 2.6.26 with iop32x_defconfig and arm-linux-gnueabi-gcc
> (GCC) 4.2.4 (Debian 4.2.4-2).  Booting on my n4100, I get this:

> RedBoot> exec -c "console=ttyS0,115200 mem=256M@0xa0000000 panic=5 root=nfs
> nfsroot=192.168.2.10:/exports/arm
> ip=192.168.2.8:192.168.2.10:192.168.2.1:255.255.255.0:n4100:eth0:off init=/bin/sh"
> Using base address 0x00200000 and length 0x00200594
> i82544_stop
> i82544_stop 0 flg 17
> Uncompressing Linux...............................................................
> ..................................................................... done,
> booting the kernel.
> Linux version 2.6.26 (bgat@mercury) (gcc version 4.2.4 (Debian 4.2.4-2)) #9 Mon
> Jul 14 11:41:31 CDT 2008
> CPU: XScale-80219 [69052e30] revision 0 (ARMv5TE), cr=0000397f
> Machine: Intel IQ31244

Thats probable the wrong machine. Try prependig the N2100 machine-id
for fixups.

devio > vmlinuz 'wl 0xe3a01c04,4' 'wl 0xe381104d,4'
cat arch/arm/boot/zImage >> vmlinuz

> ...
> scsi0 : sata_vsc
> scsi1 : sata_vsc
> scsi2 : sata_vsc
> scsi3 : sata_vsc

n2100 is sata_sil, so the device is more different from N2100 than I
thought. actually, IQ31244 has sata_vsc, so perhaps thats more correct
after all...

> ata1: SATA max UDMA/133 mmio m4096@0x80080000 port 0x80080200 irq 27
> ata2: SATA max UDMA/133 mmio m4096@0x80080000 port 0x80080400 irq 27
> ata3: SATA max UDMA/133 mmio m4096@0x80080000 port 0x80080600 irq 27
> ata4: SATA max UDMA/133 mmio m4096@0x80080000 port 0x80080800 irq 27
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: qc timeout (cmd 0x27)
> ata1.00: failed to read native max address (err_mask=0x4)
> ata1.00: HPA support seems broken, skipping HPA handling
> ata1: failed to recover some devices, retrying in 5 secs
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: configured for UDMA/100
> ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata2.00: qc timeout (cmd 0x27)
> ata2.00: failed to read native max address (err_mask=0x4)
> ata2.00: HPA support seems broken, skipping HPA handling
> ata2: failed to recover some devices, retrying in 5 secs
> ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata2.00: configured for UDMA/100
> ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata3.00: qc timeout (cmd 0x27)
> ata3.00: failed to read native max address (err_mask=0x4)
> ata3.00: HPA support seems broken, skipping HPA handling
> ata3: failed to recover some devices, retrying in 5 secs
> ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata3.00: configured for UDMA/100
> ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata4.00: qc timeout (cmd 0x27)
> ata4.00: failed to read native max address (err_mask=0x4)
> ata4.00: HPA support seems broken, skipping HPA handling
> ata4: failed to recover some devices, retrying in 5 secs
> ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata4.00: configured for UDMA/100
> scsi 0:0:0:0: Direct-Access     ATA      WDC WD3000JD-00K 08.0 PQ: 0 ANSI: 5
> sd 0:0:0:0: [sda] 586072368 512-byte hardware sectors (300069 MB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO
> or FUA
> sd 0:0:0:0: [sda] 586072368 512-byte hardware sectors (300069 MB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO
> or FUA
>  sda:<3>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
>          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: hard resetting link
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: configured for UDMA/100
> ...
> ...
> ...
>
> It repeats this over and over and over again, as far as I can tell it tries
> UDMA/133, then UDMA/100, ... until it gets to UDMA/33.  For each device.  It
> takes an *age*.
>
> After that, it apparently gives up and moves through the rest of the boot
> process (which I haven't finished yet--- I had to restart because I forgot the
> ip= parameter needed for nfsroot).
>
> Interestingly, the above does contain the right information for the drive(s) in
> question: WDC WD3000JD-00K.  So the drives are at least still talking.
>
> Not knowing much about SATA, though, I can't tell what all the above means---
> either for the kernel's functionality on this platform, or the health of the
> drives running in it.

perhaps you'll want to ask the sata_vsc author. another possibility is
that the pci IRQ map is wrong and the driver isn't recieving interrupts
from the sata controller.

overall seems quite promising. contrast: with the default IQ31244 confing
n2100 dies when probing for second i2c controller :)

--
"rm -rf" only sounds scary if you don't have backups


--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bill Gatliff]

Riku Voipio wrote:

>
> perhaps you'll want to ask the sata_vsc author. another possibility is
> that the pci IRQ map is wrong and the driver isn't recieving interrupts
> from the sata controller.

Here is lspci -vvv output.  See anything?  Looks like the PCI-X SATA HBA is tied
to IRQ 29.  Not sure what to do with that information, though...


b.g.
--
Bill Gatliff
bgat@...

00:01.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)
        Subsystem: Intel Corporation 82541GI Gigabit Ethernet Controller
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 68 (63750ns min), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 27
        Region 0: Memory at 80000000 (64-bit, non-prefetchable) [size=128K]
        Region 2: Memory at 80040000 (64-bit, non-prefetchable) [size=64K]
        Region 4: I/O ports at fe000000 [size=64]
        [virtual] Expansion ROM at 80050000 [disabled] [size=64K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [e4] PCI-X non-bridge device
                Command: DPERE- ERO+ RBC=512 OST=1
                Status: Dev=00:00.0 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC=2048 DMOST=1 DMCRS=8 RSCEM- 266MHz- 533MHz-
        Capabilities: [f0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
                Address: 0000000000000000  Data: 0000
        Kernel driver in use: e1000

00:02.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)
        Subsystem: Intel Corporation 82541GI Gigabit Ethernet Controller
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 68 (63750ns min), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 30
        Region 0: Memory at 80020000 (64-bit, non-prefetchable) [size=128K]
        Region 2: Memory at 80060000 (64-bit, non-prefetchable) [size=64K]
        Region 4: I/O ports at fe000040 [size=64]
        [virtual] Expansion ROM at 80070000 [disabled] [size=64K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [e4] PCI-X non-bridge device
                Command: DPERE- ERO+ RBC=512 OST=1
                Status: Dev=00:00.0 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC=2048 DMOST=1 DMCRS=8 RSCEM- 266MHz- 533MHz-
        Capabilities: [f0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
                Address: 0000000000000000  Data: 0000
        Kernel driver in use: e1000

00:03.0 SATA controller: Intel Corporation GD31244 PCI-X SATA HBA
        Subsystem: Intel Corporation GD31244 PCI-X SATA HBA
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0 (4000ns min, 250ns max), Cache Line Size: 512 bytes
        Interrupt: pin A routed to IRQ 29
        Region 0: Memory at 80080000 (64-bit, non-prefetchable) [size=4K]
        Capabilities: [e0] PCI-X non-bridge device
                Command: DPERE- ERO+ RBC=512 OST=4
                Status: Dev=00:00.0 64bit- 133MHz+ SCD- USC- DC=simple DMMRBC=512 DMOST=4 DMCRS=16 RSCEM- 266MHz- 533MHz-
        Capabilities: [e8] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [f0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/2 Enable-
                Address: 0000000000000000  Data: 0000
        Kernel driver in use: sata_vsc

[Arnaud Patard (Rtp)]

Bill Gatliff <bgat@...> writes:

Hi,

> Riku Voipio wrote:
>
>>
>> perhaps you'll want to ask the sata_vsc author. another possibility is
>> that the pci IRQ map is wrong and the driver isn't recieving interrupts
>> from the sata controller.
>
> Here is lspci -vvv output.  See anything?  Looks like the PCI-X SATA HBA is tied
> to IRQ 29.  Not sure what to do with that information, though...

Well, this information confirms what we were expecting. The iq31244
doesn't have the same irq than the n4100. [ On the boot log
you sent previously, the irq assigned to the sata controller is 27
instead of 29 ].

Did you try what was suggested in
http://lists.debian.org/debian-arm/2008/07/msg00016.html ?

Arnaud


--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bill Gatliff]

Riku Voipio wrote:

> On Mon, Jul 14, 2008 at 12:35:21PM -0500, Bill Gatliff wrote:
>> I just built mainline 2.6.26 with iop32x_defconfig and arm-linux-gnueabi-gcc
>> (GCC) 4.2.4 (Debian 4.2.4-2).  Booting on my n4100, I get this:
>
>> RedBoot> exec -c "console=ttyS0,115200 mem=256M@0xa0000000 panic=5 root=nfs
>> nfsroot=192.168.2.10:/exports/arm
>> ip=192.168.2.8:192.168.2.10:192.168.2.1:255.255.255.0:n4100:eth0:off init=/bin/sh"
>> Using base address 0x00200000 and length 0x00200594
>> i82544_stop
>> i82544_stop 0 flg 17
>> Uncompressing Linux...............................................................
>> ..................................................................... done,
>> booting the kernel.
>> Linux version 2.6.26 (bgat@mercury) (gcc version 4.2.4 (Debian 4.2.4-2)) #9 Mon
>> Jul 14 11:41:31 CDT 2008
>> CPU: XScale-80219 [69052e30] revision 0 (ARMv5TE), cr=0000397f
>> Machine: Intel IQ31244
>
> Thats probable the wrong machine. Try prependig the N2100 machine-id
> for fixups.
>
> devio > vmlinuz 'wl 0xe3a01c04,4' 'wl 0xe381104d,4'
> cat arch/arm/boot/zImage >> vmlinuz

Finally got around to trying this out (it's been a rough summer), this time on
2.6.27-rc5.  It definitely changes things:

...
scsi0 : sata_vsc
scsi1 : sata_vsc
scsi2 : sata_vsc
scsi3 : sata_vsc
ata1: SATA max UDMA/133 mmio m4096@0x80080000 port 0x80080200 irq 29
ata2: SATA max UDMA/133 mmio m4096@0x80080000 port 0x80080400 irq 29
ata3: SATA max UDMA/133 mmio m4096@0x80080000 port 0x80080600 irq 29
ata4: SATA max UDMA/133 mmio m4096@0x80080000 port 0x80080800 irq 29
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-6: WDC WD3000JD-00KLB0, 08.05J08, max UDMA/100
ata1.00: 586072368 sectors, multi 0: LBA48
ata1.00: configured for UDMA/100
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: ATA-6: WDC WD3000JD-00KLB0, 08.05J08, max UDMA/100
ata2.00: 586072368 sectors, multi 0: LBA48
ata2.00: configured for UDMA/100
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: ATA-6: WDC WD3000JD-00KLB0, 08.05J08, max UDMA/100
ata3.00: 586072368 sectors, multi 0: LBA48
ata3.00: configured for UDMA/100
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata4.00: ATA-6: WDC WD3000JD-00KLB0, 08.05J08, max UDMA/100
ata4.00: 586072368 sectors, multi 0: LBA48
ata4.00: configured for UDMA/100
scsi 0:0:0:0: Direct-Access     ATA      WDC WD3000JD-00K 08.0 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 586072368 512-byte hardware sectors (300069 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
sd 0:0:0:0: [sda] 586072368 512-byte hardware sectors (300069 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
 sda: sda1 sda2
sd 0:0:0:0: [sda] Attached SCSI disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
scsi 1:0:0:0: Direct-Access     ATA      WDC WD3000JD-00K 08.0 PQ: 0 ANSI: 5
sd 1:0:0:0: [sdb] 586072368 512-byte hardware sectors (300069 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
sd 1:0:0:0: [sdb] 586072368 512-byte hardware sectors (300069 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
 sdb: sdb1 sdb2
sd 1:0:0:0: [sdb] Attached SCSI disk
sd 1:0:0:0: Attached scsi generic sg1 type 0
scsi 2:0:0:0: Direct-Access     ATA      WDC WD3000JD-00K 08.0 PQ: 0 ANSI: 5
sd 2:0:0:0: [sdc] 586072368 512-byte hardware sectors (300069 MB)
sd 2:0:0:0: [sdc] Write Protect is off
sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
sd 2:0:0:0: [sdc] 586072368 512-byte hardware sectors (300069 MB)
sd 2:0:0:0: [sdc] Write Protect is off
sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
 sdc: sdc1 sdc2
sd 2:0:0:0: [sdc] Attached SCSI disk
sd 2:0:0:0: Attached scsi generic sg2 type 0
scsi 3:0:0:0: Direct-Access     ATA      WDC WD3000JD-00K 08.0 PQ: 0 ANSI: 5
sd 3:0:0:0: [sdd] 586072368 512-byte hardware sectors (300069 MB)
sd 3:0:0:0: [sdd] Write Protect is off
sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
sd 3:0:0:0: [sdd] 586072368 512-byte hardware sectors (300069 MB)
sd 3:0:0:0: [sdd] Write Protect is off
sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
 sdd: sdd1 sdd2
sd 3:0:0:0: [sdd] Attached SCSI disk
sd 3:0:0:0: Attached scsi generic sg3 type 0
physmap platform flash device: 01000000 at f0000000
physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
 Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
cmdlinepart partition parsing not available
Searching for RedBoot partition table in physmap-flash.0 at offset 0xfe0000
7 RedBoot partitions found on MTD device physmap-flash.0
Creating 7 MTD partitions on "physmap-flash.0":
0x00000000-0x00040000 : "RedBoot"
0x00040000-0x001c0000 : "zImage"
0x001c0000-0x00d40000 : "unallocated"
0x00d40000-0x00ea0000 : "kernel"
0x00ea0000-0x00fc0000 : "unallocated"
0x00fc0000-0x00fc1000 : "RedBoot config"
0x00fe0000-0x01000000 : "FIS directory"
usbmon: debugfs is not available
USB Universal Host Controller Interface driver v3.0
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
mice: PS/2 mouse device common for all mice
i2c /dev entries driver
rtc-rs5c372 0-0032: rs5c372b found, 24hr, driver version 0.5
rtc-rs5c372 0-0032: rtc core: registered rtc-rs5c372 as rtc0
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
md: raid10 personality registered for level 10
raid6: int32x1     55 MB/s
raid6: int32x2     52 MB/s
raid6: int32x4     50 MB/s
raid6: int32x8     42 MB/s
raid6: using algorithm int32x1 (55 MB/s)
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@...
iop-adma iop-adma.0: Intel(R) IOP: ( cpy intr )
iop-adma iop-adma.1: Intel(R) IOP: ( cpy intr )
TCP cubic registered
NET: Registered protocol family 10
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
XScale DSP coprocessor detected.
rtc-rs5c372 0-0032: setting system clock to 2038-09-09 12:47:59 UTC (2167649279)
IP-Config: Failed to open eth0
IP-Config: Device `eth0' not found.
md: Autodetecting RAID arrays.
md: Scanned 4 and added 4 devices.
md: autorun ...
md: considering sdd2 ...
md:  adding sdd2 ...
md:  adding sdc2 ...
md:  adding sdb2 ...
md:  adding sda2 ...
md: created md0
md: bind<sda2>
md: bind<sdb2>
md: bind<sdc2>
md: bind<sdd2>
md: running: <sdd2><sdc2><sdb2><sda2>
raid5: device sdd2 operational as raid disk 3
raid5: device sdc2 operational as raid disk 2
raid5: device sdb2 operational as raid disk 1
raid5: device sda2 operational as raid disk 0
raid5: allocated 4201kB for md0
raid5: raid level 5 set md0 active with 4 out of 4 devices, algorithm 2
RAID5 conf printout:
 --- rd:4 wd:4
 disk 0, o:1, dev:sda2
 disk 1, o:1, dev:sdb2
 disk 2, o:1, dev:sdc2
 disk 3, o:1, dev:sdd2
md: ... autorun DONE.
...


So now the kernel is very happy talking to the drives, apparently.  But it
doesn't like the e1000's:

...
Intel(R) PRO/1000 Network Driver - version 7.3.20-k3-NAPI
Copyright (c) 1999-2006 Intel Corporation.
e1000: 0000:00:01.0: e1000_probe: The EEPROM Checksum Is Not Valid
/*********************/
Current EEPROM Checksum : 0xffff
Calculated              : 0xbaf9
Offset    Values
========  ======
00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Include this output when contacting your support provider.
This is not a software error! Something bad happened to your hardware or
EEPROM image. Ignoring this problem could result in further problems,
possibly loss of data, corruption or system hangs!
The MAC Address will be reset to 00:00:00:00:00:00, which is invalid
and requires you to set the proper MAC address manually before continuing
to enable this network device.
Please inspect the EEPROM dump and report the issue to your hardware vendor
or Intel Customer Support.
/*********************/
e1000: 0000:00:01.0: e1000_probe: Invalid MAC Address
e1000: 0000:00:01.0: e1000_probe: (PCI:33MHz:32-bit) 00:00:00:00:00:00
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: 0000:00:02.0: e1000_probe: The EEPROM Checksum Is Not Valid
/*********************/
Current EEPROM Checksum : 0xffff
Calculated              : 0xbaf9
Offset    Values
========  ======
00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Include this output when contacting your support provider.
This is not a software error! Something bad happened to your hardware or
EEPROM image. Ignoring this problem could result in further problems,
possibly loss of data, corruption or system hangs!
The MAC Address will be reset to 00:00:00:00:00:00, which is invalid
and requires you to set the proper MAC address manually before continuing
to enable this network device.
Please inspect the EEPROM dump and report the issue to your hardware vendor
or Intel Customer Support.
/*********************/
e1000: 0000:00:02.0: e1000_probe: Invalid MAC Address
e1000: 0000:00:02.0: e1000_probe: (PCI:33MHz:32-bit) 00:00:00:00:00:00
e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
...


That makes it tough to do root-over-NFS, which is how I was planning on running
the installer.  :)

I found in the .17 kernel where Thecus commented out the EEPROM checksum test in
the e1000 driver, I'm going to do the same and see what happens.  My first
attempt caused the code to load all ff's for the MAC, which obviously isn't what
I want.

Lennert allocated a machid for the N4100.  I guess at some point, I need to
clone the n2100 board code and continue from there...




b.g.
--
Bill Gatliff
bgat@...


--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bill Gatliff]

Bill Gatliff wrote:

> I found in the .17 kernel where Thecus commented out the EEPROM checksum test in
> the e1000 driver, I'm going to do the same and see what happens.  My first
> attempt caused the code to load all ff's for the MAC, which obviously isn't what
> I want.

... and this patch is sooooo bad, I hesitate to post it.  But if I don't, I'll
lose it myself!  :)


diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index ad6da7b..9a2a65a 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1064,6 +1064,7 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
        /* before reading the EEPROM, reset the controller to
         * put the device in a known good starting state */

+#if 0
        e1000_reset_hw(hw);

        /* make sure the EEPROM is good */
@@ -1080,10 +1081,21 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
                 */
                memset(hw->mac_addr, 0, netdev->addr_len);
        } else {
                /* copy the MAC address out of the EEPROM */
                if (e1000_read_mac_addr(hw))
                        DPRINTK(PROBE, ERR, "EEPROM Read Error\n");
        }
+#else
+#warning "TODO: Figure out how to deal with EEPROM checksum on N4100"
+       static int mac_seed = 0x8a;
+       hw->mac_addr[0] = 0;
+       hw->mac_addr[1] = 0x14;
+       hw->mac_addr[2] = 0xfd;
+       hw->mac_addr[3] = 0x10;
+       hw->mac_addr[4] = 0x11;
+       hw->mac_addr[5] = mac_seed++;
+#endif
        /* don't block initalization here due to bad MAC address */
        memcpy(netdev->dev_addr, hw->mac_addr, netdev->addr_len);
        memcpy(netdev->perm_addr, hw->mac_addr, netdev->addr_len);



b.g.
--
Bill Gatliff
bgat@...


--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Martin Michlmayr]

* Bill Gatliff <bgat@...> [2008-09-08 14:30]:
> So now the kernel is very happy talking to the drives, apparently.  But it
> doesn't like the e1000's:

I thought you were aware of this, but in case you're not: Thecus
removed the EEPROM from both i82541 chips and stored the MAC address
in the RedBoot configuration area.

--
Martin Michlmayr
http://www.cyrius.com/


--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Peter Korsgaard]

>>>>> "Bill" == Bill Gatliff <bgat@...> writes:

Hi,

 Bill> ... and this patch is sooooo bad, I hesitate to post it.  But
 Bill> if I don't, I'll lose it myself!  :)

;)

 Bill> +#else
 Bill> +#warning "TODO: Figure out how to deal with EEPROM checksum on N4100"
 Bill> +       static int mac_seed = 0x8a;
 Bill> +       hw->mac_addr[0] = 0;
 Bill> +       hw->mac_addr[1] = 0x14;
 Bill> +       hw->mac_addr[2] = 0xfd;
 Bill> +       hw->mac_addr[3] = 0x10;
 Bill> +       hw->mac_addr[4] = 0x11;
 Bill> +       hw->mac_addr[5] = mac_seed++;

You could atlest use random_ether_addr().

--
Bye, Peter Korsgaard


--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bill Gatliff]

Martin Michlmayr wrote:
> * Bill Gatliff <bgat@...> [2008-09-08 14:30]:
>> So now the kernel is very happy talking to the drives, apparently.  But it
>> doesn't like the e1000's:
>
> I thought you were aware of this, but in case you're not: Thecus
> removed the EEPROM from both i82541 chips and stored the MAC address
> in the RedBoot configuration area.
>

Yep.  The head-scratching part is figuring out a way to tell the e1000 driver to
keep the MAC that's already programmed.  I don't see a robust, convenient way to
do that with the existing driver.


b.g.
--
Bill Gatliff
bgat@...


--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bill Gatliff]

Peter Korsgaard wrote:

>>>>>> "Bill" == Bill Gatliff <bgat@...> writes:
>
> Hi,
>
>  Bill> ... and this patch is sooooo bad, I hesitate to post it.  But
>  Bill> if I don't, I'll lose it myself!  :)
>
> ;)
>
>  Bill> +#else
>  Bill> +#warning "TODO: Figure out how to deal with EEPROM checksum on N4100"
>  Bill> +       static int mac_seed = 0x8a;
>  Bill> +       hw->mac_addr[0] = 0;
>  Bill> +       hw->mac_addr[1] = 0x14;
>  Bill> +       hw->mac_addr[2] = 0xfd;
>  Bill> +       hw->mac_addr[3] = 0x10;
>  Bill> +       hw->mac_addr[4] = 0x11;
>  Bill> +       hw->mac_addr[5] = mac_seed++;
>
> You could atlest use random_ether_addr().

That would definitely be a more generic solution.  :)

I'm trying to avoid the sudden change in MAC address that the other network
members would suddenly see, and the ARP cache trashing that it would cause
(which is a problem for root-over-NFS, at least).  My patch obviously isn't the
answer, either.


b.g.
--
Bill Gatliff
bgat@...


--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Riku Voipio-2]

On Tue, Sep 09, 2008 at 06:20:47AM -0500, Bill Gatliff wrote:
> Martin Michlmayr wrote:
> > * Bill Gatliff <bgat@...> [2008-09-08 14:30]:
> >> So now the kernel is very happy talking to the drives, apparently.  But it
> >> doesn't like the e1000's:

> > I thought you were aware of this, but in case you're not: Thecus
> > removed the EEPROM from both i82541 chips and stored the MAC address
> > in the RedBoot configuration area.

> Yep.  The head-scratching part is figuring out a way to tell the e1000 driver to
> keep the MAC that's already programmed.  I don't see a robust, convenient way to
> do that with the existing driver.

Perhaps the e1000 driver developers have a idea howto support cleanly
e1000 devices on embedded systems without eeprom?

--
"rm -rf" only sounds scary if you don't have backups


--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...