Created attachment 124577 [details]
panic

Adding the boot parameter 'ide=nodma' makes the problem go away.

[This comment added as part of a mass-update to all open FC4 kernel bugs]

FC4 has now transitioned to the Fedora legacy project, which will continue to
release security related updates for the kernel.  As this bug is not security
related, it is unlikely to be fixed in an update for FC4, and has been migrated
to FC5.

Please retest with Fedora Core 5.

Thank you.

Still happens with kernel-2.6.17-1.2187_FC5 if DMA isn't explicitly disabled for
that specific drive.

A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

Still happens with 2.6.18-1.2200.fc5 if DMA isn't explicitly disabled for
that specific drive.

erk, that panic is actually a machine check exception which is usually
indicative of a hardware problem.  Does this system survive a run of memtest86+ ?

It is unusual that it survives if DMA is off though. If anything that would be
more CPU intensive, so more likely to provoke flaky hardware.

Alan ?

I've seen this before when the system has hardware problems to do with PCI or
bus arbitration rather than the memory dimms themselves. 

The machine check is pretty good evidence the machine is feeling ill.

Hello.

Just ran memtest86+ without any errors. Do note that this machine does not have
any problems at all except in this specific case which is 100% reproducible.
Turning DMA off for this drive using hdparm makes everything work fine again. My
other DVD connected to hdb (the faulty one is hda) works fine with DMA. Could it
be flaky firmware in the drive or maybe my specific drive that is somewhat broken?

Its a very strange report. The MCE is coming from the CPU and from the trace I
would guess that an inb() from the controller (a request for data from it)
stalled forever and the CPU objected.

What hardware is in the system -e specially what disk controller ?

It's a ASUS A8N-SLI Motherboard with a single dual-core AMD64 CPU. The
disk-controller identifies itself as (lspci -vvv)

00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a [Master
SecP PriP])
        Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0 (750ns min, 250ns max)
        Region 4: I/O ports at f000 [size=16]
        Capabilities: [44] 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-

Closing as there will be no further work done on nvidia old-ide and because the
MCE indicates a hardware fault