Outgoing TCP connection problem
Hello. I have a firewall at home which is used to protect my LAN. But I have a small problem in that for the past few months (using kernels 2.2.14, and a 2.2.17pre with the TCP "hang" fix), outgoing connections to a destination port of 80 seem to "hang," and will timeout. Connections to other ports seem alright, but most of the traffic is http traffic (I know in at lesat one case outgoing IRC seemed to be affected). After 20 or so outgoing attempts are tried after the hang is discovered, connections start working again. Existing connections continue unaffected. I use a large-ish ipchains ruleset, and have port fowarding turned on to allow compatbility with some net games I use. It's been getting worse (occuring more often) as my ipchains ruleset has grown. Any help is appreciated (Note: please CC: as I've been unsubcribed from the digest by the recent move, and am having troubles resubscribing) -- www.kuro5hin.org -- technology and culture, from the trenches. - 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/ - 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/
[BUG REPORT] Conflict between Tulip driver w/ LinkSys 100LNE and EEPro driver w/ Intel PCI EtherExpress Pro100 82557
The problem: I can't have the Tulip and EEPro drivers loaded at the same time. If I have the Tulip driver loaded, and I load the EEPro driver, the self check fails with 0x and complains that I don't have the card in a bus master slot. If I have the EEPro driver loaded and the ether tested as working, and I insmod the tulip driver, this happens: . Oct 18 10:13:33 zephyr kernel: eepro100: wait_for_cmd_done timeout! Oct 18 10:13:33 zephyr kernel: eepro100: wait_for_cmd_done timeout! Oct 18 10:14:02 zephyr last message repeated 27 times Oct 18 10:14:02 zephyr last message repeated 27 times Oct 18 10:14:04 zephyr kernel: eepro100: wait_for_cmd_done timeout! EEPro driver: Oct 18 10:15:51 zephyr kernel: eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin <[EMAIL PROTECTED]> and others Tulip driver: Oct 18 10:12:50 zephyr kernel: tulip.c:v0.91g-ppc 7/16/99 [EMAIL PROTECTED] Oct 18 10:12:50 zephyr kernel: eth2: Macronix 98715 PMAC rev 37 at 0x7000, 00:20:78:D0:3D:F2, IRQ 9. Oct 18 10:12:50 zephyr kernel: eth2: EEPROM default media type MII 100baseT4 For more information on the card, go here. http://www.linksys.com/products/product.asp?prid=31&grid=10 Another problem is that despite the fact that I don't have a 100Mbps network at the moment, the Tulip driver doesn't give me a way to override the (I've tried the insmod options=0x9 to get MII autodetect) stupid default that the Linksys morons left in the EEProm. /proc/pci entries for the cards: Bus 0, device 11, function 0: Ethernet controller: Intel 82557 (rev 1). Medium devsel. Fast back-to-back capable. IRQ 5. Master Capable. Latency=64. Min Gnt=8.Max Lat=56. Prefetchable 32 bit memory at 0xe4101000 [0xe4101008]. I/O at 0x6c00 [0x6c01]. Non-prefetchable 32 bit memory at 0xe400 [0xe400]. Bus 0, device 13, function 0: Ethernet controller: Macronix MX98715 / MX98725 (rev 37). Medium devsel. Fast back-to-back capable. IRQ 9. Master Capable. Latency=64. Min Gnt=8.Max Lat=56. I/O at 0x7000 [0x7001]. Non-prefetchable 32 bit memory at 0xe410 [0xe410]. Any help is appreciated.. please CC: any replies as I'm not subscribed to the list (not since digest went away :-(). -- www.kuro5hin.org -- technology and culture, from the trenches. - 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/
Which build issues not fixed for 2.2.18pre13 on Slackware
Hi. Just wanted to report that the which things seems not to have been fixed for Slackware (at least). Output of 'make menuconfig': --8<--8<--8<-- /bin/sh: -c: line 1: syntax error near unexpected token `(/' /bin/sh: -c: line 1: `if which: no gcc272 in (/usr/local/qt/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/openwin/bin:/usr/games:.) which: no kgcc in (/usr/local/qt/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/openwin/bin:/usr/games:.) cc -D__KERNEL__ -I/usr/src/linux/include -fno-strict-aliasing -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-fno-strict-aliasing"; fi' rm -f include/asm ( cd include ; ln -sf asm-i386 asm) make -C scripts/lxdialog all make[1]: Entering directory `/usr/src/linux-2.2.18pre/scripts/lxdialog' make[1]: Leaving directory `/usr/src/linux-2.2.18pre/scripts/lxdialog' /bin/sh scripts/Menuconfig arch/i386/config.in Using defaults found in .config --8<--8<--8<-- make bzImage fails miserably. --8<--8<--8<-- /bin/sh: -c: line 1: syntax error near unexpected token `(/' /bin/sh: -c: line 1: `if which: no gcc272 in (/usr/local/qt/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/openwin/bin:/usr/games:.) which: no kgcc in (/usr/local/qt/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/openwin/bin:/usr/games:.) cc -D__KERNEL__ -I/usr/src/linux/include -fno-strict-aliasing -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-fno-strict-aliasing"; fi' gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep scripts/mkdep.c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/split-include scripts/split-include.c make[1]: Entering directory `/usr/src/linux-2.2.18pre/arch/i386/boot' make[1]: Nothing to be done for `dep'. make[1]: Leaving directory `/usr/src/linux-2.2.18pre/arch/i386/boot' which: no gcc272 in (/usr/local/qt/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/openwin/bin:/usr/games:.) which: no kgcc in (/usr/local/qt/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/openwin/bin:/usr/games:.) cc -D__KERNEL__ -I/usr/src/linux/include -E -C -P -I/usr/src/linux/include -imacros /usr/src/linux/include/asm-i386/page_offset.h -Ui386 arch/i386/vmlinux.lds.S >arch/i386/vmlinux.lds /bin/sh: -c: line 1: syntax error near unexpected token `(/' /bin/sh: -c: line 1: `which: no gcc272 in (/usr/local/qt/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/openwin/bin:/usr/games:.) which: no kgcc in (/usr/local/qt/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/openwin/bin:/usr/games:.) cc -D__KERNEL__ -I/usr/src/linux/include -E -C -P -I/usr/src/linux/include -imacros /usr/src/linux/include/asm-i386/page_offset.h -Ui386 arch/i386/vmlinux.lds.S >arch/i386/vmlinux.lds' make: *** [arch/i386/vmlinux.lds] Error 2 --8<--8<--8<-- Perhaps just doing 'which gcc' instead of forcing people to keep a specific version of GCC around (or relevant symlinks) would be good. GCC 2.95.2 seems stable for doing 2.2.x work now. Another question .. why change how the CC is assigned at all? None of the other things (ar, as, etc) have been changed in any why. Why is this change happening? Restoring the 'old' CC line seems to have fixed any build problems. -- www.kuro5hin.org -- technology and culture, from the trenches. - 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/
PS/2 mouse problems in Linux 2.4.0 and 2.2.17 on KT133 chipset based motherboards.
Hello. I recently upgraded my workstation from an EPoX MPV3-G to a Gigabyte 7-VX-1. In XFree 3.3.6 the mouse cursor will randomly jump to the upper-right hand corner of the screen and remain there until I scroll the mousewheel. This used to happen on the old workstation when switching between virtual consoles and X's screen occasionally, but stopped happening when I used X exclusively (with terminal windows). This new behaviour has been verified to also affect the Gigabyte 7-ZX-1 and the Asus A7V motherboards (also based on the VIA KT133 chipset). Windows 2000, Windows 98, OpenBSD 2.8's PS/2 mouse handling does not appear affected on the same chipset, nor have I ever been able to make the mouse cursor jump to the upper-right hand corner of the screen in them. The PS/2 mouse I am using is the Logitech M-S48. This also affects the Microsoft Intellimouse and other PS/2 mice without a mousewheel. Please CC me in any followup since I do not follow the Linux-kernel mailing list directly. -- www.kuro5hin.org -- technology and culture, from the trenches. - 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/
More on the VIA KT133 chipset misbehaving in Linux
The VIA KT133 chipset exhibits the following bugs under Linux 2.2.17 and 2.4.0: 1) PS/2 mouse cursor randomly jumps to upper right hand corner of screen and locks for a bit 2) Detects a maximum of 64mb of ram, unless worked around by the "mem=" switch 3) The clock drifts slowly (more so under heavy load than light load), leaking time. I think #2 is because e820h memory detection is not properly implemented on the KT133 chipset, or because of some silly BIOS bug that VIA has not addressed. I have no idea yet why #1 and #3 happen. If any gurus out there have any pointers on where I can look, and what I should prod, I know my way around with a compiler and editor ;) -- www.kuro5hin.org -- technology and culture, from the trenches. - 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: More on the VIA KT133 chipset misbehaving in Linux
Mark Hahn wrote: > mine (gigabyte ga-7zm) shows NONE of these under 2.4.0 or the last > 100 or so pre-2.4 kernels. I have no idea what it does on obsolete kernels. The symptoms have occured on a Gigabyte 7-ZX-1 and a 7-VX-1. I have a bit of a suspicion that the 250W power supplies aren't enough for it, but won't be able to check this until after LWE. > > 3) The clock drifts slowly (more so under heavy load than light load), > > leaking time. > > this is perfectly normal for all computers; it's why ntpd exists. > I collect my ntp drifts, and they look perfectly normal (compared > to drifts over the same period on two other linux boxes and a Sun 420R.) This isn't 5 seconds in a month or two like my old K6-III/EPoX MVP3-G setup. This is 10 minutes every 9-12 hours. When I woke up this morning, my clock was off by 15 minutes. That's a bit abnormal > > I think #2 is because e820h memory detection is not properly implemented on > > the KT133 chipset, or because of some silly BIOS bug that VIA has not > > perhaps you should upgrade your bios. Very much so. I'll have to wait until I can get a DOS boot disk, though, since flashing doesn't work well in Linux ;) > #1 is usually a sign that gpm/X are not talking the same mouse protocol > as your mouse. my board gets along swimmingly with my mouseman/fx > (I've probably never had anything else on it.) No GPM. Logitech PS/2 mouse with imps2. Microsoft Intelli PS/2 mouse does the same. -- www.kuro5hin.org -- technology and culture, from the trenches. - 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/
Broken memory init on VIA KX133
I'm wondering if anyone knows/has a fix for memory past 64mb not being detected (unless you use append="mem=...M" in lilo) on the Via VT8371 [KX133] North bridge. (Please CC any replies since I'm off kernel list atm.) -- www.kuro5hin.org -- technology and culture, from the trenches. - 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: Broken memory init on VIA KX133
Alan Cox wrote: > > I'm wondering if anyone knows/has a fix for memory past 64mb not being > > detected (unless you use append="mem=...M" in lilo) on the Via VT8371 > > [KX133] North bridge. (Please CC any replies since I'm off kernel list > > atm.) > > Consult your BIOS vendor Actually, I just did some additional testing (as this was not an issue with FreebSD 4.2, Win2k, Win98 on the same hardware). The problem I describe was fixed in 2.2.19 -- where Linux now properly uses e820 instead of a legacy BIOS call to determine memory size. -- www.kuro5hin.org -- technology and culture, from the trenches. - 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/
Buggy emu10k1 drivers.
Hi. The emu10k1 drivers shipped with 2.2.19 do not work well past 1Ghz. In the original system, an Athlon 550, all OSS sound applications worked. Loki games, libsdl games, XMMS, mplayer, RealPlayer, and the 'play' command from the sox pacnage. When I upgraded my machine to a 1Ghz TBird, everything except XMMS would hang while the first audio buffer looped infinitely. It also fails at 1.1Ghz. As a control, I enabled the onboard audio (a C-Media Electronics Inc CM8738 (rev 10)), and was able to use all the applications listed again (except SDL/Loki games). I'd fix it if I knew how since I don't like hearing bus traffic (plus the CMeda can't play multiple sources) :-/ Please CC me since I am not on the list. -- www.kuro5hin.org -- technology and culture, from the trenches. - 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: Buggy emu10k1 drivers.
Kernel 2.4.5 has a working emu10k1 driver (all apps which hung with 2.2.19's driver worked fine, none of the working ones stopped working). Could we perhaps see this backported to the 2.2.20 prepatches so that us 2.2 lovers can enjoy working sound? -- www.kuro5hin.org -- technology and culture, from the trenches. - 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/
Still some problems with UHCI driver in 2.4.5 on VIA chipsets
Another thing I was happy to find working better in 2.4.5, was USB. I had just dumped off ~70 high res pics (which would've taken forever via the usual RS232 method), and was deleting the last pics when gphoto froze. The dmesg log has the same messages it had before when I experimented with 2.4.1 and 2.2.19. I'm not sure if it was harder to trigger the problem now because of improvements to 2.4.5, or if it was because the proc is 1.1Ghz (affecting a possible race condition). The USB controller: Bus 0, device 4, function 2: USB Controller: VIA Technologies, Inc. UHCI USB (rev 22). IRQ 5. Master Capable. Latency=32. I/O at 0xd400 [0xd41f]. Bus 0, device 4, function 3: USB Controller: VIA Technologies, Inc. UHCI USB (#2) (rev 22). IRQ 5. Master Capable. Latency=32. I/O at 0xd000 [0xd01f]. dmesg log: usb.c: registered new driver dc2xx dc2xx.c: v1.0.0 David Brownell, <[EMAIL PROTECTED]> dc2xx.c: USB Camera Driver for Kodak DC-2xx series cameras PCI: Found IRQ 5 for device 00:04.2 PCI: The same IRQ used for device 00:04.3 uhci.c: USB UHCI at I/O 0xd400, IRQ 5 usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected PCI: Found IRQ 5 for device 00:04.3 PCI: The same IRQ used for device 00:04.2 uhci.c: USB UHCI at I/O 0xd000, IRQ 5 usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 2 ports detected uhci.c: Linus Torvalds, Johannes Erdfelt, Randy Dunlap, Georg Acher, Deti Fliegl, Thomas Sailer, Roman Weissgaerber uhci.c: USB Universal Host Controller Interface driver hub.c: USB new device connect on bus1/2, assigned device number 2 dc2xx.c: USB Camera #0 connected, major/minor 180/80 ** here is where it froze ** usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb.c: USB disconnect on device 2 usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout ** rmmod the drivers ** dc2xx.c: USB Camera #0 disconnected usb.c: USB disconnect on device 1 usb.c: USB bus 1 deregistered usb.c: USB disconnect on device 1 usb.c: USB bus 2 deregistered usb.c: deregistering driver dc2xx ** usbcore refuses to rmmod because its ref cnt won't decrement, this also affected it before I had the usb_control/bulk_msg timeout/loop issues ** -- www.kuro5hin.org -- technology and culture, from the trenches. - 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: Still some problems with UHCI driver in 2.4.5 on VIA chipsets
Johannes Erdfelt wrote: > Could you load uhci with the debug=1 option? I did an 'insmod uhci.o debug=1' but the dmesg output did not alter. My easy steps to reproduce it is to 'delete selected images' in gphoto such that there will be no images in the camera left when the operation is done. At loast it doesn't lock up the camera like it used to :-/ I think this may be a problem in the dc2xx.o then, since uhci didn't reveal any new messages. -- www.kuro5hin.org -- technology and culture, from the trenches. - 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: [Emu10k1-devel] Re: Buggy emu10k1 drivers.
Robert Love wrote: > > Can you give the CVS driver a try? Snapshots are available here: > > http://opensource.creative.com/snapshot.html > > > > The driver in the kernel is based on a CVS snapshot from last summer, the > > problem may be fixed in CVS. Also, the CVS driver is a common driver for > > 2.2 and 2.4 (with some #ifdef), so it may be useful to see if it works for > > you on 2.4.5 but not on 2.2.19. > > if the driver in the kernel is that old, could we try merging a newer > release? is there any reason why it has not been done yet? Tried 2.4.5 and 2.2.19 with the same snapshot code (emu10k1-20010617.tar.gz) 2.4.5 works, 2.2.19 doesn't. Maybe 2.2.19 has deeper problems with my hardware which aren't in the driver, then, as identical code works on one and not the other. -- www.kuro5hin.org -- technology and culture, from the trenches. - 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: Still some problems with UHCI driver in 2.4.5 on VIA chipsets
Johannes Erdfelt wrote: > > I think this may be a problem in the dc2xx.o then, since uhci didn't reveal > > any new messages. > > It's possible. Many cameras are touchy wrt to the commands it receives. > If one is slightly wrong, some of them will just stop talking. Yeah, looks like I get to see if I can debug the camera driver.. > Did you try with the usb-uhci driver as well? > > JE Here's a transcript of a session with usb-uhci.o (vs uhci.o). It locks in a way that I can't turn off the camera (have to pop batteries), which is a bit worse than just uhci.o. On the plus side, it seemed a bit faster at a few things. usb.c: USB disconnect on device 1 usb.c: USB bus 1 deregistered usb.c: USB disconnect on device 1 usb.c: USB bus 2 deregistered usb-uhci.c: $Revision: 1.259 $ time 16:56:57 Jun 22 2001 usb-uhci.c: High bandwidth mode enabled PCI: Found IRQ 5 for device 00:04.2 PCI: The same IRQ used for device 00:04.3 usb-uhci.c: USB UHCI at I/O 0xd400, IRQ 5 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected PCI: Found IRQ 5 for device 00:04.3 PCI: The same IRQ used for device 00:04.2 usb-uhci.c: USB UHCI at I/O 0xd000, IRQ 5 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 2 ports detected usb-uhci.c: v1.251 Georg Acher, Deti Fliegl, Thomas Sailer, Roman Weissgaerber usb-uhci.c: USB Universal Host Controller Interface driver hub.c: USB new device connect on bus1/2, assigned device number 2 dc2xx.c: USB Camera #0 connected, major/minor 180/80 usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb-uhci.c: interrupt, status 3, frame# 1004 usb.c: USB disconnect on device 2 usb-uhci.c: interrupt, status 3, frame# 1997 usb-uhci.c: interrupt, status 3, frame# 949 usb-uhci.c: interrupt, status 3, frame# 1949 usb-uhci.c: interrupt, status 3, frame# 901 usb-uhci.c: interrupt, status 3, frame# 1901 dc2xx.c: USB Camera #0 disconnected -- www.kuro5hin.org -- technology and culture, from the trenches. - 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/
Annoying kernel behaviour
I upgraded a fileserver to 2.4.5 because of the RAID support (the 0.90 patch I grabbed did not apply cleanly to 2.2.19, despite it being a fresh copy). Besides a nice speed increase (the EEPro now pumps 10 megs a second, instead of 2 or 3), there is a problem with the video4linux in it. The box has a bttv card hooked up to a camera. Under 2.2.19, Apache had mod_video installed, which would produce a jpeg of the composite in on the card (a cheapy CCD camera is hooked up). Upon insmoding: Module Size Used by bttv 55184 0 (unused) videodev4864 2 [bttv] i2c-algo-bit7712 1 [bttv] i2c-dev 3904 0 (unused) i2c-core 12656 0 [bttv i2c-algo-bit i2c-dev] and accesing mod_video, the box locked up hard (not even sysrq worked). And when I rebooted, I found that some files is /etc were eaten -- even though that partition is mounted with the sync option, and even though it'd had a good 2-5 seconds the write the ~10k data file. So why does bttv lock the box, and why does sync not sync? I don't feel like converting ~80gb to some other FS than ext2 just yet. PS: I can't give an Oops because the DPMS mode on the console was on, and it won't return when it locks up (perhaps turn on monitor as part of Oops handling?). Assuming there even was an oops. PPS: Please CC me since I'm not on the list. -- www.kuro5hin.org -- technology and culture, from the trenches. - 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 BUG in inode.c line 486 in 2.4.5
Found these lurking in dmesg.. no timestamp on them, so I have no idea when they happened.. the system seems ok, but I'm going to go fsck it a bit now.. Asus A7M266 board (VIA Southbridge). VIA82CXXX chipset support is on, use DMA by default is on. ext2 partitions on a 20gb drive: FilesystemSize Used Avail Use% Mounted on /dev/hda5 2.9G 1.9G 873M 69% / /dev/hda7 13G 10G 2.6G 80% /home tmpfs 103M 0 103M 0% /var/shm Hope this helps.. -=- kernel BUG at inode.c:486! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00013286 eax: 001b ebx: c726a2c0 ecx: 0001 edx: c022a068 esi: c022cee0 edi: d489c9c0 ebp: d501dfa4 esp: d501deec ds: 0018 es: 0018 ss: 0018 Process gmc (pid: 169, stackpage=d501d000) Stack: c01f602c c01f608b 01e6 c726a2c0 c0142887 c726a2c0 d4221a40 c726a2c0 c015a66d c726a2c0 c01402f6 d4221a40 c726a2c0 d4221a40 c0138d18 d4221a40 d501df68 c013945a d489c9c0 d501df68 cc51b000 Call Trace: [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c f6 83 f4 00 00 00 10 75 1f 68 e8 01 00 00 68 -=- kernel BUG at inode.c:486! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010286 eax: 001b ebx: c6bab980 ecx: 0001 edx: c022a068 esi: c022cee0 edi: d489c9c0 ebp: d5559fa4 esp: d5559eec ds: 0018 es: 0018 ss: 0018 Process gmc (pid: 18464, stackpage=d5559000) Stack: c01f602c c01f608b 01e6 c6bab980 c0142887 c6bab980 d4221dc0 c6bab980 c015a66d c6bab980 c01402f6 d4221dc0 c6bab980 d4221dc0 c0138d18 d4221dc0 d5559f68 c013945a d489c9c0 d5559f68 cae3b000 Call Trace: [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c f6 83 f4 00 00 00 10 75 1f 68 e8 01 00 00 68 -=- kernel BUG at inode.c:486! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010286 eax: 001b ebx: cf9b4640 ecx: 0001 edx: c022a068 esi: c022cee0 edi: d489c9c0 ebp: c3bd1fa4 esp: c3bd1eec ds: 0018 es: 0018 ss: 0018 Process gmc (pid: 18470, stackpage=c3bd1000) Stack: c01f602c c01f608b 01e6 cf9b4640 c0142887 cf9b4640 c1c1b5c0 cf9b4640 c015a66d cf9b4640 c01402f6 c1c1b5c0 cf9b4640 c1c1b5c0 c0138d18 c1c1b5c0 c3bd1f68 c013945a d489c9c0 c3bd1f68 c6087000 Call Trace: [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c f6 83 f4 00 00 00 10 75 1f 68 e8 01 00 00 68 -=- kernel BUG at inode.c:486! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010286 eax: 001b ebx: cf9b4040 ecx: 0001 edx: c022a068 esi: c022cee0 edi: d489c9c0 ebp: d4ea1fa4 esp: d4ea1eec ds: 0018 es: 0018 ss: 0018 Process xmms (pid: 14150, stackpage=d4ea1000) Stack: c01f602c c01f608b 01e6 cf9b4040 c0142887 cf9b4040 c1c1b9c0 cf9b4040 c015a66d cf9b4040 c01402f6 c1c1b9c0 cf9b4040 c1c1b9c0 c0138d18 c1c1b9c0 d4ea1f68 c013945a d489c9c0 d4ea1f68 d3693000 Call Trace: [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c f6 83 f4 00 00 00 10 75 1f 68 e8 01 00 00 68 -- www.kuro5hin.org -- technology and culture, from the trenches. - 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 BUG in inode.c line 486 in 2.4.5
I should mention, there are also NFS3 mounts on the system.. Dylan Griffiths wrote: > -=- > > kernel BUG at inode.c:486! > invalid operand: > CPU:0 > EIP:0010:[] > EFLAGS: 00013286 > eax: 001b ebx: c726a2c0 ecx: 0001 edx: c022a068 > esi: c022cee0 edi: d489c9c0 ebp: d501dfa4 esp: d501deec > ds: 0018 es: 0018 ss: 0018 > Process gmc (pid: 169, stackpage=d501d000) > Stack: c01f602c c01f608b 01e6 c726a2c0 c0142887 c726a2c0 d4221a40 > c726a2c0 >c015a66d c726a2c0 c01402f6 d4221a40 c726a2c0 d4221a40 > c0138d18 >d4221a40 d501df68 c013945a d489c9c0 d501df68 cc51b000 > > Call Trace: [] [] [] [] [] > [] [] >[] > > Code: 0f 0b 83 c4 0c f6 83 f4 00 00 00 10 75 1f 68 e8 01 00 00 68 > -- www.kuro5hin.org -- technology and culture, from the trenches. - 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: Annoying kernel behaviour
Colonel wrote: > Look in the people/mingo directory for a patch The patch did not work. > I have: > > Linux video capture interface: v1.00 > bttv: driver version 0.7.63 loaded > bttv: using 2 buffers with 2080k (4160k total) for capture > bttv: Host bridge needs ETBF enabled. > bttv: Bt8xx card found (0). > bttv0: Bt878 (rev 2) at 00:0b.0, irq: 10, latency: 32, memory: 0xe300 > bttv0: subsystem: 144f:3000 => TView 99 (CPH063) => card=38 > bttv0: model: BT878(TView99 CPH063) [autodetected] > bttv0: enabling ETBF (430FX/VP3 compatibilty) > i2c-core.o: adapter bt848 #0 registered as adapter 0. Linux video capture interface: v1.00 bttv: driver version 0.7.57 loaded bttv: using 2 buffers with 2080k (4160k total) for capture bttv: Bt8xx card found (0). bttv0: Bt848 (rev 18) at 00:0f.0, irq: 10, latency: 64, memory: 0xd79ff000 bttv0: model: BT848A( *** UNKNOWN *** ) [autodetected] i2c-dev.o: Registered 'bt848 #0' as minor 0 i2c-core.o: adapter bt848 #0 registered as adapter 0. ** ^^ this worked in 2.2.19 as bttv0: Brooktree Bt848 (rev 18) bus: 0, devfn: 88, irq: 11, memory: 0xe4102000. bttv: 1 Bt8xx card(s) found. bttv0: NO fader chip: TEA6300 bttv0: model: BT848(Miro) Sigh.. I'll try the update. > Bttv-0.7.63-2.4.3.patch.bz2 > > from the website. Video4linux has always worked in the various 2.4 > kernels I've tried. > > >and accesing mod_video, the box locked up hard (not even sysrq worked). And > > I don't run mod_video, but xawtv works fine. Did you try that or > rebuilding mod_video? It shouldn't matter, as userspace programs should not be able te fuck te kernel over in such a complete instant deadlock. There is something seriously rotten with video4linux or the driver if my little userspace app can take out machines with no warnings and no error messages on conesole/in logs. Recompiling didn't affect it, either. > >when I rebooted, I found that some files is /etc were eaten -- even though > > You must have grues. No, the sync writes seem broken in 2.4.5. That is very bad. -- www.kuro5hin.org -- technology and culture, from the trenches. - 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: Annoying kernel behaviour
Colonel wrote: > Ah, notice that the IRQ shifted? Perhaps there is something else on > irq 10, such as the SCSI controller? My video cards always end up on > that IRQ, perhaps the computer is still accessible via the network? I would expect the IRQ to shift as the system has a different motherboard/processor than it did in December. CPU0 0:3208074 XT-PIC timer 1: 2 XT-PIC keyboard 2: 0 XT-PIC cascade 10: 1 XT-PIC bttv 12: 10444 XT-PIC eth0 14: 12366 XT-PIC ide0 15: 67 XT-PIC ide1 NMI: 0 ERR: 0 There are no conflicts, and PCI should be able to share anyways. That machine, being a server, is only accesible via the network. And when all my SSH sessions to it died, and the pings weren't pinging, I went over to the server corner, attached a monitor to the machaine and tried the magic sysrq on the keyboard after verifying that I couldn't get a local response. As I said, I can easily lock an entire system in a way that corrupts files even on a synchronuslly mounted partition from userland with no warning, no error messages. Waht part of this do you fail to grasp? -- www.kuro5hin.org -- technology and culture, from the trenches. - 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/
EEPro100 problems in SMP on 2.4.5 ?
Hi. While doing some file tranfers to our new server (a Compaq Proliant 8way XEON 500 with 4gb ram and an EEPro100 NIC), the box socked solid (no oops, no response via network, no response via console). The other hardware in the system was a Compaq Smart Array 9SMART2 driver). It's running Slackware 7.1. The other system was a dual P3 450 running Redhat 7.1 (Linux velocity.kuro5hin.org 2.4.2-2smp #1 SMP Sun Apr 8 20:21:34 EDT 2001 i686 unknown) w/ 3c59x NIC. The Redhat machine experienced no problems. In Uni processor mode, the system is totally stable. But only using 1/8th of its power :-/ We had to roll back to 2.2.19 with a bigmem patch, but we'd like to have a stable 2.4 kernel to use (since it's so much better SMP wise, throughput wise, etc). -- www.kuro5hin.org -- technology and culture, from the trenches. - 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: EEPro100 problems in SMP on 2.4.5 ?
Andrew Morton wrote: > 1: Include `magic sysrq' support in the kernel and use ALT-SYSRQ-T and S >when it has locked up. If you get some traces then please feed them >into `ksymoops -m System.map' and report back. That was locked as well, AFAIK. > 2: If the above doesn't work, add `nmi_watchdog=1' to the kernel boot >options. That may catch the lockup. > > 3: Replace the NIC with another eepro100. If the problem goes away then >chuck the old one. > > 4: Replace the NIC with one of a different type (ie: swap with the other >machine). If that fixes it we look at the ethernet driver. Otherwise >we look at, umm, the rest of the kernel. I'd love to do some of this, but since the box is now being shipped to a colo facility in New York, I don't really have a choice in the matter. Hopefully someone here doing SMP + EEPro100 can see if they can reproduce the issue (2.4.5 kernel). -- www.kuro5hin.org -- technology and culture, from the trenches. - 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/
Slackware 8
No need to worry, I'm already downloading the ISOs. All will be well soon enough :-D -- www.kuro5hin.org -- technology and culture, from the trenches. - 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/
