Re: [sentinix-list] Kernel panic!!!!

"TIM MOORE" <MOORET10-9IS0pmFPeZWVwMm3yRH58PU/[email protected]>
Newsgroups gmane.linux.sentinix
Message-ID <[email protected]>
The mobo I am using is an Asus CUSL2 or something along those lines with a Celeron 466 chip.  I have had some other weird things with this mobo, like having the board power cycle over and over right after the POST unless I go into the BIOS and exit saving the changes.  Then it seems to boot normal.  Maybe time for a new board, cpu and memory.  Also, something that might help is the logs from the kernel for the past few days.  I noticed that I get the same error at 4:40am when the cron.daily scrips run.  I think it could be caused by the slocate script.  Since I do not use the locate command I moved the script out of /etc/cron.daily and I will check the logs tomorrow.  Here are the logs:

Dec 13 04:40:34 lam kernel: EXT3-fs error (device ide0(3,2)): ext3_readdir: directory #586380 contains a hole at offset 4096
Dec 13 04:41:14 lam kernel: EXT3-fs error (device ide0(3,2)): ext3_readdir: directory #977436 contains a hole at offset 4096
Dec 14 04:40:34 lam kernel: EXT3-fs error (device ide0(3,2)): ext3_readdir: directory #586380 contains a hole at offset 4096
Dec 14 04:41:14 lam kernel: EXT3-fs error (device ide0(3,2)): ext3_readdir: directory #977436 contains a hole at offset 4096
Dec 15 04:40:34 lam kernel: EXT3-fs error (device ide0(3,2)): ext3_readdir: directory #586380 contains a hole at offset 4096
Dec 15 04:41:13 lam kernel: EXT3-fs error (device ide0(3,2)): ext3_readdir: directory #977436 contains a hole at offset 4096
Dec 16 04:40:07 lam kernel: memory.c:100: bad pmd 00000010.
Dec 16 04:40:14 lam kernel: EXT3-fs error (device ide0(3,2)): ext3_readdir: directory #4658620 contains a hole at offset 4096
Dec 16 04:40:16 lam kernel: EXT3-fs error (device ide0(3,2)): ext3_readdir: directory #4658604 contains a hole at offset 4096
Dec 16 02:57:07 lam kernel: klogd 1.4.1, log source = /proc/kmsg started.

Dec 17 10:40:23 lam kernel: memory.c:100: bad pmd 00000010.

Maybe a hardware problem here?  I never had any crashes prior to this point, but you never know.





On Tuesday 16 December 2003 14:57, TIM MOORE wrote:
> I just recently switched to Sentinix.  I have been running kernel 2.4.23
> for about a week now. Then at around 4'oclock this morning my Kernel logged
> this message killed my processes.
>
> Message from [email protected] at Tue Dec 16 04:40:21 2003 ...
> lam kernel: Assertion failure in do_get_write_access() at
> transaction.c:612: "jh->b_transaction == transaction || jh->b_transaction
> == journal->j_committing_transaction"
>
> From what I've read online it seems that there are some problems with EXT3
> that could cause this. Anyone else experience this error with this fs?

I read about this one some time ago (long time ago now I think).   I think the 
bug has been fixed long ago even, it shouldn't be in 2.4.23.  It could, 
however, be a case of cache corruption, i.e. faulty or rather incompatible 
hardware... there's always that. :-P

I have never gotten this one, but I have experienced difficulties running 
Linux 2.4.19 and 20 on a weird Intel GLX? (or something) motherboard, I think 
that machine was some kind of Dell (pretty much narrows it down, not).   
Snort would work a couple of days, then there would be funny IO errors and 
the machine would lock up.  We simply switched machine, used the same SCSI 
controller and the same harddisk, and it stopped... definitely something with 
that Intel motherboard.

Do you run IDE + SCSI harddisks (on the same machine)?  I just read a post 
about that, someone having your problems, but only seems to be with IDE+SCSI.

> I'm not insisting this is a problem with Sentinix, just looking for help.
>
> I can't remember, does the install for Sentinix give an option for what
> type of fs you want?

EXT2 or EXT3 only.

 Michel

--------------------------------------
Tim Moore
DNS/Linux/Cisco Admin
ODJFS
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.