Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Chip Burke wrote: > Good call. It is FC4 2.6.14_1656 . Do I need to go back just one revision? > Or is there a specific kernel where this problem popped up? > Lars, Philipp, With this thread and the "Commands freeze when accessing drbd device..." thread, it looks like something has been botched with the current Fedora Core 4 (FC4) 2.6 kernel. Can you give us some hints on how to figure out what is causing the fault, as it is not kind enough to throw an OOPS pointing at the source[2]. Looking at a diff of the two trees, out of the 42 files with changes, the files I would put the highest chance of causing the problem to be: drivers/block/ll_rw_blk.c # generic_make_request(struct bio *bio) was renamed to # __generic_make_request(struct bio *bio), and the new # generic_make_request(struct bio *bio) was created with # a loop in it calling __generic_make_request. # The comment at the top of the new generic_make_request is: +/* + * We only want one ->make_request_fn to be active at a time, + * else stack usage with stacked devices could be a problem. + * So use current->bio_{list,tail} to keep a list of requests + * submited by a make_request_fn function. + * current->bio_tail is also used as a flag to say if + * generic_make_request is currently active in this task or not. + * If it is NULL, then no make_request is active. If it is non-NULL, + * then a make_request is active, and new requests should be added + * at the tail + */ #so it looks like they modified the way "stacked devices" are handled... #HMMM... DRBD on LVM on IDE/SCSI ... #still I don't have a plan to prove the fault. #The above change comes from a patch Neil Brown sent to linux-kernel at vger.kernel.org "Mon, 7 Nov 2005 11:16:48" Subject: do_mount: reduce stack consumption Signed-off-by: Neil Brown <neilb at cse.unsw.edu.au> Signed-off-by: Neil Brown <neilb at suse.de> #other possibly interesting files. drivers/acpi/utilities/utmisc.c kernel/sysctl.c mm/rmap.c #if they are using scsi (none of the reporters has #indicated what the physical hardware they are using was) #the following may be interesting drivers/scsi/dpt_i2o.c drivers/scsi/scsi_lib.c drivers/scsi/sd.c I think we (those of us using FC4) will need to file a bug with Fedora[1] so this does not become a reoccurring fault keeping us stuck at an old kernel. [1] Well at least for now I will blame Fedora :) It is not impossible for us to find something DRBD is doing, is being done in an interesting way. :) [2] Or as I have not yet tried the new kernel & drbd, I assume the folks are not missing the OOPS because their server being in runlevel 5 instead of 3. > Thanks so much > > ________________________________________ > Chip Burke > > > -----Original Message----- > From: Anquijix Schiptara [mailto:anquijix at hotmail.com] > Sent: Friday, January 20, 2006 10:34 AM > To: cburke at innova-partners.com > Subject: RE: [DRBD-user] mkfs hangs > > If you run FC4 with newest kernel, install an older version, reinstall drbd > module, and all good... There is already a similar thread according to the > newest FC4-Kernel. > > >>From: "Chip Burke" <cburke at innova-partners.com> >>Reply-To: cburke at innova-partners.com >>To: <drbd-user at linbit.com> >>Subject: [DRBD-user] mkfs hangs >>Date: Fri, 20 Jan 2006 10:13:44 -0500 >> >>I am running 0.7.15 and I cannot seem to format a drive. When I go to run >>'mkfs -j /dev/drbd0', mfks hangs while writing the inode tables at the same >>place every time. If I stop drbd and format the underlying device, it works >>fine, but the drbd device is not a happy camper. Any ideas as to what the >>issue may be? /dev/drbd0 is set to primary and syncs just fine with it's >>slave, so everything seems okay. but the drive isn't much good with out a >>files system.