Messages in this thread | | | Date | Wed, 28 Apr 2004 22:09:54 +0200 | From | Jens Axboe <> | Subject | Re: [BUG] DVD writing in 2.6.6-rc2 |
| |
On Wed, Apr 28 2004, Kenneth Johansson wrote: > On Wed, 2004-04-28 at 13:30, Jens Axboe wrote: > > On Wed, Apr 28 2004, Moritz Muehlenhoff wrote: > > > Jens Axboe wrote: > > > >> I have a problem when using growisofs version 5.19. > > > >> > > > >> The problem is that in the very end when gowisofs tries to flush the > > > >> cache. When stracing the process I can see it sits in a call to poll > > > >> that never returns. > > > > > > > > I noted the same thing yesterday with cdrdao, so yours is not an > > > > isolated incident. I'll debug it tomorrow. > > > > > > I can confirm this bug for kernel 2.6.3-rc4 as well, so it's not too recent. > > > I found the following on my console after quitting k3b ungracefully, maybe > > > > This is really strange, I haven't been able to locate a kernel problem. > > Looking at command traces, cdrdao issues two FLUSH_CACHE commands when > > ending the writes. The last commands are: > > > > 0x2a (last real write) > > 0x35 (first flush cache) (takes about 10 seconds to complete) > > 0x00 (test unit ready) > > 0x51 (read disc info, length 4) > > 0x35 (2nd flush cache) -> never completes > > > > That last sync cache never generates an interrupt, so cdrdao gets stuck > > forever waiting on it. I cannot even reproduce this with a test case > > My problem was in growisofs itself. They use poll to wait instead of > using nanosleep and totally confusing me. It did not help that strace do > not print out the arguments until the syscall return so I never saw the > input to poll.
So it just helped me unearth a different problem :-). There certainly is a bug here, it looks like it's hardware though (see the above description). ide-cd just needs to have it's SYNC_CACHE retries limited, then the kernel should at least recover.
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |