From: Jeff D. <jd...@ka...> - 2002-08-29 22:31:28
|
joh...@fo... said: > Then the system freezes for a few moments, und the UML crashs. > Is this a known bug? Do you seriously expect to be told whether or not this is a known bug? Does it occur to you to include even a tiny amount of information? Jeff |
From: Jeff D. <jd...@ka...> - 2002-08-29 23:51:07
|
jfo...@mu... said: > UML kernel 2.4.18 with the latest patch avaiable on the website host: > debian 3.0 with 2.8.18 with highmen 1 GB RAM 5 GB Swap > inside the UML woody too That's some of it. > Errormessages. diffrent, I#ll try to collect somme if it might helf And that would be the rest, for starters. Jeff |
From: Jeff D. <jd...@ka...> - 2002-08-30 00:34:13
|
jfo...@mu... said: > I hope this is enough for the moment. I think it is. > This always happens when create files in the /tmp an the server > starts to swap => ist freezes nearly via ssh. From this comment, I guess you have /tmp as NFS? If so, this is an NFS bug. You can upgrade it and see if the bug is fixed, complain to the NFS people if you're running the latest stuff, or mount tmpfs on /tmp. tmpfs is recommended anyway for performance. Jeff |
From: Johannes F. <jfo...@mu...> - 2002-08-30 00:47:36
|
At 20:36 Uhr -0400 29.08.2002, Jeff Dike wrote: >jfo...@mu... said: >> I hope this is enough for the moment. > >I think it is. > >> This always happens when create files in the /tmp an the server >> starts to swap => ist freezes nearly via ssh. > >>From this comment, I guess you have /tmp as NFS? > >If so, this is an NFS bug. You can upgrade it and see if the bug is fixed, >complain to the NFS people if you're running the latest stuff, or mount >tmpfs on /tmp. Sorry, but NFS was banned from this box when it was installed. /tmp ist on tmpfs # df -h Filesystem Size Used Avail Use% Mounted on /dev/hda1 4.6G 825M 3.5G 19% / /dev/hda6 46G 1.3G 42G 3% /home none 4.0G 50M 3.9G 2% /tmp >tmpfs is recommended anyway for performance. That's the reason why I've choosen it. mfg johannes |
From: Jeff D. <jd...@ka...> - 2002-08-30 01:32:44
|
jfo...@mu... said: > Sorry, but NFS was banned from this box when it was installed. /tmp > ist on tmpfs OK, I don't know what the problem is, but it isn't UML. The host is very sick somehow. The only other times I've seen behavior like this is with the host /tmp on a filesystem with a buggy mmap. I've seen this with versions of reiserfs, nfs, and xfs. You might try the usual health checks, like memtest86, to figure out what's going on. Jeff |
From: Net Llama! <net...@li...> - 2002-08-30 01:37:50
|
Jeff Dike wrote: > jfo...@mu... said: > >>Sorry, but NFS was banned from this box when it was installed. /tmp >>ist on tmpfs > > > OK, I don't know what the problem is, but it isn't UML. The host is very > sick somehow. The only other times I've seen behavior like this is with > the host /tmp on a filesystem with a buggy mmap. I've seen this with versions > of reiserfs, nfs, and xfs. So UML will only run reliably on ext2/3? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman net...@li... Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 6:35pm up 24 days, 2:58, 6 users, load average: 0.07, 0.16, 0.15 |
From: Johannes F. <jfo...@mu...> - 2002-08-30 01:46:15
|
At 18:36 Uhr -0700 29.08.2002, Net Llama! wrote: >Jeff Dike wrote: >>jfo...@mu... said: >> >>>Sorry, but NFS was banned from this box when it was installed. /tmp >>>ist on tmpfs >> >> >>OK, I don't know what the problem is, but it isn't UML. The host is very >>sick somehow. The only other times I've seen behavior like this is with >>the host /tmp on a filesystem with a buggy mmap. I've seen this >>with versions >>of reiserfs, nfs, and xfs. > >So UML will only run reliably on ext2/3? host /tmp on a filesystem with a buggy mmap ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ So it should run without problems everywhere else, as long /tmp is alright (but it should run in my setup too :-) ) |
From: Johannes F. <jfo...@mu...> - 2002-08-30 01:38:25
|
At 21:35 Uhr -0400 29.08.2002, Jeff Dike wrote: >jfo...@mu... said: >> Sorry, but NFS was banned from this box when it was installed. /tmp >> ist on tmpfs > >OK, I don't know what the problem is, but it isn't UML. The host is very >sick somehow. The only other times I've seen behavior like this is with >the host /tmp on a filesystem with a buggy mmap. I've seen this with versions >of reiserfs, nfs, and xfs. > >You might try the usual health checks, like memtest86, to figure out what's >going on. I'll try. it might be a bit difficult since the server is locatet at an ISp, but we'll have a look, thanks for your help, MfG johannes |
From: Johannes F. <jfo...@mu...> - 2002-08-30 01:48:53
|
At 21:35 Uhr -0400 29.08.2002, Jeff Dike wrote: >jfo...@mu... said: >> Sorry, but NFS was banned from this box when it was installed. /tmp >> ist on tmpfs > >OK, I don't know what the problem is, but it isn't UML. The host is very >sick somehow. The only other times I've seen behavior like this is with >the host /tmp on a filesystem with a buggy mmap. I've seen this with versions >of reiserfs, nfs, and xfs. > >You might try the usual health checks, like memtest86, to figure out what's >going on. Just a thought that crossed my mind: Why does UML then only crashes when a large file ist created an the host starts to swap and not later or bevor? Mfg johannes |
From: Jeff D. <jd...@ka...> - 2002-08-30 03:23:03
|
net...@li... said: > So UML will only run reliably on ext2/3? Did you see where I said "versions of ..."? As far as I know, current reiserfs, nfs, and xfs are fine. However, if you have /tmp as something other than tmpfs/ext2/ext3, you're not entirely up to date on the host, and you see crazy behavior from UML like Johannes is, then I would strongly suspect whatever filesystem is running /tmp. Jeff |
From: Jeff D. <jd...@ka...> - 2002-08-30 03:35:50
|
jfo...@mu... said: > Why does UML then only crashes when a large file ist created an the > host starts to swap and not later or bevor? Hmmm. I don't know, but that sounds like a great big clue to me. Is it possible that data is corrupted by being swapped out and swapped back in again? You could test this by having a small program create a large file on /tmp, write a byte pattern into it, make sure some or all of it is swapped, read it back, and see if it's still the same. Jeff |
From: Johannes F. <jfo...@mu...> - 2002-08-30 08:12:04
|
At 23:39 Uhr -0500 29.08.2002, Jeff Dike wrote: >jfo...@mu... said: >> Why does UML then only crashes when a large file ist created an the >> host starts to swap and not later or bevor? > >Hmmm. I don't know, but that sounds like a great big clue to me. > >Is it possible that data is corrupted by being swapped out and swapped >back in again? You could test this by having a small program create a >large file on /tmp, write a byte pattern into it, make sure some or all of >it is swapped, read it back, and see if it's still the same. I'll try it, creating a file over 1 GB on tempfs should be enough, since then it has to swap out. MfG Johannes P.S. an other errormessage, just happened when tempfs got more than 1GB of Data in it, so it das to swap them out -- I'm tracing myself and I can't get out kernel BUG at slab.c:1110! -- Could this be a tmpfs Problem an not a UML Problem? P.P.S. To find out under which conditions UML crashes seems to be more interesting in the moment. I've just managed to freeze a uml completely no errormessage but no reaction on the console and no ping reply for over 10 minutes. Sometimes the UML runns withou at problem and sometime it crasches. and again a Bad op in do_proc_op Might ist be, that the detached RAM-Filkes were overwritten by dd? I'Ll try it by copying the files via cp in /tmp now |
From: Johannes F. <jfo...@mu...> - 2002-08-30 08:32:01
|
Might ist be, that the detached RAM-Filkes were overwritten by dd? I'll try it by copying the files via cp in /tmp now After While Copying the last 2 Files of 840 MB in 60 MB files the kernel fails again: Scheduling in interrupt Scheduling in interrupt Scheduling in interrupt kernel BUG at sched.c:566! Scheduling in interrupt kernel BUG at sched.c:566! Scheduling in interrupt Detaching pid 3369 Kernel panic: Segfault with no mm In interrupt handler - not syncing I'll go now an try to write my 'swapfiltester' MfG Johannes |
From: Johannes F. <jfo...@mu...> - 2002-08-30 08:42:21
|
hmm, I don't think it ist the Filesystem. I've just created a file NOT in /tmp (on ext3) and the UML was killed again. So it ist (IMHO) a kernelBug on the host, or a bug in the uml? Or da you think? |
From: Johannes F. <jfo...@mu...> - 2002-08-30 11:03:00
|
I recompiled the umlkernel now, the same when I let run dd somewhre in the system: I'll try now a new kernel on the host, should I pay attention to spezial kerneloptions? # Scheduling in interrupt Kernel panic: kernel BUG at sched.c:566! Scheduling in interrupt Kernel panic: kernel BUG at sched.c:566! In interrupt handler - not syncing Scheduling in interrupt Kernel panic: kernel BUG at sched.c:566! In interrupt handler - not syncing <0>Kernel panic: Segfault with no mm In interrupt handler - not syncing <0>Kernel panic: Segfault with no mm In interrupt handler - not syncing <0>Kernel panic: Segfault with no mm In interrupt handler - not syncing <0>Kernel panic: Segfault with no mm In interrupt handler - not syncing <0>Kernel panic: Segfault with no mm In interrupt handler - not syncing <0>Kernel panic: Segfault with no mm In interrupt handler - not syncing <0>Kernel panic: Segfault with no mm In interrupt handler - not syncing <3>Unfixable SEGV in '' (pid 0) at 0xe8531a6a (ip 0x200005c7) Unfixable SEGV in ' ?S' (pid 1229344335) at 0x535610ec (ip 0xf689c3c9) Scheduling in interrupt Kernel panic: kernel BUG at sched.c:566! In interrupt handler - not syncing <0>Kernel panic: Segfault with no mm In interrupt handler - not syncing <0>Kernel panic: Segfault with no mm In interrupt handler - not syncing <0>Kernel panic: Segfault with no mm In interrupt handler - not syncing Seg fault in?~ nalsT ----------------------------- <4>Scheduling in interrupt Kernel panic: kernel BUG at sched.c:566! In interrupt handler - not syncing <0>Kernel panic: Segfault with no mm In interrupt handler - not syncing <3>Unfixable SEGV in '' (pid 0) at 0x3ce8016a (ip 0xec83e589) Scheduling in interrupt Kernel panic: kernel BUG at sched.c:566! In interrupt handler - not syncing <3>Unfixable SEGV in '' (pid 1229344335) at 0x4320230a (ip 0xa0144354) Kernel panic: Segfault with no mm In interrupt handler - not syncing <0>Kernel panic: Segfault with no mm In interrupt handler - not syncing <0>Kernel panic: Segfault with no mm In interrupt handler - not syncing t rq Seg fault in signals |
From: Jeff D. <jd...@ka...> - 2002-08-30 12:43:14
|
jfo...@mu... said: > So it ist (IMHO) a kernelBug on the host, or a bug in the uml? > Or da you think? There's no way that this is a UML bug. Jeff |
From: Johannes F. <jfo...@mu...> - 2002-08-30 13:04:30
|
At 8:46 Uhr -0500 30.08.2002, Jeff Dike wrote: >jfo...@mu... said: >> So it ist (IMHO) a kernelBug on the host, or a bug in the uml? >> Or da you think? > >There's no way that this is a UML bug. ok, then I'll take a look at the Hardware. MfG johannes |
From: Johannes F. <jfo...@mu...> - 2002-08-29 22:46:09
|
At 18:33 Uhr -0400 29.08.2002, Jeff Dike wrote: >joh...@fo... said: >> Then the system freezes for a few moments, und the UML crashs. >> Is this a known bug? > >Do you seriously expect to be told whether or not this is a known bug? > >Does it occur to you to include even a tiny amount of information? what kind of information do you like? UML kernel 2.4.18 with the latest patch avaiable on the website host: debian 3.0 with 2.8.18 with highmen 1 GB RAM 5 GB Swap inside the UML woody too Errormessages. diffrent, I#ll try to collect somme if it might helf Greetings Johannes |
From: Johannes F. <jfo...@mu...> - 2002-08-29 23:45:57
|
>Errormessages. diffrent, I#ll try to collect somme if it might help Bad op in do_proc_op -------- Scheduling in interrupt Scheduling in interrupt kernel BUG at sched.c:566! Scheduling in interrupt kernel BUG at sched.c:566! Detaching pid 1138 Kernel panic: Segfault with no mm In interrupt handler - not syncing ------------- Bad op in do_proc_op --------- Child 2727 exited with signal 12 kernel BUG at slab.c:1110! kernel BUG at slab.c:1110! ------------- Kernel panic: read of switch_pipe failed, errno = 9 In idle task - not syncing sleeping process 4285 got unexpected signal : 14 I hope this is enough for the moment. This always happens when create files in the /tmp an the server starts to swap => ist freezes nearly via ssh. I use dd if=/dev/zero of=<an new file in /tmp which is mountet on tmpfs> seek=100 count=200 bs=1M as root an as normal user. Other programms seems not to beaffektet, so I think this ist a bug inside UML and not a general kernelbug. MfG johannes |