Schuppen und Augen

<M> EHCI HCD (USB 2.0) support 

Wie sinnvoll ist es, in einem Kernel, der via USB sein Bootdevice finden soll, die Low-Level-Treiber als Modul zu bauen? Narf, narf, narf ;)
Wie geht der Spruch? »Kaum macht man’s richtig, funktioniert’s«? :)

Uncompressing Linux.............................................................................................................................................................. done, booting the kernel.
Linux version 2.6.32.2 (wusel@greebo) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-68) ) #9 PREEMPT Wed Jun 16 20:44:08 CEST 2010
CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053177
[...]
Kernel command line: console=ttyS0,115200 root=/dev/sda1 rootdelay=10 rootfstype=ext2
[...]
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
orion-ehci orion-ehci.0: Marvell Orion EHCI
orion-ehci orion-ehci.0: new USB bus registered, assigned bus number 1
orion-ehci orion-ehci.0: irq 19, io mem 0xf1050000
orion-ehci orion-ehci.0: USB 2.0 started, EHCI 1.00
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
[...]
usb 1-1: new high speed USB device using orion-ehci and address 2
usb 1-1: configuration #1 chosen from 1 choice
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
usb 1-1.4: new high speed USB device using orion-ehci and address 3
rtc-mv rtc-mv: internal RTC not ticking
[...]
Waiting 10sec before mounting root device...
scsi 0:0:0:0: Direct-Access A60C0709 Flash Disk 8.07 PQ: 0 ANSI: 2
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:0:0: [sda] 2048000 512-byte logical blocks: (1.04 GB/1000 MiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] Assuming drive cache: write through
sda: sda1 sda3
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] Attached SCSI removable disk
EXT2-fs: sda1: couldn't mount because of unsupported optional features (4).
List of all partitions:
1f00 1024 mtdblock0 (driver?)
1f01 4096 mtdblock1 (driver?)
1f02 32768 mtdblock2 (driver?)
1f03 224256 mtdblock3 (driver?)
0800 1024000 sda driver: sd
0801 805169 sda1
0803 218410 sda3
No filesystem could mount root, tried: ext2
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)
[<c002b9fc>] (unwind_backtrace+0x0/0xdc) from [<c0383e4c>] (panic+0x58/0x12c)
[<c0383e4c>] (panic+0x58/0x12c) from [<c0008ec8>] (mount_block_root+0x1c8/0x208)
[<c0008ec8>] (mount_block_root+0x1c8/0x208) from [<c000911c>] (prepare_namespace+0x120/0x178)
[<c000911c>] (prepare_namespace+0x120/0x178) from [<c00085bc>] (kernel_init+0xdc/0x110)
[<c00085bc>] (kernel_init+0xdc/0x110) from [<c0027444>] (kernel_thread_exit+0x0/0x8)

Na, ok, fast ;) ext2 ankündigen, ext3 liefern ist ja auch unfair, irgendwie …

Why I don't belive in the PSU being the problem in SheevaPlugs

There is some discussion going on regarding dead SheevaPlug-PSUs, reworked PSUs for the new GuruPlug and why Sheevas and Gurus are dying more and more frequently the older (talking about weeks here) they get.
Personally, I own two SheevaPlugs, one purchased by mid-December 2009, the other one was delivered around January 2010. Well, both PSUs already died, in both it’s the same capacitor in the PSU that shows visual anomalies. And because of what I’ve seen after opening the PSUs, I personally don’t expect a replacement PSU to last much longer than 3 to 6 months each :(
From what can be learned from the issues of the GuuPlug, it’s not the PSU which heats up the box but the CPU; therefore I suspect, as SheevaPlug is built in some way similar to GuruPlug, that it’s the CPU which is literally frying the components of the PSU — until they finally give up and die. Thus, a replacement PSU would be boiled as well — and at least according to German law, 6 months after purchase it’s the customer who has to bring prove that a defect was there at the time of purchase to claim replacements free of charge …

So, what to do? The most sensible thing to do right now, in my opinion, would be to address the (European) seller asking for a full refund both on SheevaPlugs as well as GuruPlugs, as they are proven to be unfit for the duty intended; they might not last longer that 3-6 months until burnung out — which was not advertized back then …
If you actually use them, your situation might be different; in that case, I’d request a preload of PSU replacements for the usual time electronic devices work/ran/stay usable, based on my experience I’ll need a new PSU every 3rd to 4th month, i. e. four per year. Thinking about using the SheevaPlugs for 4 to 5 years, I’d need a supply of 16 to 20 in total per Sheeva … And maybe I’d still lrequest a partial refund due to the lack of usability during each PSU failure and the time I need to spend replacing PSUs myself …
To be honest: I strongly assume that, if checked before Marketing started, they wouldn’t be allowed to be distributed within th EU at all, with all that heat and the heated PSU becoming a risk of fire …

(Edited: Some typos corrected.)