linux-kernel - Re: [BUG] 2.6.24 refuses to boot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <200802031316.01707.dhazelton@enter.net>
Date:	Sun, 3 Feb 2008 13:16:00 -0500
From:	Daniel Hazelton <dhazelton@...er.net>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Chris Rankin <rankincj@...oo.com>, linux-kernel@...r.kernel.org
Subject: Re: [BUG] 2.6.24 refuses to boot - ATA problem?

On Sunday 03 February 2008 12:36:33 Jeff Garzik wrote:
> Daniel Hazelton wrote:
> > On Saturday 02 February 2008 18:40:55 Chris Rankin wrote:
> >> Hi,
> >>
> >> I have tried to boot a 2.6.24 kernel on my 1 GHz Coppermine / 512 MB RAM
> >> PC. (This is without the nmi_watchdog=1 option.) However, the ATA layer
> >> is failing to initialise:
> >
> > <snip>
> >
> >> Driver 'sd' needs updating - please use bus_type methods
> >> scsi0 : ata_piix
> >> scsi1 : ata_piix
> >> ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xa800 irq 14
> >> ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xa808 irq 15
> >> ata1.00: ATA-4: ST320420A, 3.12, max UDMA/66
> >> ata1.00: 39851760 sectors, multi 16: LBA
> >> ata1.00: configured for UDMA/66
> >> ata2.00: ATAPI: Pioneer DVD-ROM ATAPIModel DVD-116  0122, E1.22, max
> >> UDMA/66 ata2.01: ATAPI: SONY    CD-RW  CRX145E, 1.0b, max UDMA/33
> >> ata2.00: configured for UDMA/66
> >> ata2.01: configured for UDMA/33
> >> scsi 0:0:0:0: Direct-Access     ATA      ST320420A        3.12 PQ: 0
> >> ANSI: 5 sd 0:0:0:0: [sda] 39851760 512-byte hardware sectors (20404 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] 39851760 512-byte hardware sectors
> >> (20404 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:<4>ehci_hcd 0000:03:0d.2: Unlink after no-IRQ?
> >> Controller is probably using the wrong IRQ. ata1.00: exception Emask 0x0
> >> SAct 0x0 SErr 0x0 action 0x2 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: soft resetting link
> >> ata1.00: configured for UDMA/66
> >> ata1: EH complete
> >> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 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: soft resetting link
> >> ata1.00: configured for UDMA/66
> >> ata1: EH complete
> >> SysRq : Emergency Sync
> >> Emergency Sync complete
> >> SysRq : Emergency Remount R/O
> >> Emergency Remount complete
> >> SysRq : Resetting
> >
> > This error is what I mentioned in a post yesterday that mentioned several
> > errors I've seen with a recent kernel built from linus' git.
> >
> > The only difference is that here the kernel starts at UDMA/133 and
> > devolves all the way down to PIO0 before spinning forever at that. A
> > fully "cold" boot (ie: removing all power from the system for a period of
> > several minutes and then powering it back on) seems to fix this problem.
> >
> > I've got a kernel here built from git b036555adc but I haven't tested it
> > yet. If the problem still occurs with it, I'll try to get a copy of the
> > output posted here.
>
> If its reproducible, please bisect...  That will tell us precisely the
> problematic change.
>
> 	Jeff

It doesn't occur with 36555adc here - at least, it didn't the two times I've 
booted a kernel built from that tree. With 36555adc I have other problems and 
will be refreshing my copy of the code first. But I will start bisecting if 
the problem persists.

I'm also going to make sure it wasn't caused by something strange, although, 
IIRC, the only real differences in the configs from the kernel that booted 
but had the somewhat random libata problem and the "strange xchat lockup"
problem is the CPA code and the "pre-emptible RCU" - so I'm going to turning 
off one and then both of those options.

DRH

-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/