Peter Osterlund wrote:
On Thu, 2 May 2002, Johnathan Hicks wrote:
After many VPRINTK() insertions into pktcdvd.c I finally tracked the freeze point down to a blk_init_queue() call from pkt_init_queue(). From that it would appear the the problem is not with pktcdvd after all. Do you think I should hunt down blk_init_queue() and stuff it with printk() or would I end up with too much output for it to be useful?
I think you are using an SMP kernel. The packet driver grabs the io_request_lock before calling blk_init_queue, which then tries to grab the lock again, causing a deadlock. It works on UP kernels because spinlocks are NOPs there. It worked before 2.4.19-pre5 because then blk_init_queue didn't grab the io_request_lock.
Correct, I am using an SMP kernel. I think that the 2.5 version has a similar problem as I'm seeing 2 overlapping appearently identical calls and then a freeze.
I don't know if it was ever legal to call blk_init_queue with the lock held, or if the packet driver just worked by accident before kernel 2.4.19-pre5.
The patch below fixes the freeze, but I suspect there are SMP races in the open/setup/teardown paths in the packet driver. (Based on a quick comparision with the loop device driver.)
<PATCH SNIPPED> With any luck I'll run into them too. :) --John