2.4.6-pre4 tulip driver still mashed with 21041
I have been following the development of the tulip driver with some interest because my hardware requires it! I have described the hardware setup I use before, but I can post it again if necessary. I will only be able to test new versions/fixes until Tuesday morning (UK) because then I lose my ethernet connection and will not get it back again :-( The tests below were done with a freshly compiled 2.4.6-pre4 kernel with no additional patches of any kind. The last kernel that worked for me straight out of the tarball was 2.4.4-ac6 The symptoms are that with anything above 2.4.4-ac6 nothing gets through to or from the network to my box. The results I get from running "tulip-diag -aa -ee" having run "/etc/rc.d/init.d/network start" (RH 7.1) are: tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DC21041 Tulip adapter at 0xd800. * A potential Tulip chip has been found, but it appears to be active. * Either shutdown the network, or use the '-f' flag to see all values. Digital DC21041 Tulip chip registers at 0xd800: 0x00: ffe08000 0129a000 0129a200 fc66 fffe2202 ebef Port selection is full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. The NWay status register is 50c8. When I set "network stop", the results are: tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DC21041 Tulip adapter at 0xd800. Digital DC21041 Tulip chip registers at 0xd800: 0x00: ffe08000 0129a000 0129a200 fc000102 fffe0200 fffe 0x40: fffe 4bf0 fffe 50c8 ef01 0008 Port selection is full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit unit is set to store-and-forward. The NWay status register is 50c8. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor , device . CardBus Information Structure at offset . Ethernet MAC Station Address 00:C0:F0:14:7B:AE. EEPROM transceiver/media description table. Leaf node at offset 30, default media type 0800 (Autosense). 3 transceiver description blocks: 21041 media index 00 (10baseT). 21041 media index 01 (10base2). 21041 media index 04 (10baseT-Full Duplex). EEPROM contents (64 words): 0x00: 0x08: 0101 c000 14f0 ae7b 1e00 0800 0x10: 0003 0401 0x18: 0x20: 0x28: 0x30: 0x38: 104b 38f4 ID block CRC 0xe3 (vs. 00). Full contents CRC 0x38f4 (read as 0x38f4). Internal autonegotiation state is 'Negotiation complete'. John [EMAIL PROTECTED] - 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-pre4 tulip driver still mashed with 21041
I have been following the development of the tulip driver with some interest because my hardware requires it! I have described the hardware setup I use before, but I can post it again if necessary. I will only be able to test new versions/fixes until Tuesday morning (UK) because then I lose my ethernet connection and will not get it back again :-( The tests below were done with a freshly compiled 2.4.6-pre4 kernel with no additional patches of any kind. The last kernel that worked for me straight out of the tarball was 2.4.4-ac6 The symptoms are that with anything above 2.4.4-ac6 nothing gets through to or from the network to my box. The results I get from running tulip-diag -aa -ee having run /etc/rc.d/init.d/network start (RH 7.1) are: tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DC21041 Tulip adapter at 0xd800. * A potential Tulip chip has been found, but it appears to be active. * Either shutdown the network, or use the '-f' flag to see all values. Digital DC21041 Tulip chip registers at 0xd800: 0x00: ffe08000 0129a000 0129a200 fc66 fffe2202 ebef Port selection is full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. The NWay status register is 50c8. When I set network stop, the results are: tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DC21041 Tulip adapter at 0xd800. Digital DC21041 Tulip chip registers at 0xd800: 0x00: ffe08000 0129a000 0129a200 fc000102 fffe0200 fffe 0x40: fffe 4bf0 fffe 50c8 ef01 0008 Port selection is full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit unit is set to store-and-forward. The NWay status register is 50c8. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor , device . CardBus Information Structure at offset . Ethernet MAC Station Address 00:C0:F0:14:7B:AE. EEPROM transceiver/media description table. Leaf node at offset 30, default media type 0800 (Autosense). 3 transceiver description blocks: 21041 media index 00 (10baseT). 21041 media index 01 (10base2). 21041 media index 04 (10baseT-Full Duplex). EEPROM contents (64 words): 0x00: 0x08: 0101 c000 14f0 ae7b 1e00 0800 0x10: 0003 0401 0x18: 0x20: 0x28: 0x30: 0x38: 104b 38f4 ID block CRC 0xe3 (vs. 00). Full contents CRC 0x38f4 (read as 0x38f4). Internal autonegotiation state is 'Negotiation complete'. John [EMAIL PROTECTED] - 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: Current tulip driver from 2.4.5 is plain broken
Michal Jaegermann wrote: > I mentioned that before but this should be stated clearly. As far > as I am concerned "Linux Tulip driver version 0.9.15-pre2 (May 16, > 2001)", as used in 2.4.5 - and other kernels - is totally buggered. > It comes up, and ethernet interfaces can be configured, but does > not matter how I am playing with options I cannot get a single > packet through. > > Replacing it in 2.4.5 with "Linux Tulip driver version 0.9.14d > (April 3, 2001)", which I have handy, restores sanity immediately > and a network simply works without any heroic efforts. > > My NIC is "Digital DS21143 Tulip rev 65 at 0x8800". BTW - a > version "tulip-1.1.7" from sourceforge behaves exactly like > 0.9.15-pre2. I see exactly the same (broken!) behaviour here. The last kernel that works for me in 2.4.4-ac6, which I'm running at the moment. All subsequent -ac kernels and 2.4.5-pre4 and above are broken. I reported the bug last week. Quick system summary: RH7.1, Duron, KT133, Network card chip "Digital 21041-AA". I get the same problem as above (working kernels set half-duplex, broken kernels set full-duplex). More details available on request, or at http://boudicca.tux.org/hypermail/linux-kernel/2001week21/0278.html Thanks! John [EMAIL PROTECTED] - 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: Current tulip driver from 2.4.5 is plain broken
Michal Jaegermann wrote: I mentioned that before but this should be stated clearly. As far as I am concerned Linux Tulip driver version 0.9.15-pre2 (May 16, 2001), as used in 2.4.5 - and other kernels - is totally buggered. It comes up, and ethernet interfaces can be configured, but does not matter how I am playing with options I cannot get a single packet through. Replacing it in 2.4.5 with Linux Tulip driver version 0.9.14d (April 3, 2001), which I have handy, restores sanity immediately and a network simply works without any heroic efforts. My NIC is Digital DS21143 Tulip rev 65 at 0x8800. BTW - a version tulip-1.1.7 from sourceforge behaves exactly like 0.9.15-pre2. I see exactly the same (broken!) behaviour here. The last kernel that works for me in 2.4.4-ac6, which I'm running at the moment. All subsequent -ac kernels and 2.4.5-pre4 and above are broken. I reported the bug last week. Quick system summary: RH7.1, Duron, KT133, Network card chip Digital 21041-AA. I get the same problem as above (working kernels set half-duplex, broken kernels set full-duplex). More details available on request, or at http://boudicca.tux.org/hypermail/linux-kernel/2001week21/0278.html Thanks! John [EMAIL PROTECTED] - 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: tulip driver BROKEN in 2.4.5-pre4
> Could you post the output of > > #tulip-diag -mm -aa -f > > with the broken driver? > Some code that's required for Linksys Tulip clones was moved > from pnic specific part into the generic part, perhaps that > causes problems. Here is the output from the kernels I've tested to try to get the driver working: 2.4.4-ac6, this kernel works! tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DC21041 Tulip adapter at 0xd800. Digital DC21041 Tulip chip registers at 0xd800: 0x00: ffe08000 0129f000 0129f200 fc66 fffe2002 ebef 0x40: fffe 03ff fffe 01c8 ef05 ff3f 0008 Port selection is half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. The NWay status register is 01c8. No MII transceivers found! Internal autonegotiation state is 'Autonegotiation disabled'. -- 2.4.5-pre4 this kernel doesn't work tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DC21041 Tulip adapter at 0xd800. Digital DC21041 Tulip chip registers at 0xd800: 0x00: ffe08000 0129e000 0129e200 fc66 fffe2202 ebef 0x40: fffe 03ff fffe 50c8 ef01 0008 Port selection is full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. The NWay status register is 50c8. No MII transceivers found! Internal autonegotiation state is 'Negotiation complete'. -- 2.4.4-ac9 with tulip 1.1.7 driver (from sf.net/projects/tulip) tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DC21041 Tulip adapter at 0xd800. Digital DC21041 Tulip chip registers at 0xd800: 0x00: ffe08000 0129f000 0129f200 fc66 fffe2202 ebef 0x40: fffe 03ff fffe 50c8 ef01 0008 Port selection is full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. The NWay status register is 50c8. No MII transceivers found! Internal autonegotiation state is 'Negotiation complete'. Let me know if I can provide any more useful information about the driver problem. John [EMAIL PROTECTED] - 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: tulip driver BROKEN in 2.4.5-pre4
Could you post the output of #tulip-diag -mm -aa -f with the broken driver? Some code that's required for Linksys Tulip clones was moved from pnic specific part into the generic part, perhaps that causes problems. Here is the output from the kernels I've tested to try to get the driver working: 2.4.4-ac6, this kernel works! tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DC21041 Tulip adapter at 0xd800. Digital DC21041 Tulip chip registers at 0xd800: 0x00: ffe08000 0129f000 0129f200 fc66 fffe2002 ebef 0x40: fffe 03ff fffe 01c8 ef05 ff3f 0008 Port selection is half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. The NWay status register is 01c8. No MII transceivers found! Internal autonegotiation state is 'Autonegotiation disabled'. -- 2.4.5-pre4 this kernel doesn't work tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DC21041 Tulip adapter at 0xd800. Digital DC21041 Tulip chip registers at 0xd800: 0x00: ffe08000 0129e000 0129e200 fc66 fffe2202 ebef 0x40: fffe 03ff fffe 50c8 ef01 0008 Port selection is full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. The NWay status register is 50c8. No MII transceivers found! Internal autonegotiation state is 'Negotiation complete'. -- 2.4.4-ac9 with tulip 1.1.7 driver (from sf.net/projects/tulip) tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DC21041 Tulip adapter at 0xd800. Digital DC21041 Tulip chip registers at 0xd800: 0x00: ffe08000 0129f000 0129f200 fc66 fffe2202 ebef 0x40: fffe 03ff fffe 50c8 ef01 0008 Port selection is full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. The NWay status register is 50c8. No MII transceivers found! Internal autonegotiation state is 'Negotiation complete'. Let me know if I can provide any more useful information about the driver problem. John [EMAIL PROTECTED] - 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/
tulip driver BROKEN in 2.4.5-pre4
Okay, so Jeff Garzik already knows about this - I told him last week - but seeing as how the code has made it to a Linus pre-release without a fix I thought I'd better post the breakage description to l-k! The symptoms are: In 2.4.5-pre4 (and 2.4.4-ac8 and above - note: I didn't try -ac7) system boots up normally, card is recognised etc, but all networking services fail because it's not possible to talk to the network. The system appears to be stable apart from the bug (possible to compile kernels, run X, etc.), but nothing gets to or from the network. I'm using the "DECchip Tulip (dc21x4x) PCI support" option to get the driver for the PCI card which has a Digital 21041 chip in it. FWIW I think it might be related to the selection of full- or half-duplex. 2.4.4-ac6 (which works fine) says: Port selection is half-duplex when I run tulip-diag, whereas 2.4.5-pre4 says Port selection is full-duplex My system is RH7.1 (using gcc-2.96 not kgcc) Duron 750, KT133 chipset (not kt133a!) Network card details (it is a PCI): Kingston KNE40BT (1995) Digital 21041-AA DC1017BA 21-40756-01 Dec 1994 S15313-02 A 9615 More details on request. And I'm willing to test patches... John [EMAIL PROTECTED] - 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/
tulip driver BROKEN in 2.4.5-pre4
Okay, so Jeff Garzik already knows about this - I told him last week - but seeing as how the code has made it to a Linus pre-release without a fix I thought I'd better post the breakage description to l-k! The symptoms are: In 2.4.5-pre4 (and 2.4.4-ac8 and above - note: I didn't try -ac7) system boots up normally, card is recognised etc, but all networking services fail because it's not possible to talk to the network. The system appears to be stable apart from the bug (possible to compile kernels, run X, etc.), but nothing gets to or from the network. I'm using the DECchip Tulip (dc21x4x) PCI support option to get the driver for the PCI card which has a Digital 21041 chip in it. FWIW I think it might be related to the selection of full- or half-duplex. 2.4.4-ac6 (which works fine) says: Port selection is half-duplex when I run tulip-diag, whereas 2.4.5-pre4 says Port selection is full-duplex My system is RH7.1 (using gcc-2.96 not kgcc) Duron 750, KT133 chipset (not kt133a!) Network card details (it is a PCI): Kingston KNE40BT (1995) Digital 21041-AA DC1017BA 21-40756-01 Dec 1994 S15313-02 A 9615 More details on request. And I'm willing to test patches... John [EMAIL PROTECTED] - 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: Matrox G400 Dualhead
> I have a similar problem with my G450, booting into the framebuffer, > then loading xdm and working in X, and then switching back to the > console. I may have another detail to add in that when I switch back > to the console from X, my monitor blanks and displays the warning > that the frequencies are out of range. I think I have a work around. Boot up 2.4.3 with the framebuffer enabled as normal. Log in as root and use the fbset program to change the settings for all the framebuffers. eg. fbset -a 1024x768-70 or whatever works for you. fbset has its own man page. This makes everything hunky-dory for me, in that after running fbset I can go in and out of X without ever losing the video signal. Petr, I had a look at the drivers/video/matrox subdir and there's no difference between 2.4.2 and 2.4.3, however there are differences in the drivers/video dir to do with framebuffers. The files that have been changed in drivers/video/ are: creatorfb.c fbmem.c fonts.c modedb.c sbus.c I know nothing about the nature of the changes that have been made though! It does seem to be a kernel problem rather than a X4.0.3 problem seeing as how 4.0.3 works fine under 2.4.2, and that using fbset on the framebuffer console in 2.4.3 solves the problem. John [EMAIL PROTECTED] - 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: Matrox G400 Dualhead
I have a similar problem with my G450, booting into the framebuffer, then loading xdm and working in X, and then switching back to the console. I may have another detail to add in that when I switch back to the console from X, my monitor blanks and displays the warning that the frequencies are out of range. I think I have a work around. Boot up 2.4.3 with the framebuffer enabled as normal. Log in as root and use the fbset program to change the settings for all the framebuffers. eg. fbset -a 1024x768-70 or whatever works for you. fbset has its own man page. This makes everything hunky-dory for me, in that after running fbset I can go in and out of X without ever losing the video signal. Petr, I had a look at the drivers/video/matrox subdir and there's no difference between 2.4.2 and 2.4.3, however there are differences in the drivers/video dir to do with framebuffers. The files that have been changed in drivers/video/ are: creatorfb.c fbmem.c fonts.c modedb.c sbus.c I know nothing about the nature of the changes that have been made though! It does seem to be a kernel problem rather than a X4.0.3 problem seeing as how 4.0.3 works fine under 2.4.2, and that using fbset on the framebuffer console in 2.4.3 solves the problem. John [EMAIL PROTECTED] - 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: Matrox G400 Dualhead
> Does anyone know why fualhead is not working anymore? > I just get a screen with rubbish on the second head. > Also when kernel loads and and registers fb1 I lose signal > on the second head. ... >With 2.4.2 it was working just fine. I have also noticed problems with the 2.4.3 release. I have a G450 32Mb, that I use in single-head mode. The console framebuffer runs fine at boot time, but when I load X (4.0.3 compiled with Matrox HAL library) and then return to the console, I get a blank screen (signal lost). I don't know what the problem is. I can confirm with Mythos that under 2.4.2 it was working just fine :-) Petr Vandrovec is the man who knows... what do you say Petr?! John [EMAIL PROTECTED] - 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: Matrox G400 Dualhead
Does anyone know why fualhead is not working anymore? I just get a screen with rubbish on the second head. Also when kernel loads and and registers fb1 I lose signal on the second head. ... With 2.4.2 it was working just fine. I have also noticed problems with the 2.4.3 release. I have a G450 32Mb, that I use in single-head mode. The console framebuffer runs fine at boot time, but when I load X (4.0.3 compiled with Matrox HAL library) and then return to the console, I get a blank screen (signal lost). I don't know what the problem is. I can confirm with Mythos that under 2.4.2 it was working just fine :-) Petr Vandrovec is the man who knows... what do you say Petr?! John [EMAIL PROTECTED] - 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: Matrox G450 problems with 2.4.0 and xfree
Dear Petr, I think I might have something to add to this discussion, but then again you probably know this already! On Tue Jan 30 2001 Petr Vandrovec wrote: > > > > Installed a Matrox G450 on my linux system. Now it has > > > > problems booting. The kernel is compiled with framebuffer > > > > support so is supposed to boot up with the Linux logo. > > > > Unfortunately the systems hangs when the kernel switches to > > > > the graphics mode. When I first boot into windoze and the > > > > reboot to linux it works fine. So it looks like an > > > > initialisation problem... > Windows drivers works around somehow, as after booting > to Windows matroxfb works fine - but without Windows it is just > pure luck. I have a similar problem to the one outlined above with kernel 2.4.x (hardware details below). I don't have Windows installed on my machine, but I find that if I cold boot to 2.2 (RH7) first and start up X (4.0.2 with Matrox driver 1.00.04 compiled in), I am then able to "shutdown -r now" and warm restart to 2.4 with FB acceleration enabled. This generally works fine for me. The 2.2 kernel I have (2.2.16 Redhat 7.0 standard) does not have FB enabled This isn't generally too much of a problem because 2.4.x is so stable I don't have to reboot for weeks! > It looks like that if you compile 'agpgart' into kernel, chances > that it will work are better, but I have also reports that it did > not changed anything. I have agpgart compiled directly in (not as a module) to the kernel, but this does not seem to relieve any of the cold boot problems :-( I'm willing to try out some patches if that would be useful. Note: Please CC me as I'm not subscribed to l-k. My hardware is: Matrox G450 Duron 750 128 Mb Ram Aopen AK33 m/b with VIA KT133 / 686A chipset relevant lspci output: 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 82) (prog-if 00 [VGA]) Subsystem: Matrox Graphics, Inc.: Unknown device 0641 Flags: bus master, medium devsel, latency 64, IRQ 10 Memory at d800 (32-bit, prefetchable) [size=32M] Memory at da00 (32-bit, non-prefetchable) [size=16K] Memory at db00 (32-bit, non-prefetchable) [size=8M] Expansion ROM at [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Capabilities: [f0] AGP version 2.0 John [EMAIL PROTECTED] - 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 when vim exits, and connection problems
On Sun 24 Sep 2000 Derrik Pates wrote: >- I am unable to connect to several sites, including >cisco.netacad.net and www.hotmail.com. I always receive a "connection >refused". It seems weird, but with 2.2.18pre10, I could connect, and >with 2.4.0-test8, I can't. I get similar behaviour on my box (RH6.2 kernel 2.4.0-t9p5). I am able to call up the hotmail homepage using Netscape, but am unable to login. More crucially I am unable to send email (using qmail) to hotmail addresses when running the latest kernels (I've noticed this problem since test8 - I was going to email hotmail about it, but seeing as how it's come up here!) However, I am able to connect without any problems using my 2.2.16 kernel, and I am also able to send emails to hotmail addresses using qmail using that kernel. Instructions describing how to gather more useful information would be welcome (or pointers to where the relevant instructions are :-) John [EMAIL PROTECTED] - 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 when vim exits, and connection problems
On Sun 24 Sep 2000 Derrik Pates wrote: - I am unable to connect to several sites, including cisco.netacad.net and www.hotmail.com. I always receive a "connection refused". It seems weird, but with 2.2.18pre10, I could connect, and with 2.4.0-test8, I can't. I get similar behaviour on my box (RH6.2 kernel 2.4.0-t9p5). I am able to call up the hotmail homepage using Netscape, but am unable to login. More crucially I am unable to send email (using qmail) to hotmail addresses when running the latest kernels (I've noticed this problem since test8 - I was going to email hotmail about it, but seeing as how it's come up here!) However, I am able to connect without any problems using my 2.2.16 kernel, and I am also able to send emails to hotmail addresses using qmail using that kernel. Instructions describing how to gather more useful information would be welcome (or pointers to where the relevant instructions are :-) John [EMAIL PROTECTED] - 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] Unable to handle kernel NULL pointer dereference
Thank you Martin! Upgrading to test9-pre5 and applying your patch works a treat. I've tried running through the steps that lead to the crash with the old kernel and there's now no trace of an oops! Thanks also to Igmar Palsenberg who pointed me in the right direction. John [EMAIL PROTECTED] Martin Diehl wrote: > On Wed, 20 Sep 2000, J Brook wrote: > > > >>EIP; c01527b9<= > > Trace; c015357b > > this is the quota issue for which I've posted a fix some days ago. > It's (as of 2.4.0-t9p5) waiting on the TODO list to be merged. > I'd consider it "critical" (wrt what Linus accepts for 2.4.0) as > processes calling sys_chown() may be trapped in D-state forever so > you end up fscking. > > Martin - 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] Unable to handle kernel NULL pointer dereference
Thank you Martin! Upgrading to test9-pre5 and applying your patch works a treat. I've tried running through the steps that lead to the crash with the old kernel and there's now no trace of an oops! Thanks also to Igmar Palsenberg who pointed me in the right direction. John [EMAIL PROTECTED] Martin Diehl wrote: On Wed, 20 Sep 2000, J Brook wrote: EIP; c01527b9 check_idq+d/118 = Trace; c015357b dquot_transfer+28b/4c8 this is the quota issue for which I've posted a fix some days ago. It's (as of 2.4.0-t9p5) waiting on the TODO list to be merged. I'd consider it "critical" (wrt what Linus accepts for 2.4.0) as processes calling sys_chown() may be trapped in D-state forever so you end up fscking. Martin - 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] Unable to handle kernel NULL pointer dereference
Hi, I ran into some trouble while compiling the pspell library that the new version of Balsa requires - okay, so perhaps I was asking for it :-) I ran the configure script fine, but a kernel oops occurred a few lines into the "make" process. I gather that it might be something to do with dodgy source code, but surely just compiling source code should not produce an oops (there were no compiler warnings until after the oops)? The oops is not fatal; I was able to download, compile and install the ksysmoops program to get the decoded oops message without having to reboot. I rebooted the system and tried compiling from clean sources again and got the same oops, so it seems to be repeatable on my system. If this is the wrong forum for such a message, please let me know! My system is RH6.2, with various updates probably best described by the output of the ver_linux script: Linux 2.4.0-test9 #1 Sat Sep 16 17:11:06 BST 2000 i586 unknown Kernel modules 2.3.14 Gnu C egcs-2.91.66 Binutils 2.9.5.0.22 Linux C Library2.1.3 Dynamic linker ldd (GNU libc) 2.1.3 Procps 2.0.7 Mount 2.10o Net-tools 1.54 Console-tools 0.3.3 Sh-utils 2.0 Modules Loaded emu10k1 soundcore kernel version 2.4.0-test9p1 with Rick van Riel's VM patch System: P133 w/ 32Mb ram. More details available on request. The decoded Oops message is below. Unable to handle kernel NULL pointer dereference at virtual address 0034 c01527b9 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: ebx: ecx: 0001 edx: c1afc000 esi: edi: 0004 ebp: esp: c14d7ee0 ds: 0018 es: 0018 ss: 0018 Process ar (pid: 13549, stackpage=c14d7000) Stack: c14d7f24 c015357b 0001 c14d7f54 01f6 c0a51440 b960 c0706019 c109aa50 c14d7f2c c14d7f24 0013 c01363d8 0001 ff86 c000d220 c012c1e7 c0a51440 c14d7f54 Call Trace: [] [] [] [] [] [] [] Code: f6 43 34 40 74 07 31 c0 e9 f9 00 00 00 8b 53 48 85 d2 74 43 >>EIP; c01527b9<= Trace; c015357b Trace; c01363d8 Trace; c012c1e7 Trace; c01371a9 <__user_walk+4d/58> Trace; c012c23b Trace; c011d630 Trace; c0108d83 Code; c01527b9 <_EIP>: Code; c01527b9<= 0: f6 43 34 40 testb $0x40,0x34(%ebx) <= Code; c01527bd 4: 74 07 je d <_EIP+0xd> c01527c6 Code; c01527bf 6: 31 c0 xor%eax,%eax Code; c01527c1 8: e9 f9 00 00 00jmp106 <_EIP+0x106> c01528bf Code; c01527c6 d: 8b 53 48 mov0x48(%ebx),%edx Code; c01527c9 10: 85 d2 test %edx,%edx Code; c01527cb 12: 74 43 je 57 <_EIP+0x57> c0152810 John [EMAIL PROTECTED] - 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] Unable to handle kernel NULL pointer dereference
Hi, I ran into some trouble while compiling the pspell library that the new version of Balsa requires - okay, so perhaps I was asking for it :-) I ran the configure script fine, but a kernel oops occurred a few lines into the "make" process. I gather that it might be something to do with dodgy source code, but surely just compiling source code should not produce an oops (there were no compiler warnings until after the oops)? The oops is not fatal; I was able to download, compile and install the ksysmoops program to get the decoded oops message without having to reboot. I rebooted the system and tried compiling from clean sources again and got the same oops, so it seems to be repeatable on my system. If this is the wrong forum for such a message, please let me know! My system is RH6.2, with various updates probably best described by the output of the ver_linux script: Linux 2.4.0-test9 #1 Sat Sep 16 17:11:06 BST 2000 i586 unknown Kernel modules 2.3.14 Gnu C egcs-2.91.66 Binutils 2.9.5.0.22 Linux C Library2.1.3 Dynamic linker ldd (GNU libc) 2.1.3 Procps 2.0.7 Mount 2.10o Net-tools 1.54 Console-tools 0.3.3 Sh-utils 2.0 Modules Loaded emu10k1 soundcore kernel version 2.4.0-test9p1 with Rick van Riel's VM patch System: P133 w/ 32Mb ram. More details available on request. The decoded Oops message is below. Unable to handle kernel NULL pointer dereference at virtual address 0034 c01527b9 *pde = Oops: CPU:0 EIP:0010:[c01527b9] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: ebx: ecx: 0001 edx: c1afc000 esi: edi: 0004 ebp: esp: c14d7ee0 ds: 0018 es: 0018 ss: 0018 Process ar (pid: 13549, stackpage=c14d7000) Stack: c14d7f24 c015357b 0001 c14d7f54 01f6 c0a51440 b960 c0706019 c109aa50 c14d7f2c c14d7f24 0013 c01363d8 0001 ff86 c000d220 c012c1e7 c0a51440 c14d7f54 Call Trace: [c015357b] [c01363d8] [c012c1e7] [c01371a9] [c012c23b] [c011d630] [c0108d8 3] Code: f6 43 34 40 74 07 31 c0 e9 f9 00 00 00 8b 53 48 85 d2 74 43 EIP; c01527b9 check_idq+d/118 = Trace; c015357b dquot_transfer+28b/4c8 Trace; c01363d8 cached_lookup+10/54 Trace; c012c1e7 chown_common+ff/120 Trace; c01371a9 __user_walk+4d/58 Trace; c012c23b sys_chown+33/48 Trace; c011d630 sys_chown16+40/44 Trace; c0108d83 system_call+33/40 Code; c01527b9 check_idq+d/118 _EIP: Code; c01527b9 check_idq+d/118 = 0: f6 43 34 40 testb $0x40,0x34(%ebx) = Code; c01527bd check_idq+11/118 4: 74 07 je d _EIP+0xd c01527c6 check_idq+1a/118 Code; c01527bf check_idq+13/118 6: 31 c0 xor%eax,%eax Code; c01527c1 check_idq+15/118 8: e9 f9 00 00 00jmp106 _EIP+0x106 c01528bf check_idq+113/118 Code; c01527c6 check_idq+1a/118 d: 8b 53 48 mov0x48(%ebx),%edx Code; c01527c9 check_idq+1d/118 10: 85 d2 test %edx,%edx Code; c01527cb check_idq+1f/118 12: 74 43 je 57 _EIP+0x57 c0152810 check_idq+64/118 John [EMAIL PROTECTED] - 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/
