Stuck: What to do with solid locks?
Hello, Three times since I upgraded to 2.4.3 and at least once in the 2.4.3-pre series, my machine would completely lock hard. I've got KDB running on a serial console (as I've been seeing lots of crashes, usually in the scsi_eh_0 process) and even this fails to pick up anything wrong. It's just a completely hard crash. I don't know what to do or how to go about collecting info for debugging purposes. I run Win2k and FreeBSD on it too and while Win2k does crash on it sometimes, it doesn't crash anywhere near as much as Linux. FreeBSD doesn't crash at all. Unfortunately for me, I prefer Linux for my machine, so ditching Linux for one of these is not a preferred option. Anyway, I'm stumped. The magic SysReq stuff doesn't respond either. Any ides on how to debug this? My HW is: dual P3 600, 640M RAM, IEEE1394 PCI card, G200 (and G400 sometimes) AGP card, Promise Ultra66 PCI card, Adaptec 2940UW PCI card, SB Live (EMU10k1) card, and a Linksys 10/100 PCI ethernet card. Additionally, I have two USB hubs plugged into my PC. One of these hubs has a USB mouse and a (USB) SanDisk SDDR-31 plugged into it. The other hub (sometimes) has a Rio 500 plugged into it. I have a generic ATAPI CDROM (the Kenwood True-X 72x was very flaky when using IDE-SCSI) connected to the Promise card (yes, I know it doesn't do UDMA4) and a Plextor 12/4/32 SCSI CD-RW connected to the Adaptec card. Finally, I have two hard drives with Linux partitions on both. Almost all of these partition are ReiserFS, with /, /var, and /boot being EXT2. Attached is my .config file. I'm using stock 2.4.3 with the most recent KDB patch and the newest AIC7xxx driver (6.1.8). I'm using RH7.0 with XFree 4.0.1. I've upgraded packages as per the Changes docs. I'm also using the most recent modutils (2.4.5). Every crash has happened in X, but then, I almost always work in X on this workstation, so the only place for them to happen would be in X. I'll see about leaving it on overnight without running X. This is very frustrating. I really, really want to be able to start doing something on my workstation without having to worry everytime about it crashing. Thanks, pete # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_PM=y # CONFIG_ACPI is not set CONFIG_APM=m # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set CONFIG_APM_CPU_IDLE=y # CONFIG_APM_DISPLAY_BLANK is not set CONFIG_APM_RTC_IS_GMT=y # CONFIG_APM_ALLOW_INTS is not set CONFIG_APM_REAL_MODE_POWER_OFF=y # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_FIFO=y CONFIG_PARPORT_PC_SUPERIO=y # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=m CONFIG_ISAPNP=m # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_SIZE=4096 # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG
Re: Stuck: What to do with solid locks?
Oh, I realize this. I don't mind and even expect the occational crash right now in the 2.4.x series, but the frequency of these crashes fall into the "frequent" category. I know that if I want a much more stable system, I should go back to 2.2.19, but I'd prefer to stick it out with 2.4.x and help by collecting data. The data collection part is all (I think) I can do, as I don't know the first place to begin when it comes to fixing most kernel problems. I know it's not much, but it's about all I can do to give something back to the Linux community and I'd really like to help. The message I wrote last night was a bit too whiny as I had just had three crashes/locks within a fairly short period of time. The most frustrating part is these solid locks. I don't even have KDB to nose about the system with. Even when the system does crash to KDB, I don't get Oops messages, just "kernel cannot handle NULL paging request"-sort of stuff. Nothing ever gets logged to (k)syslogd (or, at least, handled by (k)syslogd). Keith Owens has been great about helping me us KDB to try to collect data for people who might be able to track down bugs, but if I can't get into KDB even, then I have no idea where to begin to help fix this problem (or these problems). pete On Tue, 03 Apr 2001, Alan Cox wrote: > > This is very frustrating. I really, really want to be able to start > > doing something on my workstation without having to worry everytime > > about it crashing. > > Then install 2.2.19. 2.4.x isnt stable yet. If you have the time then oopses > and debugging data are wonderful if not then 2.2 is stable. > > > Alan > - 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 2.4.3-ac5
On Fri, 13 Apr 2001, Scott Prader wrote: > one of the problems i've been having so far with the 2.4.3 series is the > fact that USB appears to be futzed. It just doesn't want to work right. > Also, I compile a lot of things as modules and I've been getting lots of > unresolved symbols and hence many things (including my nic) don't work, > so I am still stuck at 2.4.2-ac4. So here's some info that should help > out whoevers doing the specific work on USB and whatever else decided it > wanted to say "ok, you suck, go away" ;) [snip] > modutils 2.4.2 [snip] probably a silly question, but have you tried modutils 2.4.5? these won't help with the missing symbol issues, but are you using the latest hotplug scripts and the patched version of pci-utils and usb-utils? there are links to all of these at the linux-usb site. hth, pete PGP signature
Re: 2.4.x SMP blamed for Xfree 4.0 crashes
i have been running 4.0.2 on my smp system using the 2.4.1 kernel. the one thing is, i was using the xfree out of precision insite's cvs with the g400 binary-only hal lib dri module loaded. every-so-often, especially when closing windows or switching virtual desktops, the kernel would crash. luckily, i'm also running kdb on a serial console, so i am able to check things out and keep a log. unfortunately, when btp all the processes, i found no text.lock, which is as far as i know how to "debug" a kernel crash. of course, this could very well be something wrong with the binary-only module from matrox, so i'm seeing if the same problem presents itself with the original mga.o loaded (which also disables hardware dri). pete On Tue, 13 Feb 2001, Tony Gale wrote: > Having experienced a number of crashes with Xfree 4.0 with 2.4 > kernels, that I wasn't getting with 2.2 kernels, a quick search on > the xfree Xpert mailing list reveals this: -- Pete Toscano [EMAIL PROTECTED] 703.948.3364 GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736 PGP signature
Re: 2.4.1ac17 hang on mounting loopback fs
hmmm... I've been trying to play with GRUB on my 2.4.2-pre4 system. For safety's sake, I wanted to make a bookdisk with mkbootdisk. After reading this, I see now why mkbootdisk was locking in the D state with the loop mounted... Would this also explain not being able to seek forward while writing a floppy? I was trying to make the GRUB boot disk by writing the stage 1 and 2 loaders to the floppy (as per the GRUB docs) with dd: [root@bubba grub]# dd of=/dev/fd0 if=stage1 bs=512 count=1 1+0 records in 1+0 records out [root@bubba grub]# dd of=/dev/fd0 if=stage2 bs=512 seek=1 dd: advancing past 1 blocks in output file `/dev/fd0': Permission denied With 2.4.1, I get a different error message, but, AFAICT, the same result. pete Alan Cox writes: > > # mount -t ext2 -o loop /spare/i486-linuxaout.img /spare/mnt > > loop: enabling 8 loop devices > > Loop does not currently work in 2.4. It might partly work by luck > but thats it. This will change as and when the new loop patches go > in. Until then if you need loop use 2.2 PGP signature
Re: 2.4.1ac17 hang on mounting loopback fs
Excellent! Thanks, that worked. pete On Sat, 17 Feb 2001, Thomas Molina wrote: > On Sat, 17 Feb 2001, Pete Toscano wrote: > > > reading this, I see now why mkbootdisk was locking in the D state with > > the loop mounted... Would this also explain not being able to seek > > forward while writing a floppy? > > > > I was trying to make the GRUB boot disk by writing the stage 1 and 2 > > loaders to the floppy (as per the GRUB docs) with dd: > > > > [root@bubba grub]# dd of=/dev/fd0 if=stage1 bs=512 count=1 > > 1+0 records in > > 1+0 records out > > [root@bubba grub]# dd of=/dev/fd0 if=stage2 bs=512 seek=1 > > dd: advancing past 1 blocks in output file `/dev/fd0': Permission denied > > Different problem. Add conv=notrunc to the dd command to make it work. > PGP signature
Mysterious lockups with 2.4.X (Help w/KDB)
Hello, I've been experiencing some strange lock ups and I hope someone can help. I don't remember exactly when they started, but I know it was happening around the release of 2.4.0, possibly earlier with the test 2.4.0 kernels too. Around 2.4.0 time, I started patching in KDB to help find the problem as it helped find an emu10k issue a while ago. First, my hardware: I'm using a Tyan Tiger 133a motherboard (Via Apollo Pro 133a chipset) with dual P3 600s, 512M RAM, Soundblaster Live, Matrox G[24]00 (was using the G400, had a hardware problem, went back to a G200), Promise Ultra66 PCI IDE card, ADS Tech IEEE 1394 PCI card, Adaptec 2940 PCI SCSI card, and a Linksys 10/100 NIC. I'm also using a few USB devices: USB mouse, USB compact flash reader, and USB Rio500. Because of the continuing problems with PCI routing, SMP-enabled kernels, and the Via's APIC, I need to disable APIC (with "noapic") when I boot if I wish to use my USB devices. Finally, I have a serial console hooked to this machine so that I can capture dump info and use KDB. When I get a crash (it happened 3 times yesterday), a message like this appears on the serial console: Unable to handle kernel NULL pointer dereference at virtual address 017c printing eip: e08ac8bd *pde = Entering kdb (current=0xc7dbe000, pid 2513) on processor 0 Panic: Oops due to panic @ 0xe08ac8bd eax = 0xce39a400 ebx = 0x ecx = 0x000f edx = 0xc02daba0 esi = 0x0282 edi = 0x esp = 0xc7dbff5c eip = 0xe08ac8bd ebp = 0xc7dbff68 xss = 0x0018 xcs = 0x0010 eflags = 0x00010082 xds = 0xc02d0018 xes = 0x0018 origeax = 0x ®s = 0xc7dbff28 and then the KDB prompt appears. Back when I had my emu10k problems, Keith Owen told me to (in a nutshell), go through the running processes and "btp" their PID and look for "text.lock". Back then, I'd eventually find the process with the "text.lock", gather some more information, and send it to this list where somebody would almost always be able to tell me what the problem is. Needless to say, I'd like to be able to do this again, but I can't find any process with "text.lock". When the crashes would first happen, I'd go through the whole process table looking for the "text.lock" and not find any. This could take quite a while, but I'd repeat it thinking I was missing something somewhere, but after doing this a few times, I started to realize that it might not be me. Another thing I noticed the last time I tried to use KDB to hunt down a problem was that the process with "text.lock" would usually be the process marked with a 1 in the "*" column of the process list. This time, though, I'm still finding only on process marked with a 1 in the "*" column (klogd), but there's no "text.lock". Finally, if I run what's dumped to the console (like what I showed above) through ksymoops, it just returns the same text with no further expansion. (I guess this would make sense since "oops" never appears in the text of my dump, so I guess it's not an oops, eh?) Anyway, I'd like to try to track this bug down further -- it's making me pull out what little hair I have =) -- but I don't know what to do next, so I implore you, o great kernel hackers, to impart some of your knowledge upon me so that I may debug too. Any tips would be good too. =;] FWIW, I'm running 2.4.2 with the KDB patch, modutils-2.4.2, binutils 2.10.0.33, util-linux 2.10s, e2fsprogs 1.19, GNU make 3.79, and RedHat's kgcc (egcs 2.91.66). thanks, pete PGP signature
2.4.2 + SMP + EMU10k1 == lock?
Hello, I asked here about a week ago for help with debugging a random lock I've been experiencing. With the help of Mr. Owens, I seem to have gotten a bit further. (Long winded way of saying, "Sorry about the messy looking, clueless debugging.") I'm running 2.4.2 + KDB 1.8 on my SMP machine (2xp3-600). I have a serial console connected to my box. It looks like things might be locking up in the EMU10k1 driver. Anyone else? Is there any further info I can provide to someone who might be working on this? Thanks, pete [0]kdb> rd eax = 0xc983cca0 ebx = 0x ecx = 0xc02c8794 edx = 0x esi = 0x3296 edi = 0x esp = 0xc028bf34 eip = 0xe08ac8bd ebp = 0xc028bf40 xss = 0x0018 xcs = 0x0010 eflags = 0x00013096 xds = 0x0018 xes = 0x0018 origeax = 0x ®s = 0xc028bf00 [0]kdb> bt EBP EIP Function(args) 0xc028bf40 0xe08ac8bd [emu10k1]emu10k1_waveout_bh+0x11 (0xc983cca0, 0x1, 0xc02c7680) emu10k1 .text 0xe08aa060 0xe08ac8ac 0xe08ac950 0xc028bf58 0xc011bd6b tasklet_hi_action+0x4f (0xc02c7680, 0x0, 0xc02be800) kernel .text 0xc010 0xc011bd1c 0xc011bda4 0xc028bf78 0xc011bbfd do_softirq+0x5d (0xc01071d0, 0xc028a000) kernel .text 0xc010 0xc011bba0 0xc011bc30 0xc028bf94 0xc010b09e do_IRQ+0xda (0xc01071d0, 0x0, 0xc028a000, 0xc028a000, 0xc01071d0) kernel .text 0xc010 0xc010afc4 0xc010b0b0 0xc010919c ret_from_intr kernel .text 0xc010 0xc010919c 0xc01091bc Interrupt registers: eax = 0x ebx = 0xc01071d0 ecx = 0x edx = 0xc028a000 esi = 0xc028a000 edi = 0xc01071d0 esp = 0xc028bfd0 eip = 0xc01071ff ebp = 0xc028bfd0 xss = 0x0018 xcs = 0x0010 eflags = 0x3246 xds = 0xc0100018 xes = 0xc0280018 origeax = 0xff00 ®s = 0xc028bf9c 0xc01071ff default_idle+0x2f kernel .text 0xc010 0xc01071d0 0xc0107208 0xc028bfe4 0xc0107272 cpu_idle+0x42 kernel .text 0xc010 0xc0107230 0xc0107288 [0]kdb> rd eax = 0xc983cca0 ebx = 0x ecx = 0xc02c8794 edx = 0x esi = 0x3296 edi = 0x esp = 0xc028bf34 eip = 0xe08ac8bd ebp = 0xc028bf40 xss = 0x0018 xcs = 0x0010 eflags = 0x00013096 xds = 0x0018 xes = 0x0018 origeax = 0x ®s = 0xc028bf00 [0]kdb> bt EBP EIP Function(args) 0xc028bf40 0xe08ac8bd [emu10k1]emu10k1_waveout_bh+0x11 (0xc983cca0, 0x1, 0xc02c7680) emu10k1 .text 0xe08aa060 0xe08ac8ac 0xe08ac950 0xc028bf58 0xc011bd6b tasklet_hi_action+0x4f (0xc02c7680, 0x0, 0xc02be800) kernel .text 0xc010 0xc011bd1c 0xc011bda4 0xc028bf78 0xc011bbfd do_softirq+0x5d (0xc01071d0, 0xc028a000) kernel .text 0xc010 0xc011bba0 0xc011bc30 0xc028bf94 0xc010b09e do_IRQ+0xda (0xc01071d0, 0x0, 0xc028a000, 0xc028a000, 0xc01071d0) kernel .text 0xc010 0xc010afc4 0xc010b0b0 0xc010919c ret_from_intr kernel .text 0xc010 0xc010919c 0xc01091bc Interrupt registers: eax = 0x ebx = 0xc01071d0 ecx = 0x edx = 0xc028a000 esi = 0xc028a000 edi = 0xc01071d0 esp = 0xc028bfd0 eip = 0xc01071ff ebp = 0xc028bfd0 xss = 0x0018 xcs = 0x0010 eflags = 0x3246 xds = 0xc0100018 xes = 0xc0280018 origeax = 0xff00 ®s = 0xc028bf9c 0xc01071ff default_idle+0x2f kernel .text 0xc010 0xc01071d0 0xc0107208 0xc028bfe4 0xc0107272 cpu_idle+0x42 kernel .text 0xc010 0xc0107230 0xc0107288 [0]kdb> bt EBP EIP Function(args) 0xc028bf40 0xe08ac8bd [emu10k1]emu10k1_waveout_bh+0x11 (0xc983cca0, 0x1, 0xc02c7680) emu10k1 .text 0xe08aa060 0xe08ac8ac 0xe08ac950 0xc028bf58 0xc011bd6b tasklet_hi_action+0x4f (0xc02c7680, 0x0, 0xc02be800) kernel .text 0xc010 0xc011bd1c 0xc011bda4 0xc028bf78 0xc011bbfd do_softirq+0x5d (0xc01071d0, 0xc028a000) kernel .text 0xc010 0xc011bba0 0xc011bc30 0xc028bf94 0xc010b09e do_IRQ+0xda (0xc01071d0, 0x0, 0xc028a000, 0xc028a000, 0xc01071d0) kernel .text 0xc010 0xc010afc4 0xc010b0b0 0xc010919c ret_from_intr kernel .text 0xc010 0xc010919c 0xc01091bc Interrupt registers: eax = 0x ebx = 0xc01071d0 ecx = 0x edx = 0xc028a000 esi = 0xc028a000 edi = 0xc01071d0 esp = 0xc028bfd0 eip = 0xc01071ff ebp = 0xc028bfd0 xss = 0x0018 xcs = 0x0010 eflags = 0x3246 xds = 0xc0100018 xes = 0xc0280018 origeax = 0xff00 ®s = 0xc028bf9c 0xc01071ff default_idle+0x2f kernel .text 0xc010 0xc01071d0 0xc0107208 0xc028bfe4 0xc0107272 cpu_idle+0x42
usb + smp + apollo pro 133a + 2.4.0 = still broken
just a heads up that usb in smp-enabled 2.4.0 kernels running on machines with the via apollo pro 133a chipset is still broken. the last word i heard was that it's a pci irq routing problem. smp and usb will play together pretty nicely if you disable apic (ie. "noapic" to lilo). i'm more than willing to help test patches and provide any more info to people working on this, but i lack the low-level knowledge to actually fix it. thanks, pete -- Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED] GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736 PGP signature
Re: Related VIA PCI crazyness?
On Sun, 07 Jan 2001, Linus Torvalds wrote: [snip] > If the VIA logic for getting/setting the irq is wrong, it should only be > a problem if there are devices that _haven't_ been routed by the BIOS. > Usually these devices are limited to things like USB, ACPI and CardBus > controllers, and getting the irq routing wrong in that case can be > deadly (infinite irq streams on the wrong irq line). h, interesting that you should mention usb in this conversation. there's a problem with usb in smp-enabled kernels running on the via apollo pro 133a chipset. basically, unless apic is disabled, the usb controller (usb-uhci) doesn't get any interrupts and no usb device will be recognized. this has existed since the early 2.4.0-test days, if not earlier. i was talking with johannes erdfelt about this and he feels that it's a pci irq routing problem. as of yet, we haven't been able to find anyone who can help. we do see an occasional message on linux-usb about this problem though. > Could anybody with a VIA chip who has the energy please do something for > me: > - enable DEBUG in arch/i386/kernel/pci-i386.h > - do a "/sbin/lspci -xxvvv" on the interrupt routing chip (it's the >"ISA bridge" chip - the VIA numbers are 82c586, 82c596, the PCI >numbers for them are 1106:0586 and 1106:0596, I think) > - do a cat /proc/pci from a follow-up post, i get the impression that this won't help with smp-enabled systems, but if there's something similar that you think might help solve this one, please let me know and i'll be more than happy to oblige. thanks, pete -- Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED] GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736 PGP signature
Re: VIA chipset discussion
well, i know there's a problem with the via apollo pro 133a chipset, smp, apic, and usb. it looks like the usb driver (usb-uhci) doesn't receive any interrupts if apic is enabled. if you disable apic from the lilo prompt with "noapic", then it'll all work (of course, without apic). according to the linux-usb maintainers, it's a pci irq routing problem. i've asked jeff garzik and martin mares if they'll look into it, but they're pretty busy and i haven't heard anything back from them (not that'd i'd expect to for quite a while, considering their load). i've asked on the list too, but i've only heard back from people with the same problem, not anyone who can fix the problem. i've pretty much got the same system as you, except for the ultra66 promise card. pete On Wed, 17 Jan 2001, David D.W. Downey wrote: > > Could those that were involved in the VIA chipset discussion email me > privately at [EMAIL PROTECTED]? > > I'm truly interested in solving this issue. I personally think it's more > than just the chipset causing the problems. > > > I'm looking for members of the list that are using the kernel support for > the following > > > VIA chipset > Promise controller (PDC2026# with specifics on the PDC20265 (ATA100)) > SMP support > IDE + SCSI mix in the system. > > > I'm trying to track a number of POSSIBLE bugs (can't say they are for > sure) and any input from folks with this mix of drivers would be > exponentially useful, even if for nothing more than discounting some of my > thoughts. > > > Also, can anyone summurize the already known and specific problems with > combinations of the above requirements? I would truly appreciate that. > > David D.W. Downey - 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.2.18pre21 and ipv6 problems/questions
hello, i'm trying to set up an ipv6 machine. i got a setup script from freenet6 complete with an ipv6 address and the ipv6 and ipv4 addresses of my tunnel endpoint. i'm seeing some strange behavior, so i have a few questions. most of these are probably ubd (user brain damage), but i'd like to have these verified if possibe =). 0. basically, how complete/correct is the ipv6 implementation on 2.2.18pre21? should i even bother or is it fairly stable and correct? 1. how come i can ping6 ::1 just fine as long as the sit0 device is down, but as soon as it comes up, i can't? 2. i understand that the sit devices are pseudo devices on top of (well, in my case) eth0. afaict, sit0 represents my side of an ipv6-in-ipv4 tunnel and sit1 is the other side of it. ipv6 packets destined for removte ipv6 networks should be routed to the like-scoped ipv6 address of the sit1 device, right? 3. aliased interfaces are in ipv4-only construct right? i shouldn't be able to create an alias interface with only an ipv6 address, da? 4. should i be able to delete an address i add to an interface? when i "ifconfig add" an ipv6 address to an interface and then try to "ifconfig del" it, i get "SIOCDIFADDR: Invalid argument". i've tried to del with and without the /prefixlen and neither has worked. thanks, pete -- Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED] GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736 PGP signature
Re: 2.4.0-test12 not liking high disk i/o
well, i hate to be piling on here, but i just encountered this (i think it's this) this morning. i was printing a 145+m file (to /dev/lp0) from an ide drive and it locked up. just before the lockup, i noticed it was very sluggish, as if it were under very heavy load (which is really wasn't). this is on an smp-enabled machine (noapic at lilo prompt because of the usb/pirq(?) problem). i'm using 2.4.0-test12 on a tyan tiger 133 (via apollo 133a chipset) mobo. the machine has 512m memory and another 512m in swap (didn't notice much swap activity, but i could have missed it). there were no messages in the logs. if there's any info i can provide or tests i can run, just let me know. pete On Tue, 12 Dec 2000, Petr Vandrovec wrote: > On 12 Dec 00 at 17:43, Niels Kristian Bech Jensen wrote: > > On Tue, 12 Dec 2000, Mohammad A. Haque wrote: > > > > > Any one else experiencing problems when they do lots of disk activity > > > in test12? > > > > > Yes, I've had some complete freezes (nothing working at all) in > > test12-pre8 and test12. They can be triggered by e.g. Netscape. > > test12-pre7 seems to be stable. -- Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED] GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736 PGP signature
Re: [linux-usb-devel] PROBLEM: USB (MS Intellimouse specifically) does not work with SMP Linux 2.2.18.
what mobo/chipset are you using? i and a bunch of other people have been having very similar problems with this and the 2.4.0-test kernels. we all use the tyan tiger 133 mobo with the apollo pro 133a chipset. i believe that the 2.2.18 usb support has been pulled from the 2.4.0-test source, so i'm not surprised to be seeing this. on the linux-usb list, i was talking with johannes erdfel and doing some checks for him. he thinks that it's a pci irq problem as the usb controller (uhci and usb-uhci) don't get any interrupts on smp-enabled kernels when apic is enabled. i've written martin mares about this (but to the email address listed on his web page -- not [EMAIL PROTECTED], yet -- so it probably got dropped into /dev/null) and i'm eager to hear his opinion on matters. i'll bet that now that the problem has moved into the 2.2 line, we'll be seeing more noise about it. laramie, try disabling apic at the lilo prompt (add "noapic" after your kernel image's name) and see if that helps. pete On Tue, 12 Dec 2000, Greg KH wrote: > On Tue, Dec 12, 2000 at 02:07:59PM -, Laramie Leavitt wrote: > > [1.] One line summary of the problem: > > USB (MS Intellimouse specifically) does not work with SMP kernel 2.2.18. > > > > [2.] Full description of the problem/report: > > When trying to install a Microsoft Intellimouse Explorer (USB) > > to a SMP kernel, I get the following error multiple times: > > > > usb.c: USB device not accepting new address (error=-110) > > What's your BIOS setting for MSR? > > And how about the contents of /proc/interrupts? > > This is a case of when the usb code isn't getting the hardware interrupt > delivered properly. > > thanks, > > greg k-h -- Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED] GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736 PGP signature
test1[12] + sparc + bind 9.1.0b1 == bad things
hello,
i'm tried using the first beta release of bind 9.1.0 on an ultra 5
running 2.4.0-test11 or test12 (modified redhat 6.2 distro -- mostly
ipv6-related mods). as soon as i start up named, the machine goes nuts
and continuously prints the following oops (from test12):
\|/ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
(10): Oops
TSTATE: 80f09606 TPC: 00448264 TNPC: 00448268 Y: 0180
g0: 0041a198 g1: g2: g3: 30303866
g4: f800 g5: 000f g6: f800167dc000 g7:
o0: 0001 o1: 000f o2: f800167dc178 o3:
o4: 00624f3b o5: 00624f3f sp: f8001295bdd1 ret_pc: 00443848
l0: 0006 l1: f800167dc000 l2: 00629000 l3: 0068dc00
l4: 00629000 l5: 3fff l6: 000f l7: 00625318
i0: 0009 i1: 0400 i2: f800167dc000 i3: 0001
i4: 00624f1b i5: 00624f26 i6: f8001295be91 i7: 0041a198
Instruction DUMP: 10680005 90102000 c45aa008 c6708000 913a2000 c0728000
c072a008 91924000
Aiee, killing interrupt handler
ÿÿ<1>Unable to handle kernel paging request in mna handler<1> at virtual address
3030386e
current->{mm,active_mm}->context = 625318ff
current->{mm,active_mm}->pgd = 03402a00
here's the ksymoops output:
ksymoops 2.3.5 on sparc64 2.4.0-test12-1. Options used
-V (default)
-K (specified)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test12-1/ (default)
-m /usr/src/linux/System.map (default)
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
(10): Oops
TSTATE: 80f09606 TPC: 00448264 TNPC: 00448268 Y: 0180
Using defaults from ksymoops -t elf32-sparc -a sparc
g0: 0041a198 g1: g2: g3: 30303866
g4: f800 g5: 000f g6: f800167dc000 g7:
o0: 0001 o1: 000f o2: f800167dc178 o3:
o4: 00624f3b o5: 00624f3f sp: f8001295bdd1 ret_pc: 00443848
l0: 0006 l1: f800167dc000 l2: 00629000 l3: 0068dc00
l4: 00629000 l5: 3fff l6: 000f l7: 00625318
i0: 0009 i1: 0400 i2: f800167dc000 i3: 0001
i4: 00624f1b i5: 00624f26 i6: f8001295be91 i7: 0041a198
Instruction DUMP: 10680005 90102000 c45aa008 c6708000 913a2000 c0728000
c072a008 91924000
>>PC; 00448264<=
>>O7; 00443848
>>I7; 0041a198
Code; 00448258
<_PC>:
Code; 00448258
0: 10 68 00 05 unknown
Code; 0044825c
4: 90 10 20 00 clr %o0
Code; 00448260
8: c4 5a a0 08 unknown
Code; 00448264<=
c: c4 70 e0 08 unknown <=
Code; 00448268
10: c6 70 80 00 unknown
Code; 0044826c
14: 91 3a 20 00 sra %o0, 0, %o0
Code; 00448270
18: c0 72 80 00 unknown
Code; 00448274
1c: c0 72 a0 08 unknown
Code; 00448278
20: 91 92 40 00 unknown
Aiee, killing interrupt handler
<1>Unable to handle kernel paging request in mna handler<1> at virtual address
3030386e
is there any further info i can provide? would the test11 oops help
too?
is it not bad enough that i spent the whole day frustrated, working with
this system? but then the computer had to keep making faces at me,
mocking me. *sigh* =;]
pete
--
Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED]
GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736
PGP signature
linux ipv6 questions. bugs?
i'm using test12 with ipv6 enabled. i'm seeing something strange, but i can't tell if it's a linux or openbsd bug. i have two boxes, one's running 2.4.0-test12 and the other's running openbsd 2.8 (the same problem was seen with this machine using 2.7 too). they are on a little ipv6 network, with a 125 bit prefix length. i have two question, one short, one longer. i'll start with the short one: 0. whenever i ping6 the loopback interface (::1/128), all echo requests seem to be dropped and i get no echo replies. is this correct? on the openbsd box, i can ping6 ::1 just fine. 1. i can only ping6 the ipv6 address of the openbsd machine once i put the openbsd box's ethernet interface into promisc mode (with tcpdump). after that (and even once the openbsd box's eth is back in non-promisc mode), i can ping6 the openbsd box fine. looking at a packet capture, i see the neighbor solicitation packets from the linux box, but i noticed something strange; in the ethernet header of the n.s. packets, the destination mac address is set to the linux box's mac address and the source mac address is set to 0:0:0:0:0:0. shouldn't this be the other way around? this would explain why the openbsd box doesn't respond to the linux box's n.s. until it starts looking at all the packets in promisc mode, right? thanks, pete -- Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED] GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736 PGP signature
Re: linux ipv6 questions. bugs?
On Wed, 13 Dec 2000, [EMAIL PROTECTED] wrote: > Hello! > > > 0. whenever i ping6 the loopback interface (::1/128), all echo requests > > seem to be dropped and i get no echo replies. is this correct? > Your guess? 8) Of course, it is incorrect. I even have no idea > how it is possible to put system into such sad state. well, just power it on, it seems. but then again, this is just a guess. =;] > Though... probably, you forgot to up loopback. doesn't look it: [root@nsv6 /root]# ifconfig lo loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:7952 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 [root@nsv6 /root]# ping6 ::1 PING ::1(::1) from ::1 : 56 data bytes --- ::1 ping statistics --- 156 packets transmitted, 0 packets received, 100% packet loss ...and this is right after boot. > > the destination mac address is set to the linux box's mac address and > > the source mac address is set to 0:0:0:0:0:0. > > I think it is consequence of above. When loopback interface is missing, > networking does not work. > > > > other way around? this would explain why the openbsd box doesn't > > respond to the linux box's n.s. until it starts looking at all the > > packets in promisc mode, right? > > Rather it means that openbsd is buggy, its stack accepts packets > not destined to it. It cannot react to those strange packets, which > you have just described. that may very well be, but shouldn't the neighbor solisitation packets from the linux box have the source mac address set to its mac address and the destination mac address set to 0:0:0:0:0:0 and not the other way around? thanks, pete -- Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED] GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736 PGP signature
Re: linux ipv6 questions. bugs?
ugh, bad form, i know, but i forgot this little dollop of information: it looks like the incorrectly mac addressed n.s. packets are being fed right back into the linux box's ip stack (as it sees an ethernet packet with the destination set to its own mac address): [root@nsv6 /root]# ping6 X:Y::1 PING X:Y::1(X:Y::1) from X:Y::4 : 56 data bytes From ::1: Destination unreachable: Address unreachable From ::1: Destination unreachable: Address unreachable . . . From ::1: Destination unreachable: Address unreachable 64 bytes from X:Y::1: icmp_seq=16 hops=64 time=433 usec 64 bytes from X:Y::1: icmp_seq=15 hops=64 time=1.000 sec the pings start working when i put the X:Y::1 box's ethernet card into promsc mode and it sees an ipv6 packet destined for one of its multicast addresses. (i guess promsc mode tells the eth to just ignore all link-level addressing info.) pete On Wed, 13 Dec 2000, Pete Toscano wrote: > > On Wed, 13 Dec 2000, [EMAIL PROTECTED] wrote: > > > Hello! > > > > > 0. whenever i ping6 the loopback interface (::1/128), all echo requests > > > seem to be dropped and i get no echo replies. is this correct? > > > Your guess? 8) Of course, it is incorrect. I even have no idea > > how it is possible to put system into such sad state. > > well, just power it on, it seems. but then again, this is just a guess. > =;] > > > Though... probably, you forgot to up loopback. > > doesn't look it: > > [root@nsv6 /root]# ifconfig lo > loLink encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:7952 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > [root@nsv6 /root]# ping6 ::1 > PING ::1(::1) from ::1 : 56 data bytes > > --- ::1 ping statistics --- > 156 packets transmitted, 0 packets received, 100% packet loss > > ...and this is right after boot. > > > > the destination mac address is set to the linux box's mac address and > > > the source mac address is set to 0:0:0:0:0:0. > > > > I think it is consequence of above. When loopback interface is missing, > > networking does not work. > > > > > > > other way around? this would explain why the openbsd box doesn't > > > respond to the linux box's n.s. until it starts looking at all the > > > packets in promisc mode, right? > > > > Rather it means that openbsd is buggy, its stack accepts packets > > not destined to it. It cannot react to those strange packets, which > > you have just described. > > that may very well be, but shouldn't the neighbor solisitation packets > from the linux box have the source mac address set to its mac address > and the destination mac address set to 0:0:0:0:0:0 and not the other way > around? > > thanks, > pete -- Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED] GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736 PGP signature
Re: test1[12] + sparc + bind 9.1.0b1 == bad things
On Wed, 13 Dec 2000, Pete Zaitcev wrote:
> > Is this the first OOPS it prints out? I don't think so. I am
> > very sure it printed out messages from die_if_kernel first and
> > we need that initial OOPS to diagnose this bug and fix it.
> >
> > All the rest of the OOPS messages are useless and won't tell
> > us what the real problem is.
>
> > Later,
> > David S. Miller
no, you're right. here's the first oops:
named(465): Oops
TSTATE: f0f09603 TPC: 0043f730 TNPC: 0043f734 Y: 0c00
g0: 70029eb470029ea0 g1: 003d g2: 0002 g3:
g4: f800 g5: 0004 g6: f8001318c000 g7: 003d
o0: 0068dd00 o1: 0001 o2: o3: 0071
o4: o5: sp: f8001318ed91 ret_pc: 0042d5c0
l0: l1: 70188270 l2: f8001398b8f0 l3: 005b4400
l4: 0068fc00 l5: 005b45c0 l6: 000f l7:
i0: i1: f80010528908 i2: 0001 i3: 0001
i4: i5: 0003 i6: f8001318ee51 i7: 004b2878
Caller[004b2878]
Caller[004b2b3c]
Caller[004e205c]
Caller[004ef3d8]
Caller[004e3e5c]
Caller[0041b154]
Caller[00408874]
Caller[0042d5c0]
Caller[0042da28]
Caller[004100b4]
Caller[7005ccd4]
Instruction DUMP: a4063ff0 d85ca008 f05e 900f4008 80a22000 0247fff8
80a60019 02f6ffcc
Aiee, killing interrupt handler
Unable to handle kernel NULL pointer dereference
tsk->{mm,active_mm}->context = 05c9
tsk->{mm,active_mm}->pgd = f80013789000
..and here's its ksymoops output:
ksymoops 2.3.5 on sparc64 2.4.0-test12-1. Options used
-V (default)
-K (specified)
-L (specified)
-O (specified)
-m /usr/src/linux/System.map (default)
named(465): Oops
TSTATE: f0f09603 TPC: 0043f730 TNPC: 0043f734 Y:0c00
Using defaults from ksymoops -t elf32-sparc -a sparc
g0: 70029eb470029ea0 g1: 003d g2: 0002 g3:
g4: f800 g5: 0004 g6: f8001318c000 g7: 003d
o0: 0068dd00 o1: 0001 o2: o3: 0071
o4: o5: sp: f8001318ed91 ret_pc: 0042d5c0
l0: l1: 70188270 l2: f8001398b8f0 l3: 005b4400
l4: 0068fc00 l5: 005b45c0 l6: 000f l7:
i0: i1: f80010528908 i2: 0001 i3: 0001
i4: i5: 0003 i6: f8001318ee51 i7: 004b2878
Caller[004b2878]
Caller[004b2b3c]
Caller[004e205c]
Caller[004ef3d8]
Caller[004e3e5c]
Caller[0041b154]
Caller[00408874]
Caller[0042d5c0]
Caller[0042da28]
Caller[004100b4]
Caller[7005ccd4]
Instruction DUMP: a4063ff0 d85ca008 f05e 900f4008 80a22000 0247fff8
80a60019 02f6ffcc
>>PC; 0043f730 <__wake_up+110/220> <=
>>O7; 0042d5c0
>>I7; 004b2878
Trace; 004b2878
Trace; 004b2b3c
Trace; 004e205c
Trace; 004ef3d8
Trace; 004e3e5c
Trace; 0041b154
Trace; 00408874
Trace; 0042d5c0
Trace; 0042da28
Trace; 004100b4
Trace; 7005ccd4
Code; 0043f724 <__wake_up+104/220>
<_PC>:
Code; 0043f724 <__wake_up+104/220>
0: a4 06 3f f0 add %i0, -16, %l2
Code; 0043f728 <__wake_up+108/220>
4: d8 5c a0 08 unknown
Code; 0043f72c <__wake_up+10c/220>
8: f0 5e 00 00 unknown
Code; 0043f730 <__wake_up+110/220> <=
c: d0 5b 00 00 unknown <=
Code; 0043f734 <__wake_up+114/220>
10: 90 0f 40 08 and %i5, %o0, %o0
Code; 0043f738 <__wake_up+118/220>
14: 80 a2 20 00 cmp %o0, 0
Code; 0043f73c <__wake_up+11c/220>
18: 02 47 ff f8 unknown
Code; 0043f740 <__wake_up+120/220>
1c: 80 a6 00 19 cmp %i0, %i1
Code; 0043f744 <__wake_up+124/220>
20: 02 f6 ff cc unknown
Aiee, killing interrupt handler
Unable to handle kernel NULL pointer dereference
tsk->{mm,active_mm}->context = 05c9
tsk->{mm,active_mm}->pgd = f80013789000
thanks,
pete
--
Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED]
GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736
PGP signature
usb + smp + 2.4.0test = pci irq routing problem?
hello, i've been working with johannes erdfelt in fixing a problem with usb on my machine. it's a dual pentium 3 system on a tyan tiger 133 mobo (via apollo pro 133a chipset). basically, usb works when i don't enable smp or when i disable apic on smp-enabled kernels. he believes that we're seeing a pci irq routing problem and that i should contact martin mares about this problem. (i've written him a couple times, but have heard nothing, so i figure he's either away, busy, or whatnot and i thought i'd try lkml for help.) i have an ethernet card on my system and it shares an irq with usb-uhci. in this state, i see interrupts for the irq eth0 and usb-uhci share. when i remove the ethernet card, i get this in /proc/interrupts: CPU0 CPU1 0: 37124 19379IO-APIC-edge timer 1:146 84IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 8: 1 0IO-APIC-edge rtc 14: 1640 1910IO-APIC-edge ide0 15: 1 1IO-APIC-edge ide1 16: 29 28 IO-APIC-level ide2 18: 26 27 IO-APIC-level aic7xxx 19: 0 0 IO-APIC-level usb-uhci NMI: 56419 56419 LOC: 56392 56403 ERR: 0 from this, je thought that this was a pci irq routing problem and not a usb problem. because of this, running an smp-enabled kernel with apic enabled yields the "device not accepting new address" error on startup (usb is compiled into my kernel, so i'm not sure what part is actually triggering the error) and none of the usb devices work. (yes, i've checked the mps and tried both 1.1 and 1.4.) if i disable apic or don't use an smp-enabled kernel, everything works fine. this has been happening for quite a while, at least since 2.4.0test9, right up to test13-pre3. i really don't know what kind of information would be useful for debugging this problem. i don't know much about kernel programming, but i am more than willing to try any kind of patch or give any information about my system that could help squash this bug. it's a problem that quite a few people on the linux-usb list are complaining about (all, it seems, have this via chipset). please let me know if there's any more info i can provide, i'm more than happy to help. thanks, pete -- Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED] GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736 PGP signature
usb and smp problems with 2.4.0-test9/2.2.18-pre15
hello, i haven't been on lkml since vger died, but just subscribed and looked at the archives and was unable to find anything on this... i'm running 2.4.0-test9 and 2.2.18-pre15. for both of these kernels, if i enable usb and smp, i get a lot of usb device timeout errors. if i recompile, just disabling smp, the usb devices work fine. i'm using a tyan tiger 133 (1854d, i believe) mobo (via apollo pro 133a chipset). this is with both redhat 6.2 and 7.0 (thought it might be gcc 2.96, but it seems to happen with both). i also tried both the normal UHCI and JE's UHCI drivers, but there's no change. any ideas? any more information i can provide to help? thanks, pete -- Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED] GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736 PGP signature
Re: usb and smp problems with 2.4.0-test9/2.2.18-pre15
oh, btw, i also tried an asus p2b-ds mobo with the intel bx chipset with the same results. pete On Mon, 09 Oct 2000, Pete Toscano wrote: > hello, > > i haven't been on lkml since vger died, but just subscribed and looked > at the archives and was unable to find anything on this... > > i'm running 2.4.0-test9 and 2.2.18-pre15. for both of these kernels, if > i enable usb and smp, i get a lot of usb device timeout errors. if i > recompile, just disabling smp, the usb devices work fine. > > i'm using a tyan tiger 133 (1854d, i believe) mobo (via apollo pro 133a > chipset). this is with both redhat 6.2 and 7.0 (thought it might be gcc > 2.96, but it seems to happen with both). i also tried both the normal > UHCI and JE's UHCI drivers, but there's no change. > > any ideas? > > any more information i can provide to help? > > thanks, > pete -- Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED] GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736 PGP signature
Re: usb and smp problems with 2.4.0-test9/2.2.18-pre15
greg, machine's at home and in a bit of a wedged state, so i can't get this info to you right away, but i will if you think it'll help debug the issue. from what you say, the people on the linux-usb-devel list already have patches for these things, so i'm wondering if it'll be useful. anyway, i don't recall all of the usb errors, but i think there was "breadth" in it, it had about four lines of error message produced and they kept repeating until i unplugged all usb devices, and there were timeouts. useful, eh? =8] like i said, i can get this info to you if you think it'd be helpful. i'm using a usb mouse. i have two usb hubs -- one in my keyboard (ms natural pro) and one in my monitor (nokia 446xpro). i also have a usb compact flash card reader and a rio 500. the mouse and the reader are usually plugged into the monitor and the rio is plugged into the keyboard, if at all. i'll send my .config file if you think it'd be helpful. it's set to mps 1.1. linux has issues with 1.4? if it's not a problem, would you please send the patches or point me to where i can pick them up? thanks, pete On Mon, 09 Oct 2000, Greg KH wrote: > On Mon, Oct 09, 2000 at 12:36:46PM -0400, Pete Toscano wrote: > > any more information i can provide to help? > > Yes: > What kind of timeout errors are you seeing? Kernel debug logs would be > helpful. > What devices are you trying to use? > What is your .config file? > What is your BIOS setting for MPS (if it's 1.4, please try 1.1)? > > There are quite a few broken USB drivers in 2.4.0-test9. See the > linux-usb-devel mailing list for the patches, or I can send them to you > if you want. > > I'm successfully running USB on a smp machine for both 2.4.0-test9 (with > extra USB patches) and 2.2.18pre15 with no problems. > > thanks, > > greg k-h -- Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED] GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736 PGP signature
2.4.2 Lockup in SCSI Error Handler
Hello, I'm running 2.4.2 with KDB patch on an SMP system. I have an Adaptec 2940 SCSI card that my CD burner is connected to. When this happened, I was not using the CD at all. This is on a Tyan Tiger 133 motherboard (with the Via Apollo Pro 133a chipset). I'm running with "noapic" due to the Via PCI IRQ routing problem, so that I can use USB devices. I'm not very good with debuggers or hunting down kernel bugs, so I apologize in advance. Here's what I found: Stack traceback for pid 448 EBP EIP Function(args) 0xe68f1f6c 0xc011524a schedule+0x41e (0xe76021c0, 0xe68f) kernel .text 0xc010 0xc0114e2c 0xc0115460 0xe68f1f9c 0xc0107bb8 __down_interruptible+0x94 kernel .text 0xc010 0xc0107b24 0xc0107c24 0xe68f1fac 0xc0107c96 __down_failed_interruptible+0xa (0x100, 0xe694dd14, 0xe694dd6c, 0xe68f1fd8, 0x0) kernel .text 0xc010 0xc0107c8c 0xc0107c9c 0xe8f4edbf [scsi_mod].text.lock+0x1fb scsi_mod .text.lock 0xe8f4ebc4 0xe8f4ebc4 0xe8f4eee8 0xe68f1fec 0xe8f4a2bf [scsi_mod]scsi_error_handler+0x107 scsi_mod .text 0xe8f45060 0xe8f4a1b8 0xe8f4a330 0xc0107547 kernel_thread+0x23 kernel .text 0xc010 0xc0107524 0xc010755c [0]kdb> id 0xe8f4eba0 0xe8f4eba0 scan_scsis_single+0x594cmp$0x1,%dl 0xe8f4eba3 scan_scsis_single+0x597jne0xe8f4ebaf scan_scsis_single+0x5a3 0xe8f4eba5 scan_scsis_single+0x599testb $0xf,0x3(%eax) 0xe8f4eba9 scan_scsis_single+0x59dje 0xe8f4e6f5 scan_scsis_single+0xe9 0xe8f4ebaf scan_scsis_single+0x5a3mov$0x1,%eax 0xe8f4ebb4 scan_scsis_single+0x5a8lea0xff68(%ebp),%esp 0xe8f4ebba scan_scsis_single+0x5aepop%ebx 0xe8f4ebbb scan_scsis_single+0x5afpop%esi 0xe8f4ebbc scan_scsis_single+0x5b0pop%edi 0xe8f4ebbd scan_scsis_single+0x5b1mov%ebp,%esp 0xe8f4ebbf scan_scsis_single+0x5b3pop%ebp 0xe8f4ebc0 scan_scsis_single+0x5b4ret 0xe8f4ebc1 scan_scsis_single+0x5b5nop 0xe8f4ebc2 scan_scsis_single+0x5b6nop 0xe8f4ebc3 scan_scsis_single+0x5b7nop 0xe8f4ebc4 .text.lockcall 0xc0107cac __up_wakeup [0]kdb> id 0xe8f4ebb0 0xe8f4ebb0 scan_scsis_single+0x5a4add%eax,(%eax) 0xe8f4ebb2 scan_scsis_single+0x5a6add%al,(%eax) 0xe8f4ebb4 scan_scsis_single+0x5a8lea0xff68(%ebp),%esp 0xe8f4ebba scan_scsis_single+0x5aepop%ebx 0xe8f4ebbb scan_scsis_single+0x5afpop%esi 0xe8f4ebbc scan_scsis_single+0x5b0pop%edi 0xe8f4ebbd scan_scsis_single+0x5b1mov%ebp,%esp 0xe8f4ebbf scan_scsis_single+0x5b3pop%ebp 0xe8f4ebc0 scan_scsis_single+0x5b4ret 0xe8f4ebc1 scan_scsis_single+0x5b5nop 0xe8f4ebc2 scan_scsis_single+0x5b6nop 0xe8f4ebc3 scan_scsis_single+0x5b7nop 0xe8f4ebc4 .text.lockcall 0xc0107cac __up_wakeup 0xe8f4ebc9 .text.lock+0x5jmp0xe8f450ae scsi_wait_done+0x22 0xe8f4ebce .text.lock+0xacmpb $0x0,0xe8f58af4 0xe8f4ebd5 .text.lock+0x11repz nop [0]kdb> id 0xe8f4edbf 0xe8f4edbf .text.lock+0x1fbjmp0xe8f4a2bf scsi_error_handler+0x107 0xe8f4edc4 .text.lock+0x200call 0xc0107cac __up_wakeup 0xe8f4edc9 .text.lock+0x205jmp0xe8f4a320 scsi_error_handler+0x168 0xe8f4edce .text.lock+0x20acmpb $0x0,0xc027d140 0xe8f4edd5 .text.lock+0x211repz nop 0xe8f4edd7 .text.lock+0x213jle0xe8f4edce .text.lock+0x20a 0xe8f4edd9 .text.lock+0x215jmp0xe8f4a33b scsi_old_times_out+0xb 0xe8f4edde .text.lock+0x21acmpb $0x0,0xc027d140 0xe8f4ede5 .text.lock+0x221repz nop 0xe8f4ede7 .text.lock+0x223jle0xe8f4edde .text.lock+0x21a 0xe8f4ede9 .text.lock+0x225jmp0xe8f4a4d1 scsi_old_times_out+0x1a1 0xe8f4edee .text.lock+0x22acmpb $0x0,0xc027d140 0xe8f4edf5 .text.lock+0x231repz nop 0xe8f4edf7 .text.lock+0x233jle0xe8f4edee .text.lock+0x22a 0xe8f4edf9 .text.lock+0x235jmp0xe8f4aa71 scsi_old_done+0x501 0xe8f4edfe .text.lock+0x23acmpb $0x0,0xc027d140 Is this a known problem that's been fixed in the AC or test line? Is there any more information I can provide about my system? Any tips on better information to grab next time something like this happens? Thanks, pete PGP signature
Re: APIC usb MPS 1.4 and the 2.4.2 kernel
Well, I can't speak for the consequences of noapic (I've wondered as much myself), but I know that there's been a problem with SMP 2.4 kernels (even the 2.4 test kernels) and USB running on VIA chipsets for a while now. I'm told by the linux-usb maintainers that it's a problem with the PCI IRQ routing for the VIA chipsets, but I've been unable to get anyone who knows about this to do anything (and I've been asking for a while). Alas, since this stuff is beyond me, I just accept the fact that it'll probably always be broke. pete On Mon, 12 Mar 2001, David DeGeorge wrote: > I am running 2.4.2 as obtained from redhat, but I have experienced the same > problems with a kernel compiled from the 2.4.2 sources at kernel.org. > I am experiencing troubles with enabling MPS 1.4 and USB. I have an ABIT VP6 > motherboard with two stock 733MHz PIIIs. > If I set MPS1.1 in the bios then my IOmega Photoshow usb zip drive works, the > usb interrupt appears on irq 9 and after a day or two I experience a hard > (sysreq doesn't work) lock. It seems usb related since doing usb things i.e. > mounting the drive sometimes cause the lock. > If I set MPS1.4 in the bios then the usb interrupt appears on irq 19, whose > count is alway zero, and the zip drive doesn't get registered. If give the > noapic command line then things appear to work, irq=9,don't know about the > hard locks, but booting seems much slower. Of course I can provide much more > information but I wonder is this a common problem and what are the > consequences of the noapic command? > David PGP signature
Re: APIC usb MPS 1.4 and the 2.4.2 kernel
On Tue, 13 Mar 2001, Greg KH wrote: > On Tue, Mar 13, 2001 at 12:25:13AM -0500, Pete Toscano wrote: > > Well, I can't speak for the consequences of noapic (I've wondered as > > much myself), but I know that there's been a problem with SMP 2.4 > > kernels (even the 2.4 test kernels) and USB running on VIA chipsets for > > a while now. I'm told by the linux-usb maintainers that it's a problem > > with the PCI IRQ routing for the VIA chipsets, but I've been unable to > > get anyone who knows about this to do anything (and I've been asking for > > a while). Alas, since this stuff is beyond me, I just accept the fact > > that it'll probably always be broke. > It seems that the APIC on this motherboard does not have most of the > pins connected, so that even if we could get the USB interrupt to work > properly (which we couldn't) there would be no benefit to run in APIC > mode. I was going to run some crude benchmarks on the box with and > without APIC mode just to get an sense if we are missing anything > running in noapic mode, but I haven't gotten around to it yet. 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? > But, Linux does seem to run just fine with USB and SMP in the noapic > mode, which is a lot better than Win2000 can say, as it doesn't even > support the VIA USB chipset on this board at all :) How would this express itself? I recently upgraded from WinME to Win2k and it all _seems_ to be working well. Where would I look to verify this? Thanks for the info and the update. pete PGP signature
Re: APIC usb MPS 1.4 and the 2.4.2 kernel
On Wed, 14 Mar 2001, Juha Saarinen wrote: > Greg, > > :: It seems that the APIC on this motherboard does not have most of the > :: pins connected, so that even if we could get the USB interrupt to work > :: properly (which we couldn't) there would be no benefit to run in APIC > :: mode. I was going to run some crude benchmarks on the box with and > :: without APIC mode just to get an sense if we are missing anything > :: running in noapic mode, but I haven't gotten around to it yet. > > So for Tyan Tigers, is it better to compile the kernel without APIC? About > to install Linux on a dual 500 P3 here. AFAIK, the option to compile w/o APIC is only for UP systems. If you want to use both of your processors, you have to compile in APIC support, but just disable it when loading the kernel (ie. for lilo, 'append="noapic"') > :: But, Linux does seem to run just fine with USB and SMP in the noapic > :: mode, which is a lot better than Win2000 can say, as it doesn't even > :: support the VIA USB chipset on this board at all :) > > There's a Win2K patch for VIA chip sets now... I've got USB working under > Win2K here. That would explain why it works for me. Now, if only I didn't have devices that need to have their BIOSes upgraded via a Windows .exe... pete PGP signature
Re: [sligthly OT] serial console on palm
I use my Palm VX as a serial console on Linux, OpenBSD, FreeBSD, and Solaris. Just get a serial cable for your unit and some console program such as pTelnet. The rest is quite simple. If you find something different than pTelnet for console, please let me know as I find it crashes too much. pete On Sun, 18 Mar 2001, Andreas Dilger wrote: > John Lenton writes: > > 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? > > I got one recently called "serialrecord" for the Palm, but it is one-way > only (useful for capturing OOPSes or so. If someone had a two-way console > for the Palm, it would be great. Sorry, no URL, but you _should_ be able > to find it in l-k archives. PGP signature
Constant Crash in scsi_eh_0
Hello, I'm currently running 2.4.3-pre4. (I tried 2.4.3-pre6, but it wouldn't boot. I'm about to try -pre7.) This seemed worse with 2.4.2, but it's still a problem. My system's about as stable as Crispin Glover after a week-long meth binge. =8] I'm running an SMP system (dual P3 600s) with 640M of RAM. It's using a Tyan Tiger 133 motherboard (VIA Apollo Pro 133a chipset). It's got 2 ATA66 IDE drives, an IDE CD-ROM, and a SCSI CD burner (connected to an Adaptec 2940 adaptor). I also have a few USB devices: mouse, rio500, and Sandisk SDDR-31 compact flash reader. The burner and CF reader use SCSI. These are the only two SCSI-related devices on my system (that I'm aware of, at least). For every crash that I remember, I have not once been using either the CF reader or the burner. The usb-storage and scsi_mod devices were loaded by the hotplug driver (version 2001_02_28). None of these were used. I do have KDB compiled into the kernel, so I was able to get some debugging info captured via a serial console. Unfortunately, I don't know what would be useful and what's not that useful. Anyway, I've attached the log. If there's other information that'd be good to have, please let me know and I'll try to get it *sigh* the next time my machine crashes. As far as I can tell, something bad happens in scsi_eh_0 every time. Also attached is my config file. Please let me know if there's anything I can do to try to fix the problem. I'm not adverse to trying experimental patches. pete # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_PM=y # CONFIG_ACPI is not set CONFIG_APM=m # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set CONFIG_APM_CPU_IDLE=y # CONFIG_APM_DISPLAY_BLANK is not set CONFIG_APM_RTC_IS_GMT=y # CONFIG_APM_ALLOW_INTS is not set CONFIG_APM_REAL_MODE_POWER_OFF=y # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_FIFO=y CONFIG_PARPORT_PC_SUPERIO=y # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=m CONFIG_ISAPNP=m # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_SIZE=4096 # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=m CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y # CONFIG_NETLINK_DEV is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set CONFIG_INET_ECN=y CONFIG_SYN_COOKIES=y # # IP: Netfilter
Via PCI IRQ routing problem related? (was: PCI IRQ routing problem in 2.4.0)
hmmm, would these sis-related pirq problems be related to the current problems lots of people with a via chipset (at least the apollo pro 133a chipset) and an smp-enabled kernel are seeing? currently, people with this chipset and an smp-enabled kernel have to disable apic if they wish to use usb. i've been told a few times that it's a problem with pci irq routing, but have been able to find a fix. reports of this problem pop up every-so-often on the linux-usb list. here's my dump_pirq output: Interrupt routing table found at address 0xfdb50: Version 1.0, size 0x00a0 Interrupt router is device 00:07.0 PCI exclusive interrupt mask: 0x1c20 [5,10,11,12] Compatible router: vendor 0x1106 device 0x0596 Device 00:0f.0 (slot 1): FireWire (IEEE 1394) INTA: link 0x05, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTB: link 0x01, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTC: link 0x02, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTD: link 0x03, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] Device 00:10.0 (slot 2): SCSI storage controller INTA: link 0x01, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTB: link 0x02, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTC: link 0x03, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTD: link 0x05, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] Device 00:11.0 (slot 3): Multimedia audio controller INTA: link 0x02, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTB: link 0x03, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTC: link 0x05, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTD: link 0x01, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] Device 00:12.0 (slot 4): Unknown mass storage controller INTA: link 0x03, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTB: link 0x05, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTC: link 0x01, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTD: link 0x02, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] Device 00:13.0 (slot 5): Ethernet controller INTA: link 0x05, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTB: link 0x01, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTC: link 0x02, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTD: link 0x03, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] Device 00:14.0 (slot 6): INTA: link 0x01, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTB: link 0x02, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTC: link 0x03, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTD: link 0x05, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] Device 00:01.0 (slot 0): PCI bridge INTA: link 0x01, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTB: link 0x02, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTC: link 0x03, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTD: link 0x05, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] Device 00:07.0 (slot 0): ISA bridge INTC: link 0x03, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTD: link 0x05, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] Interrupt router at 00:07.0: VIA 82C596 PCI-to-ISA bridge PIRQA (link 0x01): irq 11 PIRQB (link 0x02): irq 5 PIRQC (link 0x03): irq 10 PIRQD (link 0x05): irq 12 any ideas? i also saved the lspci -vvvxxx and dmesg output if that'll be helpful. thanks, pete On Sun, 28 Jan 2001, Linus Torvalds wrote: > On Sun, 28 Jan 2001, Tim Hockin wrote: > > > > In reading the PIRQ specs, and making it work for our board, I thought > > about this. PIRQ states that link is chipset-dependant. No chipset that I > > have seen specifies what link should be. So, as this case demonstrates, it > > may be 'A' - the value the chipset expects, or 1, the logical index. > > Either one makes sense, assuming the PIRQ routing code knows what link > > means. Here we see two BIOS vendors/versions that apparently do it > > differently for the same chipset.Grrr. > > They _may_ do the same thing for the same chipset, it's just that we don't > know exactly what that "same" thing is. > > Ok, I want to see what people have. ANYBODY who has a SiS chipset, please > take 5 seconds to do this as root (yes, you need to be root): > > dump_pirq | mail -s "dump_pirq" [EMAIL PROTECTED] -- Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED] GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736 PGP signature
Re: Linux 2.4.[01] and BogoMips
hmmm, *remembers back to lwe* maybe linus would be able to say if there's been a change... i seem to recall he was surprised by this... =;] pete On Mon, 05 Feb 2001, Pat Verner wrote: > Has there been a change in the definition of "BogoMips"? -- Pete Toscano [EMAIL PROTECTED] 703.948.3364 GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736 PGP signature
Re: ip_tables/ipchains
I had a similar problem with this yesterday. Try moving your .config file to a safe place, making mrproper, then moving your .config back and rebuilding. I did this and all was well. HTH, pete On Wed, 20 Jun 2001, Ted Gervais wrote: > Wondering something.. > I ran insmod to bring up ip_tables.o and I received the following error: > > /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved > symbol nf_unregister_sockopt > /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved > symbol nf_register_sockopt > > This is with kernel 2.4.5 and Slackware 7.1 is the distribution. > Does anyone know what these unresolved symbols are about?? - 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/
USB printing == kernel lockup?
Hello, I'm still looking into this, but has anybody else seen this problem? When I do anything (print to it, query its ink levels with escputil, etc.) with my Epson 870 while it's hooked to my computer via USB, the whole machine locks hard. If I change the connection over to a printer cable on a parallel port connection, eveything works fine. USB printing used to work fine until recently. (I don't print much, so how recently, I don't know yet.) I'm in the process of trying other kernels (tested 2.4.5 and 2.4.6-pre[68]) and USB controllers (JE's UHCI vs the standard UHCI) but I'm not done yet. Has anyone else has seen this problem? I posted to the gimp-print and linux-usb lists, but there was nary a response. The printer is connected to the USB hub in my Nokia monitor, which also has a mouse connected to it and that's running fine. I'm using a Tyan Tiger 133 mother board (VIA Apollo Pro 133A chipset) and SMP-enabled kernel. Thanks, pete - 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: Hi all, a strange full lock in SMP-kernel 2.4.6 and 2.4.5
I think I've seen this same problem, at least with regards to USB printing. Yesterday, I traced the problem down to a patch to usb-uhci.c in the transition from 2.4.3 to 2.4.4. The problem persists today. A work around for this problem is to use the alternate UHCI driver (uhci.o). What motherboard and chipset are you using. I use the Tyan Tiger 133 motherboard with the VIA Apollo Pro 133a chipset. Someone else who I heard from uses another VIA-based chipset (I think, he never replied to my question). Maybe this is a VIA-related problem, like the APIC problem is. (Do you use "noapic" when you boot? He and I both have SMP systems too) I posted something on the linux-usb list yesterday about this problem and with all the info I was able to track down, but I have yet to see any response. I've taken this as far as I can by myself. I don't know enough about kernel programming or about USB to check the code in usb-uhci.c, but I'm more than happy to help by providing information and/or testing potential patches/fixes. pete On Sat, 07 Jul 2001, linuxx wrote: > Well Full lock in 2.4.5 and .6 when in a SMP intel p III 500mhz when i try to print >any file in a epson 760 usb and parport > printer. > I put in antecedents . With 2.4.3 and before the printer via usb or partport print >ok . In 2.4.5-6 when i try to send > anything to /dev/usb/lp0 like cat a.txt > /dev/usb/lp0 the system fail or if i do in >lpr same . I have no problem if i use parport whit the sames kernels .I have all >right configured. With the same computer in other distribution .Same kernel = same >lock .Of course the LPRng and gcc are > all compiled in this machine and work right for months , both stables versions.I put >the only trace y can get for the lock. > I hope help something for any other thing i not subscribed to kernel list so i like >to know any answer you can give. THANKS > > CPU:0 > EIP:0010:[] > EFLAGS: 0086 > eax: cd747600 ebx: cd1d42a0 ecx: 0001 edx: cd747600 > esi: cd1d41fc edi: ebp: 0004 esp: cd077f34 > ds: 0018 es: 0018 ss:0018 > Process cat (pid: 378, stackpage=cd077000) > Stack: 017a 0005 0206 cd1d41a0 cd8f >0004 d0837aac cd1d41fc d084e411 cd1d41fc cdec8c60 ffea > 0004 c013a1c6 cdec8c60 0804c860 0004 cdec8c80 0025 > > Call Trace: [<013a1c6>] [] > Code: 80 7b 24 00 f3 90 7e f8 e9 e0 d0 ff ff 80 bf 80 00 00 00 00 > console shuts up ... > > +++ killed by SIGSEGV +++ - 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: Hi all, a strange full lock in SMP-kernel 2.4.6 and 2.4.5
Just to follow up to myself, after futher testing, it looks like it's an SMP-related problem. I'm not yet sure if it's an SMP-Via chipset problem or just an SMP problem. I've heard from two people with this same problem. I think one of them has a Via chipset and I'm not sure about the other one. Can anybody look into this or give me a good brain dump on how I can fix it? Thanks, pete On Fri, 06 Jul 2001, Pete Toscano wrote: > I think I've seen this same problem, at least with regards to USB > printing. Yesterday, I traced the problem down to a patch to usb-uhci.c > in the transition from 2.4.3 to 2.4.4. The problem persists today. A > work around for this problem is to use the alternate UHCI driver > (uhci.o). > > What motherboard and chipset are you using. I use the Tyan Tiger 133 > motherboard with the VIA Apollo Pro 133a chipset. Someone else who I > heard from uses another VIA-based chipset (I think, he never replied to > my question). Maybe this is a VIA-related problem, like the APIC > problem is. (Do you use "noapic" when you boot? He and I both have SMP > systems too) > > I posted something on the linux-usb list yesterday about this problem > and with all the info I was able to track down, but I have yet to see > any response. I've taken this as far as I can by myself. I don't know > enough about kernel programming or about USB to check the code in > usb-uhci.c, but I'm more than happy to help by providing information > and/or testing potential patches/fixes. > > pete - 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/
