Re: 2.4.6 + MediaGX = kernel panic
On 7-Jul-01 at 20:42, Alan Cox ([EMAIL PROTECTED]) wrote: > > I have Casio Fiva 102 which is a mini notebook based on Cyrix MediaGX > > (clone) chipset. 2.4.5 runs like a charm, but 2.4.6, immediately > > after starting, displays this: > > 2.4.7pre3 should fix that one It works, thanks. Eugene - 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/
2.4.6 + MediaGX = kernel panic
I have Casio Fiva 102 which is a mini notebook based on Cyrix MediaGX (clone) chipset. 2.4.5 runs like a charm, but 2.4.6, immediately after starting, displays this: zone(0): 4096 pages. zone(1): 11648 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=linux ro root=304 sb=0x220,5,1,5 Initializing CPU#0 Working around Cyrix MediaGX virtual DMA bugs Console: colour VGA+ 80x25 kernel BUG at softirq.c:206! == The rest of the output is passed through ksymoops: ksymoops 2.3.3 on i586 2.4.5. Options used -v /usr/src/linux/vmlinux (specified) -K (specified) -L (specified) -O (specified) -m /usr/src/linux/System.map (default) invalid operand: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010082 eax: 001d ebx: c0253b20 ecx: 0001 edx: c01fce68 esi: c0253b20 edi: 0001 ebp: esp: c020befc ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c020b000) Stack: c01d1caa c01d1d26 00ce 0009 c023d5c0 c023d5c0 c020bf40 c0113d1f c023d5c0 c023b900 c010807d c0201e60 c020bf9f 02d4 c01fca40 02d4 c0106d80 c0201e60 02d4 c020bf9f 02d4 Call trace: [] [] [] [] [] Code: 0f 0b 83 c4 0c 8b 43 08 85 c0 75 18 fb 8b 43 10 50 8b 43 0c >>EIP; c0113f0e<= Trace; c0113d1f Trace; c010807d Trace; c0106d80 Trace; c011092f Trace; c0105000 <_stext+0/0> Code; c0113f0e <_EIP>: Code; c0113f0e<= 0: 0f 0b ud2a <= Code; c0113f10 2: 83 c4 0c add$0xc,%esp Code; c0113f13 5: 8b 43 08 mov0x8(%ebx),%eax Code; c0113f16 8: 85 c0 test %eax,%eax Code; c0113f18 a: 75 18 jne24 <_EIP+0x24> c0113f32 Code; c0113f1a c: fbsti Code; c0113f1b d: 8b 43 10 mov0x10(%ebx),%eax Code; c0113f1e 10: 50push %eax Code; c0113f1f 11: 8b 43 0c mov0xc(%ebx),%eax Kernel panic: Aiee, killing interrupt handler! Tell me if I can provide more information Eugene - 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: [Acpi] Re: ACPI fundamental locking problems
In article <[EMAIL PROTECTED]>, Alexander Viro <[EMAIL PROTECTED]> writes: >> Doesn't the approach "treat a chunk of data built into bzImage as >> populated ramfs" look cleaner? No need to fiddle with tar format, >> no copying data from place to place. > > What the hell _is_ "populated ramfs"? The thing doesn't live in array > of blocks. Its directory structure consists of a bunch of dentries. I am stupid. But the point still stays: having an image of pre-populated filesystem (some other than ramfs) that you only need to load into RAM seems more sutable than parsing tar format. Maybe (probably) I am missing something. Eugene - 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: [Acpi] Re: ACPI fundamental locking problems
In article <[EMAIL PROTECTED]>, Linus Torvalds <[EMAIL PROTECTED]> writes: > I don't like the current initrd very much myself, I have to admit. I'm not > going to accept a "you have to have a ramdisk" approach - I think the > ramdisks are really broken. > > But I've seen a "populate ramfs from a tar-file built into 'bzImage'" > patch somewhere, and that would be a whole lot more palatable to me. Doesn't the approach "treat a chunk of data built into bzImage as populated ramfs" look cleaner? No need to fiddle with tar format, no copying data from place to place. Eugene - 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: [Acpi] Re: ACPI fundamental locking problems
In article [EMAIL PROTECTED], Linus Torvalds [EMAIL PROTECTED] writes: I don't like the current initrd very much myself, I have to admit. I'm not going to accept a you have to have a ramdisk approach - I think the ramdisks are really broken. But I've seen a populate ramfs from a tar-file built into 'bzImage' patch somewhere, and that would be a whole lot more palatable to me. Doesn't the approach treat a chunk of data built into bzImage as populated ramfs look cleaner? No need to fiddle with tar format, no copying data from place to place. Eugene - 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: [Acpi] Re: ACPI fundamental locking problems
In article [EMAIL PROTECTED], Alexander Viro [EMAIL PROTECTED] writes: Doesn't the approach treat a chunk of data built into bzImage as populated ramfs look cleaner? No need to fiddle with tar format, no copying data from place to place. What the hell _is_ populated ramfs? The thing doesn't live in array of blocks. Its directory structure consists of a bunch of dentries. I am stupid. But the point still stays: having an image of pre-populated filesystem (some other than ramfs) that you only need to load into RAM seems more sutable than parsing tar format. Maybe (probably) I am missing something. Eugene - 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/
2.4.6 + MediaGX = kernel panic
I have Casio Fiva 102 which is a mini notebook based on Cyrix MediaGX (clone) chipset. 2.4.5 runs like a charm, but 2.4.6, immediately after starting, displays this: zone(0): 4096 pages. zone(1): 11648 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=linux ro root=304 sb=0x220,5,1,5 Initializing CPU#0 Working around Cyrix MediaGX virtual DMA bugs Console: colour VGA+ 80x25 kernel BUG at softirq.c:206! == The rest of the output is passed through ksymoops: ksymoops 2.3.3 on i586 2.4.5. Options used -v /usr/src/linux/vmlinux (specified) -K (specified) -L (specified) -O (specified) -m /usr/src/linux/System.map (default) invalid operand: CPU:0 EIP:0010:[c0113f0e] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010082 eax: 001d ebx: c0253b20 ecx: 0001 edx: c01fce68 esi: c0253b20 edi: 0001 ebp: esp: c020befc ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c020b000) Stack: c01d1caa c01d1d26 00ce 0009 c023d5c0 c023d5c0 c020bf40 c0113d1f c023d5c0 c023b900 c010807d c0201e60 c020bf9f 02d4 c01fca40 02d4 c0106d80 c0201e60 02d4 c020bf9f 02d4 Call trace: [c0113d1f] [c010807d] [c0106d80] [c011092f] [c0105000] Code: 0f 0b 83 c4 0c 8b 43 08 85 c0 75 18 fb 8b 43 10 50 8b 43 0c EIP; c0113f0e tasklet_hi_action+6a/b4 = Trace; c0113d1f do_softirq+3f/68 Trace; c010807d do_IRQ+9d/b0 Trace; c0106d80 ret_from_intr+0/7 Trace; c011092f register_console+22b/234 Trace; c0105000 _stext+0/0 Code; c0113f0e tasklet_hi_action+6a/b4 _EIP: Code; c0113f0e tasklet_hi_action+6a/b4 = 0: 0f 0b ud2a = Code; c0113f10 tasklet_hi_action+6c/b4 2: 83 c4 0c add$0xc,%esp Code; c0113f13 tasklet_hi_action+6f/b4 5: 8b 43 08 mov0x8(%ebx),%eax Code; c0113f16 tasklet_hi_action+72/b4 8: 85 c0 test %eax,%eax Code; c0113f18 tasklet_hi_action+74/b4 a: 75 18 jne24 _EIP+0x24 c0113f32 tasklet_hi_action+8e/b4 Code; c0113f1a tasklet_hi_action+76/b4 c: fbsti Code; c0113f1b tasklet_hi_action+77/b4 d: 8b 43 10 mov0x10(%ebx),%eax Code; c0113f1e tasklet_hi_action+7a/b4 10: 50push %eax Code; c0113f1f tasklet_hi_action+7b/b4 11: 8b 43 0c mov0xc(%ebx),%eax Kernel panic: Aiee, killing interrupt handler! Tell me if I can provide more information Eugene - 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: 2.4.6 + MediaGX = kernel panic
On 7-Jul-01 at 20:42, Alan Cox ([EMAIL PROTECTED]) wrote: I have Casio Fiva 102 which is a mini notebook based on Cyrix MediaGX (clone) chipset. 2.4.5 runs like a charm, but 2.4.6, immediately after starting, displays this: 2.4.7pre3 should fix that one It works, thanks. Eugene - 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/
[2.4.2] APM unwanted wakeup from standby (kreiserfsd?)
Gentlemen,
this might be somewhat offtopic but I could not find answers on the Net
and "official" APM page seems dramatically out of date...
I recently bought Casio Fiva mini notebook that has APM BIOS 1.2,
Linux APM support partly works. "Hibernate" does not work at all,
but let it be. "Standby" ("apm -S") puts the box in standby mode
but after 10..30 seconds it inevitably awakes with a message like
"Normal resume from standby". This happens even if there are no
processes that would initiate disk/screen/whatever activity (single
user mode).
My suspect is kreiserfsd. If I am right, could it be modified to
honor standby mode and stop disk access? If I am wrong, does
anyone have suggestions/advice/ideas how to make standby mode work?
(advice on making hibernate work is also welcome)
Eugene
-
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: Mounting ISO via Loop Devices
In article <[EMAIL PROTECTED]>, "Brent D. Norris" <[EMAIL PROTECTED]> writes: > On my redhat 7.1 machine I have been using the 2.4.0 redhat kernel and > mounting ISO's to loop devices and it worked fine. I upgraded to a 2.4.2 > kernel and now none of the ISO's will mount. They all hang when the > command is run. Are there any other known occurences of this? I can confirm that mount over loopback hangs on 2.4.2 (from kernel.org), regardless of the filesystem type. Eugene - 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: Mounting ISO via Loop Devices
In article [EMAIL PROTECTED], "Brent D. Norris" [EMAIL PROTECTED] writes: On my redhat 7.1 machine I have been using the 2.4.0 redhat kernel and mounting ISO's to loop devices and it worked fine. I upgraded to a 2.4.2 kernel and now none of the ISO's will mount. They all hang when the command is run. Are there any other known occurences of this? I can confirm that mount over loopback hangs on 2.4.2 (from kernel.org), regardless of the filesystem type. Eugene - 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: rsync over ssh on 2.4.2 to 2.2.18
In article <[EMAIL PROTECTED]>, Russell King <[EMAIL PROTECTED]> writes: > I'm seeing odd behaviour with rsync over ssh between two x86 machines - I've seen hanging rsync over ssh more than once, while sending much data from an x86 running Linux (late 2.3.x) to Sparc/Solaris2.5.1 over ssh 1.2.26. I had a feeling that it was triggered by certain data patterns because it often stopped at the same spot after restart (and therefore I attributed it to a bug in rsync). I did not investigate further. Eugene - 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: rsync over ssh on 2.4.2 to 2.2.18
In article [EMAIL PROTECTED], Russell King [EMAIL PROTECTED] writes: I'm seeing odd behaviour with rsync over ssh between two x86 machines - I've seen hanging rsync over ssh more than once, while sending much data from an x86 running Linux (late 2.3.x) to Sparc/Solaris2.5.1 over ssh 1.2.26. I had a feeling that it was triggered by certain data patterns because it often stopped at the same spot after restart (and therefore I attributed it to a bug in rsync). I did not investigate further. Eugene - 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: 2.4.0 tcp over firewall - no connection
In article <[EMAIL PROTECTED]>, Doug McNaught <[EMAIL PROTECTED]> writes: >> I noticed rather strange behavior: stock 2.4.0 with old ISA 3Com >> on UP compiled as UP cannot open TCP connection to hosts behind a >> firewall. E.g. it is impossible to go to http://www.etrade.com/ - >> connect just never finishes. 2.2.17 on the same hardware works >> right. 2.4.0 on SMP over PPP connection works right too. MTU >> is 1500 in both cases. In both cases, kernel is compiled with >> netfilter as modules, but those are not loaded. > > Known problem, exhaustively discussed on the list, and not related > to your NIC. Disable ECN (explicit congestion notification), either > in your kernel compile or in /proc/sys/. This really was ECN, sorry for noise in this list... Eugene - 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/
2.4.0 tcp over firewall - no connection
I noticed rather strange behavior: stock 2.4.0 with old ISA 3Com on UP compiled as UP cannot open TCP connection to hosts behind a firewall. E.g. it is impossible to go to http://www.etrade.com/ - connect just never finishes. 2.2.17 on the same hardware works right. 2.4.0 on SMP over PPP connection works right too. MTU is 1500 in both cases. In both cases, kernel is compiled with netfilter as modules, but those are not loaded. I did not investigate further yet, just wanted to bring this to attention of those whom it may concern... Eugene - 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/
2.4.0 tcp over firewall - no connection
I noticed rather strange behavior: stock 2.4.0 with old ISA 3Com on UP compiled as UP cannot open TCP connection to hosts behind a firewall. E.g. it is impossible to go to http://www.etrade.com/ - connect just never finishes. 2.2.17 on the same hardware works right. 2.4.0 on SMP over PPP connection works right too. MTU is 1500 in both cases. In both cases, kernel is compiled with netfilter as modules, but those are not loaded. I did not investigate further yet, just wanted to bring this to attention of those whom it may concern... Eugene - 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: 2.4.0 tcp over firewall - no connection
In article [EMAIL PROTECTED], Doug McNaught [EMAIL PROTECTED] writes: I noticed rather strange behavior: stock 2.4.0 with old ISA 3Com on UP compiled as UP cannot open TCP connection to hosts behind a firewall. E.g. it is impossible to go to http://www.etrade.com/ - connect just never finishes. 2.2.17 on the same hardware works right. 2.4.0 on SMP over PPP connection works right too. MTU is 1500 in both cases. In both cases, kernel is compiled with netfilter as modules, but those are not loaded. Known problem, exhaustively discussed on the list, and not related to your NIC. Disable ECN (explicit congestion notification), either in your kernel compile or in /proc/sys/something. This really was ECN, sorry for noise in this list... Eugene - 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/
2.4.0-test11: "_isofs_bmap: block < 0"
I have a cdrom with iso9660+RR filesystem, with a few hundred files in ten directories. With all previous kernels (checked up to test11-pre3), I had no problems with it. With test11 final, "ls" command shows zero entries on the mounted CD, and each "ls" attempt causes this kernel message: _isofs_bmap: block < 0 If I open a file directly, it opens and is read fine, so it's only readdir() that is not working. Tell me if I need to provide more info. Eugene - 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/
2.4.0-test11: _isofs_bmap: block 0
I have a cdrom with iso9660+RR filesystem, with a few hundred files in ten directories. With all previous kernels (checked up to test11-pre3), I had no problems with it. With test11 final, "ls" command shows zero entries on the mounted CD, and each "ls" attempt causes this kernel message: _isofs_bmap: block 0 If I open a file directly, it opens and is read fine, so it's only readdir() that is not working. Tell me if I need to provide more info. Eugene - 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/
2.4.0-test7: umount + mount = same directory (CD)
The problem that I reported for -test6 is still here: I have a mounted CD. "ls -l /mount/point" shows its directory. If I do umount /mount/point, replace CD with another one and mount on the same point (I did not try different mount point), "ls -l" shows the directory from the *first* CD. If I try to "mount" and empty tray, then insert a CD and mount it, I see the directory of the new CD. SMP x86, SCSI CDROM (Plextor) on ncr53x810. Eugene - 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/
