lkml.org 
[lkml]   [2008]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Problem with ata layer in 2.6.24
    From
    Date
    On Mon, 2008-01-28 at 11:35 -0500, Gene Heskett wrote:
    > On Monday 28 January 2008, Mikael Pettersson wrote:
    > >Gene Heskett writes:
    > > > On Monday 28 January 2008, Peter Zijlstra wrote:
    > > > >On Mon, 2008-01-28 at 09:17 +0100, Mikael Pettersson wrote:
    > > > >> 1. Wrong mailing list; use linux-ide (@vger) instead.
    > > > >
    > > > >What, and keep all us other interested people in the dark?
    > > >
    > > > As a test, I tried rebooting to the latest fedora kernel and found it
    > > > kills X, so I'm back to the second to last fedora version ATM, and the
    > > > third 'smartctl -t lng /dev/sda' in 24 hours is running now. The first
    > > > two completed with no errors.
    > > >
    > > > I've added the linux-ide list to refresh those people of the problem,
    > > > the logs are being spammed by this message stanza:
    > > >
    > > > Jan 28 04:46:25 coyote kernel: [26550.290016] ata1.00: exception Emask
    > > > 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Jan 28 04:46:25 coyote kernel:
    > > > [26550.290028] ata1.00: cmd 35/00:58:c9:9c:0a/00:01:00:00:00/e0 tag 0 dma
    > > > 176128 out Jan 28 04:46:25 coyote kernel: [26550.290029] res
    > > > 40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) Jan 28 04:46:25
    > > > coyote kernel: [26550.290032] ata1.00: status: { DRDY } Jan 28 04:46:25
    > > > coyote kernel: [26550.290060] ata1: soft resetting link Jan 28 04:46:25
    > > > coyote kernel: [26550.452301] ata1.00: configured for UDMA/100 Jan 28
    > > > 04:46:25 coyote kernel: [26550.452318] ata1: EH complete
    > > > Jan 28 04:46:25 coyote kernel: [26550.455898] sd 0:0:0:0: [sda] 390721968
    > > > 512-byte hardware sectors (200050 MB) Jan 28 04:46:25 coyote kernel:
    > > > [26550.456151] sd 0:0:0:0: [sda] Write Protect is off Jan 28 04:46:25
    > > > coyote kernel: [26550.456403] sd 0:0:0:0: [sda] Write cache: enabled,
    > > > read cache: enabled, doesn't support DPO or FUA
    > >
    > >It's not obvious from this incomplete dmesg log what HW or driver
    > >is behind ata1, but if the 2.6.24-rc7 kernel matches the 2.6.24 one,
    > >
    > >it should be pata_amd driving a WDC disk:
    > > > [ 30.702887] pata_amd 0000:00:09.0: version 0.3.10
    > > > [ 30.703052] PCI: Setting latency timer of device 0000:00:09.0 to 64
    > > > [ 30.703188] scsi0 : pata_amd
    > > > [ 30.709313] scsi1 : pata_amd
    > > > [ 30.710076] ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xf000
    > > > irq 14 [ 30.710079] ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma
    > > > 0xf008 irq 15 [ 30.864753] ata1.00: ATA-6: WDC WD2000JB-00EVA0,
    > > > 15.05R15, max UDMA/100 [ 30.864756] ata1.00: 390721968 sectors, multi
    > > > 16: LBA48
    > > > [ 30.871629] ata1.00: configured for UDMA/100
    > >
    > >Unfortunately we also see:
    > > > [ 48.285456] nvidia: module license 'NVIDIA' taints kernel.
    > > > [ 48.549725] ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [APC4] -> GSI
    > > > 19 (level, high) -> IRQ 20 [ 48.550149] NVRM: loading NVIDIA UNIX x86
    > > > Kernel Module 169.07 Thu Dec 13 18:42:56 PST 2007
    > >
    > >We have no way of debugging that module, so please try 2.6.24 without it.
    >
    > Sorry, I can't do this and have a working machine. The nv driver has suffered
    > bit rot or something since the FC2 days when it COULD run a 19" crt at
    > 1600x1200, and will not drive this 20" wide screen lcd 1680x1050 monitor at
    > more than 800x600, which is absolutely butt ugly fuzzy, looking like a jpg
    > compressed to 10%. The system is not usable on a day to basis without the
    > nvidia driver.
    >
    > Fix the nv driver so it will run this screen at its native resolution and I'll
    > be glad to run it even if it won't run google earth, which I do use from time
    > to time. Now, if in all the hits you can get from google on this, currently
    > 14,800 just for 'exception Emask', apparently caused by a timeout, if 100% of
    > the complainers are running nvidia drivers also, then I see a legit
    I can invalidate this theory...
    i helped a guy on irc debug this problem, and he had ati. I tried having
    him stop using fglrx, and go to r300.. same problem, and same problem
    even with vesa.. :)

    also, i have this on my fileserver with .20, which doesent even run X,
    or module support in kernel :)

    > complaint. Again, fix the nv driver so it will run my screen & I'll be glad
    > to switch. I can see the reason, sure, but the machine must be capable of
    > doing its common day to day stuff, while using that driver, like running kde
    > for kmail, and browsers that work.
    >
    > >If the problems persist, please try to capture a complete log from the
    > >failing kernel -- the interesting bits are everything from initial boot
    > >up to and including the first few errors. You may need to increase the
    > >kernel's log buffer size if the log gets truncated (CONFIG_LOG_BUF_SHIFT).
    >
    > If by log you mean /var/log/messages, I have several megabytes of those.
    > If you mean a live dmesg capture taken right now, its attached. It contains
    > several of these at the bottom. I long ago made the kernel log buffer
    > bigger, cuz it couldn't even show the start immediately after the boot, and
    > even the dump to syslog was truncated.
    >
    > >There are no pata_amd changes from 2.6.24-rc7 to 2.6.24 final.
    >
    > That is what I was afraid of. I've done some limited grepping in that branch
    > of the kernel tree, and cannot seem to locate where this EH handler is being
    > invoked from.
    >
    > There is 2 lines of interest in the dmesg:
    >
    > [ 0.000000] Nvidia board detected. Ignoring ACPI timer override.
    > [ 0.000000] If you got timer trouble try acpi_use_timer_override
    >
    > But I have NDI what it means, kernel argument/xconfig option?
    >
    > I've also done some googling, and it appears this problem is fairly widespread
    > since the switchover to libata was encouraged. A stock fedora F8 kernel
    > suffers the same freezes and eventually locks up, but does it without the
    > error messages being logged, it just freezes, feeling identical to this in
    > the minutes before the total freeze. I've tried 2 of those too, but the
    > newest one won't even run X.
    >



    \
     
     \ /
      Last update: 2008-01-29 05:27    [W:0.027 / U:1.028 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site