Messages in this thread |  | | From | (Harald Koenig) | Subject | Re: GPF in 2.0.26 _load__block_bitmap | Date | Thu, 12 Dec 1996 10:04:53 +0100 (MET) |
| |
> > any idea about the reason of the following general protection failure > > in Linux 2.0.26? > > It's the following C code: > > sb->u.ext2_sb.s_block_bitmap_number[j] = > sb->u.ext2_sb.s_block_bitmap_number[j - 1]; > sb->u.ext2_sb.s_block_bitmap[j] = > sb->u.ext2_sb.s_block_bitmap[j - 1]; > > Actually, it's the first assignment, and it barfs on reading > sb->u.ext2_sb.s_block_bitmap_number[j - 1]. > > It happens in the middle of the LRU algorithm of the bitmap cache and, > frankly, it doesn't make any sense to me, as j at the moment of the GP is > 4 and has executed several loops already. I guess an ext2 expert will have > to look into this.
thanks for the first pointer
> BTW, just curios: what stepping is your CPU (if it's a pentium), and what > gcc are using? My compiled version of load__block_bitmap (ELF) is twice as > short as yours (aout)...
I'm still using gcc-2.5.8 (yes, I've read these warnings, but...;) since I'm the last bastion of a.out support for XFree86 (or I was until XFree86 3.2 has been released, now I'm going to migrate to ELF for my main development system;). I have a complete ELF system with gcc-2.7.2 installed too but this is rarly used yet; whatever can be done with aout has been done here...
so, the kernel is compiled for plain "m486" because I'd like to be able to switch back to my old DX33 from time to time for some tests without hassle...
CPU is a 83MHz Pentium OverDrive in a 486-style ASUS SP3G main board:
# cat /proc/cpuinfo processor : 0 cpu : 586 model : OverDrive PODP5V83 vendor_id : GenuineIntel stepping : 2 fdiv_bug : no hlt_bug : no fpu : yes fpu_exception : yes cpuid : yes wp : yes flags : fpu vme de pse tsc msr cx8 bogomips : 33.18
according to intel this should be same as a "C" stepping normal Pentium (P100 or similar)
> > i just happened again :-( at exactly the same EIP. > > Yeah, but now j is 2, not 4 as before (j is in %eax). Definitely strange.. > > BTW, general protection is exception 13 (I don't know off the top of > my head what could generate it and I don't have the docs handy).
where can I check this ?
> > this is ne 2nd crash; I'll compile 2.0.27 now... > > Shouldn't make any difference, as far as I can tell...
since it took 16 days before it happened first with my 2.0.26 kernel image I don't think it's worth compiling it using gcc-2.7.2 and waiting anther couple of weeks for testing as long as I don't know how "smail" triggered this twice within a very short time...
Harald -- All SCSI disks will from now on ___ _____ be required to send an email notice 0--,| /OOOOOOO\ 24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\ \ \/OOOOOOOOOOOOOOO\ \ OOOOOOOOOOOOOOOOO|// Harald Koenig, \/\/\/\/\/\/\/\/\/ Inst.f.Theoret.Astrophysik // / \\ \ koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
|  |