Breezy Kernel 2.6.12 boot failure on JetWay A210GDMS-Pro

After a little googling and discovering the inner workings of initramfs, I
believe I've isolated the cause of my troubles. Apparently, it's the sata_uli
driver causing the hang-- when modprobed, after discovering the attached hard
drive, it just sits there forever.

(apologies for the spam)
If it's any help, here's what lspci -vv has to say about my SATA controller, at
least under 2.6.10:

0000:00:1f.1 RAID bus controller: ALi Corporation: Unknown device 5287 (rev 02)
        Subsystem: ALi Corporation: Unknown device 5287
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 128, Cache Line Size: 0x80 (512 bytes)
        Interrupt: pin A routed to IRQ 19
        Region 0: I/O ports at fd00 [size=16]
        Region 1: I/O ports at fc00 [size=8]
        Region 2: I/O ports at fb00 [size=16]
        Region 3: I/O ports at fa00 [size=8]
        Region 4: I/O ports at f900 [size=32]
        Region 5: Memory at dfffa000 (32-bit, non-prefetchable) [size=1K]
        Capabilities: [60] 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+

Please get a trace from the hang, see https://wiki.ubuntu.com/DebuggingSystemCrash

Unfortunately, it seems that Magic SysRq is disabled in all the AMD64 kernels,
both Hoary's and Breezy's. I'll need to compile a modified kernel.

(In reply to comment #4)
> Unfortunately, it seems that Magic SysRq is disabled in all the AMD64 kernels,
> both Hoary's and Breezy's. I'll need to compile a modified kernel.

No, it isn't.

Hm, well, you're right (manually adding CONFIG_MAGIC_SYSRQ=y to the config file
and rebuilding didn't affect anything, but there's no mention of it in the
/boot/config-* file, which confused me), but unfortunately, I'm not able to get
the Magic SysRq key to work. Alt-sysrq-1 and altl-sysrq-t unfortunately behave
just like alt-1 and alt-t. (I've also tried the other permutations of ctrl and
alt, with no success)

For what it's worth, I also tried the magic sysrq key in a working kernel, and
with a different keyboard, to no effect.

(In reply to comment #6)
> Hm, well, you're right (manually adding CONFIG_MAGIC_SYSRQ=y to the config file
> and rebuilding didn't affect anything, but there's no mention of it in the
> /boot/config-* file, which confused me), but unfortunately, I'm not able to get
> the Magic SysRq key to work. Alt-sysrq-1 and altl-sysrq-t unfortunately behave
> just like alt-1 and alt-t. (I've also tried the other permutations of ctrl and
> alt, with no success)
>
> For what it's worth, I also tried the magic sysrq key in a working kernel, and
> with a different keyboard, to no effect.

Perhaps you aren't using an Ubuntu kernel.

mizar:[~] grep SYSRQ /boot/config*
/boot/config-2.6.12-3-k7:CONFIG_MAGIC_SYSRQ=y
/boot/config-2.6.12-7-k7:CONFIG_MAGIC_SYSRQ=y
/boot/config-2.6.12-8-k7:CONFIG_MAGIC_SYSRQ=y
/boot/config-2.6.12-9-k7:CONFIG_MAGIC_SYSRQ=y

I'm quite certain I'm using an Ubuntu kernel-- it's a fresh install from
official CD, with subsequent upgrade to breezy by apt.

I was notably using a 64bit kernel, however. (-k8-smp, not -k7). Out of
curiosity, I tried downloading the 32bit i386 liveCD, though and I noticed that
it didn't seem to have this trouble. It also had working Magic SysRq. :)

If possible, please upgrade to Dapper's 2.6.15-7 kernel. If you do not want to
upgrade to Dapper, then you can also wait for the Dapper Flight 2 CD's, which
are due out within the next few days.

Let me know if this bug still exists with this kernel.

Please forgive the delay in response; The Dapper Flight 2 AMD64 LiveCD does
boot, but it needs some combination of nolapic noapic noacpi pci=routeirq,noacpi
and acpi=off on the kernel command line. (I was shotgun troubleshooting; It'll
take me a while to figure out exactly which of these is required and which isn't)

It does take 5-10sec to scan for drives; I don't know if that's normal or a
necessary evil.

The LiveCD is rebooting after it tries to start X at the moment, so I'm going to
try an installation to see if I can get that working; that's a different bug,
though.

Okay, upon further research, the parameters required to boot are 'nolapic
pci=noacpi'.

Unfortunately, the delay I mentioned earlier was actually the sata_uli driver
timing out while trying to talk to the hard drive.. I was able to glean this
info from dmesg, when the driver was modprobed:

PCI: enabling device 0000:00:1f.1
sata_uli: 0000:00:1f.1: version 0.5
ata1: SATA Max UDMA/133 cmd 0xfd00 ctl FC02 bmdma 0xf900 irq 11
ata1: SATA link up 1.5Gbps (SStatus 113)
ata1: slow completion (cmd ec)
ata1: dev 0 cfg 49:0000 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 88:0000
ata1: no dma
ata1: dev 0 not supported, ignoring

subsequent attempts to modprobe -r sata_uli and modprobe sata_uli provide a
similar message, except with these two lines:

ata1: SATA linkup 1.5 Gbps (SStatus 113)
ata1 is slow to respond, please be patient.
ata1 failed to respond (30 secs)

(In reply to comment #11)
> Okay, upon further research, the parameters required to boot are 'nolapic
> pci=noacpi'.

Alright, there have been quite a few updates since flight2, especially for
amd64. If possible, could you try one of the latest daily ISO's? If you have an
install of some kind, then just doing a dist-upgrade to latest dapper would also
work.

Thanks

Well, it seems to be getting closer.. now it finds the hard drive (though it
still takes quite a while), unfortunately, it doesn't seem to make it through
the disk partitioner initialization. Dmesg output is full of this line,
repeating over and over:

ata1: command 0x25 timeout stat 0x50 host_stat 0x4

Sorry for the long delay again. The problem seems to have been resolved as of Dapper Final.