Problems with accessing directory
After a new build off a server we keep getting problems with it. The server is in software raid-1 (mirroring) with slackware 10.1 and reiserfs. When accessing a particulary directory, the systems hangs with a kernel panic (mapping memory). Memory has been changed twice without any effect. When starting up the machine we got lot (hundreds) of thes messages: md:reiserfsck (pid 106) used obsolete MD ioctl, upgrade your software to use new ictls. Then machine boots further, and it works normally until we access a perticulair directory. The server reboots or hangs with a kernel panic (mapping virtual memory) Switching to init 1 and then reiserfsck --rebuild-tree reports errors which can be fixed, but the problems still remains. /proc/mdstat gives no errors Personalities : [linear] [raid0] [raid1] [raid5] read_ahead 1024 sectors md0 : active raid1 sdb2[1] sda2[0] 19542976 blocks [2/2] [UU] md1 : active raid1 sdb3[1] sda3[0] 19542976 blocks [2/2] [UU] md2 : active raid1 sdb5[1] sda5[0] 19542976 blocks [2/2] [UU] md3 : active raid1 sdb6[1] sda6[0] 17293824 blocks [2/2] [UU] unused devices: none any ideas? Thx in advandce...
Re: Problems with accessing directory
On Tue, 29 May 2001 18:14:28 +0200, Webservice said: When accessing a particulary directory, the systems hangs with a kernel panic (mapping memory). This will be a lot easier to diagnose with: The exact version of your kernel (uname -a), the version of reiserfsck, and the actual panic traceback (set up a serial console to catch it, or even take a picture with a digital camera if all else fails). Have you run 'badblocks' on the 4 md devices, to rule out an actual bad spot on the disk? pgpFfAoRZDuOp.pgp Description: PGP signature
Re: Problems with accessing directory
On Sun, 29 May 2005 18:44:02 +0200, Kurt Ghekiere said:
May 29 17:28:51 mail3 kernel: Process hax0r (pid: 3738,
stackpage=f121b000)
May 29 17:28:51 mail3 kernel: Stack: bfe5 1000 f63b6000
bfffe7f0 f63b6000 b8e4
May 29 17:28:51 mail3 kernel:f78aaf22 0a3a 0020 f121a000
c0108a93 000b bfffe7f0 f78a99a1
May 29 17:28:51 mail3 kernel:
May 29 17:28:51 mail3 kernel: Call Trace:[c0108a93]
May 29 17:28:51 mail3 kernel:
May 29 17:28:51 mail3 kernel: Code: 8a 02 84 c0 75 ef e8 9c ec ff ff 89
c2 80 3a 00 0f 84 bb 00
Interesting process name indeed. Hopefully you recognize it? ;)
I would suggest running the call trace through ksymoops, but it's so short that
we've quite obviously clobbered the stack to the point that ksymoops won't tell
us anything useful.
I'd investigate why you get all those insmod errors - why is the system trying
to load pciehp and hw_random if there's no device? Alternatively, are other
modules getting loaded incorrectly and blocking those from starting? It's
possible that if your kernel and modules are out of sync, that Bad Things like
panics happen
You probably should look at upgrading the userspace reiserfsck and MD/LVM tools
- your kernel seems unhappy with the old versions.
Other than that, I admit to not having any clear AHA! THAT's their problem
solution, sorry
pgpTiOKMSdDkf.pgp
Description: PGP signature
RE: Problems with accessing directory
Valdis,
Thank you for your info,
Its Sunday evening in Belgium, we will have to find a solution
Because as ISP its that or cut the phone lines tomorrow :-)
If we find something we'll post it
Thanks,
Kurt Pascal
-Oorspronkelijk bericht-
Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Verzonden: zondag 29 mei 2005 20:05
Aan: Kurt Ghekiere
CC: Webservice; reiserfs-list@namesys.com
Onderwerp: Re: Problems with accessing directory
On Sun, 29 May 2005 18:44:02 +0200, Kurt Ghekiere said:
May 29 17:28:51 mail3 kernel: Process hax0r (pid: 3738,
stackpage=f121b000)
May 29 17:28:51 mail3 kernel: Stack: bfe5 1000
f63b6000 bfffe7f0 f63b6000 b8e4
May 29 17:28:51 mail3 kernel:f78aaf22 0a3a 0020
f121a000
c0108a93 000b bfffe7f0 f78a99a1
May 29 17:28:51 mail3 kernel:
May 29 17:28:51 mail3 kernel: Call Trace:[c0108a93]
May 29 17:28:51 mail3 kernel:
May 29 17:28:51 mail3 kernel: Code: 8a 02 84 c0 75 ef e8 9c ec ff ff
89
c2 80 3a 00 0f 84 bb 00
Interesting process name indeed. Hopefully you recognize it? ;)
I would suggest running the call trace through ksymoops, but it's so
short that we've quite obviously clobbered the stack to the point that
ksymoops won't tell us anything useful.
I'd investigate why you get all those insmod errors - why is the system
trying to load pciehp and hw_random if there's no device?
Alternatively, are other modules getting loaded incorrectly and blocking
those from starting? It's possible that if your kernel and modules are
out of sync, that Bad Things like panics happen
You probably should look at upgrading the userspace reiserfsck and
MD/LVM tools
- your kernel seems unhappy with the old versions.
Other than that, I admit to not having any clear AHA! THAT's their
problem
solution, sorry
