Karol Lewandowski <[EMAIL PROTECTED]> wrote:
> Package: kernel-image-2.6.8-2-k7
> Version: 2.6.8-16
> Severity: important
>
> Linux kernel 2.6.(everything) panics when mounting cdrom when DMA
> transfers are enabled (default). It works fine if DMA is disabled.
>
> The drive is clearly broken. Adding blacklist to drivers/ide/ide-dma.c
> for this model ("CD-912E/ATK") fixes this problem.
>
> Messages gathered on panic condition:
>
> --- Begin kernel messages ---
>
> ide-cd: cmd 0x28 timed out
> hdc: DMA interrupt recovery
> hdc: lost interrupt
> hdc: cdrom_decode_status: status=0xd0 { Busy }
> ide: failed opcode was: unknown
> hdc: DMA disabled
> ------------[ cut here ]------------
> kernel BUG at drivers/ide/ide-iops.c:949!
> invalid operand: 0000 [#1]
> Modules linked in:
> CPU: 0
> EIP: 0060:[<c01ece82>] Not tainted VLI
> EFLAGS: 00010086 (2.6.14-eve1)
> EIP is at ide_execute_command+0x22/0x90
> eax: c01ecef0 ebx: c02fed38 ecx: 00008000 edx: c3f81580
> esi: c02feca8 edi: 00000286 ebp: c01f9000 esp: c02c7e50
> ds: 007b es: 007b ss: 0068
> Process swapper (pid: 0, threadinfo=c02c6000 task=c028eba0)
> Stack: 00000082 00808000 c01179e5 a00ce600 c10ce600 c02fed38 c02feca8 c01f8869
> c02fed38 000000a0 c01f9000 00001770 c01f86e0 c10d8ec4 c02fed38 c10d8ec4
> c10ce600 00000004 c01f938a c02fed38 00008000 c01f9000 c02fed38 c10d8ec4
> Call Trace:
> [<c01179e5>] update_process_times+0x85/0x130
> [<c01f8869>] cdrom_start_packet_command+0x119/0x1a0
> [<c01f9000>] cdrom_start_read_continuation+0x0/0xb0
> [<c01f86e0>] cdrom_timer_expiry+0x0/0x70
> [<c01f938a>] cdrom_start_read+0xca/0xd0
> [<c01f9000>] cdrom_start_read_continuation+0x0/0xb0
> [<c01fa075>] ide_do_rw_cdrom+0x95/0x1b0
> [<c01eb1b6>] start_request+0x156/0x240
> [<c01eb4fa>] ide_do_request+0x22a/0x380
> [<c01eb867>] ide_timer_expiry+0xd7/0x1c0
> [<c01eb790>] ide_timer_expiry+0x0/0x1c0
> [<c0117b66>] run_timer_softirq+0xb6/0x1b0
> [<c0113deb>] __do_softirq+0x7b/0x90
> [<c0113e26>] do_softirq+0x26/0x30
> [<c010415e>] do_IRQ+0x1e/0x30
> [<c0102a46>] common_interrupt+0x1a/0x20
> [<c0100920>] default_idle+0x0/0x30
> [<c0100943>] default_idle+0x23/0x30
> [<c01009e0>] cpu_idle+0x50/0x60
> [<c02c87f6>] start_kernel+0x146/0x170
> [<c02c8380>] unknown_bootoption+0x0/0x1e0
> Code: c3 90 8d b4 26 00 00 00 00 57 56 53 83 ec 10 8b 5c 24 20 0f b6 44 24 24
> 88 44 24 0f 8b 73 6c 8b 56 08 9c 5f fa 8b 02 85 c0 74 08 <0f> 0b b5 03 9c 08
> 27 c0 8b 44 24 28 89 02 8b 44 24 30 89 82 dc
> <0>Kernel panic - not syncing: Fatal exception in interrupt
>
> --- End ---
>
> But this shouldn't happen anyway.
Thanks, I've made a trivial patch to implement your blacklist
suggestion, as its seems to apply to current 2.6, and I am going
to send it on to the maintainers. Watch this space.
> Linux 2.4-series kernels, in contrast works just fine when mounting
> cdroms when DMA is enabled. The kernel tries to start DMA transfer,
> but fails waiting for irq(drq?) and disables DMA. Excerpt from log:
>
> (Linux kernel 2.4.32)
>
> kernel: hdc: lost interrupt
> kernel: hdc: cdrom_decode_status: status=0xd0 { Busy }
> kernel: hdc: cdrom_decode_status: error=0xd0LastFailedSense 0x0d
> kernel: hdc: DMA disabled
> kernel: hdc: ATAPI reset complete
> kernel: ISO 9660 Extensions: RRIP_1991A
>
>
> It seems that IDE DMA error recovery doesn't work as described in
> drivers/ide/ide-dma.c:
>
> (Comment from linux kernel 2.6.14)
>
> * To enable DMA, use "hdparm -d1 /dev/hd?" on a per-drive basis after booting.
> * If problems arise, ide.c will disable DMA operation after a few retries.
> * This error recovery mechanism works and has been extremely well exercised.
Running 2.4.32 and looking at a comment from 2.6.14.
Those kernels likely differ wildly. I can pass your problem on to
the 2.4 maintainer, but that kernel is basically frozen now,
so you are unlikely to get much luck.
> Experiments have shown, that linux kernels 2.6.* always panics after
> 60 seconds (from issuing request to drive, eg. "mount /cdrom"), while
> linux kernels 2.4.* disables DMA after 10 seconds (one WAIT_CMD).
>
> (Please tell me the best way to report bugs against all
> linux kernels 2.6.* because I have at least one more.)
This is kind of tricky, but here's how it goes.
For 2.4 kernels, that means 2.4.27 in Debian-land,
I prefer it if you log your bugs against the kernel-source-2.4.27
package, unless it really is pecific to some image or header
package.
For 2.6 kernels from sarge, that means 2.6.8, please
log bugs against kernel-source-2.6.8.
For 2.6 kernels in etch, sid and occasionaly experimental, that means >=
2.6.12, you can log the bug against linux-2.6 or whatever image the bug
came in. It doesn't really matter too much as they all have the same
source package.
Any 2.6 kernel < 2.6.8, or > 2.6.8 and < 2.6.12
(that basically means 2.6.6,7,10,11) are not supported,
so not reporting bugs against them is a most
excllent practice.
In all cases, please report which version of the package
you are using, e.g. kernel-source-2.6.8 2.6.8-12.
And if you have a bug which you think needs to cover
multiple kernel versions, its probably best to just
report it against one and ask if it should be clonned
in the bug report. Its pretty easy to duplicate the bug
and reassign it if needed.
--
Horms
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
