Re: Upgrade to 2.6.32-5-amd64 failing miserably

[lrhorer <lrhorer@satx.rr.com>]

martin f krafft wrote:

> also sprach lrhorer <lrhorer@satx.rr.com> [2011.02.02.2057 +0100]:
>> [    4.228353] ata4.04: hard resetting link
>> [    4.564319] ata4.04: SATA link down (SStatus 0 SControl 320)
>> [    4.564375] ata4.05: hard resetting link
>> [    4.900300] ata4.05: SATA link up 1.5 Gbps (SStatus 113 SControl
>> [    320)
> […]
>> [    4.965365] ata4: EH complete
> 
> This does not look like a happy SATA controller or disk.

        I have two of those controllers on two different systems.  They both
produce the same reports in dmesg and neither produces any errors when
running.  I regularly transfer to and from them at over 800 Mbps
without a belch.  It's moot in any case, because this is a SATA
controller, and the two boot disks are IDE:

[    0.807649] ata8: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xff00
irq 14
[    1.022462] ata8.00: ATA-7: ST3500641A, 3.AAE, max UDMA/100
[    1.022464] ata8.00: 976773168 sectors, multi 16: LBA48
[    1.065826] ata8.01: ATA-7: ST3500641A, 3.AAE, max UDMA/100
[    1.065830] ata8.01: 976773168 sectors, multi 16: LBA48
[    1.065847] ata8.00: limited to UDMA/33 due to 40-wire cable
[    1.065849] ata8.01: limited to UDMA/33 due to 40-wire cable
[    1.113673] ata8.00: configured for UDMA/33
[    1.165339] ata8.01: configured for UDMA/33


> Similarly:
> 
>> [   23.324019] ata7: softreset failed (timeout)
>> [   33.340017] ata7: softreset failed (timeout)
>> [   68.364019] ata7: softreset failed (timeout)
>> [   68.364053] ata7: limiting SATA link speed to 1.5 Gbps
>> [   73.388016] ata7: softreset failed (timeout)
>> [   73.388049] ata7: reset failed, giving up
> 
> But this might not be a problem.

        That's just an external SATA docking station with no hard drive
inserted.

>> [   74.143154] md: array md3 already has disks!
> 
> I really need to see initramfs debug output, i.e. the shell traces
> when you pass the debug option on the kernel boot line and then
> obtain the file from /dev/.initramfs or whatever the location was
> according to the wiki; I am offline right now and cannot check.
> 
>> > Also, what version of mdadm are you using? Which package?
>>
>> Debian "Squeeze".  Both the mdadm binary in the 2.6.32-5 and in
>> the /sbin/ directory of the root array report 3.1.2, which is the
>> version supported in the distro.
> 
> Squeeze has had 3.1.4-something for several months. I suggest you
> upgrade.

        Bingo!  That did it.  I don't know what the system did not like about
3.1.2, but now booting under the old kernel brings up md0 properly, and
booting under the new kernel works.  I take it you no longer want to
see the shell traces?

        Thanks for all the help!