Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Tuesday 06 April 2004 14:42, Andreas Schultz wrote:
> On Monday 05 April 2004 16:22, Andreas Schultz wrote:
> > Hi,
> >
> > When attempting to start a drbd device on 2.6.5-rc3-bk2, i get the
> > following oops:
> >
> > Apr 5 16:12:50 sdev01 kernel: Unable to handle kernel NULL pointer
> > dereference at virtual address 00000000 Apr 5 16:12:50 sdev01 kernel:
> > printing eip:
> > Apr 5 16:12:50 sdev01 kernel: c01fcf46
> > Apr 5 16:12:50 sdev01 kernel: *pde = 00000000
> > Apr 5 16:12:50 sdev01 kernel: Oops: 0002 [#1]
> > Apr 5 16:12:50 sdev01 kernel: PREEMPT SMP
> > Apr 5 16:12:50 sdev01 kernel: CPU: 0
> > Apr 5 16:12:51 sdev01 kernel: EIP: 0060:[blk_run_queue+38/128] Not
> > tainted Apr 5 16:12:51 sdev01 kernel: EFLAGS: 00010002
> > (2.6.5-rc3-bk2-vs0.09.29) Apr 5 16:12:51 sdev01 kernel: EIP is at
> > blk_run_queue+0x26/0x80
>
> I have tracked this down in drivers/block/ll_rw_blk.c to:
>
> void blk_run_queue(struct request_queue *q)
> {
> unsigned long flags;
>
> spin_lock_irqsave(q->queue_lock, flags);
> ^^^^^^^^^^^^^
> here, the queue_lock has not been inititalized
>
> blk_remove_plug(q);
> q->request_fn(q);
> spin_unlock_irqrestore(q->queue_lock, flags);
> }
>
> The cruelprint is that i want to use a lvm device as the backend for my
> drbd device and dm devices do not initialise the queue_lock.
>
> setup command: /sbin/drbdsetup /dev/drbd0 disk /dev/nsys/db internal -1
> --on-io-error=panic
>
> comments?
>
How old is your CVS checkout ?
Yes, I can remember that this line:
q->queue_lock = &mdev->req_lock; // needed since we use
was missing. But it is fixed since weeks.
[grep for this line in drbd_main.c]
-Philipp
--
: Dipl-Ing Philipp Reisner Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austria http://www.linbit.com :