[DRBD-user] Oops when shutting down drbd

Rainer Sabelka sabelka at iue.tuwien.ac.at
Wed Aug 1 10:16:35 CEST 2007

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


Hi Lars,

thanks for your answer!

On Tuesday 31 July 2007 22:10, Lars Ellenberg wrote:
> On Tue, Jul 31, 2007 at 05:58:09PM +0200, Rainer Sabelka wrote:
[...]
> > Jul 30 14:57:40 newserver2 kernel: drbd0: drbd_bm_resize:
> > (down_trylock(&b->bm_change)) in
> > /usr/src/modules/drbd/drbd/drbd_bitmap.c:370 Jul 30 14:57:40 newserver2
> > kernel: drbd0: drbd_bm_resize called with capacity == 1409178656
>
> so you do have ~ 1.4 TB of storage.

No. The partition I use for DRBD has 704610868 kB, so this apoprox. the half.

> > [...]
> it may be that you see two problems:
> first, some race condition accessing the bitmap,
> second the debug aid that should help in finding the cause of the race
> condition dereferencing a NULL pointer in a debug printk...
>
> and that NULL pointer would be the mdev->bitmap,
> compare with drbd_bitmap.c ~ line 780 (drbd_bm_rw)...
> and the printk in the __drbd_bm_lock function...

Hmmm...  with printk you mean the line

	ERR("%s:%d: bitmap already locked by %s:%lu\n",
 		file, line, b->bm_file,b->bm_line);


in __drbd_bm_lock()?

If b (=mdev->bitmap) is NULL here, then the crash would be before calling 
printk(), wouldn't it?
Could it be that b->bm_file is NULL?
 
> if this is actually the case, we need to track down and fix the cause of
> the race condition.  as a work around for now, I'd recommend to add some
> "sleep 1" statements between your "multiple drbd related operations",
> and maybe even between the various drbdadm calls in the drbd init script.

Yes, I'll try this. (I've never had this problem when executing drbdadm 
commnds directly from the commandline, only when doing multiple commands in a 
script - so this may indeed be due to a race condition).
I'll let you know when I'm seeing this again - hopefully then I can give you 
more information than just a kernel call trace.

[...]
> > 2nd incident:
> > [...]
> this one should be fixed with svn revision 2964.
>
> please try again with current
>  svn.drbd.org/drbd/branches/drbd-8.0/

I'll try.

Thanks for your help!

-Rainer



More information about the drbd-user mailing list