Hide Forgot
testcdrom is started (@10:51) with dma enabled followed by cdrw test, etc, Within ~1 minute of testcdrom starting, the following shows up in /var/log/messages: 10:52:39 hdg: timeout waiting for DMA 10:52:39 hdg: status timeout: status = 0xd0 {Busy} 10:52:39 hdg: status timeout: error: 0xd0LastFailedSense 0x0d 10:52:39 hdg: tray open . . . 14:26:31 hdg: tray open 14:26:32 hdg: timeout waiting for DMA 14:26:33 hdg: timeout waiting for DMA 14:27:14 hdg: DMA disabled 14:27:17 hdg: DMA disabled . . . Note that /dev/hdg is the cd-rom device and the tray is not open! The testcdrom process is long since gone, as the \"tray open\" continues to appear. In addition, the initial \"timeout waiting for DMA\" is no expected. ---------- Action by: kim.jensen Issue Registered ---------- Action by: kim.jensen Attached are the system log files that were captured after the 14:27 timeframe lspci -vv > lspci.base lsmod > lsmod.base cat /proc/meminfo > meminfo.base cat /proc/cpuinfo > cpuinfo.base cp /var/log/messages var-log-messages Status set to: Waiting on Tech (Long Term) File uploaded: tray_open_data.tar.gz ---------- Action by: ltroan What was code level being tested? Especially specific kernel? x86 or IPF? With sushi drops, alpha4 and beta1 are not descriptive enough. kim.jensen assigned to issue for HP-WS. Category set to: Kernel Status set to: Waiting on Client ---------- Action by: ltroan Summary edited. ---------- Action by: kim.jensen IPF RHEL3.0 Beta1 linux-2.4.21-1.1931.2.349.2.2.ent Status set to: Waiting on Tech ---------- Action by: kim.jensen Narrowed the issue down to a simple script. Found that this same problem occurs on RHEL3.0 Beta 1 (2.4.21-1.1931.2.349.2.2.ent) and does not occur on AS 2.1 QU2 (2.4.18-e.31). Reading from the cdrom fails when you try to cat /proc/ide/ide3/<cdrom-device>/identify when reading is in progress. /var/log/messages indicates errors from ide-dma driver and ll_rw_blk.c. These messages continue after the process completes, especially when DMA is disabled. See testcdrom-tray_open script attached. File uploaded: testcdrom-tray_open ISUE TRACKER 26814 opened as sev 2
Created attachment 93674 [details] testcdrom-tray_open
FILE tray_open_data.tar.gz TOO BIG TO ATTACH TO BUGZILLA. SEE ISSUE TRACKER 26814 FOR THIS APPEND (will try to break up and append later)
Files from .gz file (too big to append to Bugzilla) cpuinfo.base lsmod.base lspci.base meminfo.base var-log-messages
Created attachment 93846 [details] lsmod.base
Created attachment 93847 [details] lspci.base
Created attachment 93848 [details] meminfo.base
/proc/cpuinfo from tray_open_data.tar.gz is 36.7MB of junk. /var/log/messages and /var/log/dmesg missing..... Will ask HP to resend.
FROM ISSUE TRACKER.... Event posted 08-22-2003 03:03pm by kim.jensen with duration of 0.00 tray_open.tar.gz Attached tray_open.tar.gz to replace tray_open_info.tar.gz. Have you been able to reproduce the problem with the testcdrom-tray_open script?
tar -zxvf tray_open.tar.gz (too big to append on Bugzilla - expanding) cpuinfo.base lsmod.base lspci.base meninfo.base var-log-messages
Created attachment 94003 [details] cpuinfo.base (new)
Created attachment 94004 [details] lsmod.base (new)
Created attachment 94005 [details] lspci.base (new)
Created attachment 94006 [details] meninfo.base (new)
36.7MB /var/log/messages is included in tray_open.tar.gz attached to Issue Tracker 26814. TOO BIG TO ATTACH TO BUGZILLA.
I have been unable to reproduce this problem using the test script provided. I tried with dma enabled and disabled, and neither case causes problems.
I have now managed to reproduce the problem. There are a couple of issues. First, the cdrom device should not return an I/O error (or should at least we should cleanly recover from it). Next, once the error is reported, it should be cleaned up: Currently, if a device returns an I/O error, the PG_error bit is set in the page struct, but never cleared. I wrote a patch which addresses this issue, but the first issue of why the I/O error occurs remains. The behaviour after this patch is applied is that the I/O error will still be reported to the application. However, subsequent requests will succeed.
Created attachment 96152 [details] patch to clear the PG_error bit
The patch to clear PG_error has been accepted for U1.
I'm changing this from MODIFIED to NEEDINFO, since the core problem here wasn't really addressed. Larry, are you still experiencing this issue?
Closing due to lack of response. This is believed to have been fixed in U1.