Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Oops\s+removing\s+files\s+on\s+a\s+full\s+f\/s\s*$/: 38 ]

Total 38 documents matching your query.

1. Oops removing files on a full f/s (score: 1)
Author: "Juha Saarinen" <juha@xxxxxxxxxxxx>
Date: Tue, 19 Jun 2001 13:14:23 +1200
fsstress filled up /usr 100% so I was going remove the p* directories and files. This provoked an oops: Kernel BUG at ll_rw_blk.c:700! Entering kdb (current=0xcbc1a000, pid 944) on processor 0 Oops:
/archives/xfs/2001-06/msg00676.html (8,204 bytes)

2. Re: Oops removing files on a full f/s (score: 1)
Author: Daniel Moore <dxm@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 19 Jun 2001 11:21:41 +1000
"Juha Saarinen" writes: => fsstress filled up /usr 100% so I was going remove the p* directories => and files. This provoked an oops: => => Kernel BUG at ll_rw_blk.c:700! => => Entering kdb (current=
/archives/xfs/2001-06/msg00677.html (9,227 bytes)

3. Re: Oops removing files on a full f/s (score: 1)
Author: Steve Lord <lord@xxxxxxx>
Date: Mon, 18 Jun 2001 20:49:21 -0500
Yes, a backtrace from this would be really useful, also, in the backtrace you will see the arguments of the functions, if you could take the third argument of __make_request and pass it to the md com
/archives/xfs/2001-06/msg00678.html (9,611 bytes)

4. RE: Oops removing files on a full f/s (score: 1)
Author: "Juha Saarinen" <juha@xxxxxxxxxxxx>
Date: Tue, 19 Jun 2001 14:28:48 +1200
OK. System: Dual P3 (500MHz) 192MB PC100 SDRAM Tyan Tiger 133 (VIA Apollo Pro 133A) Single 20GB Seagate IDE drive (UDMA-66), master channel 0 Single ASUS 40X IDE CD drive (UDMA-33), master channel 1
/archives/xfs/2001-06/msg00684.html (10,025 bytes)

5. RE: Oops removing files on a full f/s (score: 1)
Author: "Juha Saarinen" <juha@xxxxxxxxxxxx>
Date: Tue, 19 Jun 2001 14:30:29 +1200
So, if we have: 0xc040a240 0xc020ca4 __make_request+0xa4 (0xc040a240, 0x0, 0xca02d00, 0x0, 0x100000) I would do: ? -- Juha
/archives/xfs/2001-06/msg00685.html (9,125 bytes)

6. Re: Oops removing files on a full f/s (score: 1)
Author: Christopher McCrory <chrismcc@xxxxxxxxxxxxxxxx>
Date: Mon, 18 Jun 2001 19:54:26 -0700
I just kind of picked a message from this thread at random to reply to. I just filled up a xfs filesystem to 100%, then deleted the large files I was copying in. No oops using updated sgi rpm kernel
/archives/xfs/2001-06/msg00686.html (10,844 bytes)

7. RE: Oops removing files on a full f/s (score: 1)
Author: "Juha Saarinen" <juha@xxxxxxxxxxxx>
Date: Tue, 19 Jun 2001 15:14:52 +1200
There isn't anyway to save the output from kdb to disk, is there?
/archives/xfs/2001-06/msg00690.html (8,927 bytes)

8. Re: Oops removing files on a full f/s (score: 1)
Author: Steve Lord <lord@xxxxxxx>
Date: Mon, 18 Jun 2001 22:15:56 -0500
Yes, that would do it, Steve
/archives/xfs/2001-06/msg00691.html (9,729 bytes)

9. RE: Oops removing files on a full f/s (score: 1)
Author: "Juha Saarinen" <juha@xxxxxxxxxxxx>
Date: Tue, 19 Jun 2001 15:17:25 +1200
I get a: Bad User Address: 0xca02d00 message when I try that.
/archives/xfs/2001-06/msg00692.html (9,134 bytes)

10. Re: Oops removing files on a full f/s (score: 1)
Author: Christopher McCrory <chrismcc@xxxxxxxxxxxxxxxx>
Date: Mon, 18 Jun 2001 20:20:55 -0700
Alan Eldridge wrote: On Monday 18 June 2001 10:54 pm, you wrote: Hello... I just kind of picked a message from this thread at random to reply to. I just filled up a xfs filesystem to 100%, then dele
/archives/xfs/2001-06/msg00693.html (11,566 bytes)

11. Re: Oops removing files on a full f/s (score: 1)
Author: Keith Owens <kaos@xxxxxxxxxxxxxxxxx>
Date: Tue, 19 Jun 2001 13:39:03 +1000
The address is not in kernel space. Either you mis{copied,typed} it or it really was wrong. In the latter case it would cause the oops. At the kdb prompt, set LOGGING=1. The kdb output is stored in t
/archives/xfs/2001-06/msg00696.html (9,850 bytes)

12. RE: Oops removing files on a full f/s (score: 1)
Author: "Juha Saarinen" <juha@xxxxxxxxxxxx>
Date: Tue, 19 Jun 2001 16:00:15 +1200
Bugger. 0s look very like 8s with ATI VGA... ;-). OK, here we are: md 0xca02da80 0xca02da80 00000000 00000000 00001000 00000307 0xca02da90 00000000 00000307 0000000c 00001ee8 0xca02daa0 ca0dec20 ca5
/archives/xfs/2001-06/msg00698.html (10,149 bytes)

13. Re: Oops removing files on a full f/s (score: 1)
Author: Russell Cattelan <cattelan@xxxxxxxxxxx>
Date: Tue, 19 Jun 2001 00:56:58 -0500
Well yup that's a buffer head size 4k device (3,7) but it may be helpful to find out what make_request was doing with that buffer head when it crashed. take this script (odump) run it with the line o
/archives/xfs/2001-06/msg00700.html (10,953 bytes)

14. Re: Oops removing files on a full f/s (score: 1)
Author: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Tue, 19 Jun 2001 23:36:31 +1000
Ah. ll_rw_blk.c:700. I know it well. My bet: A buffer was unmapped in block_flushpage() but somehow somebody set it dirty again, and bdflush/kupdate tried to write the thing out. For ext3 I have impl
/archives/xfs/2001-06/msg00713.html (9,557 bytes)

15. Re: Oops removing files on a full f/s (score: 1)
Author: Steve Lord <lord@xxxxxxx>
Date: Tue, 19 Jun 2001 11:04:17 -0500
We managed to get into the read path without mapping the buffer, the information I really need to diagnose this is elsewhere else in the kernel, not the buffer_head, time to do a debug by induction.
/archives/xfs/2001-06/msg00716.html (10,450 bytes)

16. Re: Oops removing files on a full f/s (score: 1)
Author: Juha Saarinen <juha@xxxxxxxxxxxx>
Date: Wed, 20 Jun 2001 08:23:18 +1200 (NZST)
Hi Andrew, Bit more testing here... I'm able to oops the box by simply attempting to log in, either locally or remotely (through ssh). This is without f/s activity, so that was just a red herring. Ne
/archives/xfs/2001-06/msg00719.html (10,021 bytes)

17. Re: Oops removing files on a full f/s (score: 1)
Author: Steve Lord <lord@xxxxxxx>
Date: Tue, 19 Jun 2001 15:34:44 -0500
A thought occurs, which compiler are you using, I seem to remember people with things like VIA chipsets needing to use kgcc to get a stable kernel. Also, if you can repeat this I can probably come u
/archives/xfs/2001-06/msg00720.html (10,848 bytes)

18. Re: Oops removing files on a full f/s (score: 1)
Author: Juha Saarinen <juha@xxxxxxxxxxxx>
Date: Wed, 20 Jun 2001 09:59:30 +1200 (NZST)
I've compiled the CVS code with gcc 2.96-85 to see if it would work better than -81. The single mode f/s corruption that I reported before has gone, but it's entirely possible that it's a compiler is
/archives/xfs/2001-06/msg00731.html (9,112 bytes)

19. RE: Oops removing files on a full f/s (score: 1)
Author: "Juha Saarinen" <juha@xxxxxxxxxxxx>
Date: Wed, 20 Jun 2001 17:41:51 +1200
Well, looks like you should scratch RH GCC 2.96-85 from the XFS compilers list... Those oopses appear to have been caused by file system corruption (in /var/log/ksymoops this time, according to xfs_r
/archives/xfs/2001-06/msg00746.html (9,803 bytes)

20. Oops removing files on a full f/s (score: 1)
Author: "Juha Saarinen" <juha@xxxxxxxxxxxx>
Date: Tue, 19 Jun 2001 13:14:23 +1200
fsstress filled up /usr 100% so I was going remove the p* directories and files. This provoked an oops: Kernel BUG at ll_rw_blk.c:700! Entering kdb (current=0xcbc1a000, pid 944) on processor 0 Oops:
/archives/xfs/2001-06/msg01846.html (8,204 bytes)


This search system is powered by Namazu