Re: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]
On Sat, Feb 19, 2005 at 08:36:12PM -0500, Steven Rostedt wrote: Linux version 2.6.10 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-8)) #13 SMP Sat Feb 19 20:12:19 EST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000d - 000d4000 (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 0f6f (usable) BIOS-e820: 0f6f - 0f70 (reserved) BIOS-e820: 0f70 - 3fef (usable) BIOS-e820: 3fef - 3fef8000 (ACPI data) BIOS-e820: 3fef8000 - 3fefa000 (ACPI NVS) BIOS-e820: 3ff0 - 4000 (reserved) Your BIOS is broken. You probably have 1GB of RAM which extends from 0x to 0x4000. However, there's a hole in the ACPI map between 0x3fefa000 and 0x3ff0. This is where your Cardbus devices are ending up: 3fefa000-3fefa3ff : :00:1f.1 3fefb000-3fefbfff : :02:01.0 3fefb000-3fefbfff : yenta_socket 3fefc000-3fefcfff : :02:01.1 3fefc000-3fefcfff : yenta_socket Changing the bridge type to non-transparent just means that we find we can't allocate the bridge resources in this small window, so they get moved elsewhere. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core - 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: Yenta TI: ... no PCI interrupts. Fish. Please report.
Have you tried it to get it to work without ACPI in the kernel at all, and start from there? Best regards, Norbert On Saturday 19 February 2005 22:54, you wrote: Hi everyone, I've been banging my head on this one a couple of days with no luck. I have a IBM Thinkpad G41 with a pentium4M with Hyperthreading. I can't get the PCMCIA working at all. I've tried turning off hyperthreading, I've tried with and without preempt, I've even added pci=noacpi. I've added Len's ACPI patches, but nothing works. Here's lspci -vvv: :00:00.0 Host bridge: Intel Corp. 82852/855GM Host Bridge (rev 02) Subsystem: IBM: Unknown device 0579 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- Latency: 0 Region 0: Memory at d000 (32-bit, prefetchable) [size=256M] Capabilities: available only to root :00:00.1 System peripheral: Intel Corp. 855GM/GME GMCH Memory I/O Control Registers (rev 02) Subsystem: IBM: Unknown device 057a Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 :00:00.3 System peripheral: Intel Corp. 855GM/GME GMCH Configuration Process Registers (rev 02) Subsystem: IBM: Unknown device 057b Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 :00:01.0 PCI bridge: Intel Corp. 855GME GMCH Host-to-AGP Bridge (Virtual PCI-to-PCI) (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 96 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: f000-0fff Memory behind bridge: c100-c1ff Prefetchable memory behind bridge: e000-efff BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- Reset- FastB2B- [ ... USB controllers snipped out ... ] :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 81) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR+ Latency: 0 Bus: primary=00, secondary=02, subordinate=08, sec-latency=168 I/O behind bridge: 3000-6fff Memory behind bridge: c200-cfff Prefetchable memory behind bridge: f000-f7ff BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- Reset- FastB2B- :00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 01) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 [ ... snipped out IDE Bridge controllers too ... ] :00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) Subsystem: IBM: Unknown device 0547 Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Interrupt: pin B routed to IRQ 11 Region 4: I/O ports at 1880 [size=32] [ ... snipped audio VGA NVidia and Ethernet controllers ... ] :02:01.0 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01) Subsystem: IBM ThinkPad T30/T40 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 168, Cache Line Size: 0x20 (128 bytes) Interrupt: pin A routed to IRQ 177 Region 0: Memory at 3fefb000 (32-bit, non-prefetchable) [size=4K] Bus: primary=02, secondary=03, subordinate=06, sec-latency=176 Memory window 0: 4000-403ff000 (prefetchable) Memory window 1: 4040-407ff000 I/O window 0: 4000-40ff I/O window 1: 4400-44ff BridgeCtl: Parity- SERR- ISA- VGA- MAbort- Reset+ 16bInt+ PostWrite+ 16-bit legacy interface ports at 0001 :02:01.1 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01) Subsystem: IBM ThinkPad T30/T40 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 168, Cache Line Size:
Re: [ACPI] Re: Call for help: list of machines with working S3
Hello! On Fri 18 Feb 2005 21:49, Alistair John Strachan wrote: I discovered that either the i2c_core.ko or i2c_i801.ko modules cause the hang on resume! If you stop the entire i2c subsystem from being loaded by hotplug (note this is the BUS driver, not the sensors driver!), then resume works perfectly! Presumably there's a bug in the resuming of this module. Well, on my IBM ThinkPad T42p (ATI FireGL T2 128MB), I can resume with both I2C modules loaded, so probably the problem is not specific to the I2C subsystem. In other news, USB devices only work after I remove uhci_hcd and ehci_hcd and reload them. I just tested two USB devices after S3 resuming without having removed the USB modules (uhci-hcb and ehci-hcd): - Logitech USB Wheel Mouse (046d:c00c, USB 1.x), it works with no problem on console, but not on X (this was caused by the fact that I've two corepointer on my XF86Config-4, in fact after having corrected this error and restarted X, the USB mouse works) - Mitsubishi Chemical 2.5 HD Case (05e3:0702, USB 2.0 [1], with a SAMSUNG MP0804H 80GB), it works with no problem :-D The s3_bios workaround allows video to kind of work, but I can't use anything other than vga=normal (vesafb results in corruption), and the screen is no longer artificially resized to fill the LCD, it's native res and centered (which sure is annoying). Again, IMHO the problem is specific to your machine: I use the radeonfb (with acpi_sleep=s3_bios) and the resume is ok (both in console and Debian XFree86-4.3.0.dfsg.1-11, radeon driver). Thx, bye, Gismo / Luca [1] http://www.qbik.ch/usb/devices/showdescr.php?id=3039 pgpFAuFgB8Bft.pgp Description: PGP signature
Re: IBM Thinkpad G41 PCMCIA problems
Steven Rostedt wrote: I have a IBM Thinkpad G41 with a pentium4M with Hyperthreading. I can't get the PCMCIA working at all. I've tried turning off hyperthreading, I've tried with and without preempt, I've even added pci=noacpi. I've added Len's ACPI patches, but nothing works. I see the same problem with an IBM Thinkpad G40, and only when there is 1Gb of memory or more in the machine. The problem was reported the first time (to my knowledge), here: http://www.ussg.iu.edu/hypermail/linux/kernel/0306.3/0956.html by a Thinkpad T40 user. So the problem seems to affect at least three different Thinkpad models. The workaround I've seen so far have either been to disable pci_fixup_transparent_bridge (as mentioned in this thread) or to raise the value of pci_mem_start. Re, David lspci -vvv with pci_fixup_transparent bridge disabled: :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 81) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR+ Latency: 0 Bus: primary=00, secondary=02, subordinate=05, sec-latency=64 I/O behind bridge: 3000-6fff Memory behind bridge: d020-dfff Prefetchable memory behind bridge: f000-f7ff BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- Reset- FastB2B- - 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: IBM Thinkpad G41 PCMCIA problems
On Sun, Feb 20, 2005 at 10:22:09AM +0100, David Härdeman wrote: Steven Rostedt wrote: I have a IBM Thinkpad G41 with a pentium4M with Hyperthreading. I can't get the PCMCIA working at all. I've tried turning off hyperthreading, I've tried with and without preempt, I've even added pci=noacpi. I've added Len's ACPI patches, but nothing works. I see the same problem with an IBM Thinkpad G40, and only when there is 1Gb of memory or more in the machine. Check to see if your e820 map has a hole in it, and whether any of your Cardbus bridge memory / region 0 resources appear in it. If your e820 map contains a hole, I'd suspect another buggy bios. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core - 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: Bootsplash for 2.6.11-rc4
How many distros do use some variant of bootsplash? SuSE does, from above url I guess gentoo does, too... Does Red Hat do something similar? [Or do they just set log-level to very high giving them clean look?] What about Debian? Red Hat/Fedora uses quiet boot option, plus a userspace early graphic - 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: IBM Thinkpad G41 PCMCIA problems
On Sun, Feb 20, 2005 at 09:26:59AM +, Russell King wrote: On Sun, Feb 20, 2005 at 10:22:09AM +0100, David Härdeman wrote: I see the same problem with an IBM Thinkpad G40, and only when there is 1Gb of memory or more in the machine. Check to see if your e820 map has a hole in it, and whether any of your Cardbus bridge memory / region 0 resources appear in it. If your e820 map contains a hole, I'd suspect another buggy bios. e820 map: BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000ce000 - 000d (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 0f6f (usable) BIOS-e820: 0f6f - 0f70 (reserved) BIOS-e820: 0f70 - 3f6f (usable) BIOS-e820: 3f6f - 3f6f8000 (ACPI data) BIOS-e820: 3f6f8000 - 3f6fa000 (ACPI NVS) BIOS-e820: 3f70 - 4000 (reserved) BIOS-e820: ff80 - 0001 (reserved) 118MB HIGHMEM available. 896MB LOWMEM available. Is the hole between 0x36f6fa000 and 0x3f70? And what would be the proper way of fixing it (assuming that IBM won't issue a fixed BIOS)? Re, David - 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: IBM Thinkpad G41 PCMCIA problems
On Sun, Feb 20, 2005 at 10:52:12AM +0100, David Härdeman wrote: e820 map: BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000ce000 - 000d (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 0f6f (usable) BIOS-e820: 0f6f - 0f70 (reserved) BIOS-e820: 0f70 - 3f6f (usable) BIOS-e820: 3f6f - 3f6f8000 (ACPI data) BIOS-e820: 3f6f8000 - 3f6fa000 (ACPI NVS) BIOS-e820: 3f70 - 4000 (reserved) BIOS-e820: ff80 - 0001 (reserved) 118MB HIGHMEM available. 896MB LOWMEM available. Is the hole between 0x36f6fa000 and 0x3f70? Looks like it. And what would be the proper way of fixing it (assuming that IBM won't issue a fixed BIOS)? Try passing: reserve=0x3f6fa000,0x6000 to the kernel. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core - 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: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]
On Sun, Feb 20, 2005 at 08:22:26AM +, Russell King wrote: On Sat, Feb 19, 2005 at 08:36:12PM -0500, Steven Rostedt wrote: Linux version 2.6.10 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-8)) #13 SMP Sat Feb 19 20:12:19 EST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000d - 000d4000 (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 0f6f (usable) BIOS-e820: 0f6f - 0f70 (reserved) BIOS-e820: 0f70 - 3fef (usable) BIOS-e820: 3fef - 3fef8000 (ACPI data) BIOS-e820: 3fef8000 - 3fefa000 (ACPI NVS) BIOS-e820: 3ff0 - 4000 (reserved) Your BIOS is broken. You probably have 1GB of RAM which extends from 0x to 0x4000. However, there's a hole in the ACPI map between 0x3fefa000 and 0x3ff0. BTW, try passing: reserve=0x3fefa000,0x6000 to the kernel - this will mark the hole reserved and should reallocate the resources which are clashing with the RAM. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core - 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: IBM Thinkpad G41 PCMCIA problems
On Sun, Feb 20, 2005 at 10:52:12AM +0100, David Härdeman wrote: On Sun, Feb 20, 2005 at 09:26:59AM +, Russell King wrote: On Sun, Feb 20, 2005 at 10:22:09AM +0100, David Härdeman wrote: I see the same problem with an IBM Thinkpad G40, and only when there is 1Gb of memory or more in the machine. Check to see if your e820 map has a hole in it, and whether any of your Cardbus bridge memory / region 0 resources appear in it. If your e820 map contains a hole, I'd suspect another buggy bios. e820 map: BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000ce000 - 000d (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 0f6f (usable) BIOS-e820: 0f6f - 0f70 (reserved) BIOS-e820: 0f70 - 3f6f (usable) BIOS-e820: 3f6f - 3f6f8000 (ACPI data) BIOS-e820: 3f6f8000 - 3f6fa000 (ACPI NVS) BIOS-e820: 3f70 - 4000 (reserved) BIOS-e820: ff80 - 0001 (reserved) 118MB HIGHMEM available. 896MB LOWMEM available. Is the hole between 0x36f6fa000 and 0x3f70? And what would be the proper way of fixing it (assuming that IBM won't issue a fixed BIOS)? passing reserve=0x3f6fa000,0x600 as kernel boot option. Please also post /proc/iomem for further debugging, especially if this didn't help. Dominik - 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: IBM Thinkpad G41 PCMCIA problems
On Sun, Feb 20, 2005 at 11:20:59AM +0100, Dominik Brodowski wrote: Is the hole between 0x36f6fa000 and 0x3f70? And what would be the proper way of fixing it (assuming that IBM won't issue a fixed BIOS)? passing reserve=0x3f6fa000,0x600 as kernel boot option. Please also post /proc/iomem for further debugging, especially if this didn't help. You're missing a zero in the length. 8) -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core - 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: [darcs-users] Re: [BK] upgrade will be needed
Hi, David Roundy, creator of darcs, wrote: On Sat, Feb 19, 2005 at 05:42:13PM +0100, Andrea Arcangeli wrote: I read in the webpage of the darcs kernel repository that they had to add RAM serveral times to avoid running out of memory. They needed more than 1G IIRC, and that was enough for me to lose interest into it. You're right I blamed the functional approach and so I felt it was going to be a mess to fix the ram utilization, but as someone else pointed out, perhaps it's darcs to blame and not haskell. I don't know. Darcs' RAM use has indeed already improved somewhat... I'm not exactly sure how much. I'm not quite sure how to measure peak virtual memory usage, and most of the time darcs' memory use while doing the linux kernel conversion is under a couple of hundred megabytes. Wouldn't calling sbrk(0) help? I don't know if the Haskell run-time ever shrinks the data segment, if not, it could just be called at the end. Or a `strace -e trace=brk darcs ...' might do. But I guess darcs has other VM usage that doesn't show in this figure? Does /proc/$$/maps if running under Linux help? A consistent way to measure would be handy for observing changes over time. Cheers, Ralph. - 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/
[SOLVED] Linux 2.6.10-rc3-bk15 hanged under high load (i386)
Hi: This is more an attempt to get this indexed by web search engines than a request for help, although maybe someone can draw some conclusion from the following and be of some use to anyone. Although the subject refers to some specific kernel version, what is reported in the mail is also valid for (at least) any kernel version up to 2.6.11-rc3. Back in the beginning of January I sent a (desperate) email to the list reporting frequenet lockups with (then) recent 2.6.x kernel versions. The Message-ID of the original post is [EMAIL PROTECTED], and the subject Linux 2.6.10-rc3-bk15 hanged under high load (i386). Well, I heve suffering from the same problem since then, but soon I realized some kind of pattern: I was only getting one (and only one) kernel hang each day. I power on the PC, start downloading tons of mail (mostly spam), at some point spamassassin gets killed and the logs get full of very nasty messages as the ones reported back in January ( Unable to handle kernel paging request and stack dumps). Finally the box freezes. After the above I reboot the box (a simple RESET, not a power OFF / power ON cycle), start downloading mail again...and no more paging request failures, stack dumps, process killed, or hung boxes, _never_. So it seemed like the hardware is flawed and somehow needed to be rebooted once to be put in a stable configuration. From the day I realized the pattern I booted the PC, then inmediately did a reboot, and then started using the box as usual: no more error or problems of any kind since then. It's been two weeks since then, and no problems. Maybe it was just a coincidence, so today I booted the box and started using it without an initializing reboot like the previous two weeks. And some minutes after started downloading mail the box freezed hard with the messages inlined to the end of this email. So it seems clear to me that something is very broken in the hardware, but somehow it gets fixed after a reboot. I have no knowledge to investigate this further, but at least someone with the same problem will search through Google and hopefully find this message. Greetings. Feb 20 11:16:30 dardhal kernel: Unable to handle kernel paging request at virtual address 0016a51c Feb 20 11:16:30 dardhal kernel: printing eip: Feb 20 11:16:30 dardhal kernel: c01320b7 Feb 20 11:16:30 dardhal kernel: *pde = Feb 20 11:16:30 dardhal kernel: Oops: 0002 [#1] Feb 20 11:16:30 dardhal kernel: Modules linked in: sch_htb cls_u32 sch_ingress ipt_LOG ipt_limit ipt_state iptable_filter ipt_MASQUERADE iptable_nat ip_conntrack ip_tables ppp_deflate bsd_comp ppp_async crc_ccitt ppp_generic slhc deflate zlib_deflate zlib_inflate twofish serpent aes_i586 blowfish des sha256 sha1 crypto_null af_key md5 ipv6 snd_via82xx uhci_hcd usbcore i2c_viapro tuner tvaudio bttv video_buf v4l2_common btcx_risc tveeprom videodev snd_ymfpci snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_opl3_lib snd_timer snd_hwdep snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore skystar2 dvb_core mt352 stv0299 nxt2002 firmware_class mt312 8139too 8139cp mii via_agp agpgart reiserfs xfs exportfs dm_mod it87 i2c_sensor i2c_isa rtc Feb 20 11:16:30 dardhal kernel: CPU:0 Feb 20 11:16:30 dardhal kernel: EIP:0060:[c01320b7]Not tainted VLI Feb 20 11:16:30 dardhal kernel: EFLAGS: 00010006 (2.6.11-rc3) Feb 20 11:16:30 dardhal kernel: EIP is at buffered_rmqueue+0x57/0x1a0 Feb 20 11:16:30 dardhal kernel: eax: c10ef5f8 ebx: c0309224 ecx: c0309250 edx: 0016a518 Feb 20 11:16:30 dardhal kernel: esi: 0246 edi: c0309240 ebp: c0309224 esp: c0b69df4 Feb 20 11:16:30 dardhal kernel: ds: 007b es: 007b ss: 0068 Feb 20 11:16:30 dardhal kernel: Process spamassassin (pid: 5554, threadinfo=c0b68000 task=cdd065d0) Feb 20 11:16:30 dardhal kernel: Stack: c77ae000 0010 c0309250 c10ef5e0 c0309224 cd5a07dc Feb 20 11:16:30 dardhal kernel: ce900b1c c01326c3 c0309224 80d2 0001 Feb 20 11:16:30 dardhal kernel: 0001 cdd065d0 0010 c030948c 80d2 c0b69e74 Feb 20 11:16:30 dardhal kernel: Call Trace: Feb 20 11:16:30 dardhal kernel: [c01326c3] __alloc_pages+0x423/0x450 Feb 20 11:16:30 dardhal kernel: [c013c3e1] do_anonymous_page+0x71/0x130 Feb 20 11:16:30 dardhal kernel: [c013c503] do_no_page+0x63/0x2b0 Feb 20 11:16:30 dardhal kernel: [c013c92e] handle_mm_fault+0xde/0x150 Feb 20 11:16:30 dardhal kernel: [c010fd8c] do_page_fault+0x18c/0x599 Feb 20 11:16:30 dardhal kernel: [c0218516] i8042_interrupt+0x116/0x2f0 Feb 20 11:16:30 dardhal kernel: [c013ef2f] unmap_vma_list+0x1f/0x30 Feb 20 11:16:30 dardhal kernel: [c012caa0] handle_IRQ_event+0x30/0x70 Feb 20 11:16:30 dardhal kernel: [c012cb31] __do_IRQ+0x51/0xe0 Feb 20 11:16:30 dardhal kernel: [c010fc00] do_page_fault+0x0/0x599 Feb 20 11:16:30 dardhal kernel: [c0102f57] error_code+0x2b/0x30 Feb 20 11:16:30 dardhal kernel: Code: 01 d0 8d 5c c5 00 8d 7b 1c 9c 5e fa
Re: updated list of unused kernel exports posted
On Sat, 2005-02-19 at 22:14 +0100, Arjan van de Ven wrote: +wait_for_completion_interruptible +wait_for_completion_interruptible_timeout +wait_for_completion_timeout These are emerging functionality type. There are some patches in the pipeline, which make use of this and waited for inclusion of those functions into mainline. I will rework/rediff them after 2.6.11 is released. tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/net/smc-mca.c: cleanups
Arjan van de Ven [EMAIL PROTECTED] wrote:
I've used this technique in a few very
small programs to reduce their size (I could strip off both their bss and
data sections to save space). Also, I believe that the compiler is able
to optimize code using consts, but this is pure speculation, I've not
verified it.
Afaik that's the main difference between C and C++; in C you can still
change const variables... in C++ thats illegal (at least that's what I
remember and google seems to support somewhat ;)
The compiler does use the const modifier on a static object to optimise
code. Try compiling this program:
const int x;
int bar(int);
int foo(void)
{
bar(x);
return bar(x);
}
With the const gcc (3.3.4) will only load x once while it'll reload
it after calling bar if you remove the const modifier.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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/
Needed faster implementation of do_gettimeofday()
Hello all, I am running oprofile on some program. Following is the oprofile output. --- Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 10 samples %app name symbol name 9859138.6083 vmlinux mark_offset_tsc 5844735.1032 libc-2.3.2.sogetc 2959012.5836 vmlinux ide_outb 2708232.3646 vmlinux _spin_lock 2497912.1810 vmlinux _spin_unlock 2361402.0618 vmlinux timer_interrupt 1752491.5302 ld-2.3.2.so do_lookup_versioned 1404291.2261 sendmail putc 1387391.2114 sendmail stabhash 1341451.1713 sendmail getc --- From this output what I can analyse is that mark_offset_tsc(which is called from do_gettimeofday), and some other timer functions, are taking most of the CPU. Is there any faster implementation of do_gettimeofday. I am using kernel 2.6.10. with dual P4. What I found from google search is: http://lwn.net/Articles/9266/ , which is only for kernel 2.4 Thanks for help. -Puneet - 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: [SOLVED] Linux 2.6.10-rc3-bk15 hanged under high load (i386)
I have the same broken box here: Graphics freezes, sometime the whole box: It needs to warm up. Once warmed up, it will keep running stable forever (-: (Ok, the forever claim can not be verified). On Sunday 20 February 2005 11:39, Jose Luis Domingo Lopez wrote: Hi: This is more an attempt to get this indexed by web search engines than a request for help, although maybe someone can draw some conclusion from the following and be of some use to anyone. Although the subject refers to some specific kernel version, what is reported in the mail is also valid for (at least) any kernel version up to 2.6.11-rc3. Back in the beginning of January I sent a (desperate) email to the list reporting frequenet lockups with (then) recent 2.6.x kernel versions. The Message-ID of the original post is [EMAIL PROTECTED], and the subject Linux 2.6.10-rc3-bk15 hanged under high load (i386). Well, I heve suffering from the same problem since then, but soon I realized some kind of pattern: I was only getting one (and only one) kernel hang each day. I power on the PC, start downloading tons of mail (mostly spam), at some point spamassassin gets killed and the logs get full of very nasty messages as the ones reported back in January ( Unable to handle kernel paging request and stack dumps). Finally the box freezes. After the above I reboot the box (a simple RESET, not a power OFF / power ON cycle), start downloading mail again...and no more paging request failures, stack dumps, process killed, or hung boxes, _never_. So it seemed like the hardware is flawed and somehow needed to be rebooted once to be put in a stable configuration. From the day I realized the pattern I booted the PC, then inmediately did a reboot, and then started using the box as usual: no more error or problems of any kind since then. It's been two weeks since then, and no problems. Maybe it was just a coincidence, so today I booted the box and started using it without an initializing reboot like the previous two weeks. And some minutes after started downloading mail the box freezed hard with the messages inlined to the end of this email. So it seems clear to me that something is very broken in the hardware, but somehow it gets fixed after a reboot. I have no knowledge to investigate this further, but at least someone with the same problem will search through Google and hopefully find this message. Greetings. Feb 20 11:16:30 dardhal kernel: Unable to handle kernel paging request at virtual address 0016a51c Feb 20 11:16:30 dardhal kernel: printing eip: Feb 20 11:16:30 dardhal kernel: c01320b7 Feb 20 11:16:30 dardhal kernel: *pde = Feb 20 11:16:30 dardhal kernel: Oops: 0002 [#1] Feb 20 11:16:30 dardhal kernel: Modules linked in: sch_htb cls_u32 sch_ingress ipt_LOG ipt_limit ipt_state iptable_filter ipt_MASQUERADE iptable_nat ip_conntrack ip_tables ppp_deflate bsd_comp ppp_async crc_ccitt ppp_generic slhc deflate zlib_deflate zlib_inflate twofish serpent aes_i586 blowfish des sha256 sha1 crypto_null af_key md5 ipv6 snd_via82xx uhci_hcd usbcore i2c_viapro tuner tvaudio bttv video_buf v4l2_common btcx_risc tveeprom videodev snd_ymfpci snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_opl3_lib snd_timer snd_hwdep snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore skystar2 dvb_core mt352 stv0299 nxt2002 firmware_class mt312 8139too 8139cp mii via_agp agpgart reiserfs xfs exportfs dm_mod it87 i2c_sensor i2c_isa rtc Feb 20 11:16:30 dardhal kernel: CPU:0 Feb 20 11:16:30 dardhal kernel: EIP:0060:[c01320b7]Not tainted VLI Feb 20 11:16:30 dardhal kernel: EFLAGS: 00010006 (2.6.11-rc3) Feb 20 11:16:30 dardhal kernel: EIP is at buffered_rmqueue+0x57/0x1a0 Feb 20 11:16:30 dardhal kernel: eax: c10ef5f8 ebx: c0309224 ecx: c0309250 edx: 0016a518 Feb 20 11:16:30 dardhal kernel: esi: 0246 edi: c0309240 ebp: c0309224 esp: c0b69df4 Feb 20 11:16:30 dardhal kernel: ds: 007b es: 007b ss: 0068 Feb 20 11:16:30 dardhal kernel: Process spamassassin (pid: 5554, threadinfo=c0b68000 task=cdd065d0) Feb 20 11:16:30 dardhal kernel: Stack: c77ae000 0010 c0309250 c10ef5e0 c0309224 cd5a07dc Feb 20 11:16:30 dardhal kernel: ce900b1c c01326c3 c0309224 80d2 0001 Feb 20 11:16:30 dardhal kernel: 0001 cdd065d0 0010 c030948c 80d2 c0b69e74 Feb 20 11:16:30 dardhal kernel: Call Trace: Feb 20 11:16:30 dardhal kernel: [c01326c3] __alloc_pages+0x423/0x450 Feb 20 11:16:30 dardhal kernel: [c013c3e1] do_anonymous_page+0x71/0x130 Feb 20 11:16:30 dardhal kernel: [c013c503] do_no_page+0x63/0x2b0 Feb 20 11:16:30 dardhal kernel: [c013c92e] handle_mm_fault+0xde/0x150 Feb 20 11:16:30 dardhal kernel: [c010fd8c] do_page_fault+0x18c/0x599 Feb 20 11:16:30 dardhal kernel: [c0218516] i8042_interrupt+0x116/0x2f0 Feb 20 11:16:30 dardhal kernel: [c013ef2f] unmap_vma_list+0x1f/0x30 Feb 20 11:16:30
Re: IBM Thinkpad G41 PCMCIA problems
On Sun, Feb 20, 2005 at 10:19:02AM +, Russell King wrote: On Sun, Feb 20, 2005 at 10:52:12AM +0100, David Härdeman wrote: Is the hole between 0x36f6fa000 and 0x3f70? Looks like it. And what would be the proper way of fixing it (assuming that IBM won't issue a fixed BIOS)? Try passing: reserve=0x3f6fa000,0x6000 to the kernel. Thanks a bunch, that worked, now I don't have to patch my kernel to get PCMCIA working anymore :-) //David - 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/
Why does printk helps PCMCIA card to initialise?
Hi,
After updating to a new kernel (2.6.8) my PCMCIA ISDN did not work
anymore.
My test system now looks like this:
uname -s -r -v -m
Linux 2.6.11-rc4 #5 Sun Feb 20 05:19:02 CET 2005 x86_64
lspci | grep CardBus
:02:07.0 CardBus bridge: Texas Instruments PCI4510 PC card Cardbus
Controller (rev 02)
cardctl info
cardctl info
PRODID_1=SEDLBAUER
PRODID_2=ISDN-Adapter
PRODID_3= (c) 93-96 VKCB
PRODID_4=26.01.96
MANFID=,
FUNCID=6
The initialisation of my ISDN always failed with the following error
messages:
...
kernel: HiSax: LinkLayer Revision 2.59.2.4
kernel: cs: pcmcia_socket0: read_cis_mem(1, 0x3f, 5)
kernel: cs: pcmcia_socket0: 0x01 0x07 0x00 0x02 ...
kernel: cs: pcmcia_socket0: read_cis_mem(1, 0x46, 13)
kernel: cs: pcmcia_socket0: 0xc1 0x81 0x19 0x01 ...
kernel: cs: pcmcia_socket0: odd IO request: base 0x260 align 0x8
kernel: cs: pcmcia_socket0: read_cis_mem(1, 0x55, 7)
kernel: cs: pcmcia_socket0: 0x02 0x08 0xaa 0x60 ...
kernel: cs: pcmcia_socket0: odd IO request: base 0x270 align 0x8
kernel: cs: pcmcia_socket0: read_cis_mem(1, 0x5e, 7)
kernel: cs: pcmcia_socket0: 0x03 0x08 0xaa 0x60 ...
kernel: cs: pcmcia_socket0: odd IO request: base 0x280 align 0x8
kernel: cs: pcmcia_socket0: read_cis_mem(1, 0x67, 7)
kernel: cs: pcmcia_socket0: 0x04 0x08 0xaa 0x60 ...
kernel: cs: pcmcia_socket0: odd IO request: base 0x2e8 align 0x8
kernel: cs: pcmcia_socket0: read_cis_mem(1, 0x70, 7)
kernel: cs: pcmcia_socket0: 0x05 0x08 0xaa 0x60 ...
kernel: cs: pcmcia_socket0: odd IO request: base 0x2f8 align 0x8
kernel: cs: pcmcia_socket0: read_cis_mem(1, 0x79, 7)
kernel: cs: pcmcia_socket0: 0x06 0x08 0xaa 0x60 ...
kernel: cs: pcmcia_socket0: odd IO request: base 0x350 align 0x8
kernel: cs: pcmcia_socket0: read_cis_mem(1, 0x82, 7)
kernel: cs: pcmcia_socket0: 0x07 0x08 0xaa 0x60 ...
kernel: cs: pcmcia_socket0: odd IO request: base 0x3e8 align 0x8
kernel: 0.0: GetNextTuple: No more items
...
So obviously, the kernel fails to allocate an io port window for the
PCMCIA adapter, and complains about a bad request for such a window.
However, if interprete these values as a request of an 8bit large IO
Window starting at base, I don't know what's so odd about it. Maybe,
this interpretation is wrong? Furthermore, /proc/ioports tells me that
the requested IO addresses are NOT used.
Well, I browsed the sources and added simple debug messages to the code
in order to find out, what function exactly returns an error and stops
the initialisation of my card. This debug led me to the function
nonstatic_find_io_region in drivers/pcmcia/rsrc_nonstatic.c that is
used by yenta_socket. To my very surprise, the ISDN card suppenly worked
after I added a printk that never executes. The file rsrc_nonstatic.c
then changed like this:
diff -u -U 7 /linux-2.6.11-rc4.changed/drivers/pcmcia/rsrc_nonstatic.c
../linux-2.6.11-rc4/drivers/pcmcia/rsrc_nonstatic.c
--- /linux-2.6.11-rc4.changed/drivers/pcmcia/rsrc_nonstatic.c
2005-02-20 11:37:39.0 +0100
+++ ../linux-2.6.11-rc4/drivers/pcmcia/rsrc_nonstatic.c 2005-02-20
02:16:48.0 +0100
@@ -623,15 +623,14 @@
down(rsrc_sem);
#ifdef CONFIG_PCI
if (s-cb_dev) {
ret = pci_bus_alloc_resource(s-cb_dev-bus, res, num, 1,
min, 0, pcmcia_align, data);
} else
#endif
-printk(This line will never be printed, but it helps!!!);
ret = allocate_resource(ioport_resource, res, num, min,
~0UL,
1, pcmcia_align, data);
up(rsrc_sem);
if (ret != 0) {
kfree(res);
res = NULL;
Then sedlbauer_cs initialises with following debug messages:
...
kernel: HiSax: LinkLayer Revision 2.59.2.4
kernel: cs: pcmcia_socket0: read_cis_mem(1, 0x3f, 5)
kernel: cs: pcmcia_socket0: 0x01 0x07 0x00 0x02 ...
kernel: cs: pcmcia_socket0: read_cis_mem(1, 0x46, 13)
kernel: cs: pcmcia_socket0: 0xc1 0x81 0x19 0x01 ...
kernel: cs: pcmcia_socket0: odd IO request: base 0x260 align 0x8
kernel: cs: pcmcia_socket0: write_cis_mem(1, 0x100, 1)
kernel: cs: pcmcia_socket0: write_cis_mem(1, 0x101, 1)
kernel: sedlbauer: index 0x01: Vcc 5.0, irq 18, io 0x0260-0x0267
kernel: HiSax: Card 1 Protocol EDSS1 Id=HiSax (0)
kernel: HiSax: Sedlbauer driver Rev. 1.34.2.6
kernel: Sedlbauer: defined at 0x260-0x268 IRQ 18
kernel: Sedlbauer: testing IPAC version 0
kernel: Sedlbauer: speed star detected
...
So the io request stay odd, but now it works. If printk is not there,
allocate_resource returns with error code EBUSY. I do not understand
that at all. Maybe my printk irritates the semaphore that is set around
the allocate_resource? However, then my solution won't be very safe,
although my card works perfectly now. I have only a very basic
understanding of those kernel functions, and wonder if someone can tell
me, what this is all about.
Thanks,
Martin Drohmann
-
To unsubscribe from this list: send the line unsubscribe
[patch ide] fix ide_get_error_location() for LBA28
Higher bits (16-23) of the address were ignored
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
diff -Nru a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
--- a/drivers/ide/ide-io.c 2005-02-19 17:38:53 +01:00
+++ b/drivers/ide/ide-io.c 2005-02-19 17:38:53 +01:00
@@ -238,9 +238,10 @@
high = ide_read_24(drive);
} else {
u8 cur = HWIF(drive)-INB(IDE_SELECT_REG);
- if (cur 0x40)
+ if (cur 0x40) {
+ high = cur 0xf;
low = (hcyl 16) | (lcyl 8) | sect;
- else {
+ } else {
low = hcyl * drive-head * drive-sect;
low += lcyl * drive-sect;
low += sect - 1;
-
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: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]
On Sat, 2005-02-19 at 22:51 -0800, Linus Torvalds wrote: Does a patch like this (instead of your version) work for you? It removes the Intel quirk entirely, and replaces it with the if there's no resource, use the parent resource as the default fallback code. Hi Linus, I live on the East coast so it's later for me than for you, so sorry about not responding earlier. I have to go to my daughter's gymnastics meet today so I probably won't get to try any of this till tomorrow. Thanks, -- Steve - 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: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]
On Sun, 2005-02-20 at 08:22 +, Russell King wrote: Your BIOS is broken. You probably have 1GB of RAM which extends from 0x to 0x4000. Just to leave no doubt. Yes, I have a Gig of RAM. -- Steve - 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: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]
On Sun, 2005-02-20 at 10:20 +, Russell King wrote: BTW, try passing: reserve=0x3fefa000,0x6000 to the kernel - this will mark the hole reserved and should reallocate the resources which are clashing with the RAM. I just tried this on 2.6.9 (with no patches) and it worked. So I think Russ is right. I guess the problem arises when you have an IBM G41 Thinkpad with a Gig of RAM. Linus, How much RAM is on your machine? -- Steve - 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: Why does printk helps PCMCIA card to initialise?
Hello
On Sunday 20 February 2005 11:44 am, you wrote:
diff -u -U 7 /linux-2.6.11-rc4.changed/drivers/pcmcia/rsrc_nonstatic.c
../linux-2.6.11-rc4/drivers/pcmcia/rsrc_nonstatic.c
--- /linux-2.6.11-rc4.changed/drivers/pcmcia/rsrc_nonstatic.c
2005-02-20 11:37:39.0 +0100
+++ ../linux-2.6.11-rc4/drivers/pcmcia/rsrc_nonstatic.c 2005-02-20
02:16:48.0 +0100
@@ -623,15 +623,14 @@
down(rsrc_sem);
#ifdef CONFIG_PCI
if (s-cb_dev) {
ret = pci_bus_alloc_resource(s-cb_dev-bus, res, num, 1,
min, 0, pcmcia_align, data);
} else
#endif
-printk(This line will never be printed, but it helps!!!);
ret = allocate_resource(ioport_resource, res, num, min,
What you're doing is forcing the execution of allocate_resource (ioport... );
Cause adding the printk you're adding it's changing this:
else
ret = allocate_resource(...);
up(...);
by this:
else
printk(...);
/*This is not executing inside the else clause no more,
*so doesn't matter if s-cb_dev it's true or not, you're going with this*/
ret = allocate_resource(...);
up(...);
You're changing the block inside the else clause.
It's not about upsetting the sem afaik.
I could be wrong though, and that'll be a terrible tragedy.
Of course this is as long as CONFIG_PCI it's evaluating true, is it?
Vicente.
-
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: [PATCH 2/2] page table iterators
Andi Kleen wrote: On Thu, Feb 17, 2005 at 03:30:31PM -0800, David S. Miller wrote: On Fri, 18 Feb 2005 00:03:42 +0100 Andi Kleen [EMAIL PROTECTED] wrote: And to be honest we only have about 6 or 7 of these walkers in the whole kernel. And 90% of them are in memory.c While doing 4level I think I changed all of them around several times and it wasn't that big an issue. So it's not that we have a big pressing problem here... It's super error prone. A regression added by your edit of these Actually it was in Nick's code (PUD layer ;-). But I won't argue that my code didn't have bugs too... I won't look back to see where the error came from :) But yeah it is equally (if not more) likely to have come from me. And it probably did happen because all the code is slightly different and hard to understand. walkers for the 4level changes was only discovered and fixed yesterday by the ppc folks. I absolutely support any change which consolidates these things. The problem is just that these walker macros when they do all the lazy walking stuff will be quite complicated. And I don't really want another uaccess.h-like macro mess. Yes currently they look simple, but that will change. But even in that case, it will still be better to have the extra complexity once in the macro rather than throughout mm/ Open coding is probably the smaller evil. And they're really not changed that often. It is not so much a matter of changing, so much as having 10 slightly different implementations. I think it should be easier to go from the iterators patch to perhaps more complex iterators, or some open coding, etc etc. rather than try to put a big complex pt walker on top of these 10 different open coded implementations. But perhaps I'm missing something you're not - I'd need to see the lazy walking code I guess. Nick - 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: Why does printk helps PCMCIA card to initialise?
On Sun, Feb 20, 2005 at 12:44:25PM +0100, Martin Drohmann wrote:
#ifdef CONFIG_PCI
if (s-cb_dev) {
ret = pci_bus_alloc_resource(s-cb_dev-bus, res, num, 1,
min, 0, pcmcia_align, data);
} else
#endif
-printk(This line will never be printed, but it helps!!!);
If you added this, you've done much more than just adding it. Look
two lines above and realise that you've just changed what the else
clause conditionalises.
ret = allocate_resource(ioport_resource, res, num, min,
~0UL,
1, pcmcia_align, data);
So, with your printk in place, we try pci_bus_alloc_resource. If that
succeeds or fails, we completely stomp on that with allocate_resource.
Bad. Very bad.
The first thing that needs solving is why you're getting the odd IO
request crap. That may explain why the resource can't be allocated.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
-
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: Bootsplash for 2.6.11-rc4
On Sat, Feb 19, 2005 at 03:03:26PM -0800, Greg KH wrote: Pavel, I agree with Michal, take a look at this version of the code instead of the version that you posted. It's a _whole_ lot more sane, and possibly even mergable. Michal, any thoughts on submitting it for inclusion? It seems pretty stable now. It is pretty stable indeed, I haven't had any major bug reports for quite some time now. It's probably as ready as it's ever going to be. So the question is: what should I do with it? Who do I send it to? Also, if anyone has comments about the code, bug reports, etc. - feel free to contact me. If there are any issues remaining, I'd like to fix them ASAP. Live long and prosper. -- Michal 'Spock' JanuszewskiGentoo Linux Developer cell: +48504917690 http://dev.gentoo.org/~spock/ JID: [EMAIL PROTECTED] freenode: #gentoo-dev, #gentoo-pl pgpK8g0ADzaui.pgp Description: PGP signature
Re: Bootsplash for 2.6.11-rc4
On Sun, Feb 20, 2005 at 12:25:19AM +0100, Pavel Machek wrote: Hi, Yes, I agree, almost anything is more sane than code I posted :-(. My only requirement is that it works with radeonfb and similar low-level drivers (so that I can get suspend-to-ram to work) and that it gets past our branding people... I don't know about the branding people, but suspend-to-ram and radeonfb shouldn't be a problem for fbsplash :) How many distros do use some variant of bootsplash? SuSE does, from above url I guess gentoo does, too... Does RedHat do something similar? [Or do they just set log-level to very high giving them clean look?] What about Debian? As far as I know: SuSE uses bootsplash, Gentoo and PLD use fbsplash, RedHat uses rhgb (100% userspace solution, based on xvesa, doesn't provide graphical backgrounds on vt's - for that a kernel patch like bootsplash or fbsplash is necessary). I don't know about Debian - they probably have some (possibly unofficial) support for both bootsplash and fbsplash. Live long and prosper. -- Michal 'Spock' JanuszewskiGentoo Linux Developer cell: +48504917690 http://dev.gentoo.org/~spock/ JID: [EMAIL PROTECTED] freenode: #gentoo-dev, #gentoo-pl pgpagHh0Xoksi.pgp Description: PGP signature
Kernel 2.4.29 (Sparc64) and iproute
Hello, I'm trying to use iproute (20041019) with 2.4.29 official kernel on a UltraSparc 1E. I have marked all packets that come from an intranet server (192.168.0.130:3000 / tcp) like this : Chain PREROUTING (policy ACCEPT 13344 packets, 1830K bytes) pkts bytes target prot opt in out source destination 89 5340 MARK tcp -- * * 192.168.0.130 0.0.0.0/0 tcp spts:3000:3001 MARK set 0x1 And I have logged the result of iptables. All packets are marked. So, I have written a new rule with iproute : Root kant:[/var/log] ip rule show 0: from all lookup local 100:from 192.168.1.1 lookup intranet 101:from all fwmark 0x1 lookup intranet 32766: from all lookup main 32767: from all lookup default Root kant:[/var/log] ip route show table intranet default via 192.168.1.254 dev eth2 Root kant:[/var/log] My intranet table is ignored. But I can use the second interface. If I replace from all fwmark 0x1 lookup intranet by from 192.168.0.130 lookup intranet, all packets coming from my intranet server all redirected conforming to intranet table. Any idea ? Is iproute broken with 2.4.29 ? Thanks in advance, JKB - 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/
[PATCH] Replaces (2 * HZ) with DATA_TIMEOUT in /drivers/usb/atm/speedtch.c
This Patch replaces (2 * HZ) with DATA_TIMEOUT which is defined as
#define DATA_TIMEOUT (2 * HZ)
in /drivers/usb/atm/speedtch.c in kernel 2.6.10.
Signed-off-by: Telemaque Ndizihiwe [EMAIL PROTECTED]
--- linux-2.6.10/drivers/usb/atm/speedtch.c.orig2005-02-20
12:44:22.235267848 +
+++ linux-2.6.10/drivers/usb/atm/speedtch.c 2005-02-20
12:50:52.205983288 +
@@ -494,7 +494,7 @@ static void speedtch_upload_firmware(str
/* URB 7 */
if (dl_512_first) { /* some modems need a read before writing the
firmware */
ret = usb_bulk_msg(usb_dev, usb_rcvbulkpipe(usb_dev,
SPEEDTCH_ENDPOINT_FIRMWARE),
- buffer, 0x200, actual_length, 2 * HZ);
+ buffer, 0x200, actual_length, DATA_TIMEOUT);
if (ret 0 ret != -ETIMEDOUT)
dbg(speedtch_upload_firmware: read BLOCK0 from modem
failed (%d)!,
ret);
-
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/
Intel Gigabit NIC (2.6.5 - 2.6.10) Bug(?) Found
What is this e-mail about? Something in the kernel changed regarding the Intel e1000 driver from 2.6.5 to 2.6.10. The change resulted in thousands of errors when the NIC is receiving data. For the past two weeks I have thought about this and tried everything I could think of, it had really been pestering me. Normally, I never really looked at my ifconfig eth0, eth1 etc because I looked at it a long time ago and noticed it was just fine, this was with earlier kernels. I guess I should check my NIC statistics more often. I have tried the following to figure out why I get so many dropped packets and errors on an interface: 1] New Intel [same model] NIC. 2] Different ports in the switch. 3] New cable. 4] Switched PCI slots for the Intel Gigabit Card. 5] Switched BIOS settings/parameters to exact settings as other, identical machine. None of these fixed the problem. There are two machines (same model) here with GigE nics, on one there are very few (1-3) if any errors on the nic ever. The test that I used that reproduces the problem the quickest is dd if=/dev/zero of=/nfsv3/udp/file.img where the dd is on another box sending to the box that gets the RX errors on the NIC. Generally, there would be about 100 errors every 10 seconds. There are two identical machines on the network here, both with this same Intel Gigabit NIC (82541GI/PI). So one machine is running 2.6.5, the other 2.6.10, I figured it had to something in the kernel that was causing this. Therefore I grabbed ethtool and installed it and did a basic query for network setting parameters, immediately I noticed a difference, which is shown below: * Box with no problems. # ethtool -a eth0 Pause parameters for eth0: Autonegotiate: on RX: on TX: on * Box with NIC that generates errors, dropped packets and overrun errors. # ethtool -a eth0 Pause parameters for eth0: Autonegotiate: on RX: off TX: off According to the manpage: -A change the pause parameters of the specified ethernet device. rx on|off Specify if RX pause is enabled. tx on|off Specify if TX pause is enabled. # ethtool -A eth0 rx on # ethtool -A eth0 tx on My machine now: # ethtool -a eth0 Pause parameters for eth0: Autonegotiate: on RX: on TX: on Then, I re-run the dd command mentioned earlier and let it run for about ten minutes, long and behold not a single dropped packet, overrun or frame error reported! RX packets:6157606 errors:0 dropped:0 overruns:0 frame:0 Previously, this is what I would get after only a minute of running that dd command (I also get the errors copying files etc, dd command just speeds things up): RX packets:6374096 errors:1419 dropped:1419 overruns:1419 frame:0 Afterwards, I no longer have any errors: To the Intel/Kernel guys: Question, these are identical machines for the most part, even the same nics are used in each box, why in 2.6.5 are the settings set differently than that in 2.6.10? I do not believe that it is a distribution specific error as I did not even have ethtool installed before I checked this nor do I see it any boot scripts? For now, I will just have it set the proper settings -A tx on and -A rx on but is there another way to do this or did it change in the kernel at some point? Further investigation reveals on my main machine with an onboard Intel/PRO 1000 built-in NIC which runs on the CSA bus (A-Bit IC7-G) the pause feature is also off; HOWEVER, (2.6GHZ w/HT) this machine does not exhibit any errors! RX packets:2471666 errors:0 dropped:0 overruns:0 frame:0 TX packets:56413066 errors:0 dropped:0 overruns:0 carrier:0 Is it a bug that it defaults to off in the newer kernel versions, as it causes MASSIVE errors on the RX side of the fence? Or should people who run gigabit interfaces on slower machines just add the ethool commands to their startup scripts to avoid the errors/etc? There may be some parallel between speed_OF_CPU and whether it can handle it with the pause option on or off. If anyone has any idea of what the pause option is about and why it changed from 2.6.5 to 2.6.10, I'd like to know! Thanks! - 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/
[BK PATCHES] ide-2.6 update
Hi,
Please do a
bk pull bk://bart.bkbits.net/ide-2.6
This will update the following files:
drivers/ide/Kconfig |2 +-
drivers/ide/ide-io.c |5 +++--
drivers/ide/ide.c|4
3 files changed, 8 insertions(+), 3 deletions(-)
through these ChangeSets:
[EMAIL PROTECTED] (05/02/20 1.2130)
[ide] Kconfig for VR1000 machine driver selection
Fix the use of CONFIG_MACH_VR1000, which was missing an
trailing zero from the configuration variable, so never
being shown if only the VR1000 was selected
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
[EMAIL PROTECTED] (05/02/20 1.2129)
[ide] small compile fix to ide.c with !CONFIG_PCI
Small patch to fix following warning with CONFIG_IDE !CONFIG_PCI:
CC drivers/ide/ide.o
drivers/ide/ide.c: In function 'ide_system_bus_speed':
drivers/ide/ide.c:338: warning: unused variable 'pci_default'
I decided to save some bytes by #ifdef:ing the struct in question.
CC:ing Hanna because she did the change (and just to say hi ;-).
Signed-off-by: Mika Kukkonen [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
[EMAIL PROTECTED](none) (05/02/19 1.2128)
[ide] fix ide_get_error_location() for LBA28
Higher bits (16-23) of the address were ignored.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
diff -Nru a/drivers/ide/Kconfig b/drivers/ide/Kconfig
--- a/drivers/ide/Kconfig 2005-02-20 15:08:56 +01:00
+++ b/drivers/ide/Kconfig 2005-02-20 15:08:56 +01:00
@@ -812,7 +812,7 @@
config BLK_DEV_IDE_BAST
tristate Simtec BAST / Thorcom VR1000 IDE support
- depends on ARM (ARCH_BAST || MACH_VR100)
+ depends on ARM (ARCH_BAST || MACH_VR1000)
help
Say Y here if you want to support the onboard IDE channels on the
Simtec BAST or the Thorcom VR1000
diff -Nru a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
--- a/drivers/ide/ide-io.c 2005-02-20 15:08:56 +01:00
+++ b/drivers/ide/ide-io.c 2005-02-20 15:08:56 +01:00
@@ -238,9 +238,10 @@
high = ide_read_24(drive);
} else {
u8 cur = HWIF(drive)-INB(IDE_SELECT_REG);
- if (cur 0x40)
+ if (cur 0x40) {
+ high = cur 0xf;
low = (hcyl 16) | (lcyl 8) | sect;
- else {
+ } else {
low = hcyl * drive-head * drive-sect;
low += lcyl * drive-sect;
low += sect - 1;
diff -Nru a/drivers/ide/ide.c b/drivers/ide/ide.c
--- a/drivers/ide/ide.c 2005-02-20 15:08:56 +01:00
+++ b/drivers/ide/ide.c 2005-02-20 15:08:56 +01:00
@@ -335,10 +335,14 @@
static int ide_system_bus_speed(void)
{
+#ifdef CONFIG_PCI
static struct pci_device_id pci_default[] = {
{ PCI_DEVICE(PCI_ANY_ID, PCI_ANY_ID) },
{ }
};
+#else
+#define pci_default 0
+#endif /* CONFIG_PCI */
if (!system_bus_speed) {
if (idebus_parameter) {
-
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: Question on CONFIG_IRQBALANCE / 2.6.x
there's something I don't understand: With IRQBALANCE *enabled* almost all interrupts are processed on CPU0. This changed in an unexpected way after disabling IRQBALANCE: now all interrupts are distributed uniformly to both CPUs. Maybe it's intentional, but it's not what I expect when a config option named IRQBALANCE is *disabled*. Can anybody comment on this? If you have a Pentium 3 based system, by default they'll round robin. If you turn on IRQbalance, they won't move until the traffic gets high enough load to matter. That's presumably what you're seeing. It's an Athlon box that propably has the same behaviour. Just another question on this topic: with IRQBALANCE enabled, almost all interupts are routet to CPU0. Lately irq 0 runs on CPU1 and never returns to CPU0 - is there any obvious reason for that? If it's not getting interrupts at 1010 per second or so, it won't rotate them, on the grounds it's not worthwhile. M. - 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: Should kirqd work on HT?
--Jeff Garzik [EMAIL PROTECTED] wrote (on Saturday, February 19, 2005 11:30:53 -0500): Pallipadi, Venkatesh wrote: You are right. Kernel balancer doesn't move around the irqs, unless it has too many interrupts. The logic is moving around interrupts all the time will not be good on caches. So, there is a threshold above which the balancer start moving things around. You should see them moving around if you do 'ping -f' or a big 'dd' from the disk. If kirqd is moving NIC interrupts, it's broken. (and another reason why irqbalanced is preferable) Why is it broken to move NIC interrupts? Obviously you don't want to rotate them around a lot, but in the interests of fairness to other processes, it seems reasonable to migrate them occasionally (IIRC, kirqd rate limits to once a second or something). M. - 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: Should kirqd work on HT?
I've noticed this problem for a while, but only now decided to ask. Interrupt balancing doesn't do anything on my system. CPU0 CPU1 0: 31931808 0IO-APIC-edge timer 1: 76595 0IO-APIC-edge i8042 8: 1 0IO-APIC-edge rtc 9: 1 0 IO-APIC-level acpi 14:122 1IO-APIC-edge ide0 16:4074456 0 IO-APIC-level uhci_hcd, uhci_hcd, [EMAIL PROTECTED]:1:0:0 17:4295132 0 IO-APIC-level Intel ICH5 18:2070933 0 IO-APIC-level libata, uhci_hcd, eth0 19: 887311 0 IO-APIC-level uhci_hcd 22: 572530 0 IO-APIC-level ath0 NMI: 31931749 31931636 (I've since disabled the nmi_watchdog) LOC: 31931252 31931251 ERR: 0 MIS: 0 I enabled the debugging and found that it doesn't think it's worth the effort. Is that correct? Not a complaint, just curious! I think it's nothing to do with HT, just the rate you're sending intterrupts at isn't high enough to bother rotating. M. - 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/
[PATCH][2.6.11-rc3-mm2] perfctr-2.7.10 API update 1/4: common
Andrew,
This set of patches form the first half of a major perfctr API update.
The goal is to change the upload-new-control-data system call to be
much more generic and independent of struct layouts. To this end the
upload-new-control-data syscall will become
ret = sys_vperfctr_write(fd, namespace, data, datalen)
where namespace determines how data is to be interpreted. Initially
there will probably be one namespace for perfctr's software state,
and one CPU-specific namespace for pure hardware state; the latter
will probably be expressed generically as a reg.nr, reg.value array.
This API change will however require that the write() operation doesn't
imply a (re)start of the context, since usually more than one write will
be needed to upload all control data. Therefore this first set of patches
alter the API so that control data uploads and parameterless state changes
are performed by different system calls. The current control() call becomes
a light-weight write() call, but still using the old control data layout.
A new unified control() call is introduced for state changes, replacing and
extending the current unlink() and iresume() calls.
perfctr-2.7.10 update, 1/4:
- Added new sys_vperfctr_control(), with UNLINK, SUSPEND,
RESUME, and CLEAR sub-commands. Deleted sys_vperfctr_unlink()
and sys_vperfctr_iresume(). Changed sys_vperfctr_write()
to only update control data and not reenable the context.
RESUME now works both for resuming after overflow interrupts
and for restarting after changing control data.
- Renamed old sys_vperfctr_control() to sys_vperfctr_write().
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
drivers/perfctr/version.h |2
drivers/perfctr/virtual.c | 233 --
include/linux/perfctr.h | 19 ++-
kernel/sys_ni.c |3
4 files changed, 159 insertions(+), 98 deletions(-)
diff -rupN linux-2.6.11-rc3-mm2/drivers/perfctr/version.h
linux-2.6.11-rc3-mm2.perfctr-2.7.10-common-update/drivers/perfctr/version.h
--- linux-2.6.11-rc3-mm2/drivers/perfctr/version.h 2005-02-20
12:39:29.0 +0100
+++ linux-2.6.11-rc3-mm2.perfctr-2.7.10-common-update/drivers/perfctr/version.h
2005-02-20 13:17:43.0 +0100
@@ -1 +1 @@
-#define VERSION 2.7.9
+#define VERSION 2.7.10
diff -rupN linux-2.6.11-rc3-mm2/drivers/perfctr/virtual.c
linux-2.6.11-rc3-mm2.perfctr-2.7.10-common-update/drivers/perfctr/virtual.c
--- linux-2.6.11-rc3-mm2/drivers/perfctr/virtual.c 2005-02-20
12:39:29.0 +0100
+++ linux-2.6.11-rc3-mm2.perfctr-2.7.10-common-update/drivers/perfctr/virtual.c
2005-02-20 13:17:43.0 +0100
@@ -1,7 +1,7 @@
-/* $Id: virtual.c,v 1.110 2004/11/24 00:38:30 mikpe Exp $
+/* $Id: virtual.c,v 1.111 2005/02/20 11:56:44 mikpe Exp $
* Virtual per-process performance counters.
*
- * Copyright (C) 1999-2004 Mikael Pettersson
+ * Copyright (C) 1999-2005 Mikael Pettersson
*/
#include linux/config.h
#include linux/init.h
@@ -39,8 +39,10 @@ struct vperfctr {
#ifdef CONFIG_PERFCTR_CPUS_FORBIDDEN_MASK
atomic_t bad_cpus_allowed;
#endif
+ unsigned int preserve;
+ unsigned int resume_cstatus;
#ifdef CONFIG_PERFCTR_INTERRUPT_SUPPORT
- unsigned int iresume_cstatus;
+ unsigned int ireload_needed; /* only valid if resume_cstatus != 0 */
#endif
/* children_lock protects inheritance_id and children,
when parent is not the one doing release_task() */
@@ -64,14 +66,8 @@ static inline void vperfctr_set_ihandler
perfctr_cpu_set_ihandler(vperfctr_ihandler);
}
-static inline void vperfctr_clear_iresume_cstatus(struct vperfctr *perfctr)
-{
- perfctr-iresume_cstatus = 0;
-}
-
#else
static inline void vperfctr_set_ihandler(void) { }
-static inline void vperfctr_clear_iresume_cstatus(struct vperfctr *perfctr) { }
#endif
#ifdef CONFIG_PERFCTR_CPUS_FORBIDDEN_MASK
@@ -280,10 +276,11 @@ static void vperfctr_handle_overflow(str
__FUNCTION__, tsk-pid);
return;
}
+ perfctr-ireload_needed = 1;
/* suspend a-mode and i-mode PMCs, leaving only TSC on */
/* XXX: some people also want to suspend the TSC */
- perfctr-iresume_cstatus = perfctr-cpu_state.cstatus;
- if (perfctr_cstatus_has_tsc(perfctr-iresume_cstatus)) {
+ perfctr-resume_cstatus = perfctr-cpu_state.cstatus;
+ if (perfctr_cstatus_has_tsc(perfctr-resume_cstatus)) {
perfctr-cpu_state.cstatus = perfctr_mk_cstatus(1, 0, 0);
vperfctr_resume(perfctr);
} else
@@ -387,7 +384,7 @@ static void vperfctr_unlink(struct task_
task_unlock(owner);
perfctr-cpu_state.cstatus = 0;
- vperfctr_clear_iresume_cstatus(perfctr);
+ perfctr-resume_cstatus = 0;
if (do_unlink)
put_vperfctr(perfctr);
}
@@ -486,7 +483,7 @@ void __vperfctr_resume(struct vperfctr *
if (unlikely(atomic_read(perfctr-bad_cpus_allowed))
[PATCH][2.6.11-rc3-mm2] perfctr-2.7.10 API update 2/4: i386
perfctr-2.7.10 update, 2/4: - Update i386 syscall table for perfctr-2.7.10 API changes. Signed-off-by: Mikael Pettersson [EMAIL PROTECTED] arch/i386/kernel/entry.S |3 +-- arch/x86_64/ia32/ia32entry.S |3 +-- include/asm-i386/unistd.h|7 +++ include/asm-x86_64/ia32_unistd.h |7 +++ 4 files changed, 8 insertions(+), 12 deletions(-) diff -rupN linux-2.6.11-rc3-mm2/arch/i386/kernel/entry.S linux-2.6.11-rc3-mm2.perfctr-2.7.10-i386-syscalls-update/arch/i386/kernel/entry.S --- linux-2.6.11-rc3-mm2/arch/i386/kernel/entry.S 2005-02-20 12:39:29.0 +0100 +++ linux-2.6.11-rc3-mm2.perfctr-2.7.10-i386-syscalls-update/arch/i386/kernel/entry.S 2005-02-20 13:13:13.0 +0100 @@ -901,8 +901,7 @@ ENTRY(sys_call_table) .long sys_keyctl .long sys_vperfctr_open .long sys_vperfctr_control /* 290 */ - .long sys_vperfctr_unlink - .long sys_vperfctr_iresume + .long sys_vperfctr_write .long sys_vperfctr_read syscall_table_size=(.-sys_call_table) diff -rupN linux-2.6.11-rc3-mm2/arch/x86_64/ia32/ia32entry.S linux-2.6.11-rc3-mm2.perfctr-2.7.10-i386-syscalls-update/arch/x86_64/ia32/ia32entry.S --- linux-2.6.11-rc3-mm2/arch/x86_64/ia32/ia32entry.S 2005-02-20 12:39:29.0 +0100 +++ linux-2.6.11-rc3-mm2.perfctr-2.7.10-i386-syscalls-update/arch/x86_64/ia32/ia32entry.S 2005-02-20 13:13:13.0 +0100 @@ -597,8 +597,7 @@ ia32_sys_call_table: .quad sys_keyctl .quad sys_vperfctr_open .quad sys_vperfctr_control /* 290 */ - .quad sys_vperfctr_unlink - .quad sys_vperfctr_iresume + .quad sys_vperfctr_write .quad sys_vperfctr_read /* don't forget to change IA32_NR_syscalls */ ia32_syscall_end: diff -rupN linux-2.6.11-rc3-mm2/include/asm-i386/unistd.h linux-2.6.11-rc3-mm2.perfctr-2.7.10-i386-syscalls-update/include/asm-i386/unistd.h --- linux-2.6.11-rc3-mm2/include/asm-i386/unistd.h 2005-02-20 12:39:30.0 +0100 +++ linux-2.6.11-rc3-mm2.perfctr-2.7.10-i386-syscalls-update/include/asm-i386/unistd.h 2005-02-20 13:13:13.0 +0100 @@ -296,11 +296,10 @@ #define __NR_keyctl288 #define __NR_vperfctr_open 289 #define __NR_vperfctr_control (__NR_vperfctr_open+1) -#define __NR_vperfctr_unlink (__NR_vperfctr_open+2) -#define __NR_vperfctr_iresume (__NR_vperfctr_open+3) -#define __NR_vperfctr_read (__NR_vperfctr_open+4) +#define __NR_vperfctr_write(__NR_vperfctr_open+2) +#define __NR_vperfctr_read (__NR_vperfctr_open+3) -#define NR_syscalls 294 +#define NR_syscalls 293 /* * user-visible error numbers are in the range -1 - -128: see diff -rupN linux-2.6.11-rc3-mm2/include/asm-x86_64/ia32_unistd.h linux-2.6.11-rc3-mm2.perfctr-2.7.10-i386-syscalls-update/include/asm-x86_64/ia32_unistd.h --- linux-2.6.11-rc3-mm2/include/asm-x86_64/ia32_unistd.h 2005-02-20 12:39:30.0 +0100 +++ linux-2.6.11-rc3-mm2.perfctr-2.7.10-i386-syscalls-update/include/asm-x86_64/ia32_unistd.h 2005-02-20 13:13:13.0 +0100 @@ -296,10 +296,9 @@ #define __NR_ia32_keyctl 288 #define __NR_ia32_vperfctr_open289 #define __NR_ia32_vperfctr_control (__NR_ia32_vperfctr_open+1) -#define __NR_ia32_vperfctr_unlink (__NR_ia32_vperfctr_open+2) -#define __NR_ia32_vperfctr_iresume (__NR_ia32_vperfctr_open+3) -#define __NR_ia32_vperfctr_read(__NR_ia32_vperfctr_open+4) +#define __NR_ia32_vperfctr_write (__NR_ia32_vperfctr_open+2) +#define __NR_ia32_vperfctr_read(__NR_ia32_vperfctr_open+3) -#define IA32_NR_syscalls 294 /* must be than biggest syscall! */ +#define IA32_NR_syscalls 293 /* must be than biggest syscall! */ #endif /* _ASM_X86_64_IA32_UNISTD_H_ */ - 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/
[PATCH][2.6.11-rc3-mm2] perfctr-2.7.10 API update 3/4: x86_64
perfctr-2.7.10 update, 3/4: - Update x86_64 syscall table for perfctr-2.7.10 API changes. Signed-off-by: Mikael Pettersson [EMAIL PROTECTED] include/asm-x86_64/unistd.h |8 +++- 1 files changed, 3 insertions(+), 5 deletions(-) diff -rupN linux-2.6.11-rc3-mm2/include/asm-x86_64/unistd.h linux-2.6.11-rc3-mm2.perfctr-2.7.10-x86_64-syscalls-update/include/asm-x86_64/unistd.h --- linux-2.6.11-rc3-mm2/include/asm-x86_64/unistd.h2005-02-20 12:39:30.0 +0100 +++ linux-2.6.11-rc3-mm2.perfctr-2.7.10-x86_64-syscalls-update/include/asm-x86_64/unistd.h 2005-02-20 13:15:32.0 +0100 @@ -567,11 +567,9 @@ __SYSCALL(__NR_keyctl, sys_keyctl) __SYSCALL(__NR_vperfctr_open, sys_vperfctr_open) #define __NR_vperfctr_control (__NR_vperfctr_open+1) __SYSCALL(__NR_vperfctr_control, sys_vperfctr_control) -#define __NR_vperfctr_unlink (__NR_vperfctr_open+2) -__SYSCALL(__NR_vperfctr_unlink, sys_vperfctr_unlink) -#define __NR_vperfctr_iresume (__NR_vperfctr_open+3) -__SYSCALL(__NR_vperfctr_iresume, sys_vperfctr_iresume) -#define __NR_vperfctr_read (__NR_vperfctr_open+4) +#define __NR_vperfctr_write(__NR_vperfctr_open+2) +__SYSCALL(__NR_vperfctr_write, sys_vperfctr_write) +#define __NR_vperfctr_read (__NR_vperfctr_open+3) __SYSCALL(__NR_vperfctr_read, sys_vperfctr_read) #define __NR_syscall_max __NR_vperfctr_read - 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/
Frequent Oops on Shutdown 2.6.10
Hi, I compiled the 2.6.10 kernel with HyperThreading optimization (I'm running a 3.06 Ghz single Xeon processor with HT enabled). More or less, I'm running Mandrake 10 Official, but with my own kernel. Can anybody help explain why I'm getting this Oops on shutdown? It doesn't happen all the time -- about 50 percent of the time. Never happens with the 2.6.6 kernel. I configured the 2.6.10 kernel with mostly the same settings -- saying no to everything new, except optimizing for P4/Xeon processor, enabling HT optimization, and NOT enabling lots of ham radio and ISDN stuff that seemed to be enabled in the Mandrake kernel. Some relevant things about the machine: Single Xeon 3.06 processor 2 GB ECC RAM 2x 3ware 9500S-8 SATA RAID Cards 16 SATA drives 2 built-in GigE ports on motherboard 2 Intel 1000 MT Server Adapters on each of the two 133 Mhz PCI-X slots Here's the output from the Oops *pde = Oops: [#1] SMP Modules linked in: raid) appletalk xfs sd_mod sg sr_mod 3w_9xxx scsi_mod nfsd exportfs ipv6 af_packet raw ide_floppy ide_tape ide_cd cdrom e1000 uhci_hcd usbcore rtc ext3 jbd CPU: 1 EIP: 0060:[c018b600] Not tainted VLI EFLAGS: 00010246 (2.6.10es-feb06) EIP is at remove_proc_entry+0x2a/0x166 eax: ebx: f66a4e00 ecx: edx: f6da1300 esi: f7cfb000 edi: 0005 ebp: c2183eb4 esp: c2183e94 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c2182000 task=c214e520) Stack: c043402c c043402c c2024980 0005 f66a4e00 f7cfb000 c2183ec8 f8c4f051 0005 f6da1300 f66a4e00 c2183ee8 f8c2cc7b f66a4e00 c2024980 0002 f6da7e80 f6da6080 c2183f04 c0289967 f66a4e00 Call Trace: [c0103352] show_stack+0xaf/0xb7 [c01034d9] show_registers+0x15f/0x1d2 [c01036dd] die+0xfa/0x180 [c011365e] do_page_fault+0x464/0x646 [c0102fbf] error_code+0x2b/0x30 [f8c4f051] snmp6_unregister_dev+0x41/0x57 [ipv6] [f8c2cc7b] in6_dev_finish_destroy+0x35/0xb6 [ipv6] [c0289967] dst_destroy+0xa2/0xcd [c028969a] dst_run_gc+0x72/0xfb [c0123584] run_timer_softirq+0xc4/0x185 [c011f631] __do_softirq+0x65/0xd3 [c011f6d0] do_softirq+0x31/0x33 [c0102f18] apic_timer_interrupt+0x1c/0x24 [c0100747] cpu_idle+0x31/0x3f [] 0x0 [c2183fbc] 0xc2183fbc Code: e2 55 89 ef 83 ec 20 8b 55 0c 8b 4d 08 89 5d f4 85 d2 89 75 f8 89 7d fc 89 4d f0 0f 84 b0 00 00 00 8b 7d f0 31 c0 b9 ff ff ff ff f2 ae f7 d1 49 8b 42 34 8d 5a 34 85 c0 89 ce 0f 84 84 00 00 00 0Kernel panic not syncing: Fatal exception in interrupt - 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/
[PATCH][2.6.11-rc3-mm2] perfctr-2.7.10 API update 4/4: ppc32
perfctr-2.7.10 update, 4/4: - Update ppc32 syscall table for perfctr-2.7.10 API changes. Signed-off-by: Mikael Pettersson [EMAIL PROTECTED] arch/ppc/kernel/misc.S |5 ++--- include/asm-ppc/unistd.h |7 +++ 2 files changed, 5 insertions(+), 7 deletions(-) diff -rupN linux-2.6.11-rc3-mm2/arch/ppc/kernel/misc.S linux-2.6.11-rc3-mm2.perfctr-2.7.10-ppc32-syscalls-update/arch/ppc/kernel/misc.S --- linux-2.6.11-rc3-mm2/arch/ppc/kernel/misc.S 2005-02-20 12:39:29.0 +0100 +++ linux-2.6.11-rc3-mm2.perfctr-2.7.10-ppc32-syscalls-update/arch/ppc/kernel/misc.S 2005-02-20 13:10:06.0 +0100 @@ -1452,6 +1452,5 @@ _GLOBAL(sys_call_table) .long sys_keyctl .long sys_vperfctr_open .long sys_vperfctr_control - .long sys_vperfctr_unlink - .long sys_vperfctr_iresume /* 275 */ - .long sys_vperfctr_read + .long sys_vperfctr_write + .long sys_vperfctr_read /* 275 */ diff -rupN linux-2.6.11-rc3-mm2/include/asm-ppc/unistd.h linux-2.6.11-rc3-mm2.perfctr-2.7.10-ppc32-syscalls-update/include/asm-ppc/unistd.h --- linux-2.6.11-rc3-mm2/include/asm-ppc/unistd.h 2005-02-20 12:39:30.0 +0100 +++ linux-2.6.11-rc3-mm2.perfctr-2.7.10-ppc32-syscalls-update/include/asm-ppc/unistd.h 2005-02-20 13:10:06.0 +0100 @@ -278,11 +278,10 @@ #define __NR_keyctl271 #define __NR_vperfctr_open 272 #define __NR_vperfctr_control (__NR_vperfctr_open+1) -#define __NR_vperfctr_unlink (__NR_vperfctr_open+2) -#define __NR_vperfctr_iresume (__NR_vperfctr_open+3) -#define __NR_vperfctr_read (__NR_vperfctr_open+4) +#define __NR_vperfctr_write(__NR_vperfctr_open+2) +#define __NR_vperfctr_read (__NR_vperfctr_open+3) -#define __NR_syscalls 277 +#define __NR_syscalls 276 #define __NR(n)#n - 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/
GL520SM Sensor Chip driver fix
Hi,
I've been recently trying to get my lmsensors working under
2.6.9, and i've found this:
http://seclists.org/lists/linux-kernel/2005/Feb/2856.html
http://lkml.org/lkml/2005/2/11/90
kernel patch for gl520 chip, but after applying it kernel refused to
compile. So I've fixed it using gl518sm module source code and I want to
share the results of my work with you. I hope that it will be useful.
I've tested this on my machine and it works fine.
Bye
PS: I hope i'm writting to good list.
--
.$ .,_ .$ [ Adam 'dredzik' Kuczynski ]
gPY:$ g. ,gP ,P _,P gPY:$ [ http://dredzik.ekg2.org/ ]
Y. ,Y: `$,P Y$ Y. ,Y: [ mailto: [EMAIL PROTECTED] ]
` `b.`Y'`--` `b. [ JID: [EMAIL PROTECTED] ]
--- linux-2.6.9/drivers/i2c/chips/gl520sm.c.orig2005-02-20
15:20:38.0 +0100
+++ linux-2.6.9/drivers/i2c/chips/gl520sm.c 2005-02-20 15:41:25.0
+0100
@@ -37,6 +37,9 @@
static unsigned short normal_i2c[] = { 0x2c, 0x2d, I2C_CLIENT_END };
static unsigned int normal_isa[] = { I2C_CLIENT_ISA_END };
+static unsigned short normal_i2c_range[] = { I2C_CLIENT_END };
+static unsigned int normal_isa_range[] = { I2C_CLIENT_ISA_END };
+
/* Insmod parameters */
SENSORS_INSMOD_1(gl520sm);
@@ -500,13 +503,25 @@
static int gl520_attach_adapter(struct i2c_adapter *adapter)
{
- if (!(adapter-clRD_DATA))
- goto exit;
+ if (!(adapter-class I2C_CLASS_HWMON))
+ return 0;
+ return i2c_detect(adapter, addr_data, gl520_detect);
+}
+static int gl520_detect(struct i2c_adapter *adapter, int address, int kind)
+{
+ struct i2c_client *new_client;
+ struct gl520_data *data;
+ int err = 0;
+
+ if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA |
+ I2C_FUNC_SMBUS_WORD_DATA))
+ goto exit;
+
/* OK. For now, we presume we have a valid client. We now create the
client structure, even though we cannot fill it completely yet.
But it allows us to access gl520_{read,write}_value. */
-
+
if (!(data = kmalloc(sizeof(struct gl520_data), GFP_KERNEL))) {
err = -ENOMEM;
goto exit;
signature.asc
Description: Digital signature
Re: [PATCH] i2c.h: Fix another gcc 4.0 compile failure
Greg KH wrote:
On Sat, Feb 19, 2005 at 08:58:48AM -0800, Mickey Stein wrote:
From: Mickey Stein
Versions: linux-2.6.11-rc4-bk7, gcc4 (GCC) 4.0.0 20050217 (latest fc
rawhide from 19Feb DL)
gcc4 cvs seems to dislike include/linux/i2c.h file:
Error msg: include/linux/i2c.h:{55,194} error: array type has
incomplete element type
A. Daplas has recently done a workaround for this on another header
file. A thread discussing this
can be found by following the link below:
http://gcc.gnu.org/ml/gcc/2005-02/msg00053.html
The patch changes the array declaration from struct x y[] format to
struct x *y.
I realize its only a workaround, but the gcc guys seem to be aware of
this.
** Note: I'm a noob at this, so feel free to make chopped liver out of
this if its incorrect.
patch below is also attached since I'm not sure formatting survives
the cutpaste.
The patch looks sane, but before I apply it, care to also fix up all of
the function pointers that are affected by this patch? Also the
i2c_transfer() function itself should be changed (not just the header
file.)
thanks,
greg k-h
Greg,
I took a look for other references similar to those in my first take at
this and found a couple more files.
Attached is another patch that hopefully addresses the all the similar
cases. I tried it on today's (-bk8) kernel,
with all i2c switches enabled.
From: Mickey Stein
Versions: linux-2.6.11-rc4-bk8, gcc4 (GCC) 4.0.0 20050217 (latest fc
rawhide from 19Feb DL)
gcc4 cvs seems to dislike include/linux/i2c.h, i2c-core.c files.
I also tweaked the Documentation/i2c/writing-clients file.
Error msg: include/linux/i2c.h:{55,194} error: array type has
incomplete element type
A. Daplas has recently done a workaround for this on another header
file. A thread discussing this
can be found by following the link below:
http://gcc.gnu.org/ml/gcc/2005-02/msg00053.html
The patch changes the i2c-transfer code in i2c.h from struct x y[]
format to struct x *y.
It also changes the associated i2c-transfer declarations in i2c-core.c.
It tweaks the Documentation/i2c/writing-clients file to reconcile
i2c-transfer docs.
I realize its only a workaround, but the gcc guys seem to be aware of
this.
Thanks very much,
Mickey Stein
Signed-off-by: Mickey Stein [EMAIL PROTECTED]
--- ./include/linux/i2c.h.sav 2005-02-20 07:03:41.0 -0800
+++ ./include/linux/i2c.h 2005-02-20 07:14:26.0 -0800
@@ -55,7 +55,7 @@
/* Transfer num messages.
*/
-extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],int
num);
+extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msg,int num);
/*
* Some adapter types (i.e. PCF 8584 based ones) may support slave behaviuor.
@@ -194,7 +194,7 @@
to NULL. If an adapter algorithm can do SMBus access, set
smbus_xfer. If set to NULL, the SMBus protocol is simulated
using common I2C messages */
- int (*master_xfer)(struct i2c_adapter *adap,struct i2c_msg msgs[],
+ int (*master_xfer)(struct i2c_adapter *adap,struct i2c_msg *msgs,
int num);
int (*smbus_xfer) (struct i2c_adapter *adap, u16 addr,
unsigned short flags, char read_write,
--- ./drivers/i2c/i2c-core.c.sav2005-02-20 07:03:53.0 -0800
+++ ./drivers/i2c/i2c-core.c2005-02-20 07:11:46.0 -0800
@@ -583,7 +583,7 @@
*
*/
-int i2c_transfer(struct i2c_adapter * adap, struct i2c_msg msgs[],int num)
+int i2c_transfer(struct i2c_adapter * adap, struct i2c_msg *msgs,int num)
{
int ret;
--- ./Documentation/i2c/writing-clients.sav 2005-02-20 07:05:12.0
-0800
+++ ./Documentation/i2c/writing-clients 2005-02-20 07:08:29.0 -0800
@@ -642,7 +642,7 @@
parameter contains the bytes the read/write, the third the length of the
buffer. Returned is the actual number of bytes read/written.
- extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],
+ extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msg,
int num);
This sends a series of messages. Each message can be a read or write,
Re: Needed faster implementation of do_gettimeofday()
On Sunday 20 February 2005 05:58 am, [EMAIL PROTECTED] wrote: 985913 8.6083 vmlinux mark_offset_tsc 584473 5.1032 libc-2.3.2.so getc What makes you think mark_offset_tsc is slow? Do you have any comparative numbers? It might just be that the workload you are throwing at it justifies it. (For e.g. if your workload does a zillion system calls, system_call will show up as a hot spot in oprofile - doesn't necessarily mean it is slow - it's just overused.) Can you post the relevant code? Parag - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.11rc4: irq 5, nobody cared
Hi, My linux laptop says: irq 5: nobody cared! [c0133044] __report_bad_irq+0x24/0x90 [c0133141] note_interrupt+0x61/0x90 [c0132b2b] __do_IRQ+0x13b/0x150 [c0104a33] do_IRQ+0x23/0x40 [c01031fe] common_interrupt+0x1a/0x20 [c0119dee] __do_softirq+0x2e/0x80 [c0119e67] do_softirq+0x27/0x30 [c0119f35] irq_exit+0x35/0x40 [c0104a38] do_IRQ+0x28/0x40 [c01031fe] common_interrupt+0x1a/0x20 [c011d6c0] del_timer+0x0/0xb0 [c02b1c59] schedule_timeout+0x69/0xc0 [c0138b8f] __get_free_pages+0x1f/0x40 [c011df90] process_timeout+0x0/0x10 [c01633e5] do_select+0x195/0x2f0 [c0163090] __pollwait+0x0/0xc0 [c0128cc0] autoremove_wake_function+0x0/0x50 [c016381e] sys_select+0x2be/0x4b0 [c01194fc] sys_gettimeofday+0x2c/0x70 [c010308f] syscall_call+0x7/0xb handlers: [dc8d35f0] (usb_hcd_irq+0x0/0x60 [usbcore]) [dca21690] (ndis_irq_th+0x0/0xf0 [ndiswrapper]) Disabling IRQ #5 Does anyone care? :-) Folkert van Heusden Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden! +--+ |UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/)| |a try, it brings monitoring logfiles to a different level! See| |http://vanheusden.com/multitail/features.html for a feature list. | +--= www.unixsoftware.nl =-+ Phone: +31-6-41278122, PGP-key: 1F28D8AE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11rc4: irq 5, nobody cared
On Feb 20 2005, Folkert van Heusden wrote: My linux laptop says: irq 5: nobody cared! (...) Does anyone care? :-) Well, I'm getting similar stack traces with my system and those are sure scary, but it seems that my e-mails to the list are simply ignored, unfortunately. I am willing to test any patch and configuration (let's call me a guinea pig), but I don't know what I should do. I have, OTOH, reported my problem many times in the past few days. :-( I will retry sending my message to the list once again, with the details (in my case, the message I get is irq 10: nobody cared! and it is regarding my primary HD on my secondary Promise PDC20265 controller). Thanks for any help, Rogério. P.S.: I have already bought an 80-pin cable just for this drive in the hope that the message would go away, but it didn't. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11rc4: irq 5, nobody cared
[dca21690] (ndis_irq_th+0x0/0xf0 [ndiswrapper]) Disabling IRQ #5 Does anyone care? :-) doubt it ... ;) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11rc4: irq 5, nobody cared
Rogério Brito wrote: On Feb 20 2005, Folkert van Heusden wrote: My linux laptop says: irq 5: nobody cared! (...) Does anyone care? :-) Well, I'm getting similar stack traces with my system and those are sure scary, but it seems that my e-mails to the list are simply ignored, unfortunately. I am willing to test any patch and configuration (let's call me a guinea pig), but I don't know what I should do. I have, OTOH, reported my problem many times in the past few days. :-( I will retry sending my message to the list once again, with the details (in my case, the message I get is irq 10: nobody cared! and it is regarding my primary HD on my secondary Promise PDC20265 controller). Thanks for any help, Rogério. P.S.: I have already bought an 80-pin cable just for this drive in the hope that the message would go away, but it didn't. Report it to http://bugzilla.kernel.org/. Maybe you'll get help there. But bugs are _very_ hardware specific, so just a few people will have a similar problem and most of this people are just normal users -- not Linux Kernel developers. The developer (people who are familiar with the kernel code and who are maybe able to fix this problem) aren't able to reproduce this error and test code to get it working. So they're maybe (without knowing anything about the hardware (maybe it's broken hardware?)) not able to say something specific about the hardware -- they can just guess. You see it's very difficult to fix such irq problems because some factors can cause such an error. Maybe contacting specific malinglists (e.g. for broken pci cards the pci mailinglist, etc.), maintainers or developers would be more efficient (cc the lkml) and solve your problem (faster), because this people are specialists are this type of hardware (e.g. pci). What hardware is connect through irq 5? Matthias-Christian Ott - 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: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]
On Sun, 20 Feb 2005, Russell King wrote: On Sat, Feb 19, 2005 at 08:36:12PM -0500, Steven Rostedt wrote: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000d - 000d4000 (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 0f6f (usable) BIOS-e820: 0f6f - 0f70 (reserved) BIOS-e820: 0f70 - 3fef (usable) BIOS-e820: 3fef - 3fef8000 (ACPI data) BIOS-e820: 3fef8000 - 3fefa000 (ACPI NVS) BIOS-e820: 3ff0 - 4000 (reserved) Your BIOS is broken. You probably have 1GB of RAM which extends from 0x to 0x4000. However, there's a hole in the ACPI map between 0x3fefa000 and 0x3ff0. Good point. And dammit, we've had that problem too many times before. And I think the reason for that bug is that we use max_low_pfn to determine where we should start allocating PCI memory. We actually round it up to the next megabyte, which _should_ have made us not allocate in that small region (the last usable page is 0x3fef, rounded up to the nearest megabyte is 0x3ff0, which is marked as reserved, so we _should_ have allocated above that quite nicely). However, we are screwed by the fact that max_low_pfn is actually limited by MAXMEM_PFN, which is the kernel _mappable_ memory, so MAXMEM is actually much less than one megabyte (it's one megabyte minus VMALLOC_RESERVE, which defaults to 128MB). But the PCI allocations are not at all limited by MAXMEM - they want to be in the low 4GB, but that's the only real limit. So using max_low_pfn to determine where to start PCI allocations is pretty bogus. I'll try to write something that actually looks at the e820 memory map properly. Linus - 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 Storage problem (usb hangs)
Hi. The device is: USB2.0 to IDE 3.5 hard disk enclosure. Producer: Seven. Part of /var/log/messages with USB debug enabled in kernel is attached to this email. Kernel: 2.6.9, 2.6.10 (i cant remember from which one is attached log). Distribution: Gentoo. I'm not subscribed to the list, pleas CC me. -- Regards Sebastian Fabrycki [EMAIL PROTECTED] -- Sprawdz NOWE parametry hostingu! http://link.interia.pl/f1857 Jan 10 23:34:30 globtel usb-storage: USB Mass Storage device detected Jan 10 23:34:30 globtel usb-storage: -- associate_dev Jan 10 23:34:30 globtel usb-storage: Vendor: 0x05e3, Product: 0x0702, Revision: 0x0002 Jan 10 23:34:30 globtel usb-storage: Interface Subclass: 0x06, Protocol: 0x50 Jan 10 23:34:30 globtel usb-storage: Vendor: Genesys Logic, Product: USB TO IDE Jan 10 23:34:30 globtel usb-storage: Transport: Bulk Jan 10 23:34:30 globtel usb-storage: Protocol: Transparent SCSI Jan 10 23:34:30 globtel usb-storage: usb_stor_control_msg: rq=fe rqtype=a1 value= index=00 len=1 Jan 10 23:34:30 globtel usb-storage: GetMaxLUN command result is 1, data is 0 Jan 10 23:34:30 globtel usb-storage: *** thread sleeping. Jan 10 23:34:30 globtel scsi0 : SCSI emulation for USB Mass Storage devices Jan 10 23:34:30 globtel usb-storage: queuecommand called Jan 10 23:34:30 globtel usb-storage: *** thread awakened. Jan 10 23:34:30 globtel usb-storage: Faking INQUIRY command Jan 10 23:34:30 globtel usb-storage: scsi cmd done, result=0x0 Jan 10 23:34:30 globtel usb-storage: *** thread sleeping. Jan 10 23:34:30 globtel Vendor: Genesys Model: USB to IDE Disk Rev: 0002 Jan 10 23:34:30 globtel Type: Direct-Access ANSI SCSI revision: 02 Jan 10 23:34:30 globtel usb-storage: queuecommand called Jan 10 23:34:30 globtel usb-storage: *** thread awakened. Jan 10 23:34:30 globtel usb-storage: Command TEST_UNIT_READY (6 bytes) Jan 10 23:34:30 globtel usb-storage: 00 00 00 00 00 00 Jan 10 23:34:30 globtel usb-storage: Bulk Command S 0x43425355 T 0x2 L 0 F 0 Trg 0 LUN 0 CL 6 Jan 10 23:34:30 globtel usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes Jan 10 23:34:30 globtel usb-storage: Status code 0; transferred 31/31 Jan 10 23:34:30 globtel usb-storage: -- transfer complete Jan 10 23:34:30 globtel usb-storage: Bulk command transfer result=0 Jan 10 23:34:30 globtel usb-storage: Attempting to get CSW... Jan 10 23:34:30 globtel usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes Jan 10 23:34:40 globtel scsi.agent[7459]: Attribute /sys/devices/pci:00/:00:1d.7/usb1/1-4/1-4:1.0/host0/0:0:0:0/type does not exist Jan 10 23:35:00 globtel usb-storage: command_abort called Jan 10 23:35:00 globtel usb-storage: usb_stor_stop_transport called Jan 10 23:35:00 globtel usb-storage: -- cancelling URB Jan 10 23:35:00 globtel usb-storage: Status code -104; transferred 0/13 Jan 10 23:35:00 globtel usb-storage: -- transfer cancelled Jan 10 23:35:00 globtel usb-storage: Bulk status result = 4 Jan 10 23:35:00 globtel usb-storage: -- command was aborted Jan 10 23:35:00 globtel usb-storage: usb_stor_Bulk_reset called Jan 10 23:35:00 globtel usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value= index=00 len=0 Jan 10 23:35:20 globtel usb-storage: Timeout -- cancelling URB Jan 10 23:35:20 globtel usb-storage: Soft reset failed: -104 Jan 10 23:35:20 globtel usb-storage: scsi command aborted Jan 10 23:35:20 globtel usb-storage: *** thread sleeping. Jan 10 23:35:20 globtel usb-storage: queuecommand called Jan 10 23:35:20 globtel usb-storage: *** thread awakened. Jan 10 23:35:20 globtel usb-storage: Command TEST_UNIT_READY (6 bytes) Jan 10 23:35:20 globtel usb-storage: 00 00 00 00 00 00 Jan 10 23:35:20 globtel usb-storage: Bulk Command S 0x43425355 T 0x2 L 0 F 0 Trg 0 LUN 0 CL 6 Jan 10 23:35:20 globtel usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes Jan 10 23:35:20 globtel usb-storage: Status code 0; transferred 31/31 Jan 10 23:35:20 globtel usb-storage: -- transfer complete Jan 10 23:35:20 globtel usb-storage: Bulk command transfer result=0 Jan 10 23:35:20 globtel usb-storage: Attempting to get CSW... Jan 10 23:35:20 globtel usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes Jan 10 23:35:30 globtel usb-storage: command_abort called Jan 10 23:35:30 globtel usb-storage: usb_stor_stop_transport called Jan 10 23:35:30 globtel usb-storage: -- cancelling URB Jan 10 23:35:30 globtel usb-storage: Status code -104; transferred 0/13 Jan 10 23:35:30 globtel usb-storage: -- transfer cancelled Jan 10 23:35:30 globtel usb-storage: Bulk status result = 4 Jan 10 23:35:30 globtel usb-storage: -- command was aborted Jan 10 23:35:30 globtel usb-storage: usb_stor_Bulk_reset called Jan 10 23:35:30 globtel usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value= index=00 len=0 Jan 10 23:35:50 globtel usb-storage: Timeout -- cancelling URB Jan 10 23:35:50 globtel usb-storage: Soft reset failed: -104 Jan 10 23:35:50 globtel usb-storage:
Re: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]
On Sun, 20 Feb 2005, Linus Torvalds wrote:
But the PCI allocations are not at all limited by MAXMEM - they want to be
in the low 4GB, but that's the only real limit. So using max_low_pfn to
determine where to start PCI allocations is pretty bogus.
I'll try to write something that actually looks at the e820 memory map
properly.
Russell, what do your eagle-eyes think of a patch like this?
Steven, does this fix it without the need for any kernel command line (or
any other patches, for that matter - ie revert all the transparency-
changing ones)?
Linus
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/02/20 09:43:19-08:00 [EMAIL PROTECTED]
# Use e820 memory map to determine PCI allocation area.
#
# Don't use the VM numbers (max_low_pfn and friends), since they depend
# on the partial kernel linear mapping and only partially on the actual
# physical memory layout.
#
# arch/i386/kernel/setup.c
# 2005/02/20 09:43:12-08:00 [EMAIL PROTECTED] +19 -6
# Use e820 memory map to determine PCI allocation area.
#
# Don't use the VM numbers (max_low_pfn and friends), since they depend
# on the partial kernel linear mapping and only partially on the actual
# physical memory layout.
#
diff -Nru a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c
--- a/arch/i386/kernel/setup.c 2005-02-20 09:54:35 -08:00
+++ b/arch/i386/kernel/setup.c 2005-02-20 09:54:35 -08:00
@@ -1166,9 +1166,10 @@
/*
* Request address space for all standard resources
*/
-static void __init register_memory(unsigned long max_low_pfn)
+static void __init register_memory(void)
{
- unsigned long low_mem_size;
+ long long gapsize;
+ unsigned long long last;
int i;
if (efi_enabled)
@@ -1184,9 +1185,21 @@
request_resource(ioport_resource, standard_io_resources[i]);
/* Tell the PCI layer not to allocate too close to the RAM area.. */
- low_mem_size = ((max_low_pfn PAGE_SHIFT) + 0xf) ~0xf;
- if (low_mem_size pci_mem_start)
- pci_mem_start = low_mem_size;
+ last = 0x1ull;
+ gapsize = 0x40;
+ i = e820.nr_map;
+ while (--i = 0) {
+ unsigned long long start = e820.map[i].addr;
+ unsigned long long end = start + e820.map[i].size;
+ long long gap = last - end;
+
+ if (gap gapsize) {
+ gapsize = gap;
+ pci_mem_start = ((unsigned long) end + 0xf)
~0xf;
+ }
+ last = start;
+ }
+ printk(Allocating PCI resources starting at %08lx\n, pci_mem_start);
}
/* Use inline assembly to define this because the nops are defined
@@ -1432,7 +1445,7 @@
get_smp_config();
#endif
- register_memory(max_low_pfn);
+ register_memory();
#ifdef CONFIG_VT
#if defined(CONFIG_VGA_CONSOLE)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11rc4: irq 5, nobody cared
On Feb 20 2005, Matthias-Christian Ott wrote: Rogério Brito wrote: I am willing to test any patch and configuration (let's call me a guinea pig), but I don't know what I should do. I have, OTOH, reported my problem many times in the past few days. :-( I will retry sending my message to the list once again, with the details (in my case, the message I get is irq 10: nobody cared! and it is regarding my primary HD on my secondary Promise PDC20265 controller). First of all, Matthias-Christian, thank you very much for your kind answer. I have already tried contacting the linux-ide mailing list as a CC to my earlier messages, but I got no response. I am including some details in this e-mail. I included Bartlomiej in the CC, as he is listed as general IDE maintainer in the MAINTAINERS file. Report it to http://bugzilla.kernel.org/. Maybe you'll get help there. Thanks. I will try filing a bug on that system as soon as I get the reply to create my account there. (...) You see it's very difficult to fix such irq problems because some factors can cause such an error. Yes, I understand that. Maybe contacting specific malinglists (e.g. for broken pci cards the pci mailinglist, etc.), maintainers or developers would be more efficient (cc the lkml) and solve your problem (faster), because this people are specialists are this type of hardware (e.g. pci). What hardware is connect through irq 5? In my case, my problem is not with irq 5, but with irq 10, as I mentioned earlier. The situation is this: I have an Asus A7V motherboard with 2 VIA vt82c686a controllers and 2 Promise PDC20265 controllers. I recently bought myself a new DVD recorder and since Alan Cox told me[*] that the Promise controllers had problems with ATAPI devices, I decided to arrange my system this way: /dev/hda: the DVD recorder (VIA controller, master) /dev/hdc: an old CD recorder (VIA controller, master) /dev/hde: my first HD (Promise controller, master) /dev/hdg: my second HD (Promise controller, master) The Promise controller is able to control the HDs (which now have exclusive 80-pin cables) at their maximum, but I get the following stack trace if I have /dev/hdg turned on: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ACPI: PCI interrupt :00:11.0[A] - GSI 10 (level, low) - IRQ 10 PDC20265: chipset revision 2 PDC20265: 100% native mode on irq 10 PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:pio, hdf:pio ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:pio, hdh:pio Probing IDE interface ide2... hde: QUANTUM FIREBALL CX13.0A, ATA DISK drive ide2 at 0x8800-0x8807,0x8402 on irq 10 Probing IDE interface ide3... hdg: QUANTUM FIREBALLlct15 30, ATA DISK drive irq 10: nobody cared! [c0128fc1] __report_bad_irq+0x31/0x77 [c012906b] note_interrupt+0x4c/0x71 [c0128c86] __do_IRQ+0x93/0xbd [c0104635] do_IRQ+0x19/0x24 [c010335a] common_interrupt+0x1a/0x20 [c011935c] __do_softirq+0x2c/0x7d [c01193cf] do_softirq+0x22/0x26 [c010463a] do_IRQ+0x1e/0x24 [c010335a] common_interrupt+0x1a/0x20 [c0128d89] enable_irq+0x88/0x8d [c021edc0] probe_hwif+0x2da/0x366 [c021a137] ata_attach+0xa3/0xbd [c021ee5c] probe_hwif_init_with_fixup+0x10/0x74 [c0221597] ide_setup_pci_device+0x72/0x7f [c0216f82] pdc202xx_init_one+0x15/0x18 [c039182e] ide_scan_pcidev+0x34/0x59 [c039186f] ide_scan_pcibus+0x1c/0x88 [c039179f] probe_for_hwifs+0xb/0xd [c03917e5] ide_init+0x44/0x59 [c037c6ce] do_initcalls+0x4b/0x99 [c0100272] init+0x0/0xce [c0100299] init+0x27/0xce [c0101245] kernel_thread_helper+0x5/0xb handlers: [c021c2a6] (ide_intr+0x0/0xee) Disabling IRQ #10 irq 10: nobody cared! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This is just an excerpt of the messages. I can provide much more details if I know what is relevant. I had already posted some old dmesg logs at my site http://www.ime.usp.br/~rbrito/ide-problem/, but this was before I got myself a second 80-ribbon cable (I expected that the problem would go away, but it didn't). Any other comments are more than welcome. Thanks in advance, Rogério Brito. [*] http://infocenter.guardiandigital.com/archive/linux-kernel/2004/Dec/2663.html -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - 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/
http://kernel.org down
I get time-outs when trying to access kernel.org but the ftp works. Is this scheduled? smime.p7s Description: S/MIME Cryptographic Signature
PROBLEM: agpgart-via: probe fails with error -22
[1.] PROBLEM: agpgart-via: probe fails with error -22 [2.] When loading agpgart/agpgart-via the following occurs: Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected VIA KT400/KT400A/KT600 chipset agpgart: Maximum main memory to use for agp memory: 816M agpgart: unable to determine aperture size. agpgart: agp_backend_initialize() failed. agpgart-via: probe of :00:00.0 failed with error -22 [3.] Keywords: agpgart-via [4.] Linux version 2.6.10 ([EMAIL PROTECTED]) (gcc version 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)) #1 Fri Feb 18 10:36:35 EST 2005 [5.] agpgart: unable to determine aperture size. agpgart: agp_backend_initialize() failed. agpgart-via: probe of :00:00.0 failed with error -22 [6.] N/A [7.] LESSKEY=/etc/.less LC_PAPER=en_US LC_ADDRESS=en_US LC_MONETARY=en_US HOSTNAME=blossom SHELL=/bin/bash TERM=xterm LC_SOURCED=1 HISTSIZE=1000 TMPDIR=/root/tmp LC_NUMERIC=en_US QTDIR=/usr/lib/qt3/ USER=root LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tz=01;31:*.rpm=01;31:*.cpio=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35: LC_TELEPHONE=en_US ENV=/root/.bashrc USERNAME=root NLSPATH=/usr/share/locale/%l/%N MAIL=/var/spool/mail/root PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin LC_MESSAGES=en_US SECURE_LEVEL=2 LC_IDENTIFICATION=en_US LC_COLLATE=en_US INPUTRC=/etc/inputrc PWD=/root LANG=en_US PYTHONSTARTUP=/etc/pythonrc.py LC_MEASUREMENT=en_US [EMAIL PROTECTED] \W]\$ HISTCONTROL=ignoredups SHLVL=1 HOME=/root LANGUAGE=en_US:en GCONF_TMPDIR=/tmp TMP=/root/tmp LESS=-MM LOGNAME=root LC_CTYPE=en_US LESSOPEN=|/usr/bin/lesspipe.sh %s DISPLAY=:0.0 LC_TIME=en_US G_BROKEN_FILENAMES=1 LC_NAME=en_US XAUTHORITY=/root/.xauthqHycKh _=/bin/env [7.1.] Linux blossom 2.6.10 #1 Fri Feb 18 10:36:35 EST 2005 i686 AMD Athlon(tm) XP 2900+ unknown GNU/Linux Gnu C 3.4.1 Gnu make 3.80 binutils 2.15.90.0.3 util-linux 2.12a mount 2.12a module-init-tools 3.0 e2fsprogs 1.35 reiserfsprogs line reiser4progs line nfs-utils 1.0.6 Linux C Library2.3.3 Dynamic linker (ldd) 2.3.3 Procps 3.2.3 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.2.1 Modules Loaded snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_emu10k1 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore loop nls_iso8859_1 ntfs nvidia ehci_hcd uhci_hcd button rtc [7.2.] processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 10 model name : AMD Athlon(tm) XP 2900+ stepping: 0 cpu MHz : 1999.874 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse pni syscall mmxext 3dnowext 3dnow bogomips: 3940.35 [7.3.] snd_seq_oss 32320 0 - Live 0xf898b000 snd_seq_midi_event 6336 1 snd_seq_oss, Live 0xf892 snd_seq 50064 4 snd_seq_oss,snd_seq_midi_event, Live 0xf8a41000 snd_pcm_oss 50532 0 - Live 0xf8a33000 snd_mixer_oss 17920 1 snd_pcm_oss, Live 0xf8947000 snd_emu10k1 93764 1 - Live 0xf8996000 snd_rawmidi 20704 1 snd_emu10k1, Live 0xf894 snd_seq_device 6796 4 snd_seq_oss,snd_seq,snd_emu10k1,snd_rawmidi, Live 0xf891d000 snd_ac97_codec 72352 1 snd_emu10k1, Live 0xf8967000 snd_pcm 84232 3 snd_pcm_oss,snd_emu10k1,snd_ac97_codec, Live 0xf8951000 snd_timer 22084 2 snd_seq,snd_pcm, Live 0xf8931000 snd_page_alloc 7428 2 snd_emu10k1,snd_pcm, Live 0xf8818000 snd_util_mem 3264 1 snd_emu10k1, Live 0xf881b000 snd_hwdep 7364 1 snd_emu10k1, Live 0xf8916000 snd 44772 13 snd_seq_oss,snd_seq,snd_pcm_oss,snd_mixer_oss,snd_emu10k1,snd_rawmidi,snd_seq_device,snd_ac97_codec,snd_pcm,snd_timer,snd_hwdep, Live 0xf8925000 soundcore 7456 1 snd, Live 0xf880e000 loop 12936 0 - Live 0xf8911000 nls_iso8859_1 3776 1 - Live 0xf8816000 ntfs 178192 1 - Live 0xf88e4000 nvidia 3462844 12 - Live 0xf8c69000 ehci_hcd 27076 0 - Live 0xf8827000 uhci_hcd 29520 0 - Live 0xf881e000 button 4816 0 - Live 0xf8811000 rtc 10488 0 - Live 0xf8804000 [7.4.] -001f : dma1 0020-0021 : pic1 0040-0043 : timer0 0050-0053 : timer1 0060-006f : keyboard 0070-0077 : rtc 0080-008f : dma page reg 00a0-00a1 : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0376-0376 : ide1 03c0-03df : vga+ 03f6-03f6 : ide0 0cf8-0cff : PCI conf1 4000-4003 : PM1a_EVT_BLK 4004-4005 :
Re: http://kernel.org down
Stephen R. Bordeleau wrote: I get time-outs when trying to access kernel.org but the ftp works. Is this scheduled? thanks. should be ok now. -- ~Randy - 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/
[PATCH][2.4] Fix timer override on nforce
Per our discussion, i've ported the 2.6 nforce skip timer override (and
early PCI access) code to 2.4. This fixes an issue whereupon nforce
systems have incorrect override values for irq0. Architectures affected
are i386 and x86_64
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/02/18 07:53:21-07:00 [EMAIL PROTECTED]
# ACPI skip_timer_override backport from 2.6 including early PCI bridge
detection.
#
# include/asm-x86_64/acpi.h
# 2005/02/18 07:53:18-07:00 [EMAIL PROTECTED] +1 -0
# ACPI skip_timer_override backport from 2.6 including early PCI bridge
detection.
#
# include/asm-i386/pci-direct.h
# 2005/02/18 07:53:18-07:00 [EMAIL PROTECTED] +1 -0
# ACPI skip_timer_override backport from 2.6 including early PCI bridge
detection.
#
# include/asm-i386/acpi.h
# 2005/02/18 07:53:18-07:00 [EMAIL PROTECTED] +2 -0
# ACPI skip_timer_override backport from 2.6 including early PCI bridge
detection.
#
# arch/x86_64/kernel/io_apic.c
# 2005/02/18 07:53:18-07:00 [EMAIL PROTECTED] +7 -3
# ACPI skip_timer_override backport from 2.6 including early PCI bridge
detection.
#
# arch/x86_64/kernel/acpi.c
# 2005/02/18 07:53:18-07:00 [EMAIL PROTECTED] +7 -0
# ACPI skip_timer_override backport from 2.6 including early PCI bridge
detection.
#
# arch/i386/kernel/earlyquirk.c
# 2005/02/18 07:53:18-07:00 [EMAIL PROTECTED] +53 -0
# ACPI skip_timer_override backport from 2.6 including early PCI bridge
detection.
#
# arch/i386/kernel/acpi.c
# 2005/02/18 07:53:18-07:00 [EMAIL PROTECTED] +9 -0
# ACPI skip_timer_override backport from 2.6 including early PCI bridge
detection.
#
# arch/i386/kernel/Makefile
# 2005/02/18 07:53:18-07:00 [EMAIL PROTECTED] +1 -1
# ACPI skip_timer_override backport from 2.6 including early PCI bridge
detection.
#
diff -Nru a/arch/i386/kernel/Makefile b/arch/i386/kernel/Makefile
--- a/arch/i386/kernel/Makefile 2005-02-18 07:53:58 -07:00
+++ b/arch/i386/kernel/Makefile 2005-02-18 07:53:58 -07:00
@@ -40,7 +40,7 @@
obj-$(CONFIG_ACPI_SLEEP) += acpi_wakeup.o
obj-$(CONFIG_SMP) += smp.o smpboot.o trampoline.o
obj-$(CONFIG_X86_LOCAL_APIC) += mpparse.o apic.o nmi.o
-obj-$(CONFIG_X86_IO_APIC) += io_apic.o
+obj-$(CONFIG_X86_IO_APIC) += io_apic.o earlyquirk.o
obj-$(CONFIG_X86_VISWS_APIC) += visws_apic.o
obj-$(CONFIG_EDD) += edd.o
diff -Nru a/arch/i386/kernel/acpi.c b/arch/i386/kernel/acpi.c
--- a/arch/i386/kernel/acpi.c 2005-02-18 07:53:58 -07:00
+++ b/arch/i386/kernel/acpi.c 2005-02-18 07:53:58 -07:00
@@ -55,6 +55,7 @@
acpi_interrupt_flags acpi_sci_flags __initdata;
int acpi_sci_override_gsi __initdata;
+int acpi_skip_timer_override __initdata;
/* --
Boot-time Configuration
--
*/
@@ -320,6 +321,12 @@
return 0;
}
+ if (acpi_skip_timer_override
+ intsrc-bus_irq == 0 intsrc-global_irq == 2) {
+ printk(PREFIX BIOS IRQ0 pin2 override ignored.\n);
+ return 0;
+ }
+
mp_override_legacy_irq (
intsrc-bus_irq,
intsrc-flags.polarity,
@@ -433,6 +440,8 @@
return result;
}
+ check_acpi_pci();
+
result = acpi_blacklisted();
if (result) {
printk(KERN_NOTICE PREFIX BIOS listed in blacklist, disabling
ACPI support\n);
diff -Nru a/arch/i386/kernel/earlyquirk.c b/arch/i386/kernel/earlyquirk.c
--- a/arch/i386/kernel/earlyquirk.c 2005-02-18 07:53:58 -07:00
+++ b/arch/i386/kernel/earlyquirk.c 2005-02-18 07:53:58 -07:00
@@ -0,0 +1,53 @@
+/*
+ * Do early PCI probing for bug detection when the main PCI subsystem is
+ * not up yet.
+ */
+#include linux/init.h
+#include linux/kernel.h
+#include linux/pci.h
+#include asm/pci-direct.h
+#include asm/acpi.h
+
+#ifdef CONFIG_ACPI
+static int __init check_bridge(int vendor, int device)
+{
+ /* According to Nvidia all timer overrides are bogus. Just ignore
+ them all. */
+ if (vendor == PCI_VENDOR_ID_NVIDIA) {
+ acpi_skip_timer_override = 1;
+ }
+ return 0;
+}
+
+void __init check_acpi_pci(void)
+{
+ int num,slot,func;
+
+ /* Assume the machine supports type 1. If not it will
+ always read and should not have any side effect. */
+
+ /* Poor man's PCI discovery */
+ for (num = 0; num 32; num++) {
+ for (slot = 0; slot 32; slot++) {
+ for (func = 0; func 8; func++) {
+ u32 class;
+ u32 vendor;
+ class = read_pci_config(num,slot,func,
+
Panic in 2.6.11-rc4
I see this panic when booting 2.6.11-rc4 (plus some of my own patches...but my modules have not loaded at the point of the crash). The system is a Shuttle system with the FB65 motherboard. CPU is 3.0Ghz P4 with 1MB cache and hyperthreading. HD is an 80GB SATA disk. NVIDIA card is installed (but I have not installed the NVIDIA drivers). The system boots the latest FC2 kernel (2.6.10-1-something) fine, and other FC2 kernels too. The system hangs trying to discover hardware when I try to boot a 2.6.9 kernel I compiled... Also, the system will not save it's BIOS settings. I'm not sure exactly what that indicates, other than potentially flaky hardware of some sort... Any ideas are welcome! Thanks, Ben Linux version 2.6.11-rc4 ([EMAIL PROTECTED]) (gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)5BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1fff (usable) BIOS-e820: 1fff - 1fff3000 (ACPI NVS) BIOS-e820: 1fff3000 - 2000 (ACPI data) BIOS-e820: fec0 - 0001 (reserved) 0MB HIGHMEM available. 511MB LOWMEM available. found SMP MP-table at 000f52c0 DMI 2.2 present. ACPI: PM-Timer IO Port: 0x408 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 20 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 15:4 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Built 1 zonelists Kernel command line: ro root=LABEL=/ console=ttyS0,38400 console=tty0 Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 3008.737 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 514532k/524224k available (2124k kernel code, 9052k reserved, 838k data, 232k init, 0k hi)Checking if this processor honours the WP bit even in supervisor mode... Ok. Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 (order: 0, 4096 bytes) monitor/mwait feature present. using mwait in idle threads. CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 1024K CPU: Physical Processor ID: 0 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU0: Intel P4/Xeon Extended MCE MSRs (12) available CPU0: Thermal monitoring enabled Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. CPU0: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 01 per-CPU timeslice cutoff: 2926.21 usecs. task migration cache decay timeout: 3 msecs. Booting processor 1/1 eip 3000 Initializing CPU#1 monitor/mwait feature present. CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 1024K CPU: Physical Processor ID: 0 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#1. CPU1: Intel P4/Xeon Extended MCE MSRs (12) available CPU1: Thermal monitoring enabled CPU1: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 01 Total of 2 processors activated (11960.32 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 pin1=2 pin2=-1 checking TSC synchronization across 2 CPUs: passed. Brought up 2 CPUs checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 293k freed NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfb460, last bus=3 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050125 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: Ignoring BAR0-3 of IDE controller :00:1f.2 PCI: Transparent bridge - :00:1e.0 ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 *5 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 7 *9 10 11 12 14 15) ACPI: PCI
Re: 2.6.11rc4: irq 5, nobody cared
Rogério Brito wrote: On Feb 20 2005, Matthias-Christian Ott wrote: Rogério Brito wrote: I am willing to test any patch and configuration (let's call me a guinea pig), but I don't know what I should do. I have, OTOH, reported my problem many times in the past few days. :-( I will retry sending my message to the list once again, with the details (in my case, the message I get is irq 10: nobody cared! and it is regarding my primary HD on my secondary Promise PDC20265 controller). First of all, Matthias-Christian, thank you very much for your kind answer. I have already tried contacting the linux-ide mailing list as a CC to my earlier messages, but I got no response. I am including some details in this e-mail. I included Bartlomiej in the CC, as he is listed as general IDE maintainer in the MAINTAINERS file. Report it to http://bugzilla.kernel.org/. Maybe you'll get help there. Thanks. I will try filing a bug on that system as soon as I get the reply to create my account there. (...) You see it's very difficult to fix such irq problems because some factors can cause such an error. Yes, I understand that. Maybe contacting specific malinglists (e.g. for broken pci cards the pci mailinglist, etc.), maintainers or developers would be more efficient (cc the lkml) and solve your problem (faster), because this people are specialists are this type of hardware (e.g. pci). What hardware is connect through irq 5? In my case, my problem is not with irq 5, but with irq 10, as I mentioned earlier. The situation is this: I have an Asus A7V motherboard with 2 VIA vt82c686a controllers and 2 Promise PDC20265 controllers. I recently bought myself a new DVD recorder and since Alan Cox told me[*] that the Promise controllers had problems with ATAPI devices, I decided to arrange my system this way: /dev/hda: the DVD recorder (VIA controller, master) /dev/hdc: an old CD recorder (VIA controller, master) /dev/hde: my first HD (Promise controller, master) /dev/hdg: my second HD (Promise controller, master) The Promise controller is able to control the HDs (which now have exclusive 80-pin cables) at their maximum, but I get the following stack trace if I have /dev/hdg turned on: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ACPI: PCI interrupt :00:11.0[A] - GSI 10 (level, low) - IRQ 10 PDC20265: chipset revision 2 PDC20265: 100% native mode on irq 10 PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:pio, hdf:pio ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:pio, hdh:pio Probing IDE interface ide2... hde: QUANTUM FIREBALL CX13.0A, ATA DISK drive ide2 at 0x8800-0x8807,0x8402 on irq 10 Probing IDE interface ide3... hdg: QUANTUM FIREBALLlct15 30, ATA DISK drive irq 10: nobody cared! [c0128fc1] __report_bad_irq+0x31/0x77 [c012906b] note_interrupt+0x4c/0x71 [c0128c86] __do_IRQ+0x93/0xbd [c0104635] do_IRQ+0x19/0x24 [c010335a] common_interrupt+0x1a/0x20 [c011935c] __do_softirq+0x2c/0x7d [c01193cf] do_softirq+0x22/0x26 [c010463a] do_IRQ+0x1e/0x24 [c010335a] common_interrupt+0x1a/0x20 [c0128d89] enable_irq+0x88/0x8d [c021edc0] probe_hwif+0x2da/0x366 [c021a137] ata_attach+0xa3/0xbd [c021ee5c] probe_hwif_init_with_fixup+0x10/0x74 [c0221597] ide_setup_pci_device+0x72/0x7f [c0216f82] pdc202xx_init_one+0x15/0x18 [c039182e] ide_scan_pcidev+0x34/0x59 [c039186f] ide_scan_pcibus+0x1c/0x88 [c039179f] probe_for_hwifs+0xb/0xd [c03917e5] ide_init+0x44/0x59 [c037c6ce] do_initcalls+0x4b/0x99 [c0100272] init+0x0/0xce [c0100299] init+0x27/0xce [c0101245] kernel_thread_helper+0x5/0xb handlers: [c021c2a6] (ide_intr+0x0/0xee) Disabling IRQ #10 irq 10: nobody cared! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This is just an excerpt of the messages. I can provide much more details if I know what is relevant. I had already posted some old dmesg logs at my site http://www.ime.usp.br/~rbrito/ide-problem/, but this was before I got myself a second 80-ribbon cable (I expected that the problem would go away, but it didn't). Any other comments are more than welcome. Thanks in advance, Rogério Brito. [*] http://infocenter.guardiandigital.com/archive/linux-kernel/2004/Dec/2663.html Hi! I'm not IDE specialist, but what about operating systems? Did you try a Windows or BSD CD (try it with a Windows 2000/XP CD, if you have one, else burn a NetBSD or FreeBSD/DragonflyBSD CD -- this is important to see if it's a linux bug or acpi bug)? Anyway this is very strange. Good luck! Matthias-Christian Ott - 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/
proc path_walk glitch ?
HI !
I noticed a slight proc filesystem strangness in the 2.4.2X and 2.6.X
(atleast up to 2.6.8). Assuming that process 8655 exists and is running
long enough (ls -lR / or so)
cd /proc/8655
kill -9 8655
ls
/usr/bin/ls: .: Stale NFS file handle
open(., O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ESTALE (Stale NFS
file handle) from fs/namei.c - link_path_walk :
int fastcall link_path_walk(const char * name, struct nameidata *nd)
{
struct dentry *dentry;
struct inode *inode;
int err;
unsigned int lookup_flags = nd-flags;
while (*name=='/')
name++;
if (!*name)
goto return_reval;
...
return_reval:
/*
* We bypassed the ordinary revalidation routines.
* Check the cached dentry for staleness.
*/
dentry = nd-dentry;
if (dentry dentry-d_op dentry-d_op-d_revalidate) {
err = -ESTALE;
if (!dentry-d_op-d_revalidate(dentry, 0)) {
d_invalidate(dentry);
break;
}
}
Why does return_reval return -ESTALE instead of -ENOENT here - might need an
extra check on what filesystem this is working on ?
/usr/bin/ls: .: no such file or directory
would seem more meaningfull to me when I find it in a logfile.
thx !
hofrat
-
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: Panic in 2.6.11-rc4
Ben Greear wrote: I see this panic when booting 2.6.11-rc4 (plus some of my own patches...but my modules have not loaded at the point of the crash). Same things happens with a kernel built w/out any of my patches, by the way... Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - 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: Wake-on-LAN/PCI Linux support
Does Linux currently support Wake-on-LAN/PCI? I have a 3Com 3c905 TX-M NIC which supports wake-on-LAN and wake-on-PCI. On Windows XP, I have configured the system so that I can use ether-wake to wake up mysystem from standby/hibernation remotely through the network. (cut) However, when I shut down linux by using init 0, the system gets totally shut down, including the NIC. The switch port for the NIC shows the card is not mantaining the link and thus, ether-wake is totally useless. I found the following solution for the same problem: - use standard 3c59x driver from kernel sources (even for 3c90x cards) - load this driver as a kernel module - add the following entry in /etc/modules: cut 3c59x options=0x408 cut Wake-on-lan works properly now with 3com 905cx-tx-m card (3c905c) on my Debian 3.1 (unstable) and 2.6.10 kernel greetings Piotr (djv) Rzezniczak - 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/
6300ESB watchdog driver
Hi
I wrote earlier to the list[1] asking for a driver for the watchdog
included in the 6300ESB chipset. I got a 2.4 driver via private email
from Ross Biro which I've changed into what I hope resembles a 2.6
driver (which was done by looking a lot at the watchdog drivers already
in the 2.6 tree).
I've attached the result, and I'm hoping to get some feedback on the
coding as a first step. I can't actually test it on the hardware right
now as I won't have physical access until April. So my own tests have
been limited to compiles-without-warnings and
can-be-insmodded-in-other-machine-without-oops.
As I said, it's the first thing I've ever written, so I'm guessing it
has a few rough edges. Feedback welcome :-)
Re,
David
[1] http://marc.theaimsgroup.com/?l=linux-kernelm=110711079825794w=2
[2] http://marc.theaimsgroup.com/?l=linux-kernelm=110711973917746w=2
diff -Nur linux-2.6.10.orig/drivers/char/watchdog/i6300esb.c
linux-2.6.10/drivers/char/watchdog/i6300esb.c
--- linux-2.6.10.orig/drivers/char/watchdog/i6300esb.c 1970-01-01
01:00:00.0 +0100
+++ linux-2.6.10/drivers/char/watchdog/i6300esb.c 2005-02-07
23:27:08.0 +0100
@@ -0,0 +1,508 @@
+/*
+ * i6300esb 0.03: Watchdog timer driver for Intel 6300ESB chipset
+ *
+ * (c) Copyright 2004 Google Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * based on i810-tco.c which is
+ *
+ * (c) Copyright 2000 kernel concepts [EMAIL PROTECTED]
+ * developed for
+ * Jentro AG, Haar/Munich (Germany)
+ *
+ * which is in turn based on softdog.c by Alan Cox [EMAIL PROTECTED]
+ *
+ * The timer is implemented in the following I/O controller hubs:
+ * (See the intel documentation on http://developer.intel.com.)
+ * 6300ESB chip : document number 300641-003
+ *
+ * 2004YYZZ Ross Biro
+ * Initial version 0.01
+ * 2004YYZZ Ross Biro
+ * Version 0.02
+ * 20050210 David Härdeman [EMAIL PROTECTED]
+ * Ported driver to kernel 2.6
+ */
+
+/*
+ * Includes, defines, variables, module parameters, ...
+ */
+
+#include linux/module.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/fs.h
+#include linux/mm.h
+#include linux/miscdevice.h
+#include linux/watchdog.h
+#include linux/reboot.h
+#include linux/init.h
+#include linux/pci.h
+#include linux/ioport.h
+
+#include asm/uaccess.h
+#include asm/io.h
+
+#include i6300esb.h
+
+/* Module and version information */
+#define ESB_VERSION 0.03
+#define ESB_MODULE_NAME i6300ESB timer
+#define ESB_DRIVER_NAME ESB_MODULE_NAME , v ESB_VERSION
+#define PFX ESB_MODULE_NAME :
+
+/* internal variables */
+static void __iomem *BASEADDR;
+static spinlock_t esb_lock; /* Guards the hardware */
+static unsigned long timer_alive;
+static struct pci_dev *esb_pci;
+static unsigned short triggered; /* The status of the watchdog upon boot */
+static char esb_expect_close;
+
+/* module parameters */
+#define WATCHDOG_HEARTBEAT 30 /* 30 sec default heartbeat
(1heartbeat2*1023) */
+static int heartbeat = WATCHDOG_HEARTBEAT; /* in seconds */
+module_param(heartbeat, int, 0);
+MODULE_PARM_DESC(heartbeat, Watchdog heartbeat in seconds. (1heartbeat2046,
default= __MODULE_STRING(WATCHDOG_HEARTBEAT) ));
+
+#ifdef CONFIG_WATCHDOG_NOWAYOUT
+static int nowayout = 1;
+#else
+static int nowayout = 0;
+#endif
+module_param(nowayout, int, 0);
+MODULE_PARM_DESC(nowayout, Watchdog cannot be stopped once started
(default=CONFIG_WATCHDOG_NOWAYOUT));
+
+/*
+ * Some i6300ESB specific functions
+ */
+
+/*
+ * Prepare for reloading the timer by unlocking the proper registers.
+ * This is performed by first writing 0x80 followed by 0x86 to the
+ * reload register. After this the appropriate registers can be written
+ * to once before they need to be unlocked again.
+ */
+static inline void esb_unlock_registers(void) {
+writeb(ESB_UNLOCK1, ESB_RELOAD_REG);
+writeb(ESB_UNLOCK2, ESB_RELOAD_REG);
+}
+
+static void esb_timer_start(void)
+{
+ u8 val;
+
+ /* Enable or Enable + Lock? */
+ val = 0x02 | nowayout ? 0x01 : 0x00;
+
+pci_write_config_byte(esb_pci, ESB_LOCK_REG, val);
+}
+
+static int esb_timer_stop(void)
+{
+ u8 val;
+
+ spin_lock(esb_lock);
+ /* First, reset timers as suggested by the docs */
+ esb_unlock_registers();
+ writew(0x10, ESB_RELOAD_REG);
+ /* Then disable the WDT */
+ pci_write_config_byte(esb_pci, ESB_LOCK_REG, 0x0);
+ pci_read_config_byte(esb_pci, ESB_LOCK_REG, val);
+ spin_unlock(esb_lock);
+
+ /* Returns 0 if the timer was disabled, non-zero otherwise */
+ return (val 0x01);
+}
+
+static void esb_timer_keepalive(void)
+{
+
ASUS P2B-DS
Hi Vise People, GH1N2J3JKL - this helps, me to find answers - please keep line ASUS P2B-DS board seems NOT work very well with default kernel in FED Core 3. smp-kernel hangs booting at various stages. I am goig to try 2.6.10 today. non-smp-kernel boots fine. This is my first time I try to test with smp-kernels so I don't know what I could try. Could someone give me some directions what to test? If someone already know this is doomed motherboard might say so I wouldn't waste time with it. Thanks. Best Regards Kari Laine - 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/
[PATCH] /proc/kmalloc
I've been sitting on this for over a year now, kicking it out in the hopes that someone finds it useful. kernel.org was down when I was tidying this up so it's against 2.6.10 which is what I had handy. /proc/kmalloc allocation tracing This quick hack adds accounting for kmalloc/kfree callers. This can aid in tracking down memory leaks and large dynamic memory users. The stock version use ~280k of memory for hash tables and can track 32k active allocations. Here's some sample output from my laptop: total bytes allocated: 47118848 slack bytes allocated: 8717262 net bytes allocated:2825920 number of allocs:132796 number of frees: 122629 number of callers: 325 lost callers: 0 lost allocs: 0 unknown frees:0 totalslack net alloc/free caller 2457600 3/3 copy_thread+0x1ad 192 56 192 1/0 fbcon_startup+0xc9 32768032768 1/0 fbcon_startup+0x267 18720 9360 32 585/584 bit_cursor+0x1a1 81920 8192 1/0 sys_ioperm+0x6c 81920 8192 1/0 register_framebuffer+0x10b 5120 512 1/0 fb_alloc_cmap+0x42 5120 512 1/0 fb_alloc_cmap+0x55 8192 3192 8192 1/0 framebuffer_alloc+0x36 5120 512 1/0 fb_alloc_cmap+0x68 640 64 1/0 fb_add_videomode+0x52 10334976 45215520 80742/80742 soft_cursor+0x67 320 32 1/0 mtrr_file_add+0x8c 128 36 128 1/0 create_driver+0x20 168427520 212992 4112/4060 dup_task_struct+0x3d 15360012/12radeon_do_probe_i2c_edid+0x5f 672 336 67221/0 acpi_os_create_semaphore+0x17 32 32 32 1/0 acpi_os_create_lock+0xd 448 280 7/7 acpi_os_queue_for_execution+0x2a 2016 252 118463/26__request_region+0x20 768 480 76824/0 register_sysctl_table+0x24 328 32 1/0 radeon_agp_alloc+0x6b 128 52 128 1/0 radeon_agp_init+0x3f 224 56 224 7/0 radeon_addmap+0x2b 224 140 224 7/0 radeon_addmap+0x11f 4096 1792 4096 1/0 radeon_addbufs_agp+0x197 1024 896 102432/0 radeon_addbufs_agp+0x273 2880 720 172815/6 groups_alloc+0x35 32 280 1/1 radeon_ctxbitmap_next+0xfd 40960 4096 1/0 radeon_ctxbitmap_init+0x26 2048 732 2048 1/0 radeon_dma_setup+0x1a 32 16 32 1/0 radeon_addctx+0x77 7680 768 6/0 __create_workqueue+0x3b 32 20 32 1/0 radeon_setup+0x97 32 16 32 1/0 radeon_setup+0xd7 64 24 64 2/0 inter_module_register+0x1f 128 320 1/1 sock_kmalloc+0x3d 64 16 64 1/0 radeon_open_helper+0x51 5347584 2076992 1048576 3520/3264 alloc_skb+0x34 4160 1392 416028/0 param_sysfs_setup+0x4c 514304 2147840 1008/1008 pskb_expand_head+0x4c 32 22 32 1/0 radeon_setunique+0x73 32 15 32 1/0 radeon_setunique+0xca 160 24 160 2/0 radeon_realloc+0x21 576 360 19218/12radeon_vm_open+0x32 1920 192 1/0 radeon_stub_getminor+0xa4 19200 51600 112/112 acpi_ut_initialize_buffer+0x24 269344 111231 195008 5588/1890 acpi_ut_callocate+0x37 24416174610 761/761 acpi_ut_allocate+0x38 512 248 512 1/0 radeon_do_init_cp+0x2b 320 266 32010/0 net_sysctl_strdup+0x2a 64 40 64 2/0 use_module+0x8c ... Index: km/init/Kconfig === --- km.orig/init/Kconfig2004-12-24 13:35:24.0 -0800 +++ km/init/Kconfig 2005-02-20 10:51:49.0 -0800 @@ -287,6 +287,13 @@ config KALLSYMS_EXTRA_PASS reported. KALLSYMS_EXTRA_PASS is only a temporary workaround while you wait for kallsyms to be fixed. +config KMALLOC_ACCOUNTING + default n + bool Enabled accounting of kmalloc/kfree allocations if EMBEDDED + help + This option records kmalloc and kfree activity and reports it via + /proc/kmalloc. + config FUTEX bool Enable futex support if EMBEDDED default y Index: km/mm/slab.c === --- km.orig/mm/slab.c 2004-12-24 13:35:59.0 -0800 +++ km/mm/slab.c2005-02-20 10:50:15.0 -0800 @@ -2427,6 +2427,7 @@ EXPORT_SYMBOL(kmem_cache_alloc_node);
Re: Panic in 2.6.11-rc4
Ben Greear wrote: I see this panic when booting 2.6.11-rc4 (plus some of my own patches...but my modules have not loaded at the point of the crash). The system is a Shuttle system with the FB65 motherboard. CPU is 3.0Ghz P4 with 1MB cache and hyperthreading. HD is an 80GB SATA disk. NVIDIA card is installed (but I have not installed the NVIDIA drivers). The system boots the latest FC2 kernel (2.6.10-1-something) fine, and other FC2 kernels too. The system hangs trying to discover hardware when I try to boot a 2.6.9 kernel I compiled... Also, the system will not save it's BIOS settings. I'm not sure exactly what that indicates, other than potentially flaky hardware of some sort... Any ideas are welcome! Thanks, Ben Linux version 2.6.11-rc4 ([EMAIL PROTECTED]) (gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)5BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1fff (usable) BIOS-e820: 1fff - 1fff3000 (ACPI NVS) BIOS-e820: 1fff3000 - 2000 (ACPI data) BIOS-e820: fec0 - 0001 (reserved) 0MB HIGHMEM available. 511MB LOWMEM available. found SMP MP-table at 000f52c0 DMI 2.2 present. ACPI: PM-Timer IO Port: 0x408 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 20 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 15:4 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Built 1 zonelists Kernel command line: ro root=LABEL=/ console=ttyS0,38400 console=tty0 Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 3008.737 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 514532k/524224k available (2124k kernel code, 9052k reserved, 838k data, 232k init, 0k hi)Checking if this processor honours the WP bit even in supervisor mode... Ok. Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 (order: 0, 4096 bytes) monitor/mwait feature present. using mwait in idle threads. CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 1024K CPU: Physical Processor ID: 0 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU0: Intel P4/Xeon Extended MCE MSRs (12) available CPU0: Thermal monitoring enabled Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. CPU0: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 01 per-CPU timeslice cutoff: 2926.21 usecs. task migration cache decay timeout: 3 msecs. Booting processor 1/1 eip 3000 Initializing CPU#1 monitor/mwait feature present. CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 1024K CPU: Physical Processor ID: 0 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#1. CPU1: Intel P4/Xeon Extended MCE MSRs (12) available CPU1: Thermal monitoring enabled CPU1: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 01 Total of 2 processors activated (11960.32 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 pin1=2 pin2=-1 checking TSC synchronization across 2 CPUs: passed. Brought up 2 CPUs checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 293k freed NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfb460, last bus=3 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050125 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: Ignoring BAR0-3 of IDE controller :00:1f.2 PCI: Transparent bridge - :00:1e.0 ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 *5 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 7 *9 10
Re: proc path_walk glitch ?
Der Herr Hofrat wrote:
HI !
I noticed a slight proc filesystem strangness in the 2.4.2X and 2.6.X
(atleast up to 2.6.8). Assuming that process 8655 exists and is running
long enough (ls -lR / or so)
cd /proc/8655
kill -9 8655
ls
/usr/bin/ls: .: Stale NFS file handle
open(., O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ESTALE (Stale NFS file
handle) from fs/namei.c - link_path_walk :
int fastcall link_path_walk(const char * name, struct nameidata *nd)
{
struct dentry *dentry;
struct inode *inode;
int err;
unsigned int lookup_flags = nd-flags;
while (*name=='/')
name++;
if (!*name)
goto return_reval;
...
return_reval:
/*
* We bypassed the ordinary revalidation routines.
* Check the cached dentry for staleness.
*/
dentry = nd-dentry;
if (dentry dentry-d_op dentry-d_op-d_revalidate) {
err = -ESTALE;
if (!dentry-d_op-d_revalidate(dentry, 0)) {
d_invalidate(dentry);
break;
}
}
Why does return_reval return -ESTALE instead of -ENOENT here - might need an
extra check on what filesystem this is working on ?
/usr/bin/ls: .: no such file or directory
would seem more meaningfull to me when I find it in a logfile.
thx !
hofrat
-
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/
Does it happen in 2.6.10 or are you sing 2.6.8?
Matthias-Christian Ott
-
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: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI
On Sun, 20 Feb 2005, Linus Torvalds wrote: Russell, what do your eagle-eyes think of a patch like this? Steven, does this fix it without the need for any kernel command line (or any other patches, for that matter - ie revert all the transparency- changing ones)? Linus I tried the patch on my G40 with 1Gb RAM (previous thread about it is at http://marc.theaimsgroup.com/?t=11088915341r=1w=2), and it works great, PCI resources are now located at 0x4000 and no further tricks/patches are necessary. Re, David - 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/
[PATCH] typo in include/linux/compiler.h
small nitpick, __KERNEL__ is the inner ifdef. Signed-off-by: Olaf Hering [EMAIL PROTECTED] diff -purN linux-2.6.11-rc4.orig/include/linux/compiler.h linux-2.6.11-rc4-klibc/include/linux/compiler.h --- linux-2.6.11-rc4.orig/include/linux/compiler.h 2005-02-13 04:06:55.0 +0100 +++ linux-2.6.11-rc4-klibc/include/linux/compiler.h 2005-02-20 17:16:47.340324407 +0100 @@ -72,10 +72,10 @@ extern void __chk_io_ptr(void __iomem *) (typeof(ptr)) (__ptr + (off)); }) #endif -#endif /* __ASSEMBLY__ */ - #endif /* __KERNEL__ */ +#endif /* __ASSEMBLY__ */ + /* * Allow us to mark functions as 'deprecated' and have gcc emit a nice * warning for each use, in hopes of speeding the functions removal. - 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: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II
Perhaps node masks would be better and teaching the kernel to handle relative distances inside the masks transparently while migrating? Not sure how complicated this would be to implement though. Supporting interleaving on the new nodes may be also useful, that would need a policy argument at least too and masks. The worry I have about using node masks is that it is not as general as old_node,new_node mappings (or preferably, the original proposal I made of old_node_list, new_node_list). One can't differentiate between the I agree that the node arrays are better for this case. and the majority of the memory is shared, then we only need to make one system call and one page table scan. (We just migrate the shared object once.) So the time to do the page table scans disappears I don't like this because it makes it much more complicated to use for user space. And you can set separate policies for shared objects anyways. Yes, but only programs that care have to use the va_start and va_end. Programs who want to move everything can specify 0 and MAX_INT there and they are done. I still think it's fundamentally unclean and racy. External processes shouldn't mess with virtual addresses of other processes. -Andi But we are least at the level of agreeing that the new system call looks something like the following: migrate_pages(pid, count, old_list, new_list); right? For the external case probably yes. For internal (process does this on its own address space) it should be hooked into mbind() too. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc3-mm2: lockup in sys_timer_settime
When running a Posix conformance test (from posixtestsuite), the kernel
locks up with:
BUG: soft lockup detected on CPU#0
Pid: 1873, comm: 10-1.test
EIP: 0060:[c0126fda] CPU: 0
EIP is at sys_timer_settime+0xfa+0x1f0
EFLAGS: 0282 Not tainted (2.6.11-rc3-mm2)
EAX: 0282 EBX: 0001 ECX: EDX:
ESI: EDI: EBP: f17eafbc DS: 007b ES: 007b
CR0: 8005003b CR2: b7fac1f0 CR3: 311b3000 CR4: 06d0
in test conformance/interfaces/timer_create/10-1.c (attached).
It doesn't lockup with 2.6.11-rc4; I notice the rc3-mm2 has a lot of
Posix-timer related changes.
Hi Roland
The problem arises from code touching the union in alloc_posix_timer()
which makes firing go non-zero. When firing is checked in posix_cpu_timer_set()
it will be positive causing an infinite loop.
So either the below fix or preferably move the INIT_LIST_HEAD(x) from
alloc_posix_timer()
to somewhere later where it doesn't disturb the other union members.
Index: linux-2.6.10/kernel/posix-cpu-timers.c
===
--- linux-2.6.10.orig/kernel/posix-cpu-timers.c 2005-02-20 22:23:30.0
+0100
+++ linux-2.6.10/kernel/posix-cpu-timers.c 2005-02-20 22:27:03.0
+0100
@@ -323,6 +323,7 @@
INIT_LIST_HEAD(new_timer-it.cpu.entry);
new_timer-it.cpu.incr.sched = 0;
new_timer-it.cpu.expires.sched = 0;
+ new_timer-it.cpu.firing = 0;
read_lock(tasklist_lock);
if (CPUCLOCK_PERTHREAD(new_timer-it_clock)) {
-
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: [PATCH] /proc/kmalloc
On Sünndag 20 Februar 2005 21:47, Matt Mackall wrote:
I've been sitting on this for over a year now, kicking it out in the
hopes that someone finds it useful. kernel.org was down when I was
tidying this up so it's against 2.6.10 which is what I had handy.
/proc/kmalloc allocation tracing
Nice. I have done something similar for the buddy allocator but never
got around to sending it.
This quick hack adds accounting for kmalloc/kfree callers. This can
aid in tracking down memory leaks and large dynamic memory users. The
stock version use ~280k of memory for hash tables and can track 32k
active allocations.
Here's some sample output from my laptop:
total bytes allocated: 47118848
slack bytes allocated: 8717262
net bytes allocated:2825920
number of allocs:132796
number of frees: 122629
number of callers: 325
lost callers: 0
lost allocs: 0
unknown frees:0
totalslack net alloc/free caller
2457600 3/3 copy_thread+0x1ad
The format is not really easy to parse, it probably makes sense to
split the two parts into separate files. I also think that debugfs
would be a more appropriate place to put this in than procfs.
+void __kmalloc_account(const void *caller, const void *addr, int size, int
req)
+{
+ int i, hasha, hashc;
+ unsigned long flags;
+
+ spin_lock_irqsave(kma_lock, flags);
+ if(req = 0) /* kmalloc */
+ {
+ /* find callers slot */
+ hashc = kma_hash(caller, MAX_CALLER_TABLE);
+ for (i = 0; i MAX_CALLER_TABLE; i++) {
+ if (!kma_caller[hashc].caller ||
+ kma_caller[hashc].caller == caller)
+ break;
+ hashc = (hashc + 1) % MAX_CALLER_TABLE;
+ }
The housekeeping that is needed for the hash implementation is rather
complicated. The code that I wrote did a static allocation from inside
a macro, like
#define kmalloc(_size, _gfp) \
({ \
static struct kma_caller _caller \
__attribute__((section(.kmalloc.data))) = { \
.func = __FUNCTION__, \
.line = __LINE__, \
}; \
_caller.count++; \
_caller.size += (_size); \
__kmalloc((_size), (_gfp)); \
})
Then I could simply print out all allocations by walking through the
special linker section. OTOH, your implementation has the advantage
that it can directly match kmalloc/kfree pairs and that it does not
rely on special linker magic.
Arnd
pgp01ROXTHZ22.pgp
Description: signature
Re: proc path_walk glitch ?
Der Herr Hofrat [EMAIL PROTECTED] wrote: cd /proc/8655 kill -9 8655 ls /usr/bin/ls: .: Stale NFS file handle Seems to be fixed in 2.6.10-ac9 or earlier - 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: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II
Andi wrote: I still think it's fundamentally unclean and racy. External processes shouldn't mess with virtual addresses of other processes. It's not really messing with (changing) the virtual addresses of another process. It's messing with the physical placement. It's using the virtual addresses to help choose which pages to move. Do you have any better way to suggest, Andi, for a batch manager to relocate a job? The typical scenario, as Ray explained it to me, is thus. A lower priority job, after running a while, is displaced by a higher priority job that needs a large number of nodes. Later on enough nodes to run the lower priority job become available elsewhere. The lower priority job can either continue to wait for its original nodes to come free (after the high priority job finishes) or it can be relocated to the nodes available now. How would you recommend that the batch manager move that job to the nodes that can run it? The layout of allocated memory pages and tasks for that job must be preserved in order to keep the same performance. The migration method needs to scale to hundreds, or more, of nodes. (I'm starting to have visions of vma's having externally visible id's, in a per-task namespace.) -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 1.925.600.0401 - 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: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II
Do you have any better way to suggest, Andi, for a batch manager to relocate a job? The typical scenario, as Ray explained it to me, is - Give the shared libraries and any other files a suitable policy (by mapping them and applying mbind) - Then execute migrate_pages() for the anonymous pages with a suitable old node - new node mapping. How would you recommend that the batch manager move that job to the nodes that can run it? The layout of allocated memory pages and tasks for that job must be preserved in order to keep the same performance. The migration method needs to scale to hundreds, or more, of nodes. You have to walk to full node mapping for each array, but even with hundreds of nodes that should not be that costly (in the worst case you could create a small hash table for it in the kernel, but I'm not sure it's worth it) -Andi - 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: ASUS P2B-DS
Hi Vise People, GH1N2J3JKL - this helps, me to find answers - please keep line ASUS P2B-DS board seems NOT work very well with default kernel in FED Core 3. smp-kernel hangs booting at various stages. I am goig to try 2.6.10 today. non-smp-kernel boots fine. This is my first time I try to test with smp-kernels so I don't know what I could try. Could someone give me some directions what to test? If someone already know this is doomed motherboard might say so I wouldn't waste time with it. Thanks. P2B-DS is a great, robust mainboard. This mail is written on one, and we have some more in production. Never had any problems with them. Try deleting the OSS sound drivers under /lib/modules/*/kernel/sound/oss/ . While I don't run fedora, I had similar problems with SuSE 9.1 and 9.2. These boiled down to a problem with the el cheapo fm801 soundcard I plugged into the board. The default installation installed an OSS driver that is not SMP-safe. After removing the driver, the correct ALSA driver got selected and everything was fine. Hope this helps Tim - 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/
cifs connection loss hangs
Being a wireless user i experience the occasional connection loss due to walking out of range or something, recently after starting to use cifs mounts instead of smbfs, I've noticed that stuff tends to break if i lose connection. I first noticed this when my bootscript brought down the wireless before it umounted the cifs share, and it hung the shutdown. Recently i was copying some files over with a nautilus window open. I lost connection and the nautilus window the cp process froze. ps said that they were stuck in D (Uninterruptible Sleep). I read it's a kernel problem if something gets stuck in it. umounting the cifs filesystem didn't even wake up the process, I had to reboot (which didn't work right because something was stuck with a file open). Anyone got any ideas on how this could be fixed? Thanks -- Cameron Harris - 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/
Help - really messed up kernel
I am trying to install linux on a laptop that cannot boot from cdrom. I got a stripped-down kernel to boot from floppy, ran lspci to get the hardware information. I then reconfigured and rebuilt the kernel for the image. I built this kernel from stock 2.6.10 from www.kernel.org. This is the configuration file. I then installed it on a floppy disk with syslinux, then tried to boot it. boot: vmlinuz root=/dev/fd0 load_ramdisk=1 prompt_ramdisk=1 (my ramdisk is the next flooppy, this kernel is 1.3mb) Did not load the ramdisk. I got an error about unable to open root on NULL or device 22,6. Hmm. So, I ran rdev to set the kernel default root to /dev/fd0 and booted. Result: loaded the ramdisk, then complained about lack of a valid filesystem on /dev/fd0 Hmm. I've never seen anything like this before. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.10 # Sun Feb 20 14:07:04 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION= CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set CONFIG_M586=y # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_PPRO_FENCE=y CONFIG_X86_F00F_BUG=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_ALIGNMENT_16=y # CONFIG_HPET_TIMER is not set # CONFIG_SMP is not set CONFIG_PREEMPT=y # CONFIG_X86_UP_APIC is not set # CONFIG_X86_MCE is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y # CONFIG_REGPARM is not set # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_DEBUG is not set CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION=/dev/hda2 # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y # # APM (Advanced Power Management) BIOS Support # CONFIG_APM=y # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set # CONFIG_APM_CPU_IDLE is not set # CONFIG_APM_DISPLAY_BLANK is not set # CONFIG_APM_RTC_IS_GMT is not set # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y
Re: [RFC] pdirops: vfs patch
Alex Tomas wrote:
+static inline struct semaphore * lock_sem(struct inode *dir, struct qstr *name)
+{
+ if (IS_PDIROPS(dir)) {
+ struct super_block *sb;
+ /* name-hash expected to be already calculated */
+ sb = dir-i_sb;
+ BUG_ON(sb-s_pdirops_sems == NULL);
+ return sb-s_pdirops_sems + name-hash % sb-s_pdirops_size;
+ }
+ return dir-i_sem;
+}
+
+static inline void lock_dir(struct inode *dir, struct qstr *name)
+{
+ down(lock_sem(dir, name));
+}
+
@@ -1182,12 +1204,26 @@
/*
* p1 and p2 should be directories on the same fs.
*/
-struct dentry *lock_rename(struct dentry *p1, struct dentry *p2)
+struct dentry *lock_rename(struct dentry *p1, struct qstr *n1,
+struct dentry *p2, struct qstr *n2)
{
struct dentry *p;
if (p1 == p2) {
- down(p1-d_inode-i_sem);
+ if (IS_PDIROPS(p1-d_inode)) {
+ unsigned int h1, h2;
+ h1 = n1-hash % p1-d_inode-i_sb-s_pdirops_size;
+ h2 = n2-hash % p2-d_inode-i_sb-s_pdirops_size;
+ if (h1 h2) {
+lock_dir(p1-d_inode, n1);
+lock_dir(p2-d_inode, n2);
+ } else if (h1 h2) {
+lock_dir(p2-d_inode, n2);
+lock_dir(p1-d_inode, n1);
+ } else
+lock_dir(p1-d_inode, n1);
+ } else
+ down(p1-d_inode-i_sem);
return NULL;
}
@@ -1195,31 +1231,35 @@
for (p = p1; p-d_parent != p; p = p-d_parent) {
if (p-d_parent == p2) {
- down(p2-d_inode-i_sem);
- down(p1-d_inode-i_sem);
+ lock_dir(p2-d_inode, n2);
+ lock_dir(p1-d_inode, n1);
return p;
}
}
for (p = p2; p-d_parent != p; p = p-d_parent) {
if (p-d_parent == p1) {
- down(p1-d_inode-i_sem);
- down(p2-d_inode-i_sem);
+ lock_dir(p1-d_inode, n1);
+ lock_dir(p2-d_inode, n2);
return p;
}
}
- down(p1-d_inode-i_sem);
- down(p2-d_inode-i_sem);
+ lock_dir(p1-d_inode, n1);
+ lock_dir(p2-d_inode, n2);
return NULL;
}
With luck you have s_pdirops_size (or 1024) different renames altering
concurrently one directory inode. Therefore you need a lock protecting
your filesystem data. This is basically the job done by i_sem. So in my
opinion you only move The Problem from the VFS to the lowlevel
filesystems. But then there is no need for i_sem or your s_pdirops_sems
anymore.
Regards,
Jan
-
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: PROBLEM: agpgart-via: probe fails with error -22
On Sun, Feb 20, 2005 at 01:57:22PM -0500, Kenton Groombridge wrote: [1.] PROBLEM: agpgart-via: probe fails with error -22 [2.] When loading agpgart/agpgart-via the following occurs: Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected VIA KT400/KT400A/KT600 chipset agpgart: Maximum main memory to use for agp memory: 816M agpgart: unable to determine aperture size. agpgart: agp_backend_initialize() failed. agpgart-via: probe of :00:00.0 failed with error -22 Can you send me the output of (as root) lspci -xxx Also, is there a setting in your BIOS for 'aperture size' ? If so, what is it set to ? Dave - 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: [RFC] pdirops: vfs patch
Jan Blunck (JB) writes: JB With luck you have s_pdirops_size (or 1024) different renames altering JB concurrently one directory inode. Therefore you need a lock protecting JB your filesystem data. This is basically the job done by i_sem. So in JB my opinion you only move The Problem from the VFS to the lowlevel JB filesystems. But then there is no need for i_sem or your JB s_pdirops_sems anymore. 1) i_sem protects dcache too 2) tmpfs has no own data, so we can use it this way (see 2nd patch) 3) I have pdirops patch for ext3, but it needs some cleaning ... thanks, Alex - 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: Help - really messed up kernel
On Sun, 2005-02-20 at 15:22 -0800, Joshua Hudson wrote: I am trying to install linux on a laptop that cannot boot from cdrom. I handled this by putting smart-boot http://btmgr.webframe.org/ in the hard drive MBR from a dos floppy, smart-boot can boot from a cdrom. Then as long as you don't wipe out your MBR you can still boot from a cdrom. -- Brian Beattie LFS12947 | Honor isn't about making the right choices. [EMAIL PROTECTED] | It's about dealing with the consequences. www.beattie-home.net | -- Midori Koto - 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: Help - really messed up kernel
On Sun, 20 Feb 2005, Brian Beattie wrote: On Sun, 2005-02-20 at 15:22 -0800, Joshua Hudson wrote: I am trying to install linux on a laptop that cannot boot from cdrom. I handled this by putting smart-boot http://btmgr.webframe.org/ in the hard drive MBR from a dos floppy, smart-boot can boot from a cdrom. Then as long as you don't wipe out your MBR you can still boot from a cdrom. Ah yes, that crashes. Spotted it in Slackware 10 install CD, but it doesn't work on this system. Too bad. -- Brian Beattie LFS12947 | Honor isn't about making the right choices. [EMAIL PROTECTED] | It's about dealing with the consequences. www.beattie-home.net | -- Midori Koto - 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: Should kirqd work on HT?
Martin J. Bligh wrote: --Jeff Garzik [EMAIL PROTECTED] wrote (on Saturday, February 19, 2005 11:30:53 -0500): Pallipadi, Venkatesh wrote: You are right. Kernel balancer doesn't move around the irqs, unless it has too many interrupts. The logic is moving around interrupts all the time will not be good on caches. So, there is a threshold above which the balancer start moving things around. You should see them moving around if you do 'ping -f' or a big 'dd' from the disk. If kirqd is moving NIC interrupts, it's broken. (and another reason why irqbalanced is preferable) Why is it broken to move NIC interrupts? Obviously you don't want to rotate them around a lot, but in the interests of fairness to other processes, it seems reasonable to migrate them occasionally (IIRC, kirqd rate limits to once a second or something). This has been explained to you before, search your email archives... The main problem that has been seen in the field SMP packet ordering, but a secondary problem observed is cache misses. Just NAPI mitigates this somewhat (no pun intended). Overall, kirqd should be avoided except in special situations. It doesn't know about such policy things as network-specific or storage-specific irq balancing (and shouldn't). Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/net/smc-mca.c: cleanups
Adrian Bunk wrote:
This patch contains the following cleanups:
- make a needlessly global function static
- make three needlessly global structs static
Since after moving the now-static stucts to smc-mca.c the file smc-mca.h
was empty except for two #define's, I've also killed the rest of
smc-mca.h .
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/net/smc-mca.c | 60 +++--
drivers/net/smc-mca.h | 61 --
2 files changed, 58 insertions(+), 63 deletions(-)
--- linux-2.6.11-rc3-mm2-full/drivers/net/smc-mca.h 2004-12-24 22:35:23.0 +0100
+++ /dev/null 2004-11-25 03:16:25.0 +0100
@@ -1,61 +0,0 @@
-/*
- * djweis [EMAIL PROTECTED]
- * most of this file was taken from ps2esdi.h
- */
-
-struct {
- unsigned int base_addr;
-} addr_table[] = {
-{ 0x0800 },
-{ 0x1800 },
-{ 0x2800 },
-{ 0x3800 },
-{ 0x4800 },
-{ 0x5800 },
-{ 0x6800 },
-{ 0x7800 },
-{ 0x8800 },
-{ 0x9800 },
-{ 0xa800 },
-{ 0xb800 },
-{ 0xc800 },
-{ 0xd800 },
-{ 0xe800 },
-{ 0xf800 }
-};
-
-#define MEM_MASK 64
-
-struct {
- unsigned char mem_index;
- unsigned long mem_start;
- unsigned char num_pages;
-} mem_table[] = {
-{ 16, 0x0c, 40 },
-{ 18, 0x0c4000, 40 },
-{ 20, 0x0c8000, 40 },
-{ 22, 0x0cc000, 40 },
-{ 24, 0x0d, 40 },
-{ 26, 0x0d4000, 40 },
-{ 28, 0x0d8000, 40 },
-{ 30, 0x0dc000, 40 },
-{144, 0xfc, 40 },
-{148, 0xfc8000, 40 },
-{154, 0xfd, 40 },
-{156, 0xfd8000, 40 },
-{ 0, 0x0c, 20 },
-{ 1, 0x0c2000, 20 },
-{ 2, 0x0c4000, 20 },
-{ 3, 0x0c6000, 20 }
-};
-
-#define IRQ_MASK 243
-struct {
- unsigned char new_irq;
- unsigned char old_irq;
-} irq_table[] = {
- { 3, 3 },
- { 4, 4 },
- { 10, 10 },
- { 14, 15 }
-};
--- linux-2.6.11-rc3-mm2-full/drivers/net/smc-mca.c.old 2005-02-16 18:44:29.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/smc-mca.c 2005-02-16 18:47:24.0 +0100
@@ -49,7 +49,6 @@
#include asm/system.h
#include 8390.h
-#include smc-mca.h
#define DRV_NAME smc-mca
@@ -100,6 +99,63 @@
MODULE_PARM_DESC(ultra_io, SMC Ultra/EtherEZ MCA I/O base address(es));
MODULE_PARM_DESC(ultra_irq, SMC Ultra/EtherEZ MCA IRQ number(s));
+static struct {
+ unsigned int base_addr;
+} addr_table[] = {
+{ 0x0800 },
+{ 0x1800 },
+{ 0x2800 },
+{ 0x3800 },
+{ 0x4800 },
+{ 0x5800 },
+{ 0x6800 },
+{ 0x7800 },
+{ 0x8800 },
+{ 0x9800 },
+{ 0xa800 },
+{ 0xb800 },
+{ 0xc800 },
+{ 0xd800 },
+{ 0xe800 },
+{ 0xf800 }
+};
+
+#define MEM_MASK 64
+
+static struct {
+ unsigned char mem_index;
+ unsigned long mem_start;
+ unsigned char num_pages;
+} mem_table[] = {
+{ 16, 0x0c, 40 },
+{ 18, 0x0c4000, 40 },
+{ 20, 0x0c8000, 40 },
+{ 22, 0x0cc000, 40 },
+{ 24, 0x0d, 40 },
+{ 26, 0x0d4000, 40 },
+{ 28, 0x0d8000, 40 },
+{ 30, 0x0dc000, 40 },
+{144, 0xfc, 40 },
+{148, 0xfc8000, 40 },
+{154, 0xfd, 40 },
+{156, 0xfd8000, 40 },
+{ 0, 0x0c, 20 },
+{ 1, 0x0c2000, 20 },
+{ 2, 0x0c4000, 20 },
+{ 3, 0x0c6000, 20 }
+};
+
+#define IRQ_MASK 243
+static struct {
these tables should be const-ified
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/net/seeq8005.c: cleanups
this patch needlessly eats formfeeds - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/net/sb1000.c: make some variables static
this patch eats formfeeds - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/net/ne3210.c: cleanups
Adrian Bunk wrote: - if (ei_debug 0) - printk(version); I agree the version variable is outdated, but I disagree that the driver intro banner should be removed completely. Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/net/lp486e.c: make some code static
Adrian Bunk wrote:
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/net/lp486e.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
--- linux-2.6.11-rc3-mm2-full/drivers/net/lp486e.c.old 2005-02-16 16:08:34.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/lp486e.c 2005-02-16 16:15:33.0 +0100
@@ -112,8 +112,10 @@
CmdDiagnose = 7
};
-char *CUcmdnames[8] = { NOP, IASetup, Configure, MulticastList,
- Tx, TDR, Dump, Diagnose };
+#if 0
+static char *CUcmdnames[8] = { NOP, IASetup, Configure, MulticastList,
+ Tx, TDR, Dump, Diagnose };
+#endif
Need const.
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/net/appletalk/: make firmware static
Adrian Bunk wrote:
This patch makes some needlessly global firmware static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/net/appletalk/cops_ffdrv.h |2 +-
drivers/net/appletalk/cops_ltdrv.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.11-rc3-mm2-full/drivers/net/appletalk/cops_ffdrv.h.old 2005-02-16 15:15:32.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/appletalk/cops_ffdrv.h 2005-02-16 15:15:41.0 +0100
@@ -28,7 +28,7 @@
#ifdef CONFIG_COPS_DAYNA
-unsigned char ffdrv_code[] = {
+static unsigned char ffdrv_code[] = {
58,3,0,50,228,149,33,255,255,34,226,149,
249,17,40,152,33,202,154,183,237,82,77,68,
11,107,98,19,54,0,237,176,175,50,80,0,
--- linux-2.6.11-rc3-mm2-full/drivers/net/appletalk/cops_ltdrv.h.old 2005-02-16 15:15:50.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/appletalk/cops_ltdrv.h 2005-02-16 15:15:58.0 +0100
@@ -27,7 +27,7 @@
#ifdef CONFIG_COPS_TANGENT
-unsigned char ltdrv_code[] = {
+static unsigned char ltdrv_code[] = {
const
-
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: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II
- Give the shared libraries and any other files a suitable policy (by mapping them and applying mbind) Ah - I think you've said this before, and I'm being a bit retarded. You're saying that one could horse around with the physical placement of existing files mapped into another tasks space by mapping them into ones own space and using mbind, (once mbind is hooked up to page migration, to quote one of your earlier posts ;). Ok. How well does this work with a mapped file if the pages of that file have been placed (allocated on nodes) using some intricate first-touch pattern that is only encoded in some inscrutable initialization code of the application, and that is heavily fragmented, with few contiguous pages on the same node? It seems to me that you can't migrate such regions efficiently using the above explicit mbind'ing -- it could require a vma per page in the limit. And you can't migrate such regions using a migrate_pages() for all anonymous pages in a tasks space, because these aren't anon pages. Do you have in mind being able to tag such mapped files with an attribute that causes their pages to be migrated along with the anon pages on the migrate_pages() call? That might work ... How would you recommend that the batch manager move that job to the nodes that can run it? ... You have to walk to full node mapping for each array, but even with hundreds of nodes that should not be that costly I presume if you knew that the job only had pages on certain nodes, perhaps due to aggressive use of cpusets, that you would only have to walk those nodes, right? -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 1.925.600.0401 - 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: Bootsplash for 2.6.11-rc4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 20 Feb 2005, Michal Januszewski wrote: On Sun, Feb 20, 2005 at 12:25:19AM +0100, Pavel Machek wrote: How many distros do use some variant of bootsplash? SuSE does, from above url I guess gentoo does, too... Does RedHat do something similar? [Or do they just set log-level to very high giving them clean look?] What about Debian? As far as I know: SuSE uses bootsplash, Gentoo and PLD use fbsplash, RedHat uses rhgb (100% userspace solution, based on xvesa, doesn't provide graphical backgrounds on vt's - for that a kernel patch like bootsplash or fbsplash is necessary). I don't know about Debian - they probably have some (possibly unofficial) support for both bootsplash and fbsplash. Indeed, there is bootsplash and fbsplash for Debian, but only unofficial packages. Marcos Marado - -- /* *** */ Marcos Daniel Marado Torres AKA Mind Booster Noori http://student.dei.uc.pt/~marado - [EMAIL PROTECTED] () Join the ASCII ribbon campaign against html email, Microsoft /\ attachments and Software patents. They endanger the World. Sign a petition against patents: http://petition.eurolinux.org /* *** */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFCGUFmmNlq8m+oD34RAtbqAJ43WanT3YNwRy8bkUIbrIqCl8u1mgCggy6R 4jZqOJQoO3vCeBe/fE/WUhk= =CFlt -END PGP SIGNATURE- - 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: Panic in 2.6.11-rc4
Matthias-Christian Ott wrote: Hi! The first one is allocation error (linuxrc wants to get/read memory, but the allocation fails?). The other errors are _maybe_ caused by the first error (the scheduler schedules while a atomic operation is in progress). Is your Kernel configuration different to the configuration of the Fedora Kernel? If so: What did you change? Not a whole lot, I think. It's attached. It's strange that you can't change you Bios settings. Is the write protection jumper set to 1 (TRUE/ENABLED)? Is your Bios up2date? BIOS was up to date, and didn't notice any jumpers that I could play with. I was later able to boot this kernel on a similar machine with no problem, so I think that the problem might be some flaky hardware... Thanks, Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com # # Automatically generated make config: don't edit # Linux kernel version: 2.6.9 # Mon Nov 22 17:39:58 2004 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y # # General setup # CONFIG_LOCALVERSION= CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_HOTPLUG=y # CONFIG_IKCONFIG is not set CONFIG_EMBEDDED=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SHMEM=y # CONFIG_TINY_SHMEM is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # 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_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_SMP=y CONFIG_NR_CPUS=8 CONFIG_SCHED_SMT=y CONFIG_PREEMPT=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set CONFIG_X86_MCE_P4THERMAL=y CONFIG_TOSHIBA=m CONFIG_I8K=m CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # CONFIG_EDD=m # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y CONFIG_HIGHPTE=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_IRQBALANCE=y CONFIG_HAVE_DEC_LOCK=y CONFIG_REGPARM=y # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_DEBUG is not set CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION= # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y CONFIG_ACPI_ASUS=m CONFIG_ACPI_TOSHIBA=m CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y # # APM (Advanced Power Management) BIOS Support # CONFIG_APM=y # 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 is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y # CONFIG_CPU_FREQ_PROC_INTF is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y # CONFIG_CPU_FREQ_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_24_API is not set CONFIG_CPU_FREQ_TABLE=y # #
driver compile Parse error with gcc-3.4.3
Hi,
I am new to linux. I am trying to build one of my drivers for
2.6.9-5.EL, RHEL 4, I am getting compile parse errors as follows:
error: parse error before '(' token
#gcc -v
Configured with: ./configure --prefix=/usr/adaptec/build/gcc343-32bit
--enable-threads=posix --disable-checking --target=i386-redhat-linux
--host=i686-redhat-linux-gnu
--with-libs=/usr/adaptec/build/gcc343-32bit/lib
--with-headers=/usr/adaptec/build/gcc343-32bit/include
--enable-languages=c --disable-libunwind-exceptions --with-system-zlib
--enable-__cxa_atexit --enable-java-awt=gtk --enable-shared
--mandir=/usr/adaptec/build/gcc343-32bit/man
--infodir=/usr/adaptec/build/gcc343-32bit/info
Thread model: posix
gcc version 3.4.3
regards,
Anil
-
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: Help - really messed up kernel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joshua Hudson wrote: | I am trying to install linux on a laptop that cannot boot from cdrom. | I got a stripped-down kernel to boot from floppy, ran lspci to get | the hardware information. | | I then reconfigured and rebuilt the kernel for the image. | | I built this kernel from stock 2.6.10 from www.kernel.org. | This is the configuration file. I then installed it on a floppy disk | with syslinux, then tried to boot it. | | boot: vmlinuz root=/dev/fd0 load_ramdisk=1 prompt_ramdisk=1 | (my ramdisk is the next flooppy, this kernel is 1.3mb) | Did not load the ramdisk. | I got an error about unable to open root on NULL or device 22,6. | Hmm. So, I ran rdev to set the kernel default root to /dev/fd0 and booted. | | Result: loaded the ramdisk, then complained about lack of a valid | filesystem on /dev/fd0 you want to load your root filesystem into a ramdisk and use it from there. your kernel command line is wrong. it should have root=/dev/rd/0 or root=/dev/ram0 instead of root=/dev/fd0. after loading the initrd, your root filesystem is on a ramdisk. regards, pedro venda. - -- Pedro João Lopes Venda email: pjvenda at arrakis.dhis.org http://arrakis.dhis.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCGUajeRy7HWZxjWERAm2iAJ4yQIEXp8gB3ltotJ229PZhQUsCcwCgxXtI AHa+nWqajS299v+v09DoWCY= =cEN1 -END PGP SIGNATURE- - 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: [PATCH] /proc/kmalloc
Matt Mackall wrote: I've been sitting on this for over a year now, kicking it out in the hopes that someone finds it useful. kernel.org was down when I was tidying this up so it's against 2.6.10 which is what I had handy. /proc/kmalloc allocation tracing This quick hack adds accounting for kmalloc/kfree callers. This can aid in tracking down memory leaks and large dynamic memory users. The stock version use ~280k of memory for hash tables and can track 32k active allocations. One thing I've seen once that might be worth adding is the ability to mark generations and then ask what allocations exist from generation x?. So you do something like: echo 5 /proc/kmalloc_generation run some tests echo 6 /proc/kmalloc_generation Print all allocations from generation 5: echo 5 /proc/kmalloc_print_generations Now you get all buffers that were allocated in generation 5 and not released. Not all of these are leaks, but it's easier to wade through this list to see what is and what isn't a leak. Sometimes it's better to summarize all allocations according to the caller who asked for the allocation, it makes it easier to see if there is an undue increase from certain callers. Just some ideas. Baruch - 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: driver compile Parse error with gcc-3.4.3
Anil Kumar wrote:
Hi,
I am new to linux. I am trying to build one of my drivers for
2.6.9-5.EL, RHEL 4, I am getting compile parse errors as follows:
error: parse error before '(' token
Complete gcc output plus driver source file would help a lot.
#gcc -v
Configured with: ./configure --prefix=/usr/adaptec/build/gcc343-32bit
--enable-threads=posix --disable-checking --target=i386-redhat-linux
--host=i686-redhat-linux-gnu
--with-libs=/usr/adaptec/build/gcc343-32bit/lib
--with-headers=/usr/adaptec/build/gcc343-32bit/include
--enable-languages=c --disable-libunwind-exceptions --with-system-zlib
--enable-__cxa_atexit --enable-java-awt=gtk --enable-shared
--mandir=/usr/adaptec/build/gcc343-32bit/man
--infodir=/usr/adaptec/build/gcc343-32bit/info
Thread model: posix
gcc version 3.4.3
--
~Randy
-
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/
Merging fails reading /dev/uba1
Hi, Jens: I think this question belongs to your domain, but please let me know if I'm mistaken, so I can pursue this elsewhere. I encountered a strange performance anomaly. I do the following: - Plug USB key [EMAIL PROTECTED] ~]# time dd if=/dev/uba of=/dev/null bs=10k count=10240 10240+0 records in 10240+0 records out real0m22.731s user0m0.004s sys 0m0.345s [EMAIL PROTECTED] ~]# - Remove and replug the USB key [EMAIL PROTECTED] ~]# time dd if=/dev/uba1 of=/dev/null bs=10k count=10240 10240+0 records in 10240+0 records out real1m42.622s user0m0.005s sys 0m1.518s [EMAIL PROTECTED] ~]# So, reading from a partition of the same device is 5 times slower than reading from the device itself. The question is, why? To the best of my knowledge, this does not occur with SCSI (usb-storage and sd or sr). This hints strongly that the ub is not doing something right, but what that can be? The ub takes the request processing machinery from Carmel exactly. I am wondering if Carmel (sx8) exhibits any similar performance anomalies (cc-ing to Jeff) Additional information: [EMAIL PROTECTED] ~]# cat /proc/version Linux version 2.6.11-rc4-lem ([EMAIL PROTECTED]) (gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #1 Tue Feb 15 23:06:39 PST 2005 [EMAIL PROTECTED] ~]# cat /proc/partitions major minor #blocks name 3 0 39070080 hda 3 15935986 hda1 3 25936017 hda2 3 3 554242 hda3 3 4 1 hda4 3 5 26643771 hda5 180 01024000 uba 180 11023983 uba1 [EMAIL PROTECTED] ~]# 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: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II
Andi Kleen wrote: But we are least at the level of agreeing that the new system call looks something like the following: migrate_pages(pid, count, old_list, new_list); right? For the external case probably yes. For internal (process does this on its own address space) it should be hooked into mbind() too. -Andi That makes sense. I will agree to make that part work, too. as part of this. We will probably do the external case first, because we have need for that. -- Best Regards, Ray --- Ray Bryant 512-453-9679 (work) 512-507-7807 (cell) [EMAIL PROTECTED] [EMAIL PROTECTED] The box said: Requires Windows 98 or better, so I installed Linux. --- - 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: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]
On Sun, 2005-02-20 at 09:56 -0800, Linus Torvalds wrote: Steven, does this fix it without the need for any kernel command line (or any other patches, for that matter - ie revert all the transparency- changing ones)? Linus Hi Linus, I just tried it out (after removing all my crap) and yes it works. Thanks, -- Steve - 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/
[PATCH] Re: slab corruption on 2.6.10-rc4-bk7
Andrew Morton wrote:
Dave Jones [EMAIL PROTECTED] wrote:
(This has actually been there for a while, but I only
noticed it in dmesg this morning).
During boot on a dual em64t I see ..
scsi2 : ata_piix
isa bounce pool size: 16 pages
slab error in cache_free_debugcheck(): cache `size-2048': double free, or
memory outside object was overwritten
Call Trace:80163448{cache_free_debugcheck+392}
801646aa{kfree+234}
88065189{:libata:ata_pci_init_one+937}
801fe9ea{pci_bus_read_config_word+122}
880707f2{:ata_piix:piix_init_one+498}
80202926{pci_device_probe+134}
802691ad{driver_probe_device+77}
802692cb{driver_attach+75}
802696c9{bus_add_driver+169}
802025e3{pci_register_driver+131}
88074010{:ata_piix:piix_init+16}
80152c58{sys_init_module+344}
8010e52a{system_call+126}
81011e49f4a0: redzone 1: 0x5a2cf071, redzone 2: 0x5a2cf071.
It's plain to see how ata_pci_init_one() will free `probe_ent' twice. Jeff
wanna fix that up please? A naive fix would be
Here's the initial fix... about to test with some other fixes here.
Anybody who is seeing this wanna give it a try?
Jeff
= drivers/scsi/libata-core.c 1.116 vs edited =
--- 1.116/drivers/scsi/libata-core.c 2005-02-01 20:23:51 -05:00
+++ edited/drivers/scsi/libata-core.c 2005-02-20 23:25:52 -05:00
@@ -3751,8 +3751,8 @@
kfree(probe_ent2);
} else {
ata_device_add(probe_ent);
+ kfree(probe_ent);
}
- kfree(probe_ent);
return 0;
[PATCH #2] Re: slab corruption on 2.6.10-rc4-bk7
Actually, here's a better fix.
Jeff
= drivers/scsi/libata-core.c 1.116 vs edited =
--- 1.116/drivers/scsi/libata-core.c 2005-02-01 20:23:51 -05:00
+++ edited/drivers/scsi/libata-core.c 2005-02-20 23:34:32 -05:00
@@ -2800,7 +2800,7 @@
return 1;
/* fall through */
-
+
default:
return 0;
}
@@ -3743,16 +3743,13 @@
if (legacy_mode) {
if (legacy_mode (1 0))
ata_device_add(probe_ent);
- else
- kfree(probe_ent);
if (legacy_mode (1 1))
ata_device_add(probe_ent2);
- else
- kfree(probe_ent2);
- } else {
+ } else
ata_device_add(probe_ent);
- }
+
kfree(probe_ent);
+ kfree(probe_ent2);
return 0;
