Bug 3398
| Summary: | NForce3-250Gb IDE (PATA) lockup during boot | ||
|---|---|---|---|
| Product: | IO/Storage | Reporter: | Bryan O'Sullivan (bos) |
| Component: | IDE | Assignee: | Bartlomiej Zolnierkiewicz (bzolnier) |
| Status: | REJECTED INSUFFICIENT_DATA | ||
| Severity: | normal | CC: | bunk |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.8.1, 2.6.9 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
By the way, I know this looks a bit like bug 3071, but that one is SATA-specific, while I've only got PATA gear inside my system. This still occurs with 2.6.9. A final note: even forcing the hard disk to PIO mode doesn't necessarily help. For example, I/O hung three times during an upgrade from Fedora Core 2 to Fedora Core 3. The hang happened much earlier with DMA enabled, but still occurred with PIO instead. Each hang required a reboot, even though the kernel was still somewhat alive. Any interactions with processes that required disk I/O during each hang caused whatever process was involved to get wedged. Is this issue still present in kernel 2.6.15? I don't know. I threw out my PATA drives in frustration. Hehe. I'm closing the bug for now. |
Distribution: Fedora Core 2 Hardware Environment: MSI K8N Neo Platinum mobo (NForce3-250Gb chipset) Athlon 64 3200+ Maxtor 250GB ATA-133 hard disk Software Environment: nothing out of the ordinary Problem Description: I built a system around the above-described hardware last week. It did not make it all the way through a vanilla Fedora Core 2 (with 2.6.5 kernel) install, spontaneously switching to runlevel 6 (reboot) partway through the install. I managed to work around this by putting the hard disk into PIO mode, which allowed the install to succeed. However, on subsequently trying to boot the machine, it hung early in userspace during boot about 90% of the time. I made sure that I was booting with apic=off, but it made no difference to stability. A Google search indicated that this looked similar to an NForce2 IDE interrupt-related freeze on recent kernels, so I ran "hdparm -X udma3" during boot (as suggested in the posting I found), and now the system appears to be rock-solid. Steps to reproduce: Let a recent kernel choose the UDMA level itself, and the machine freezes during boot more than 90% of the time, and never survives heavy disk activity.