# Segmentation fault with GCC

## kirill

I guess this is right place to post to?

The problem is:

when emerging things, gcc exits with segmentation fault, please submit bug report on gcc.org. It does that very randomly, it could compile the kernel fine, but then crash on, let's say, emerging samba.  :Sad: 

hardware: 167MHz Intel Pentium MMX Processor, 32M RAM, GCC 3.1 (from gentoo 1.3b)

I suspect I'm having some kind of hardware problem.

debugging done so far:

ran burnP5 (from cpuburn) for over an hour: no lock ups

ran memtest86 full test: no errors.

How can I fix this? please help!  :Embarassed: 

--kirill

*EDIT* Please move to a better forum if this doesn't apply to Hardware. thnx. *EDIT*

----------

## rac

Do you have some other RAM that is compatible with this machine that you can try using to see if anything improves?  BTW, if you have any good tips on how you installed on this machine with such little RAM that aren't covered already in the forums, this thread might benefit from them.

----------

## kirill

There are those white(4) and long black(2) RAM -slots on the motherboard. Two whites are in use. I also have a couple of pII-class computers which use SDRAM, unfortunately there are only one per each motherboard available. As far as I can remember white and black are not compatible with each other, so that I will need to take 'white memory' away while testing the black?

Do you really think this is a RAM-problem? If so, I will do some hardware switching later today   :Razz: 

thnx

P.S. sorry I don't remember the right terms for RAM, might be EDORAM and SDRAM. It's been a while *doh*   :Wink: 

----------

## rac

 *kirill wrote:*   

> Do you really think this is a RAM-problem?

 

There are lots of hardware problems that can cause intermittent ugliness, but RAM is at the top of my personal list for frequency.  If you haven't read it already, I find the SIG11 FAQ a useful resource.

----------

## kirill

I've played a little with my RAM's now.

switched them like this: SLOT6->3, SLOT5->4. SLOT1-2 are for SDRAM and not in use.

this seems to have helped A LOT. There aren't that much segfaults anymore. but i've still seen a couple within the last 3days. But hey, there were no lock ups anymore, so my server can continue living happily  :Smile: 

----------

## phong

Did you try the Windoze manuver (rebooting to solve a problem)?  I suppose you would have had to reboot to play with the RAM....  Also, was it seg faulting in the same spots, or a different spot every time you ran an emerge?  Like if you tried to emerge the same package twice in a row, would it seg fault twice in a row at the same spot?  What CFLAGS did you compile gcc with?

----------

## kirill

Please read my original post:

 *kirill wrote:*   

> ...gcc exits with segmentation fault, please submit bug report on gcc.org. It does that very randomly, it could compile the kernel fine, but then crash on, let's say, emerging samba. 

 

Yes I had to shut the server down to switch the RAM. Also before that, the server used to lock up, so I naturally had to reboot and then see the lockups/segfaults again and again. but it's really better now  :Smile: 

I've tried the default CFLAGS from make.conf:

```
CFLAGS="-march=i586 -O3 -pipe"
```

..and also very-very default flags from make.globals:

[code]CFLAGS="-O2 -mcpu=i686 -pipe"[/b]

with same results. I'm using the first ones for now.

*cant wait when I get to the kernel compile again (should be this evening or tomorrow)*  :Very Happy: 

----------

## rac

 *kirill wrote:*   

> switched them like this: SLOT6->3, SLOT5->4. [...] this seems to have helped A LOT.

 

What may have happened is that you moved the bad RAM to a spot in memory that isn't used as often, at least until the machine has been running for a while.  If you could get just one more stick of RAM, and use it to replace each of the ones you have in there for day or so, and then run some stress tests (I posted a collection you could try in here), you might be able to isolate the RAM problems and make your server run rock-solid.  Good luck whatever you decide to do.

----------

## kirill

 *rac wrote:*   

>  *kirill wrote:*   switched them like this: SLOT6->3, SLOT5->4. [...] this seems to have helped A LOT. 
> 
> What may have happened is that you moved the bad RAM to a spot in memory that isn't used as often...(I posted a collection you could try in here), you might be able to isolate the RAM problems and make your server run rock-solid.  Good luck whatever you decide to do.

 

 *Quote:*   

> from another thread...
> 
>  *rac wrote:*   
> 
> I find a kernel compile loop, accompanied by a bunzip of a huge file (a Gentoo stage 3 tarball is very convenient for this purpose) is a more stressful and realistic memory test suite.  Here are a couple of quick-and-dirty shell scripts I used for this purpose recently:
> ...

 

Looks good. I'm gonna test this out on my server this night!

As what I've understood I would:

```

#./script-nr1.sh

#nice ./script-nr1.sh

```

Is that correct?

 *Quote:*   

> 
> 
> ```
> 
>   do 
> ...

 

would I need to make dep too first? just curious   :Laughing: 

As I've said, im gonna try this out TONIGHT.

If (when) this fails, Im gonna take that one SDRAM from my workstation and put it in the server. The workstation has worked perfectly with any OS i've tried, especially Gentoo. Unfortunately I can't get more EDORAM(white ones?), on which the servers relies now.

Also as a personal note to rac: thank you for your advices. You are helping me out here and on the other thread paralelly, I really appreciate your help. Thank you very very much!!  :Smile: 

----------

## rac

 *kirill wrote:*   

> 
> 
> ```
> 
> #./script-nr1.sh
> ...

 

You've got the same script running twice...I assume that's a typo and that you mean "nr2" or something in the second one.  Yes, that's basically OK, but a couple of fine points: both scripts run forever, so you will need to use shell job control (put an '&' at the end of the first line) or run them in separate terminals

if the file permissions are set up so that a normal user can access everything, there's no compelling need to run either of these as root

 *Quote:*   

> would I need to make dep too first? just curious   

 

No.  Although you could if you want to, I guess...as the purpose is to stress out the system.  "make dep" is only needed if you have changed something (fairly major) in your kernel configuration.  If the kernel configuration has not changed at all (as in this case), make dep is not needed.

 *Quote:*   

> Also as a personal note to rac:

 

I really appreciate the kind words, but if it hadn't been me, it would have been one of nearly 5,000 (and growing) others.  That's what makes the Gentoo Forums a great resource.

----------

## kirill

 *rac wrote:*   

>  *kirill wrote:*   
> 
> ```
> 
> #./script-nr1.sh
> ...

 

There goes my server screaming:

```

kirill@cinderella linux $ ~/bin/stress1.sh &

-> second screen window

kirill@cinderella bin $ nice ./stress2.sh &

```

top output shows me something like this:

```

16160 kirill    20   0  8712 8712  2536 R    55.6 28.3   0:03 cc1

16146 kirill    20  10  3976 3948   336 R N  15.6 12.8   0:05 bzip2

16145 kirill    15  10   636  624   600 S N  14.6  2.0   0:00 tar

```

BTW. my server just got a lock up while I was transfering the gentoo tarball over sftp. So im not really optimistic over the upcoming results...   :Crying or Very sad: 

----------

## rac

 *kirill wrote:*   

> top output shows me something like this:

 

For comparison purposes, the machine I ran those on with the bad RAM averaged a system load of about 4 with those two scripts and a Gentoo bootstrap running at the same time (in a chroot jail - the main distro was Debian).  You should be able to compare the 'log.xx' files for size and contents to see if the kernel compiles are completing correctly.  When I had the bad RAM in there, it would usually get completely hosed (to the point where things like "exit" and even "reboot" would segfault) within about 5 or 6 kernel compiles.

Once we switched it for new RAM, those two stress tests ran for 24 hours straight (system load 3.5-4.5) without a single byte being different in the kernel output logs, all the while untarring the stage3 tarball.  It also built a nice little Gentoo for itself from stage 1 during all of that.  :Razz: 

----------

## kirill

Here goes the results:

from /var/log/kern.log

```

Aug 16 00:53:28 cinderella kernel: init_special_inode: bogus imode (1)

Aug 16 04:01:50 cinderella kernel: hda: dma_timer_expiry: status=0x58 { DriveReady SeekComplete DataRequest }

Aug 16 04:01:50 cinderella kernel: hda: timeout waiting for DMA

Aug 16 04:01:50 cinderella kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14

Aug 16 04:01:50 cinderella kernel: hda: status error: status=0x50 { DriveReady SeekComplete }

Aug 16 04:01:50 cinderella kernel: hda: no DRQ after issuing MULTWRITE

Aug 16 04:01:50 cinderella kernel: hda: status timeout: status=0xd0 { Busy }

Aug 16 04:01:50 cinderella kernel: hdb: DMA disabled

Aug 16 04:01:50 cinderella kernel: hda: no DRQ after issuing WRITE

Aug 16 04:01:50 cinderella kernel: ide0: reset: success

Aug 16 04:42:04 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

Aug 16 04:42:04 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026589891, count = 1

Aug 16 04:42:04 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

Aug 16 04:42:04 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

Aug 16 04:42:05 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026597204, count = 1

Aug 16 04:42:05 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026564616, count = 1

Aug 16 04:42:05 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

Aug 16 04:56:56 cinderella kernel: hda: dma_timer_expiry: status=0x58 { DriveReady SeekComplete DataRequest }

Aug 16 04:56:56 cinderella kernel: hda: timeout waiting for DMA

Aug 16 04:56:56 cinderella kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14

Aug 16 04:56:56 cinderella kernel: hda: status timeout: status=0xd0 { Busy }

Aug 16 04:56:56 cinderella kernel: hda: no DRQ after issuing WRITE

Aug 16 04:56:56 cinderella kernel: ide0: reset: success

Aug 16 05:27:09 cinderella kernel: hda: dma_timer_expiry: status=0x58 { DriveReady SeekComplete DataRequest }

Aug 16 05:27:10 cinderella kernel: hda: timeout waiting for DMA

Aug 16 05:27:10 cinderella kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14

Aug 16 05:27:10 cinderella kernel: hda: status timeout: status=0xd0 { Busy }

Aug 16 05:27:10 cinderella kernel: hda: no DRQ after issuing WRITE

Aug 16 05:27:10 cinderella kernel: ide0: reset: success

Aug 16 06:07:16 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: bit already cleared for block 1

Aug 16 06:07:16 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

Aug 16 06:07:16 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026589891, count = 1

Aug 16 06:07:16 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

Aug 16 06:07:16 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

Aug 16 06:07:16 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026597204, count = 1

Aug 16 06:07:16 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026564616, count = 1

Aug 16 06:07:16 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

Aug 16 07:07:03 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: bit already cleared for block 1

Aug 16 07:07:03 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

Aug 16 07:07:03 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026589891, count = 1

Aug 16 07:07:03 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

Aug 16 07:07:04 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

Aug 16 07:07:04 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026597204, count = 1

Aug 16 07:07:04 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026564616, count = 1

Aug 16 07:07:04 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

```

...I started stressing the machine at about 00:30.

log.xx sizes:

```

-rw-r--r--    1 kirill   users       18317 Aug 16 00:19 log.1

-rw-r--r--    1 kirill   users       17016 Aug 16 00:20 log.2

-rw-r--r--    1 kirill   users      134804 Aug 16 01:43 log.3

-rw-r--r--    1 kirill   users      142321 Aug 16 02:58 log.4

-rw-r--r--    1 kirill   users      142321 Aug 16 04:15 log.5

-rw-r--r--    1 kirill   users      142321 Aug 16 05:29 log.6

-rw-r--r--    1 kirill   users      142321 Aug 16 06:42 log.7

-rw-r--r--    1 kirill   users      109101 Aug 16 07:45 log.8

```

log.1-3 look different because I had some problems with kernel configuration (moved the kernel folder to another place), this applies at least to log.1-2.

```

-rw-r--r--    1 kirill   users      109101 Aug 16 07:45 log.8

```

I think the compiles died at this point.

there are no error messages I could catch, the screen I ran those tests in, died at some point. The box itself managed to keep on running, it still does in fact. Looks like a filesystem corruption to me, what do you think?

P.S. tomorrow night: the same with different RAM.

----------

## kirill

 *kirill wrote:*   

> 
> 
> P.S. tomorrow night: the same with different RAM.

 

I was happy to find out that there were TWO SDRAM's in my workstation. That means that I don't have to be without a workstation while the server borrows some RAM. There it now with 64SDRAM (was: 32EDORAM) doing the same "tests".

Let's see if it's dead by tomorrow morning  :Very Happy: 

----------

## rac

It's a little late now maybe, but I hope you ran fsck on whatever partition was giving you those errors, in case something needed repair.

----------

## kirill

 *rac wrote:*   

> It's a little late now maybe, but I hope you ran fsck on whatever partition was giving you those errors, in case something needed repair.

 

No worries, been there, done that. Everything is repaired

----------

## kirill

 *kirill wrote:*   

> 
> 
> There goes my server screaming:
> 
> ```
> ...

 

Btw, I did a nice -n 5 to the second script for now. Otherwise, with the default nice (10), the kernel compile seems to steal all the CPU power, and the second script (./stress2.sh) freezes on rm -rf /path/to/stress/*

```

kirill@cinderella bin $ nice -n 5 ./stress2.sh &

```

----------

## rac

 *kirill wrote:*   

> Btw, I did a nice -n 5 to the second script for now.

 

Certainly nothing wrong with that.

 *Quote:*   

> Otherwise, with the default nice (10), the kernel compile seems to steal all the CPU power, and the second script (./stress2.sh) freezes on rm -rf /path/to/stress/*

 

I wonder if it's really frozen or just really busy...that's lots of stuff to rm.  You could try adding the -v option to rm, and it will tell you the names of files it's deleting, which would probably let you tell the difference (not that it's that important).

----------

## kirill

This night's results:

```

kirill@cinderella kirill $ tail -n 100 /var/log/kern.log

Aug 17 01:54:51 cinderella kernel: init_special_inode: bogus imode (1)

Aug 17 02:07:35 cinderella kernel: init_special_inode: bogus imode (1)

--

I remounted and repaired the partitions with 'kernel' and 'stress' at this point.

--

Aug 17 07:22:54 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

Aug 17 07:22:54 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026589891, count = 1

Aug 17 07:22:54 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

Aug 17 07:22:54 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

Aug 17 07:22:54 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026597204, count = 1

Aug 17 07:22:54 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026564616, count = 1

Aug 17 07:22:54 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

Aug 17 09:32:50 cinderella kernel: init_special_inode: bogus imode (1)

Aug 17 10:00:44 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_check_page: bad entry in directory #65091: rec_len is smaller than minimal - offset=4096, inode=2, rec_len=3, name_len=0

Aug 17 11:42:40 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_check_page: bad entry in directory #65091: rec_len is smaller than minimal - offset=4096, inode=2, rec_len=3, name_len=0

```

The compile and bzip's are still running though.

I also tried to do stage1-1.4-x86 (bootstrap) and stage2-1.4-i586 tarballs (emerge system) paralelly, but they both borked for some reasons.

I think I'll want to switch the HD next. This is very odd, I never had any problems with this HD while in the other computer...  :Sad: 

----------

## kirill

Update:

restarted the stress scripts just after my latest post. The server has now been compiling the kernel, unbzipping2 a stage3-tarball and bootstrapping 1.4-x86 for ~10hours.

the only failures are the follows:

```

Aug 17 16:30:32 cinderella kernel: hda: dma_timer_expiry: status=0x58 { DriveReady SeekComplete DataRequest }

Aug 17 16:30:32 cinderella kernel: hda: timeout waiting for DMA

Aug 17 16:30:32 cinderella kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14

Aug 17 16:30:32 cinderella kernel: hda: status timeout: status=0xd0 { Busy }

Aug 17 16:30:32 cinderella kernel: hdb: DMA disabled

Aug 17 16:30:32 cinderella kernel: hda: no DRQ after issuing WRITE

Aug 17 16:30:32 cinderella kernel: ide0: reset: success

Aug 17 18:05:24 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

Aug 17 18:05:24 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026589891, count = 1

Aug 17 18:05:24 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

Aug 17 18:05:24 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

Aug 17 18:05:25 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026597204, count = 1

Aug 17 18:05:25 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026564616, count = 1

Aug 17 18:05:25 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

```

Load averages are:

```

 11:36pm  up 10:06,  6 users,  load average: 3.76, 3.70, 3.88

```

it all looks pretty stable, I just cant understand those kernel errors messages.   :Rolling Eyes: 

----------

## kirill

 *kirill wrote:*   

> 
> 
> it all looks pretty stable, I just cant understand those kernel errors messages.  

 

Oh yeah really stable:

```

Aug 18 00:09:27 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

Aug 18 00:09:27 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026589891, count = 1

Aug 18 00:09:27 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

Aug 18 00:09:27 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

Aug 18 00:09:28 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026597204, count = 1

Aug 18 00:09:28 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026564616, count = 1

Aug 18 00:09:28 cinderella kernel: EXT2-fs error (device ide0(3,8)): ext2_free_blocks: Freeing blocks not in datazone - block = 4026593135, count = 1

```

....and the bootstrap got b0rked.

It looks like it's giving me the same filesystem errors for the same block everytime.

EVEN THOUGH I did some partition relocations (resized my temporary stress partition). The hard drive must be b0rked. I'll put another one in tomorrow morning but, until then, what do you others think?

----------

## kirill

 *kirill wrote:*   

> EVEN THOUGH I did some partition relocations (resized my temporary stress partition). The hard drive must be b0rked. I'll put another one in tomorrow morning but, until then, what do you others think?

 

Put another Hard disk in, the system has now been doing the same stress things plus bootstrapping happily:

```
 10:31pm  up 13:04,  3 users,  load average: 4.10, 4.13, 4.05

```

...all this with no single error!

Again, the system, with which I switched the hard disks with, has now Windows ME running and guess what? yes it crashes randomly  :Wink:  (error messages, blue screens, one mystical reboot...)

wtf, how can one drive b0rk up so much in both linux and windoze?

I now need some proggie to test my hard disk for possible bad blocks/other errors...

----------

## kirill

I somehow get a feeling that my machine is b0rking my hard drives.

After a couple of days of testing with the new one, I'm getting this crap again:

```

Aug 21 18:43:07 stress kernel: init_special_inode: bogus imode (1)

Aug 21 18:44:04 stress kernel: init_special_inode: bogus imode (1)

```

```

stress root # e2fsck /dev/hda9 -yf

e2fsck 1.27 (8-Mar-2002)

Pass 1: Checking inodes, blocks, and sizes

Inode 65485 is in use, but has dtime set.  Fix? yes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Inode 65485 (...) has a bad mode (01).

Clear? yes

Pass 5: Checking group summary information

Block bitmap differences:  -131902

Fix? yes

Free blocks count wrong for group #4 (30083, counted=30084).

Fix? yes

Free blocks count wrong (351418, counted=351419).

Fix? yes

Free inodes count wrong for group #4 (12805, counted=12806).

Fix? yes

Free inodes count wrong (179333, counted=179334).

Fix? yes

/dev/hda9: ***** FILE SYSTEM WAS MODIFIED *****

/dev/hda9: 44666/224000 files (0.2% non-contiguous), 96385/447804 blocks

```

...all that after I

1. mke2fs /dev/hda9

2. e2fsck /dev/hda9

3. started to bootstrap gentoo

Are those 'bad modes' really what I think they are? (==bad blocks == HD is f*cked up forever?)

What the h*ell...

----------

## zagarna

check your ide settings with hdparm

maybe your settings are too aggressive.

try disabling stuff like unmaskirq or other settings that an old drive/buggy bios won't support (the hdparm manual has lots of info on this subject)

----------

## kirill

Hi thanks for the reply

I really didn't play with hdparm at all, so that can't be my agressive hdparm settings.

here is some output from dmesg:

```
Uniform Multi-Platform E-IDE driver Revision: 6.31

ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx

PIIX4: IDE controller on PCI bus 00 dev 39

PIIX4: chipset revision 1

PIIX4: not 100% native mode: will probe irqs later

    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio

    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio

hda: ST36531A, ATA DISK drive

hdb: ATAPI CDROM, ATAPI CD/DVD-ROM drive

ide0 at 0x1f0-0x1f7,0x3f6 on irq 14

hda: 12706470 sectors (6506 MB) w/128KiB Cache, CHS=13446/15/63, UDMA(33)

hdb: ATAPI 24X CD-ROM drive, 120kB Cache, DMA

Uniform CD-ROM driver Revision: 3.12

Partition check:

 /dev/ide/host0/bus0/target0/lun0: p1 p2 < p5 p6 p7 p8 > p3

```

and hdparm /dev/hda:

```
# hdparm /dev/hda

/dev/hda:

 multcount    = 32 (on)

 IO_support   =  0 (default 16-bit)

 unmaskirq    =  0 (off)

 using_dma    =  1 (on)

 keepsettings =  0 (off)

 readonly     =  0 (off)

 readahead    =  8 (on)

 geometry     = 13446/15/63, sectors = 12706470, start = 0

```

As I mentioned the bios doesn't like any of the HD's I have available. I was thinking about maby the BIOS is buggy and needs an update. Is there any way to find out without rebooting what motherboard and BIOS it runs on?   :Rolling Eyes: 

----------

## BradN

Try replacing your IDE data cable.  I've had a bad cable that caused all sorts of strange problems once.  Otherwise, perhaps IDE DMA doesn't work well with your hardware, and you should disable it.

----------

## kirill

 *BradN wrote:*   

> Try replacing your IDE data cable.  I've had a bad cable that caused all sorts of strange problems once.  Otherwise, perhaps IDE DMA doesn't work well with your hardware, and you should disable it.

 

yup, I decided to pass the ide=nodma -option to the kernel for now. let's see how it affects the HD   :Evil or Very Mad: 

----------

