RE: Assistance in understanding this...?
> Hi Tracy- > > There was a recent thread about ext2fs-- it was > something like doing a format of a large ext2 fs > could cause the VM to run out of memory. > The solution is to do a sync() calls every 10 (pick > a number) writes so that they get flushed to disk > and that memory can be reused. So I'm using 2.4.1 now (on advice given by Alan Cox on the lkml related to the ext2 fs problems talked about in the lkml archive based on the belief that the vm was fixed in some manner related to these crashes). The same code as below and the same problems. I changed the brelse() call to bforget() - same deal except that the memory dedicated to buffers remains constant. It is my understanding that when calling wait_on_buffer(bh) this in effect makes sure the operation has been committed to disk and will give you the same result as performing a sync(). I can trigger panics during the operation or after the operation - the fragility seems to remain persistent. Panic's seem to quite consistently be 'unable to handle kernel paging request at ' or of the 'unable to handle kernel NULL pointer dereference at virtual address ' nature. Any other suggestions? t. > > See > http://www.lib.uaa.alaska.edu/linux-kernel/archive/2001-Week-07/0902.html. > > HTH. > ~Randy_ > |NOTE: Any views presented here are mine alone| > |& may not represent the views of my employer.| > ------- > > > From: Tracy Camp [mailto:[EMAIL PROTECTED]] > > > > I'm developing a driver that performs some 'formatting' of > > sorts on a scsi > > block device as part of the initialization process. This involves > > writting a long series of non-contiguous blocks to a disk device - > > something akin to: > > > > for(i =0; i < NUM_BLOCKS; i++) { > > bh = getblk(i * offset_size); > > memcpy(bh->b_data,,sizeof(struct somestruct)); > > mark_buffer_dirty(bh); > > ll_rw_block(bh, WRITE,1); > > wait_on_buffer(bh); > > brelse(bh); > > } > > > > the kernel here I should mention is stock 2.4.0 > > > > This all works fine it seems, except that after awhile the > > system becomes > > very fragile and eventually panic's with a NULL pointer > > derefrence. This > > presumeably occurs because of a resource shortage. Thing I'm not > > understand is how doing the above even for a large value of NUM_BLOCKS > > creates a resource shortage. I'm obviously missing something here > > > > This is typically triggered by running any external program, > > (ie. vi, top, > > or gcc seem to work fine for this). and the only noticable > > thing is that > > the memory allocated to buffers grows to be pretty much all > > memory except > > for the last two megs - this seems normal? I can capture some of the > > panic/dumps if anyone thinks they might be of interest. > > > > Ideas? > > > > t. > > Tracy Camp Product Development Miralink Corp.PDX Portland OR 503-223-3140 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Assistance in understanding this...?
Hi Tracy- There was a recent thread about ext2fs-- it was something like doing a format of a large ext2 fs could cause the VM to run out of memory. The solution is to do a sync() calls every 10 (pick a number) writes so that they get flushed to disk and that memory can be reused. So I'm using 2.4.1 now (on advice given by Alan Cox on the lkml related to the ext2 fs problems talked about in the lkml archive based on the belief that the vm was fixed in some manner related to these crashes). The same code as below and the same problems. I changed the brelse() call to bforget() - same deal except that the memory dedicated to buffers remains constant. It is my understanding that when calling wait_on_buffer(bh) this in effect makes sure the operation has been committed to disk and will give you the same result as performing a sync(). I can trigger panics during the operation or after the operation - the fragility seems to remain persistent. Panic's seem to quite consistently be 'unable to handle kernel paging request at some address' or of the 'unable to handle kernel NULL pointer dereference at virtual address some address' nature. Any other suggestions? t. See http://www.lib.uaa.alaska.edu/linux-kernel/archive/2001-Week-07/0902.html. HTH. ~Randy_ |NOTE: Any views presented here are mine alone| | may not represent the views of my employer.| --- From: Tracy Camp [mailto:[EMAIL PROTECTED]] I'm developing a driver that performs some 'formatting' of sorts on a scsi block device as part of the initialization process. This involves writting a long series of non-contiguous blocks to a disk device - something akin to: for(i =0; i NUM_BLOCKS; i++) { bh = getblk(i * offset_size); memcpy(bh-b_data,somestructure,sizeof(struct somestruct)); mark_buffer_dirty(bh); ll_rw_block(bh, WRITE,1); wait_on_buffer(bh); brelse(bh); } the kernel here I should mention is stock 2.4.0 This all works fine it seems, except that after awhile the system becomes very fragile and eventually panic's with a NULL pointer derefrence. This presumeably occurs because of a resource shortage. Thing I'm not understand is how doing the above even for a large value of NUM_BLOCKS creates a resource shortage. I'm obviously missing something here This is typically triggered by running any external program, (ie. vi, top, or gcc seem to work fine for this). and the only noticable thing is that the memory allocated to buffers grows to be pretty much all memory except for the last two megs - this seems normal? I can capture some of the panic/dumps if anyone thinks they might be of interest. Ideas? t. Tracy Camp Product Development Miralink Corp.PDX Portland OR 503-223-3140 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Assistance in understanding this...?
I'm developing a driver that performs some 'formatting' of sorts on a scsi block device as part of the initialization process. This involves writting a long series of non-contiguous blocks to a disk device - something akin to: for(i =0; i < NUM_BLOCKS; i++) { bh = getblk(i * offset_size); memcpy(bh->b_data,,sizeof(struct somestruct)); mark_buffer_dirty(bh); ll_rw_block(bh, WRITE,1); wait_on_buffer(bh); brelse(bh); } the kernel here I should mention is stock 2.4.0 This all works fine it seems, except that after awhile the system becomes very fragile and eventually panic's with a NULL pointer derefrence. This presumeably occurs because of a resource shortage. Thing I'm not understand is how doing the above even for a large value of NUM_BLOCKS creates a resource shortage. I'm obviously missing something here This is typically triggered by running any external program, (ie. vi, top, or gcc seem to work fine for this). and the only noticable thing is that the memory allocated to buffers grows to be pretty much all memory except for the last two megs - this seems normal? I can capture some of the panic/dumps if anyone thinks they might be of interest. Ideas? t. Tracy Camp Product Development Miralink Corp.PDX Portland OR 503-223-3140 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Assistance in understanding this...?
I'm developing a driver that performs some 'formatting' of sorts on a scsi block device as part of the initialization process. This involves writting a long series of non-contiguous blocks to a disk device - something akin to: for(i =0; i NUM_BLOCKS; i++) { bh = getblk(i * offset_size); memcpy(bh-b_data,somestructure,sizeof(struct somestruct)); mark_buffer_dirty(bh); ll_rw_block(bh, WRITE,1); wait_on_buffer(bh); brelse(bh); } the kernel here I should mention is stock 2.4.0 This all works fine it seems, except that after awhile the system becomes very fragile and eventually panic's with a NULL pointer derefrence. This presumeably occurs because of a resource shortage. Thing I'm not understand is how doing the above even for a large value of NUM_BLOCKS creates a resource shortage. I'm obviously missing something here This is typically triggered by running any external program, (ie. vi, top, or gcc seem to work fine for this). and the only noticable thing is that the memory allocated to buffers grows to be pretty much all memory except for the last two megs - this seems normal? I can capture some of the panic/dumps if anyone thinks they might be of interest. Ideas? t. Tracy Camp Product Development Miralink Corp.PDX Portland OR 503-223-3140 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/