Re: GPF in 2.0.26 _load__block_bitmap

Harald Koenig (koenig@tat.physik.uni-tuebingen.de)
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                     ^^^^^       ^^^^^