hfs bug (w/oops)
Kernel is 2.4.6 on SMP p3 box. hfs doesn't like moving files; it complains thus: = Jul 8 03:26:12 burocracia kernel: kernel BUG at /usr/src/linux/include/linux/dcache.h:244! Jul 8 03:26:12 burocracia kernel: invalid operand: Jul 8 03:26:12 burocracia kernel: CPU:0 Jul 8 03:26:12 burocracia kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Jul 8 03:26:12 burocracia kernel: EFLAGS: 00010286 Jul 8 03:26:12 burocracia kernel: eax: 0039 ebx: cd478760 ecx: 0002 edx: 0200 Jul 8 03:26:12 burocracia kernel: esi: edi: cc354c20 ebp: cb84f220 esp: c5fa7eb0 Jul 8 03:26:12 burocracia kernel: ds: 0018 es: 0018 ss: 0018 Jul 8 03:26:12 burocracia kernel: Process mv (pid: 3613, stackpage=c5fa7000) Jul 8 03:26:12 burocracia kernel: Stack: dd049346 dd049320 00f4 d3bf1e50 c2a1a6f0 d3bf1de0 c2a1a680 0Jul 8 03:26:12 burocracia kernel: cb84f200 cb84f000 6025 661f1800 74656572 2Jul 8 03:26:12 burocracia kernel: 6c6f6f74 2e315f73 2d312e33 6f705f31 70726577 2e63 c013ebee dJul 8 03:26:12 burocracia kernel: Call Trace: [vfs_rename_other+618/712] [vfs_rename+61/136] [sys_rename+Jul 8 03:26:12 burocracia kernel: Code: 0f 0b 83 c4 0c 89 f6 f0 ff 03 8b 53 08 66 c7 42 2c 00 00 a1 >>EIP; dd040fa9 <[hfs]hfs_rename+115/2ec> <= Code; dd040fa9 <[hfs]hfs_rename+115/2ec> <_EIP>: Code; dd040fa9 <[hfs]hfs_rename+115/2ec> 0: 0f 0b ud2a <= Code; dd040fab <[hfs]hfs_rename+117/2ec> 2: 83 c4 0c add $0xc,%esp Code; dd040fae <[hfs]hfs_rename+11a/2ec> 5: 89 f6 mov %esi,%esi Code; dd040fb0 <[hfs]hfs_rename+11c/2ec> 7: f0 ff 03 lock incl (%ebx) Code; dd040fb3 <[hfs]hfs_rename+11f/2ec> a: 8b 53 08 mov 0x8(%ebx),%edx Code; dd040fb6 <[hfs]hfs_rename+122/2ec> d: 66 c7 42 2c 00 00 movw $0x0,0x2c(%edx) Code; dd040fbc <[hfs]hfs_rename+128/2ec>13: a1 00 00 00 00mov 0x0,%eax = Yob if you need more info... -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: O capital é um animal muito sensível, e vai se alimentar onde se sente melhor protegido --Wolfgang Sauer PGP signature
hfs bug (w/oops)
Kernel is 2.4.6 on SMP p3 box. hfs doesn't like moving files; it complains thus: = Jul 8 03:26:12 burocracia kernel: kernel BUG at /usr/src/linux/include/linux/dcache.h:244! Jul 8 03:26:12 burocracia kernel: invalid operand: Jul 8 03:26:12 burocracia kernel: CPU:0 Jul 8 03:26:12 burocracia kernel: EIP:0010:[dd040fa9] Using defaults from ksymoops -t elf32-i386 -a i386 Jul 8 03:26:12 burocracia kernel: EFLAGS: 00010286 Jul 8 03:26:12 burocracia kernel: eax: 0039 ebx: cd478760 ecx: 0002 edx: 0200 Jul 8 03:26:12 burocracia kernel: esi: edi: cc354c20 ebp: cb84f220 esp: c5fa7eb0 Jul 8 03:26:12 burocracia kernel: ds: 0018 es: 0018 ss: 0018 Jul 8 03:26:12 burocracia kernel: Process mv (pid: 3613, stackpage=c5fa7000) Jul 8 03:26:12 burocracia kernel: Stack: dd049346 dd049320 00f4 d3bf1e50 c2a1a6f0 d3bf1de0 c2a1a680 0Jul 8 03:26:12 burocracia kernel: cb84f200 cb84f000 6025 661f1800 74656572 2Jul 8 03:26:12 burocracia kernel: 6c6f6f74 2e315f73 2d312e33 6f705f31 70726577 2e63 c013ebee dJul 8 03:26:12 burocracia kernel: Call Trace: [vfs_rename_other+618/712] [vfs_rename+61/136] [sys_rename+Jul 8 03:26:12 burocracia kernel: Code: 0f 0b 83 c4 0c 89 f6 f0 ff 03 8b 53 08 66 c7 42 2c 00 00 a1 EIP; dd040fa9 [hfs]hfs_rename+115/2ec = Code; dd040fa9 [hfs]hfs_rename+115/2ec _EIP: Code; dd040fa9 [hfs]hfs_rename+115/2ec 0: 0f 0b ud2a = Code; dd040fab [hfs]hfs_rename+117/2ec 2: 83 c4 0c add $0xc,%esp Code; dd040fae [hfs]hfs_rename+11a/2ec 5: 89 f6 mov %esi,%esi Code; dd040fb0 [hfs]hfs_rename+11c/2ec 7: f0 ff 03 lock incl (%ebx) Code; dd040fb3 [hfs]hfs_rename+11f/2ec a: 8b 53 08 mov 0x8(%ebx),%edx Code; dd040fb6 [hfs]hfs_rename+122/2ec d: 66 c7 42 2c 00 00 movw $0x0,0x2c(%edx) Code; dd040fbc [hfs]hfs_rename+128/2ec13: a1 00 00 00 00mov 0x0,%eax = Yob if you need more info... -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: O capital é um animal muito sensível, e vai se alimentar onde se sente melhor protegido --Wolfgang Sauer PGP signature
Re: Cosmetic JFFS patch.
On Thu, Jun 28, 2001 at 05:25:33PM +0100, David Woodhouse wrote: > > KERN_BANNER cool, what about kbannerd ? -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: A longo prazo, estaremos todos mortos. -- John Maynard Keynes PGP signature
Re: Cosmetic JFFS patch.
On Thu, Jun 28, 2001 at 05:25:33PM +0100, David Woodhouse wrote: KERN_BANNER cool, what about kbannerd ? -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: A longo prazo, estaremos todos mortos. -- John Maynard Keynes PGP signature
Re: ACPI or Advanced power ...
On Fri, Jun 22, 2001 at 08:14:26AM +0100, Alan Cox wrote: > > I need an advice, my machine is i810 chipset and using > > ACPI bios, but not sure which one i should use in the > > kernel config. Now I use APM with kernel kapm-idle . > > If you have the option - use APM not ACPI. ACPI is larger, and right now > being experimental code - fairly buggy I agree ACPI sucks, but I have a SMP box that I need to be able to powerdown remotely. Is there any reason APM can't do that? I mean, I understand APM was never meant for SMP, but... ? -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: I must have a prodigious quantity of mind; it takes me as much as a week sometimes to make it up. -- Mark Twain, "The Innocents Abroad" PGP signature
Re: ACPI or Advanced power ...
On Fri, Jun 22, 2001 at 08:14:26AM +0100, Alan Cox wrote: I need an advice, my machine is i810 chipset and using ACPI bios, but not sure which one i should use in the kernel config. Now I use APM with kernel kapm-idle . If you have the option - use APM not ACPI. ACPI is larger, and right now being experimental code - fairly buggy I agree ACPI sucks, but I have a SMP box that I need to be able to powerdown remotely. Is there any reason APM can't do that? I mean, I understand APM was never meant for SMP, but... ? -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: I must have a prodigious quantity of mind; it takes me as much as a week sometimes to make it up. -- Mark Twain, The Innocents Abroad PGP signature
Re: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 08:04:42PM -0700, Larry McVoy wrote: > On the other hand, the fact that it doesn't exist on other platforms sort > of means that it isn't going anywhere. In a sick sort of way, the most > likely way to make this happen is to get Microsoft to do it and then Linux > will do it as well and then the Solaris jocks will also fall in line. The > only problem with that is that Microsoft can't design an OS interface to save > their lives, so maybe Linux _should_ do it first. world domination has to start somewhere... -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Tu amigo tiene un amigo, y el amigo de tu amigo tiene otro amigo; por consiguiente, sé discreto. -- Proverbio judío. PGP signature
Re: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 08:04:42PM -0700, Larry McVoy wrote: On the other hand, the fact that it doesn't exist on other platforms sort of means that it isn't going anywhere. In a sick sort of way, the most likely way to make this happen is to get Microsoft to do it and then Linux will do it as well and then the Solaris jocks will also fall in line. The only problem with that is that Microsoft can't design an OS interface to save their lives, so maybe Linux _should_ do it first. world domination has to start somewhere... -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Tu amigo tiene un amigo, y el amigo de tu amigo tiene otro amigo; por consiguiente, sé discreto. -- Proverbio judío. PGP signature
Re: Few thoughts about CML2 and kernel configuration
On Sat, Jun 16, 2001 at 11:22:27AM +0600, Anuradha Ratnaweera wrote:
> - The feeling is much similar to that of using lynx (especially using
> left-arrow). It would be very nice if pressing right-arrow gives the
> same effect as pressing enter.
that's what the help says it *should* do. Try this:
--- cmlconfigure.py~Sun Jun 10 13:05:58 2001
+++ cmlconfigure.py Sat Jun 16 05:10:32 2001
@@ -1478,7 +1478,7 @@
cmd = self.help_popup("EXITCONFIRM", (lang["REALLY"],), beep=0)
if cmd == ord('q'):
break
-elif cmd in (curses.KEY_ENTER,ord(' '),ord('\r'),ord('\n')) :
+elif cmd in (curses.KEY_ENTER,curses.KEY_RIGHT,ord('
+'),ord('\r'),ord('\n')) :
# Operate on the current object
if sel_symbol.type == "message":
curses.beep()
--
John Lenton ([EMAIL PROTECTED]) -- Random fortune:
This wasn't just plain terrible, this was fancy terrible. This was terrible
with raisins in it.
-- Dorothy Parker
PGP signature
Re: Few thoughts about CML2 and kernel configuration
On Sat, Jun 16, 2001 at 11:22:27AM +0600, Anuradha Ratnaweera wrote:
- The feeling is much similar to that of using lynx (especially using
left-arrow). It would be very nice if pressing right-arrow gives the
same effect as pressing enter.
that's what the help says it *should* do. Try this:
--- cmlconfigure.py~Sun Jun 10 13:05:58 2001
+++ cmlconfigure.py Sat Jun 16 05:10:32 2001
@@ -1478,7 +1478,7 @@
cmd = self.help_popup(EXITCONFIRM, (lang[REALLY],), beep=0)
if cmd == ord('q'):
break
-elif cmd in (curses.KEY_ENTER,ord(' '),ord('\r'),ord('\n')) :
+elif cmd in (curses.KEY_ENTER,curses.KEY_RIGHT,ord('
+'),ord('\r'),ord('\n')) :
# Operate on the current object
if sel_symbol.type == message:
curses.beep()
--
John Lenton ([EMAIL PROTECTED]) -- Random fortune:
This wasn't just plain terrible, this was fancy terrible. This was terrible
with raisins in it.
-- Dorothy Parker
PGP signature
Re: [patch] nonblinking VGA block cursor
On Sat, Jun 16, 2001 at 05:52:39AM +0200, Mike Galbraith wrote: > On Fri, 15 Jun 2001, Albert D. Cahalan wrote: > > Ever wonder why IBM supports Linux instead of FreeBSD? Hmmm? > > I bet it has more to do with growth curves than cursor style :) don't kid yourself. cursor style is the #1 reason for OS adoption in the US. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: 24 horas num dia, 24 cervejas numa caixa. Coincidência? PGP signature
Re: [patch] nonblinking VGA block cursor
On Sat, Jun 16, 2001 at 05:52:39AM +0200, Mike Galbraith wrote: On Fri, 15 Jun 2001, Albert D. Cahalan wrote: Ever wonder why IBM supports Linux instead of FreeBSD? Hmmm? I bet it has more to do with growth curves than cursor style :) don't kid yourself. cursor style is the #1 reason for OS adoption in the US. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: 24 horas num dia, 24 cervejas numa caixa. Coincidência? PGP signature
Re: [driver] New life for Serial mice
sorry I'm late, could you tell me where this driver/patch is? also, my problem with USB mice on slow machines is that it takes up too much CPU, and you get a jumpy mouse if your box is doing a lot of work (like a heavy nfs server, say). Would this driver do the same to that box? On Fri, Jun 08, 2001 at 06:15:21PM +0200, Vojtech Pavlik wrote: > On Wed, Jun 06, 2001 at 11:21:34PM +, Pavel Machek wrote: > > > > If you still have your 3-button MouseSystems (or any other serial) mouse > > > somewhere in your driver, forgotten becase of the incredibly slow update > > > rate causing so much jumping of the pointer on the screen that it is > > > unusable, you may want to pull it out and give it a try. > > > > > > Or if you're still using it with some old 486 computer, this driver is > > > for you. > > > > > > What it does is that it enhances the update rate from 24 (with current > > > GPM and X drivers) to 96. This is almost what the best USB mice do. > > > > What's the "prediction" stuff? Does it mean you are guessing some values > > by interpolation? > > Extrapolation, yes. > > > [If so, what kind of update rate would it do on USB?] > > It wouldn't make any difference - on USB you always get whole packets, > while over serial port the data is processed byte by byte and thus we > know a little of the information before the whole packet arrives. > > -- > Vojtech Pavlik > SuSE Labs > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Hear about... the nymphomaniac teenager popularly known as Little Often Annie? PGP signature
Re: [driver] New life for Serial mice
sorry I'm late, could you tell me where this driver/patch is? also, my problem with USB mice on slow machines is that it takes up too much CPU, and you get a jumpy mouse if your box is doing a lot of work (like a heavy nfs server, say). Would this driver do the same to that box? On Fri, Jun 08, 2001 at 06:15:21PM +0200, Vojtech Pavlik wrote: On Wed, Jun 06, 2001 at 11:21:34PM +, Pavel Machek wrote: If you still have your 3-button MouseSystems (or any other serial) mouse somewhere in your driver, forgotten becase of the incredibly slow update rate causing so much jumping of the pointer on the screen that it is unusable, you may want to pull it out and give it a try. Or if you're still using it with some old 486 computer, this driver is for you. What it does is that it enhances the update rate from 24 (with current GPM and X drivers) to 96. This is almost what the best USB mice do. What's the prediction stuff? Does it mean you are guessing some values by interpolation? Extrapolation, yes. [If so, what kind of update rate would it do on USB?] It wouldn't make any difference - on USB you always get whole packets, while over serial port the data is processed byte by byte and thus we know a little of the information before the whole packet arrives. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Hear about... the nymphomaniac teenager popularly known as Little Often Annie? PGP signature
should reiserfs root be ro?
Should a box that has its root filesystem on a reiser fs mount this root readonly? i.e. should 'read-only' be in lilo.conf? -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: It seems like the less a statesman amounts to, the more he loves the flag. PGP signature
Re: how to crash 2.4.4 w/SBLive
On Thu, May 31, 2001 at 12:01:05PM +0200, [EMAIL PROTECTED] wrote: Content-Description: emu10k1 patch > Index: audio.c > === > RCS file: /usr/local/cvsroot/emu10k1/audio.c,v > retrieving revision 1.166 > diff -u -r1.166 audio.c > --- audio.c 2001/04/22 15:44:25 1.166 > +++ audio.c 2001/05/31 08:47:25 > @@ -1231,6 +1231,7 @@ > woinst->buffer.ossfragshift = 0; > woinst->buffer.numfrags = 0; > woinst->device = (card->audio_dev1 == minor); > + woinst->timer.state = TIMER_STATE_UNINSTALLED; > > init_waitqueue_head(>wait_queue); the closest I can find (in 2.4.5) is woinst->buffer.fragment_size = 0; woinst->buffer.ossfragshift = 0; woinst->buffer.numfrags = 0; woinst->device = (card->audio1_num == minor); init_waitqueue_head(>wait_queue); at lines --1116... -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: New York... when civilization falls apart, remember, we were way ahead of you. - David Letterman PGP signature
Re: how to crash 2.4.4 w/SBLive
On Thu, May 31, 2001 at 12:01:05PM +0200, [EMAIL PROTECTED] wrote: Content-Description: emu10k1 patch Index: audio.c === RCS file: /usr/local/cvsroot/emu10k1/audio.c,v retrieving revision 1.166 diff -u -r1.166 audio.c --- audio.c 2001/04/22 15:44:25 1.166 +++ audio.c 2001/05/31 08:47:25 @@ -1231,6 +1231,7 @@ woinst-buffer.ossfragshift = 0; woinst-buffer.numfrags = 0; woinst-device = (card-audio_dev1 == minor); + woinst-timer.state = TIMER_STATE_UNINSTALLED; init_waitqueue_head(woinst-wait_queue); the closest I can find (in 2.4.5) is woinst-buffer.fragment_size = 0; woinst-buffer.ossfragshift = 0; woinst-buffer.numfrags = 0; woinst-device = (card-audio1_num == minor); init_waitqueue_head(woinst-wait_queue); at lines --1116... -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: New York... when civilization falls apart, remember, we were way ahead of you. - David Letterman PGP signature
should reiserfs root be ro?
Should a box that has its root filesystem on a reiser fs mount this root readonly? i.e. should 'read-only' be in lilo.conf? -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: It seems like the less a statesman amounts to, the more he loves the flag. PGP signature
MSI6321 + PDC20265 + reiserfs + IBM deskstar => kernel BUG
Running kernel 2.4.4 w/Jeff Garzik's via-apic patch, using
reiserfs on a IBM Deskstar on the PDC20265 of a MSI-6321, some
weird shtuff starts happening.
# mount /dev/hde /mnt
reiserfs: checking transaction log (device 21:00) ...
hde: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hde: irq timeout: status=0x80 { Busy }
hde: DMA disabled
ide2: reset: success
reiserfs: replayed 12 transactions in 44 seconds
Using r5 hash to sort names
ReiserFS version 3.6.25
cool!
Now the fun starts: if I start creating a lot of files, I'll
never get to the 1000th, getting the BUG! that follows (the
farthest I've got is B/J/W, i.e. file # 933. Doing a dd instead
of just touching the file is worse). The drive never recovers; I
need to power down the box (a hard reset still leaves it making
these grunging noises).
I attach: the dewhatsitized oops, lspci -vvvxx, hdparm -i
/dev/hde, cat /proc/ide/pdc202xx (but before mounting hde), and
anything else I can think of before hitting y.
Holler if you need anything else.
--
John Lenton ([EMAIL PROTECTED]) -- Random fortune:
O mangi la minestra, o minimizzi la finestra.
-- Andrea `Zuse' Balestrero, "Matemastica e Deformatica"
cpuinfo.gz
dma.gz
hdparm.gz
interrupts.gz
iomem.gz
ioports.gz
lspci.gz
oops.gz
pdc202xx.gz
ver_linux.gz
PGP signature
MSI6321 + PDC20265 + reiserfs + IBM deskstar = kernel BUG
Running kernel 2.4.4 w/Jeff Garzik's via-apic patch, using
reiserfs on a IBM Deskstar on the PDC20265 of a MSI-6321, some
weird shtuff starts happening.
# mount /dev/hde /mnt
reiserfs: checking transaction log (device 21:00) ...
hde: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hde: irq timeout: status=0x80 { Busy }
hde: DMA disabled
ide2: reset: success
reiserfs: replayed 12 transactions in 44 seconds
Using r5 hash to sort names
ReiserFS version 3.6.25
cool!
Now the fun starts: if I start creating a lot of files, I'll
never get to the 1000th, getting the BUG! that follows (the
farthest I've got is B/J/W, i.e. file # 933. Doing a dd instead
of just touching the file is worse). The drive never recovers; I
need to power down the box (a hard reset still leaves it making
these grunging noises).
I attach: the dewhatsitized oops, lspci -vvvxx, hdparm -i
/dev/hde, cat /proc/ide/pdc202xx (but before mounting hde), and
anything else I can think of before hitting y.
Holler if you need anything else.
--
John Lenton ([EMAIL PROTECTED]) -- Random fortune:
O mangi la minestra, o minimizzi la finestra.
-- Andrea `Zuse' Balestrero, Matemastica e Deformatica
cpuinfo.gz
dma.gz
hdparm.gz
interrupts.gz
iomem.gz
ioports.gz
lspci.gz
oops.gz
pdc202xx.gz
ver_linux.gz
PGP signature
Re: PATCH 2.4.5.1: Fix Via interrupt routing issues
On Sun, May 13, 2001 at 01:28:06PM -0400, Jeff Garzik wrote: > For those of you with Via interrupting routing issues (or > interrupt-not-being-delivered issues, etc), please try out this patch > and let me know if it fixes things. It originates from a tip from > Adrian Cox... thanks Adrian! Just to add a little noise: My box (msi 694d pro AI motherboard, revI, i.e. vt82c686a) been a *lot* stabler since I removed the Live! and dropped back to the onboard soundcard. The only time it has frozen has been when checking to see if this also fixed the X-freezes-on-reentry thing (which I know was silly, since CVS X has had that fixed for some time and the fix is on the slow path to 4.1). I used to get a freeze (that is a lock-up where I have to reset the box, unable to even alt-sysrq my way out) between one and five times per day, nearly always in X, nearly always with sound, nearly always using up a lot of (memtested) memory. 'nearly always' means 'at least once not' -- scientific as hell. If I could put in words the difference between the Live! and the via, I would. Alas, I can't, so you're stuck with this inane rant: please please please fix it. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Las palabras, cera; las obras acero. -- Luis de Argote y Góngora. (1561-1627) Poeta español. PGP signature
Re: PATCH 2.4.5.1: Fix Via interrupt routing issues
On Sun, May 13, 2001 at 01:28:06PM -0400, Jeff Garzik wrote: For those of you with Via interrupting routing issues (or interrupt-not-being-delivered issues, etc), please try out this patch and let me know if it fixes things. It originates from a tip from Adrian Cox... thanks Adrian! Just to add a little noise: My box (msi 694d pro AI motherboard, revI, i.e. vt82c686a) been a *lot* stabler since I removed the Live! and dropped back to the onboard soundcard. The only time it has frozen has been when checking to see if this also fixed the X-freezes-on-reentry thing (which I know was silly, since CVS X has had that fixed for some time and the fix is on the slow path to 4.1). I used to get a freeze (that is a lock-up where I have to reset the box, unable to even alt-sysrq my way out) between one and five times per day, nearly always in X, nearly always with sound, nearly always using up a lot of (memtested) memory. 'nearly always' means 'at least once not' -- scientific as hell. If I could put in words the difference between the Live! and the via, I would. Alas, I can't, so you're stuck with this inane rant: please please please fix it. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Las palabras, cera; las obras acero. -- Luis de Argote y Góngora. (1561-1627) Poeta español. PGP signature
Re: REVISED: Experimentation with Athlon and fast_page_copy
On Sat, May 05, 2001 at 08:20:56AM +0100, Alan Cox wrote: > Dont panic just yet. Manfred's observation could mean we hit chipset specific > behaviour on prefetches. OK - Please let me know when to start. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: BOFH excuse #349: Stray Alpha Particles from memory packaging caused Hard Memory Error on Server. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: REVISED: Experimentation with Athlon and fast_page_copy
On Sat, May 05, 2001 at 08:20:56AM +0100, Alan Cox wrote: Dont panic just yet. Manfred's observation could mean we hit chipset specific behaviour on prefetches. OK - Please let me know when to start. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: BOFH excuse #349: Stray Alpha Particles from memory packaging caused Hard Memory Error on Server. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: REVISED: Experimentation with Athlon and fast_page_copy
On Sat, May 05, 2001 at 12:10:06AM +0600, Bobby D. Bryant wrote: > They do boot PIII kernels reliably for all those variants, though they still > suffer occasional oopses, hangs, or crashes (as discussed in other threads). and as happens with my SMP pIII VIA-based boxed (and I've finally fixed the memory, so I no longer get the oopses, just solid hardware hangs). > However (and here's the part I haven't mentioned before), yesterday I switched > one of them to a new mb with a non-VIA chipset (Asus A7A266), and it booted the > first Athlon kernel I tried (2.4.4). No other changes to .config, same > processor as before, same memory, same disks, same video, same case, same power > cord, you name it. damn. I guess the saving of 200$ on the MSI has probably been 300$ down the drain :( -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: If you treat people right they will treat you right -- 90% of the time. -- Franklin Delano Roosevelt PGP signature
Re: REVISED: Experimentation with Athlon and fast_page_copy
On Sat, May 05, 2001 at 12:10:06AM +0600, Bobby D. Bryant wrote: They do boot PIII kernels reliably for all those variants, though they still suffer occasional oopses, hangs, or crashes (as discussed in other threads). and as happens with my SMP pIII VIA-based boxed (and I've finally fixed the memory, so I no longer get the oopses, just solid hardware hangs). However (and here's the part I haven't mentioned before), yesterday I switched one of them to a new mb with a non-VIA chipset (Asus A7A266), and it booted the first Athlon kernel I tried (2.4.4). No other changes to .config, same processor as before, same memory, same disks, same video, same case, same power cord, you name it. damn. I guess the saving of 200$ on the MSI has probably been 300$ down the drain :( -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: If you treat people right they will treat you right -- 90% of the time. -- Franklin Delano Roosevelt PGP signature
Re: Let init know user wants to shutdown
On Tue, Apr 10, 2001 at 10:05:13AM -0700, Grover, Andrew wrote: > This is not correct, because we want the power button to be configurable. > The user should be able to redefine the power button's action, perhaps to > only sleep the system. We currently surface button events to acpid, which > then can do the right thing, including a shutdown -h now (which I assume > notifies init). Just today a friend saw my box shutdown via the powerbutton and wondered if he coudln't set his up to trigger a different event (actually two: he wanted his sister - the guilty party - zapped, and a webcam shot of her face to prove it)... -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: ¿Como meterán los cacahuetes dentro de la cáscara? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
On Tue, Apr 10, 2001 at 10:05:13AM -0700, Grover, Andrew wrote: This is not correct, because we want the power button to be configurable. The user should be able to redefine the power button's action, perhaps to only sleep the system. We currently surface button events to acpid, which then can do the right thing, including a shutdown -h now (which I assume notifies init). Just today a friend saw my box shutdown via the powerbutton and wondered if he coudln't set his up to trigger a different event (actually two: he wanted his sister - the guilty party - zapped, and a webcam shot of her face to prove it)... -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Como metern los cacahuetes dentro de la cscara? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel panic in 2.4.2
On Thu, Mar 29, 2001 at 12:55:50AM -0500, Alexander Viro wrote: > Check the memory - it _may_ be a hardware problem. damn. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Experience is not what happens to you; it is what you do with what happens to you. -- Aldous Huxley - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel panic in 2.4.2
When I arrived at my machine tonight it was dead, with a nice
panic on the screen as a greeting. On rebooting I found something
in the logs, which is rare because it said "not syncing". So I'm
assuming this isn't the panic that killed the box, but she
probably knows (of) him, so let's interrogate her anyway:
Unable to handle kernel paging request at virtual address 00020008
c0139fad
*pde =
Oops: 0002
CPU:0
EIP:0010:[bdput+5/96]
EFLAGS: 00010206
eax: 0002 ebx: 0002 ecx: ca59a648 edx: c15ddfa4
esi: c15ddfa4 edi: c97b9428 ebp: c15ddfac esp: c15ddf6c
ds: 0018 es: 0018 ss: 0018
Process kswapd (pid: 3, stackpage=c15dd000)
Stack: ca59a640 c0146ef2 0002 ca59a640 c0146f47 ca59a640 c97b9608 c97b9600
c0147179 c15ddfa4 00010f00 0004 36dd ca59a828 c29620c8
c01471a9 c012cde3 0006 0004 0006 0004
Call Trace: [clear_inode+194/220] [dispose_list+59/84] [prune_icache+261/276]
[shrink_icache_memory+33/48] [do_try_to_free_pages+103/124] [kswapd+101/240]
[kernel_thread+40/56]
Code: f0 ff 4b 08 0f 94 c0 84 c0 74 4d f0 fe 0d 60 25 24 c0 0f 88
Using defaults from ksymoops -t elf32-i386 -a i386
Code; Before first symbol <_EIP>:
Code; Before first symbol 0: f0 ff 4b 08 lock
decl 0x8(%ebx)
Code; 0004 Before first symbol 4: 0f 94 c0 sete
%al
Code; 0007 Before first symbol 7: 84 c0 test
%al,%al
Code; 0009 Before first symbol 9: 74 4d je
58 <_EIP+0x58> 0058 Before first symbol
Code; 000b Before first symbol b: f0 fe 0d 60 25 24 c0 lock
decb 0xc0242560
Code; 0012 Before first symbol 12: 0f 88 00 00 00 00 js
18 <_EIP+0x18> 0018 Before first symbol
kernel BUG at exit.c:458!
invalid operand:
CPU:0
EIP:0010:[do_exit+668/680]
EFLAGS: 00010286
eax: 001a ebx: c023d020 ecx: 0002 edx: 0200
activating NMI Watchdog ... done.
cpu: 0, clocks: 1002544, slice: 334181
cpu: 1, clocks: 1002544, slice: 334181
oh, kernel 2.4.2. I'd be using 2.4.2-ac*, but my radeon doesn't
like it (and no I can't report a bug on that, because I have
nothing to repot on that).
Cheers!
--
John Lenton ([EMAIL PROTECTED]) -- Random fortune:
What you don't know won't help you much either.
-- D. Bennett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel panic in 2.4.2
On Thu, Mar 29, 2001 at 12:55:50AM -0500, Alexander Viro wrote: Check the memory - it _may_ be a hardware problem. damn. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Experience is not what happens to you; it is what you do with what happens to you. -- Aldous Huxley - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux should better cope with power failure
On Mon, Mar 19, 2001 at 11:35:55PM +0100, Otto Wyss wrote: > > you can avoid all of these problems. Or use a journaling filesystem ext3/xfs, etc. > > So in real live you would propose to put fences and nets everywhere to > prevent children from possibly falling in abyses? I think you've got it backwards: from my point of view, _you_ are proposing the nets, _he_ is proposing the knowledgable and trustworthy parent looking after the children. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Si le dan dos órdenes contradictorias, obedezca las dos. -- Segunda Ley de Brintnall. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[sligthly OT] serial console on palm
I remember seing a project to get a palm pilot working as a serial console, but now google seems unable to find it. Does anyone know of such a project? -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: BOFH excuse #280: Traceroute says that there is a routing problem in the backbone. It's not our problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[sligthly OT] serial console on palm
I remember seing a project to get a palm pilot working as a serial console, but now google seems unable to find it. Does anyone know of such a project? -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: BOFH excuse #280: Traceroute says that there is a routing problem in the backbone. It's not our problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
oops in 2.4.2-ac20
What the subject says. I copied the oops by hand, but the output of ksymoops doesn't seem too totally wrong, so I guess I didn't botch it :) I can't blame the box; I was about to Aiee myself, radeonfb is so slow. ksymoops output: ---8< ksymoops 2.3.7 on i686 2.4.2-ac20. Options used -V (default) -k /var/log/ksymoops/20010317003908.ksyms (specified) -l /var/log/ksymoops/20010317003908.modules (specified) -O (specified) -M (specified) Kernel BUG at printk.c:458! invalid operand: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 001c ebx: ce27090c ecx: c02a97c0 edx: 4dee esi: cda3b000 edi: cda3b16f ebp: esp: c0dc7e34 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c02c7000) Stack: c0255934 01ca c01a0a10 cda3b000 c0194caf cda3b000 0003 cda3b000 0001 cda3b56c c02ae800 42000246 c01adacf a000 cda3b56f cda3b16f c0344260 c01b2e55 c03442a0 c01b2770 03e8 c01b2cb8 0002 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 08 b9 c0 97 2a c0 f0 ff 0d c0 97 2a c0 0f 88 a1 >>EIP; c011839c<= Trace; c01a0a10 Trace; c0194caf Trace; c01adacf Trace; c01b4e55 Trace; c01b2770 Trace; c01b2cb8 Trace; c0113c0b Trace; c01a64e2 Trace; c01924a7 Trace; c011d299 <__run_task_queue+cd/278> Trace; c011ff5e Trace; c011d0a5 Trace; c011cf85 Trace; c011cdac Trace; c010affa Trace; c01071e0 Trace; c01071e0 Trace; c010962c <__read_lock_failed+1440/2804> Trace; c01071e0 Trace; c01071e0 Trace; c0100018 Before first symbol Trace; c010720d Trace; c0107272 Trace; c0105000 Trace; c01001cf Before first symbol Code; c011839c <_EIP>: Code; c011839c<= 0: 0f 0b ud2a <= Code; c011839e 2: 83 c4 08 add$0x8,%esp Code; c01183a1 5: b9 c0 97 2a c0mov$0xc02a97c0,%ecx Code; c01183a6 a: f0 ff 0d c0 97 2a c0 lock decl 0xc02a97c0 Code; c01183ad 11: 0f 88 a1 00 00 00 js b8 <_EIP+0xb8> c0118454 <0>Kernel panic: Aiee, killing interrupt handler! >8--- output of ver_linux: ---8< util-linux util-linux Note: /usr/bin/fdformat is obsolete and is no longer available. util-linux Please use /usr/bin/superformat instead (make sure you have the util-linux fdutils package installed first). Also, there had been some util-linux major changes from version 4.x. Please refer to the documentation. util-linux modutils 2.4.2 e2fsprogs 1.19 reiserfsprogs 3.x.0b PPP2.4.0 Linux C Library2.2.2 Dynamic linker (ldd) 2.2.2 Procps 2.0.7 Net-tools 1.58 Kbd1.04 Sh-utils 2.0.11 Modules Loaded ppp_deflate bsd_comp ppp_async ppp_generic slhc >8--- (I guess ver_linux needs updating) /proc/cpuinfo: ---8< processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 701.611 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1399.19 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 701.611 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 3 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1402.47 >8--- /var/log/ksymoops/20010317003908.modules ---8< agpgart14912 0 (unused) >8--- Anything else? -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: need help: my first packet to my provider gets lost :-( sel: dont send the first one, start with #2 1 1.bak 24.m3u 2cooltek_order.html 3Daccelx_V2-2.0ALPHA-30.i386.rpm 9skin.zip AYB AYB.tar.gz AYB.tar.gz~ Hobby Mail Media MyPilot Nautilus News PC_Product_Compare.pdf Sent Untitled1.bak XF86Config-4 bday_2001.abw bin chesterfield-lemonology-cdart.zip component.reg conni.zip conni_elektra.zip d3_ref.pdf dmusic-158.rmp drag_and_drop2.jpg easymouse+.exe evolution fba06a.pdf fba09a.pdf fba12g.pdf gears.strace index.html kernelnewbies-fortunes.tar.gz linuxq3a-1.27g-beta1.tar.gz lotr_640_internet.mpg lpg-0.4_IPC.ps lpg-0.4_IPC_even.ps mandy.zip mslugx.zip mudsh nezmouse+.exe openlogo-nd.xcf openlogo.xcf
oops in 2.4.2-ac20
What the subject says. I copied the oops by hand, but the output of ksymoops doesn't seem too totally wrong, so I guess I didn't botch it :) I can't blame the box; I was about to Aiee myself, radeonfb is so slow. ksymoops output: ---8 ksymoops 2.3.7 on i686 2.4.2-ac20. Options used -V (default) -k /var/log/ksymoops/20010317003908.ksyms (specified) -l /var/log/ksymoops/20010317003908.modules (specified) -O (specified) -M (specified) Kernel BUG at printk.c:458! invalid operand: CPU:0 EIP:0010:[c011839c] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 001c ebx: ce27090c ecx: c02a97c0 edx: 4dee esi: cda3b000 edi: cda3b16f ebp: esp: c0dc7e34 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c02c7000) Stack: c0255934 01ca c01a0a10 cda3b000 c0194caf cda3b000 0003 cda3b000 0001 cda3b56c c02ae800 42000246 c01adacf a000 cda3b56f cda3b16f c0344260 c01b2e55 c03442a0 c01b2770 03e8 c01b2cb8 0002 Call Trace: [c01a0a10] [c0194caf] [c01adacf] [c01b4e55] [c01b2770] [c01b2cb8] [c0113c0b] [c01a64e2] [c01924a7] [c011d299] [c011ff5e] [c011d0a5] [c011cf85] [c011cdac] [c010affa] [c01071e0] [c01071e0] [c010962c] [c01071e0] [c01071e0] [c0100018] [c010720d] [c0107272] [c0105000] [c01001cf] Code: 0f 0b 83 c4 08 b9 c0 97 2a c0 f0 ff 0d c0 97 2a c0 0f 88 a1 EIP; c011839c acquire_console_sem+2c/1c4 = Trace; c01a0a10 vc_resize+3230/347c Trace; c0194caf tty_unregister_driver+2447/34e8 Trace; c01adacf ide_set_handler+9f/f0 Trace; c01b4e55 ide_config_drive_speed+2aa5/3ed0 Trace; c01b2770 ide_config_drive_speed+3c0/3ed0 Trace; c01b2cb8 ide_config_drive_speed+908/3ed0 Trace; c0113c0b iounmap+18b/40c Trace; c01a64e2 handle_scancode+386/6448 Trace; c01924a7 do_SAK+347/350 Trace; c011d299 __run_task_queue+cd/278 Trace; c011ff5e del_timer_sync+112/f84 Trace; c011d0a5 tasklet_kill+d1/1b4 Trace; c011cf85 get_fast_time+99d/9c8 Trace; c011cdac get_fast_time+7c4/9c8 Trace; c010affa enable_irq+2ae/2c0 Trace; c01071e0 enable_hlt+8/1dc Trace; c01071e0 enable_hlt+8/1dc Trace; c010962c __read_lock_failed+1440/2804 Trace; c01071e0 enable_hlt+8/1dc Trace; c01071e0 enable_hlt+8/1dc Trace; c0100018 Before first symbol Trace; c010720d enable_hlt+35/1dc Trace; c0107272 enable_hlt+9a/1dc Trace; c0105000 gdt+4d94/6f64 Trace; c01001cf Before first symbol Code; c011839c acquire_console_sem+2c/1c4 _EIP: Code; c011839c acquire_console_sem+2c/1c4 = 0: 0f 0b ud2a = Code; c011839e acquire_console_sem+2e/1c4 2: 83 c4 08 add$0x8,%esp Code; c01183a1 acquire_console_sem+31/1c4 5: b9 c0 97 2a c0mov$0xc02a97c0,%ecx Code; c01183a6 acquire_console_sem+36/1c4 a: f0 ff 0d c0 97 2a c0 lock decl 0xc02a97c0 Code; c01183ad acquire_console_sem+3d/1c4 11: 0f 88 a1 00 00 00 js b8 _EIP+0xb8 c0118454 acquire_console_sem+e4/1c4 0Kernel panic: Aiee, killing interrupt handler! 8--- output of ver_linux: ---8 util-linux util-linux Note: /usr/bin/fdformat is obsolete and is no longer available. util-linux Please use /usr/bin/superformat instead (make sure you have the util-linux fdutils package installed first). Also, there had been some util-linux major changes from version 4.x. Please refer to the documentation. util-linux modutils 2.4.2 e2fsprogs 1.19 reiserfsprogs 3.x.0b PPP2.4.0 Linux C Library2.2.2 Dynamic linker (ldd) 2.2.2 Procps 2.0.7 Net-tools 1.58 Kbd1.04 Sh-utils 2.0.11 Modules Loaded ppp_deflate bsd_comp ppp_async ppp_generic slhc 8--- (I guess ver_linux needs updating) /proc/cpuinfo: ---8 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 701.611 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1399.19 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 701.611 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 3 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1402.47 8--- /var/log/ksymoops/20010317003908.modules ---8 agpgart
Re: ln -l says symlink has size 281474976710666
On Tue, Mar 13, 2001 at 02:47:16PM -0700, Andreas Dilger wrote: > ls -i (path)/imlib1; ls -i (path)/fd # record inode numbers > debugfs /dev/hdX > stat # '<' and '>' are required burocracia:~# ls -i /usr/share/doc/|grep \ imlib1$ 404176 imlib1 burocracia:~# ls -i /dev/|grep fd$ 404192 fd burocracia:~# debugfs /dev/hda2 debugfs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 debugfs: stat <404176> Inode: 404176 Type: symlinkMode: 0777 Flags: 0x0 Generation: 2457884131 User: 0 Group: 0 Size: 281474976710666 File ACL: 0Directory ACL: 0 Links: 1 Blockcount: 0 Fragment: Address: 0Number: 0Size: 0 ctime: 0x3a735ed8 -- Sat Jan 27 20:50:48 2001 atime: 0x3aaef4cd -- Wed Mar 14 01:34:21 2001 mtime: 0x3a735ed8 -- Sat Jan 27 20:50:48 2001 Fast_link_dest: imlib-base debugfs: stat <404192> Inode: 404192 Type: symlinkMode: 0777 Flags: 0x0 Generation: 1796859698 User: 0 Group: 0 Size: 281474976710669 File ACL: 0Directory ACL: 0 Links: 1 Blockcount: 0 Fragment: Address: 0Number: 0Size: 0 ctime: 0x3a7308d5 -- Sat Jan 27 14:43:49 2001 atime: 0x3aaef4cd -- Wed Mar 14 01:34:21 2001 mtime: 0x3a7308d5 -- Sat Jan 27 14:43:49 2001 Fast_link_dest: /proc/self/fd > send output. This should tell us if the badness is stored on disk or in > memory. Of course e2fsck would help as well. Were these newly created > inodes, or existing ones? If you shutdown and restart, does it go away? > Anything in syslog about ext2 warnings or errors? this is after an e2fsck, after a reboot, after restart. Nothing in the logs. The inodes are as old as the system, which isn't all that old (circa the first release with reiserfs). I did a find on the whole filesystem and I seem to have stumbled on the only two files with this problem by accident. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Acepto que sientas odio, pero no que actúes con él... acepto que ames, aplaudo que actúes siempre con él. -- Montesino. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: APIC usb MPS 1.4 and the 2.4.2 kernel
On Tue, Mar 13, 2001 at 12:49:54PM -0500, Pete Toscano wrote: > Very interesting. I had not heard about this. Are there any SMP boards > with a VIA chipset that does work well with Linux and USB? I have an > old P2B-DS that I had replace with this board as I needed more PCI > slots. Heck, for that matter are there any SMP boards that work well > with Linux and USB that have six or more PCI slots? My 694D Pro (MS-6321) has been working fine once I got the heat problem off my hands. USB works, as long as the MPS is set at 1.1. It's a SMP board with VIA's "Apollo Pro133A" chipset, and the vt82c686a. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: I matematici lo fanno in teoria, oppure lo portano al limite. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: APIC usb MPS 1.4 and the 2.4.2 kernel
On Tue, Mar 13, 2001 at 12:49:54PM -0500, Pete Toscano wrote: Very interesting. I had not heard about this. Are there any SMP boards with a VIA chipset that does work well with Linux and USB? I have an old P2B-DS that I had replace with this board as I needed more PCI slots. Heck, for that matter are there any SMP boards that work well with Linux and USB that have six or more PCI slots? My 694D Pro (MS-6321) has been working fine once I got the heat problem off my hands. USB works, as long as the MPS is set at 1.1. It's a SMP board with VIA's "Apollo Pro133A" chipset, and the vt82c686a. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: I matematici lo fanno in teoria, oppure lo portano al limite. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ln -l says symlink has size 281474976710666
On Tue, Mar 13, 2001 at 02:47:16PM -0700, Andreas Dilger wrote: ls -i (path)/imlib1; ls -i (path)/fd # record inode numbers debugfs /dev/hdX stat inode_number # '' and '' are required burocracia:~# ls -i /usr/share/doc/|grep \ imlib1$ 404176 imlib1 burocracia:~# ls -i /dev/|grep fd$ 404192 fd burocracia:~# debugfs /dev/hda2 debugfs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 debugfs: stat 404176 Inode: 404176 Type: symlinkMode: 0777 Flags: 0x0 Generation: 2457884131 User: 0 Group: 0 Size: 281474976710666 File ACL: 0Directory ACL: 0 Links: 1 Blockcount: 0 Fragment: Address: 0Number: 0Size: 0 ctime: 0x3a735ed8 -- Sat Jan 27 20:50:48 2001 atime: 0x3aaef4cd -- Wed Mar 14 01:34:21 2001 mtime: 0x3a735ed8 -- Sat Jan 27 20:50:48 2001 Fast_link_dest: imlib-base debugfs: stat 404192 Inode: 404192 Type: symlinkMode: 0777 Flags: 0x0 Generation: 1796859698 User: 0 Group: 0 Size: 281474976710669 File ACL: 0Directory ACL: 0 Links: 1 Blockcount: 0 Fragment: Address: 0Number: 0Size: 0 ctime: 0x3a7308d5 -- Sat Jan 27 14:43:49 2001 atime: 0x3aaef4cd -- Wed Mar 14 01:34:21 2001 mtime: 0x3a7308d5 -- Sat Jan 27 14:43:49 2001 Fast_link_dest: /proc/self/fd send output. This should tell us if the badness is stored on disk or in memory. Of course e2fsck would help as well. Were these newly created inodes, or existing ones? If you shutdown and restart, does it go away? Anything in syslog about ext2 warnings or errors? this is after an e2fsck, after a reboot, after restart. Nothing in the logs. The inodes are as old as the system, which isn't all that old (circa the first release with reiserfs). I did a find on the whole filesystem and I seem to have stumbled on the only two files with this problem by accident. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Acepto que sientas odio, pero no que actes con l... acepto que ames, aplaudo que actes siempre con l. -- Montesino. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ln -l says symlink has size 281474976710666
as the subject says: lrwxrwxrwx1 root root 281474976710666 Jan 27 20:50 imlib1 -> imlib-base it isn't the only one, for example lrwxrwxrwx1 root root 281474976710669 Jan 27 14:43 fd -> /proc/self/fd i.e. 2**48 + what it should be. ver_linux says Gnu C 2.95.3 Gnu make 3.79.1 binutils 2.10.91.0.2 util-linux 2.10s modutils 2.4.2 e2fsprogs 1.19 reiserfsprogs 3.x.0b PPP2.4.0 Linux C Library2.2.2 Dynamic linker (ldd) 2.2.2 Procps 2.0.7 Net-tools 1.58 Kbd1.04 Sh-utils 2.0.11 Modules Loaded ppp_deflate bsd_comp ppp_async ppp_generic slhc rtc the fs is plain ext2, and I'm running 2.4.2-ac16. My first guess was I was needing a newer foo, but all my foos seem to be OK (except for reiserfsprogs, but that's another issue). -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: L'acne giovanile si cura con la vecchiaia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ln -l says symlink has size 281474976710666
as the subject says: lrwxrwxrwx1 root root 281474976710666 Jan 27 20:50 imlib1 - imlib-base it isn't the only one, for example lrwxrwxrwx1 root root 281474976710669 Jan 27 14:43 fd - /proc/self/fd i.e. 2**48 + what it should be. ver_linux says Gnu C 2.95.3 Gnu make 3.79.1 binutils 2.10.91.0.2 util-linux 2.10s modutils 2.4.2 e2fsprogs 1.19 reiserfsprogs 3.x.0b PPP2.4.0 Linux C Library2.2.2 Dynamic linker (ldd) 2.2.2 Procps 2.0.7 Net-tools 1.58 Kbd1.04 Sh-utils 2.0.11 Modules Loaded ppp_deflate bsd_comp ppp_async ppp_generic slhc rtc the fs is plain ext2, and I'm running 2.4.2-ac16. My first guess was I was needing a newer foo, but all my foos seem to be OK (except for reiserfsprogs, but that's another issue). -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: L'acne giovanile si cura con la vecchiaia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IMS Twin Turbo 128 framebuffer
Is there any particular reason why imsttfb isn't available in the i386 arch? It doesn't work in X either in spite of being "supported", but that's not for this list. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Le donne hanno 4 labbra: due per dire delle stupidaggini, due per farsi perdonare. -- Da it.hobby.umorismo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IMS Twin Turbo 128 framebuffer
Is there any particular reason why imsttfb isn't available in the i386 arch? It doesn't work in X either in spite of being "supported", but that's not for this list. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Le donne hanno 4 labbra: due per dire delle stupidaggini, due per farsi perdonare. -- Da it.hobby.umorismo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
oops followed by "kernel BUG"s
When I woke today I found I'd gotten the following oops, Feb 25 06:27:37 burocracia kernel: Unable to handle kernel paging request at virtual address 00020008 Feb 25 06:27:37 burocracia kernel: c0139e3d Feb 25 06:27:37 burocracia kernel: *pde = Feb 25 06:27:37 burocracia kernel: Oops: 0002 Feb 25 06:27:37 burocracia kernel: CPU:1 Feb 25 06:27:37 burocracia kernel: EIP:0010:[bdput+5/96] Feb 25 06:27:37 burocracia kernel: EFLAGS: 00010206 Feb 25 06:27:37 burocracia kernel: eax: 0002 ebx: 0002 ecx: ca58a648 edx: c15ddfa4 Feb 25 06:27:37 burocracia kernel: esi: c15ddfa4 edi: c7108a08 ebp: c15ddfac esp: c15ddf6c Feb 25 06:27:37 burocracia kernel: ds: 0018 es: 0018 ss: 0018 Feb 25 06:27:37 burocracia kernel: Process kswapd (pid: 3, stackpage=c15dd000) Feb 25 06:27:37 burocracia kernel: Stack: ca58a640 c0146d82 0002 ca58a640 c0146dd7 ca58a640 c7111088 c7111080 Feb 25 06:27:37 burocracia kernel:c0147009 c15ddfa4 00010f00 0004 2576 cb8f7b88 cfb17808 Feb 25 06:27:37 burocracia kernel: c0147039 c012ccdf 0006 0004 0006 0004 Feb 25 06:27:37 burocracia kernel: Call Trace: [clear_inode+194/220] [dispose_list+59/84] [prune_icache+261/276] [shrink_icache_memory+33/48] [do_try_to_free_pages+103/124] [kswapd+103/244] [kernel_thread+40/56] Feb 25 06:27:37 burocracia kernel: Code: f0 ff 4b 08 0f 94 c0 84 c0 74 4d f0 fe 0d 20 09 26 c0 0f 88 which decodes into Code; Before first symbol <_EIP>: Code; Before first symbol 0: f0 ff 4b 08 lock decl 0x8(%ebx) Code; 0004 Before first symbol 4: 0f 94 c0 sete %al Code; 0007 Before first symbol 7: 84 c0 test %al,%al Code; 0009 Before first symbol 9: 74 4d je 58 <_EIP+0x58> 0058 Before first symbol Code; 000b Before first symbol b: f0 fe 0d 20 09 26 c0 lock decb 0xc0260920 Code; 0012 Before first symbol 12: 0f 88 00 00 00 00 js 18 <_EIP+0x18> 0018 Before first symbol and a series (2 or 3, not sure) of "kernel BUG"s, finishing with "deactivating console" or words to that effect. On reboot I'm afraid the only bit that survived after the oops was Feb 25 06:27:39 burocracia kernel: kernel BUG at exit.c:458! Feb 25 06:27:39 burocracia kernel: invalid operand: Feb 25 06:27:39 burocracia kernel: CPU:1 Feb 25 06:27:39 burocracia kernel: EIP:0010:[do_exit+668/680] Feb 25 06:27:39 burocracia kernel: EFLAGS: 00010286 Feb 25 06:27:39 burocracia kernel: eax: 001a ebx: c025b460 ecx: 0046 edx: 0100 Feb 25 07:45:11 burocracia kernel: activating NMI Watchdog ... done. Feb 25 07:45:11 burocracia kernel: CPU#0 NMI appears to be stuck. Feb 25 07:45:11 burocracia kernel: cpu: 0, clocks: 1002185, slice: 334061 Feb 25 07:45:11 burocracia kernel: cpu: 1, clocks: 1002185, slice: 334061 the box is debian unstable, w/reiserprogs from the reiser site. Let me know if any other info'll be useful. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: BOFH excuse #277: Your Flux Capacitor has gone bad. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
oops followed by kernel BUGs
When I woke today I found I'd gotten the following oops, Feb 25 06:27:37 burocracia kernel: Unable to handle kernel paging request at virtual address 00020008 Feb 25 06:27:37 burocracia kernel: c0139e3d Feb 25 06:27:37 burocracia kernel: *pde = Feb 25 06:27:37 burocracia kernel: Oops: 0002 Feb 25 06:27:37 burocracia kernel: CPU:1 Feb 25 06:27:37 burocracia kernel: EIP:0010:[bdput+5/96] Feb 25 06:27:37 burocracia kernel: EFLAGS: 00010206 Feb 25 06:27:37 burocracia kernel: eax: 0002 ebx: 0002 ecx: ca58a648 edx: c15ddfa4 Feb 25 06:27:37 burocracia kernel: esi: c15ddfa4 edi: c7108a08 ebp: c15ddfac esp: c15ddf6c Feb 25 06:27:37 burocracia kernel: ds: 0018 es: 0018 ss: 0018 Feb 25 06:27:37 burocracia kernel: Process kswapd (pid: 3, stackpage=c15dd000) Feb 25 06:27:37 burocracia kernel: Stack: ca58a640 c0146d82 0002 ca58a640 c0146dd7 ca58a640 c7111088 c7111080 Feb 25 06:27:37 burocracia kernel:c0147009 c15ddfa4 00010f00 0004 2576 cb8f7b88 cfb17808 Feb 25 06:27:37 burocracia kernel: c0147039 c012ccdf 0006 0004 0006 0004 Feb 25 06:27:37 burocracia kernel: Call Trace: [clear_inode+194/220] [dispose_list+59/84] [prune_icache+261/276] [shrink_icache_memory+33/48] [do_try_to_free_pages+103/124] [kswapd+103/244] [kernel_thread+40/56] Feb 25 06:27:37 burocracia kernel: Code: f0 ff 4b 08 0f 94 c0 84 c0 74 4d f0 fe 0d 20 09 26 c0 0f 88 which decodes into Code; Before first symbol _EIP: Code; Before first symbol 0: f0 ff 4b 08 lock decl 0x8(%ebx) Code; 0004 Before first symbol 4: 0f 94 c0 sete %al Code; 0007 Before first symbol 7: 84 c0 test %al,%al Code; 0009 Before first symbol 9: 74 4d je 58 _EIP+0x58 0058 Before first symbol Code; 000b Before first symbol b: f0 fe 0d 20 09 26 c0 lock decb 0xc0260920 Code; 0012 Before first symbol 12: 0f 88 00 00 00 00 js 18 _EIP+0x18 0018 Before first symbol and a series (2 or 3, not sure) of "kernel BUG"s, finishing with "deactivating console" or words to that effect. On reboot I'm afraid the only bit that survived after the oops was Feb 25 06:27:39 burocracia kernel: kernel BUG at exit.c:458! Feb 25 06:27:39 burocracia kernel: invalid operand: Feb 25 06:27:39 burocracia kernel: CPU:1 Feb 25 06:27:39 burocracia kernel: EIP:0010:[do_exit+668/680] Feb 25 06:27:39 burocracia kernel: EFLAGS: 00010286 Feb 25 06:27:39 burocracia kernel: eax: 001a ebx: c025b460 ecx: 0046 edx: 0100 Feb 25 07:45:11 burocracia kernel: activating NMI Watchdog ... done. Feb 25 07:45:11 burocracia kernel: CPU#0 NMI appears to be stuck. Feb 25 07:45:11 burocracia kernel: cpu: 0, clocks: 1002185, slice: 334061 Feb 25 07:45:11 burocracia kernel: cpu: 1, clocks: 1002185, slice: 334061 the box is debian unstable, w/reiserprogs from the reiser site. Let me know if any other info'll be useful. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: BOFH excuse #277: Your Flux Capacitor has gone bad. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
problem with modules in 2.2.14
Hello all. We've written a module for kernel 2.2.14 that includes a driver for 2 "virtual" devices. These devices don't actually exist, they're implemented with two circular buffers; what's written into one of the devices is read from the other, and viceversa. We believe the buffer is correctly written, but we have the following problem: We can insmod, read, write, and rmmod, and everything's OK. However, as soon as we logout we get 'INIT: Id "n" respawning too fast: disabled for 5 minutes.', where "n" is each of the consoles we were logged in at (5 minutes later, the same message occurrs). We have no idea what it could be, any pointers? Julio Bianco Edgardo Hames FaMAF - UNC [ forwarded w/translation by me ] -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Somewhere, just out of sight, the unicorns are gathering. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
problem with modules in 2.2.14
Hello all. We've written a module for kernel 2.2.14 that includes a driver for 2 "virtual" devices. These devices don't actually exist, they're implemented with two circular buffers; what's written into one of the devices is read from the other, and viceversa. We believe the buffer is correctly written, but we have the following problem: We can insmod, read, write, and rmmod, and everything's OK. However, as soon as we logout we get 'INIT: Id "n" respawning too fast: disabled for 5 minutes.', where "n" is each of the consoles we were logged in at (5 minutes later, the same message occurrs). We have no idea what it could be, any pointers? Julio Bianco Edgardo Hames FaMAF - UNC [ forwarded w/translation by me ] -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Somewhere, just out of sight, the unicorns are gathering. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
Re: OK to mount multiple FS in one dir?
On Wed, Feb 07, 2001 at 12:25:10AM -0600, Peter Samuelson wrote: > > [Wakko Warner] > > I have a question, why was this idea even considered? > > Al Viro likes Plan9 process-local namespaces. He seems to be trying to > move Linux in that direction. In the past year he has been hacking the > semantics of filesystems and mounting, probably with namespaces as an > eventual goal, and this is one of the things that has fallen out of the > implementation. Aren't "translucid" mounts the idea behind this? -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: For courage mounteth with occasion. -- William Shakespeare, "King John" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
different IRQ settings for different MPS settings?
With a MPS setting of 1.4 USB doesn't work on me; it timeouts, constantly. With MPS setting of 1.1 everything is OK. a dirty diff of lspci -vvvxx gives 62c62 < Interrupt: pin D routed to IRQ 5 --- > Interrupt: pin D routed to IRQ 19 77c77 < Interrupt: pin D routed to IRQ 5 --- > Interrupt: pin D routed to IRQ 19 103c103 < Interrupt: pin A routed to IRQ 11 --- > Interrupt: pin A routed to IRQ 18 124c124 < Interrupt: pin A routed to IRQ 5 --- > Interrupt: pin A routed to IRQ 19 140c140 < Interrupt: pin A routed to IRQ 10 --- > Interrupt: pin A routed to IRQ 16 157c157 < Interrupt: pin A routed to IRQ 12 --- > Interrupt: pin A routed to IRQ 17 186c186 < Interrupt: pin A routed to IRQ 10 --- > Interrupt: pin A routed to IRQ 16 (I've attached both lspci -vvvxx's, so you can diff -u that if you want). My question(s) is(are) is this a known bug, is this correct behaviour, am I missing something, and why is USB the only subsystem affected. Phew. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Se Deus é amor e o amor é cego, Ray Charles é Deus? lspci_mps1.1.gz lspci_mps1.4.gz
Oops on UHCI module unload (2.4.2-pre1)
When trying to figure out how to get USB to work (it was the MPS setting, more in other post) I got a repeatable Oops (is it an oops? it doesn't say "Oops!" like I thought they do). That is, I'd boot, modprobe uhci, plug something in, get lots of timeouts, unplug the something, modprobe -r uhci. Oops. Attached are two ksymoops outputs, for the two times I did this. I stopped modprobe -r'ing after that, then fixed the problem wrt timeouts, and am now unable to reproduce the bug (even going back to MPS 1.4). Let me know if there's anything else of use I can provide, and if I got the ksymoops thing right :) -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Amnesia used to be my favorite word, but then I forgot it. ksymoops.out.1.gz ksymoops.out.2.gz
Re: Oops on module onload
On Tue, Feb 06, 2001 at 05:50:30PM +1100, Keith Owens wrote: > On Tue, 6 Feb 2001 02:14:21 -0300, > John R Lenton <[EMAIL PROTECTED]> wrote: > >I'm getting oopsen on unloading the USB modules; when I run > >ksymoops over the oops it decodes into any-vegetable-module (I > >assume because the ksyms are no longer the same). In what way > >could I obtain a meaningul decoded oops? > > man insmod, find ksymoops assistance. doh! -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: El trabajo endulza siempre la vida, pero los dulces no le gustan a todo el mundo. -- Victor Hugo. (1802-1885) Novelista francés. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Oops on module onload
On Tue, Feb 06, 2001 at 05:50:30PM +1100, Keith Owens wrote: On Tue, 6 Feb 2001 02:14:21 -0300, John R Lenton [EMAIL PROTECTED] wrote: I'm getting oopsen on unloading the USB modules; when I run ksymoops over the oops it decodes into any-vegetable-module (I assume because the ksyms are no longer the same). In what way could I obtain a meaningul decoded oops? man insmod, find ksymoops assistance. doh! -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: El trabajo endulza siempre la vida, pero los dulces no le gustan a todo el mundo. -- Victor Hugo. (1802-1885) Novelista francés. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Oops on UHCI module unload (2.4.2-pre1)
When trying to figure out how to get USB to work (it was the MPS setting, more in other post) I got a repeatable Oops (is it an oops? it doesn't say "Oops!" like I thought they do). That is, I'd boot, modprobe uhci, plug something in, get lots of timeouts, unplug the something, modprobe -r uhci. Oops. Attached are two ksymoops outputs, for the two times I did this. I stopped modprobe -r'ing after that, then fixed the problem wrt timeouts, and am now unable to reproduce the bug (even going back to MPS 1.4). Let me know if there's anything else of use I can provide, and if I got the ksymoops thing right :) -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Amnesia used to be my favorite word, but then I forgot it. ksymoops.out.1.gz ksymoops.out.2.gz
Re: OK to mount multiple FS in one dir?
On Wed, Feb 07, 2001 at 12:25:10AM -0600, Peter Samuelson wrote: [Wakko Warner] I have a question, why was this idea even considered? Al Viro likes Plan9 process-local namespaces. He seems to be trying to move Linux in that direction. In the past year he has been hacking the semantics of filesystems and mounting, probably with namespaces as an eventual goal, and this is one of the things that has fallen out of the implementation. Aren't "translucid" mounts the idea behind this? -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: For courage mounteth with occasion. -- William Shakespeare, "King John" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Oops on module onload
Hi all. I'm getting oopsen on unloading the USB modules; when I run ksymoops over the oops it decodes into any-vegetable-module (I assume because the ksyms are no longer the same). In what way could I obtain a meaningul decoded oops? -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: it has been said that redhat is the thing Marc Ewing wears on his head. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bugs or other?
On Mon, Feb 05, 2001 at 09:57:39AM -, Yan Li wrote: > uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4 > usb_control/bulk_msg: timeout > usb.c: USB device not accepting new address=3 (error=-110) I got those on my (SMP) motherboard when I had my BIOS setting for MPS at 1.4; changing it to 1.1 fixed the problem. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: One picture is worth more than ten thousand words. -- Chinese proverb - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bugs or other?
On Mon, Feb 05, 2001 at 09:57:39AM -, Yan Li wrote: uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4 usb_control/bulk_msg: timeout usb.c: USB device not accepting new address=3 (error=-110) I got those on my (SMP) motherboard when I had my BIOS setting for MPS at 1.4; changing it to 1.1 fixed the problem. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: One picture is worth more than ten thousand words. -- Chinese proverb - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Oops on module onload
Hi all. I'm getting oopsen on unloading the USB modules; when I run ksymoops over the oops it decodes into any-vegetable-module (I assume because the ksyms are no longer the same). In what way could I obtain a meaningul decoded oops? -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: apt it has been said that redhat is the thing Marc Ewing wears on his head. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
VIA IDE problems related to heat?
I'm looking for confirmations on any kind of correlation between the problems people have been having with the assorted VIA IDE chipsets and possible overheating of said chipsets. I'm asking because I suffered from the VIA-chipset-ate-my-data bug, and I've been trying to reproduce it to no avail. The only thing I haven't been able to recreate is the heat (ambient was ~35C (~95F) at the time), and noticing that now with ambient at ~25C (80F) the heatsink of the 694x quickly hits ~40 when doing heavy I/O, whereas most articles I've read seem to think 25-30C is about right, and that I was doing this heavy i/o thing when the bug bit... if any of you know what temperature this thing _should_ be, and further if y'all could get onto those chipsets with thermometers to see if we have a temp vs. crashes distribution, we might be onto something. Or maybe not. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: La humanidad es como es. No se trata de cambiarla, sino de conocerla. -- Gustave Flaubert. (1821-1880) Escritor francés. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
VIA IDE problems related to heat?
I'm looking for confirmations on any kind of correlation between the problems people have been having with the assorted VIA IDE chipsets and possible overheating of said chipsets. I'm asking because I suffered from the VIA-chipset-ate-my-data bug, and I've been trying to reproduce it to no avail. The only thing I haven't been able to recreate is the heat (ambient was ~35C (~95F) at the time), and noticing that now with ambient at ~25C (80F) the heatsink of the 694x quickly hits ~40 when doing heavy I/O, whereas most articles I've read seem to think 25-30C is about right, and that I was doing this heavy i/o thing when the bug bit... if any of you know what temperature this thing _should_ be, and further if y'all could get onto those chipsets with thermometers to see if we have a temp vs. crashes distribution, we might be onto something. Or maybe not. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: La humanidad es como es. No se trata de cambiarla, sino de conocerla. -- Gustave Flaubert. (1821-1880) Escritor francés. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Disk is cheap?
On Tue, Jan 30, 2001 at 06:58:22PM -, mirabilos wrote: > I accept donations in IDE and SCSI, as well as parport devices. I have a parport device (one of the few things left from my XT). I can send it to you if you pay shipping. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Saints should always be judged guilty until they are proven innocent. - George Orwell - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Disk is cheap?
On Tue, Jan 30, 2001 at 06:58:22PM -, mirabilos wrote: I accept donations in IDE and SCSI, as well as parport devices. I have a parport device (one of the few things left from my XT). I can send it to you if you pay shipping. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Saints should always be judged guilty until they are proven innocent. - George Orwell - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
oopsen in 2.4.0-pre9
Several oops come up when using a lot of memory (using imagemagick on PIA1.tif from photojournal.jpl.nasa.gov/tiff, on a 64MB machine, for example) The weird thing is the oops happen *after* I've finished with imagemagick (or the gimp, or ...). In this particular situation netscape suddenly died, together with wmtime, and then the whole of X hung. I entered via the network, to find that xfs had died (explaining X's hanging), and as soon as I restarted X the whole box was gone. It still responded to pings, but even the active ssh session was dead and I couldn't get a new one. Please email me if you need anything else (other than the attached ksymoops output, that is). -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: 1 + 1 = 3, for large values of 1. oopsen.txt.gz
oopsen in 2.4.0-pre9
Several oops come up when using a lot of memory (using imagemagick on PIA1.tif from photojournal.jpl.nasa.gov/tiff, on a 64MB machine, for example) The weird thing is the oops happen *after* I've finished with imagemagick (or the gimp, or ...). In this particular situation netscape suddenly died, together with wmtime, and then the whole of X hung. I entered via the network, to find that xfs had died (explaining X's hanging), and as soon as I restarted X the whole box was gone. It still responded to pings, but even the active ssh session was dead and I couldn't get a new one. Please email me if you need anything else (other than the attached ksymoops output, that is). -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: 1 + 1 = 3, for large values of 1. oopsen.txt.gz
