Desparately wanted: intelfb modesetting in mainline
As a probable result of Intel opening specifications, it is now fairly easy to buy a business computer that will run Linux without loosing weeks hacking to get it up and running: just go with an intel graphic board since Intel X11 driver now works just fine. Well, this apply only if you run mainstream Linux, that is X11 for the graphics, because if your application relies on the framebuffer, we are still at far west time. Now that Linux is getting more professional with plenty of hackers paid to do so, it would be nice to include active minimal completeness of the system goal, as opposed to just passive filtering of preposed patches, because without it, small more inovative projects (that sit on top of the kernel instead of beeing kernel rated projects) have a hard time, so that Linux behaviour is not that different from closed one: favor the mainstream and ignore small players at the expense of inovation. Same applies for user land part of some drivers. The current situation is complete lack of consistency so that getting a working kernel (which nowdays means kernel + many user land helpers) get's more and more complicated year after year, as opposed to early days where user land was just achieving a fiew simple IOCTLs to configure. It is very understandable to reject many part of drivers to user land to avoid too much code (with nasty well known side effects) in the kernel, but just saying that since it is user land it does not have to follow any rule (such as beeing part of the kernel source and linking only to kernel source provided libraries) just means lot of work to distributions (so death of small ones that are not just a recent fork of a big one) -- 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/
scheduler policy question
Benchmarking Pliant (http://pliant.cx/) semaphores led to unexpectedly low results. The problem to either kernel bad features or bugs in my program since Pliant uses no glue library such as glibc: it calls directly kernel funtions. Not enough scheduling problem: - I traced the problem to the fact that when the semaphore is locked, I call sched_yield kernel function expecting that it will switch to another thread, whereas my results seem to mean that it does not. On the other hand, calling nanosleep kernel function with 0 as tv_sec and tv_nsec does exactly what I would have expected from sched_yield. Did I misunderstood sched_yield semantic ? So, sched_yield function seems to do nothing on my 2.2.15 UP box. On the other hand, on my 2.0.38 SMP box, it seems to work as expected (same as nanosleep 0) Too much scheduling problem: --- In order to restart a stopped thread (which sent a SIGSTOP signal to itself), I send a SIGCONT signal to the target thread using kill kernel function. The problem here is that it seems (also what I deduced from benchmarks) that the calling thread will be preempted immediatly. This is a big problem in the case I want to restart a set of threads at once (in case they are waiting for read access on a semaphore) and also a small one in the very general case since they is too much ping pong between the various threads dealing with the semaphore resulting in too much wasted time in the kernel scheduler. So my question is how can I restart another thread and continue running the current one until it's time slice ends ? Thanks, Hubert Tonneau - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.12-rc2
2.6.12-rc2 still does not boot properly on my box. Hubert Tonneau wrote: > > When switching from 2.6.11 to 2.6.12-rc1, > I get a 'cannot open root device' fatal error at end of kernel boot process. > Root device is 'hda1'. > > Hardware content of the box: > > 8086 Intel Corporation 334082855PM 0 > Host-Hub Interface Bridge > 8086 Intel Corporation 334182855PM 0 AGP > Bridge > 8086 Intel Corporation 24C282801DB/DBL/DBM B > USB UHCI Controller #1 > 8086 Intel Corporation 24C482801DB/DBL/DBM B > USB UHCI Controller #2 > 8086 Intel Corporation 24C782801DB/DBL/DBM B > USB UHCI Controller #3 > 8086 Intel Corporation 24CD82801DB/DBL/DBM B > USB EHCI Controller > 8086 Intel Corporation 244882801BAM/CAM/DBM0 > Hub Interface to PCI Bridge > 8086 Intel Corporation 24CC82801DBM0 LPC > Interface Bridge > 8086 Intel Corporation 24CA82801DBMB IDE > Controller (UltraATA/100) > 8086 Intel Corporation 24C582801DB/DBL/DBM B > AC97 Audio Controller > 8086 Intel Corporation 24C682801DB/DBM B AC97 > Modem Controller > 10DE NVIDIA Corporation 0324NV31B NVIDIA NV31GL > 14E4 Broadcom Corporation165DBCM5705MB > Broadcom NetXtreme Gigabit Ethernet > 104C Texas Instruments AC477510/4510 B Cardbus > 104C Texas Instruments AC4AB > 104C Texas Instruments 802BB > 104C Texas Instruments 82044610, 4515, 4610FM 0 > TI UltraMedia Firmware Loader Device > 8086 Intel Corporation 4220MPCI3B B Intel 2200 mPCI > 3B - RoW > > 2.6.11 kernel report: > > <4>Linux version 2.6.11 ([EMAIL PROTECTED]) (gcc version 3.3 (Debian)) #1 Sun > Mar 6 12:00:57 CET 2005 > <6>BIOS-provided physical RAM map: > <4> BIOS-e820: - 0009f000 (usable) > <4> BIOS-e820: 0009f000 - 000a (reserved) > <4> BIOS-e820: 0010 - 3ffae000 (usable) > <4> BIOS-e820: 3ffae000 - 4000 (reserved) > <4> BIOS-e820: feda - fee0 (reserved) > <4> BIOS-e820: ffb0 - 0001 (reserved) > <4>Warning only 896MB will be used. > <4>Use a HIGHMEM enabled kernel. > <5>896MB LOWMEM available. > <7>On node 0 totalpages: 229376 > <7> DMA zone: 4096 pages, LIFO batch:1 > <7> Normal zone: 225280 pages, LIFO batch:16 > <7> HighMem zone: 0 pages, LIFO batch:1 > <6>DMI 2.3 present. > <7>ACPI: RSDP (v000 DELL ) @ 0x000fdf00 > <7>ACPI: RSDT (v001 DELLCPi R 0x27d40903 ASL 0x0061) @ 0x3fff > <7>ACPI: FADT (v001 DELLCPi R 0x27d40903 ASL 0x0061) @ 0x3fff0400 > <7>ACPI: ASF! (v016 DELLCPi R 0x27d40903 ASL 0x0061) @ 0x3fff0800 > <7>ACPI: DSDT (v001 INT430 SYSFexxx 0x1001 MSFT 0x010e) @ 0x > <4>Allocating PCI resources starting at 4000 (gap: 4000:beda) > <4>Built 1 zonelists > <4>Kernel command line: BOOT_IMAGE=recover ro root=301 > <4>Local APIC disabled by BIOS -- you can enable it with "lapic" > <7>mapped APIC to d000 (01703000) > <6>Initializing CPU#0 > <4>PID hash table entries: 4096 (order: 12, 65536 bytes) > <4>Detected 1998.546 MHz processor. > <6>Using tsc for high-res timesource > <4>Console: colour VGA+ 80x25 > <4>Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) > <4>Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > <6>Memory: 906620k/917504k available (1598k kernel code, 10432k reserved, > 518k data, 140k init, 0k highmem) > <4>Checking if this processor honours the WP bit even in supervisor mode... > Ok. > <7>Calibrating delay loop... 3956.73 BogoMIPS (lpj=1978368) > <4>Mount-cache hash table entries: 512 (order: 0, 4096 bytes) > <7>CPU: After generic identify, caps: afe9f9bf > 0180 > <7>CPU: After vendor identify, caps: afe9f9bf > 0180 > <6>CPU: L1 I cache: 32K, L1 D cache: 32K > <6>CPU: L2 cache: 2048K > <7>CPU: After all in
2.6 upgrade overall failure report
I started to move production servers to kernel 2.6 a year ago, but the strange situation is that one year later, most of them are back to 2.4 This did not append with 2.0 -> 2.2 or 2.2 -> 2.4 upgrade. Here are the factual technical reasons: Right from the beginning, the core 2.6 kernel was rock solid for me, so I had no crash to complain, but ... . I reported a year ago that SCSI fusion was unable to properly recover from tiny errors under 2.6 as opposed to 2.4 ... and got hit by the same problem 6 monthes later . There is still a memory leak trouble (probably in tigon3 driver since others reported so on kernel mailing list, and tigon3 is not a geek hardware since most nowdays lowend servers use either tigon3 or pro1000) . There have been USB storage issues, also they are now solved . Since 2.6.10, the TCP task does not work anymore with OSX (2 Mbps instead of 60 Mbps on a 100 Mbps wire) Each time I get a problem with a kind of hardware, I move to what I find the most stable for it, until I'm sure the problem has been solved with up to date kernel, and the current result is that I have more and more servers back to 2.4 So, I could conclude with many others that the 2.6 development model is worse than the old one, but I don't think so. I think the problem to solve is handling the complexity, and it's a new issue, and neither the old development model nor the new one are suited at the moment because the change is more fondamental: you now have to deal with complexity versus stability. In real world, there are very fiew situations where top performances on the kernel side will change the situation. Most real life tasks are either easily handled by modern hardware, so even a naive 2.0 kernel would be fine, or too complex for the hardware, so the kernel cannot fill the gap; only new harware will do. On the other hand, selling people are very much interested in new features or better benchmarks because it's what will make their job easier. So, as a result of it's success, Linux kernel is focusing probably a bit more than necessary on high performances. This is even more true since most high profile developpers are now beeing given high end machines (Linus a PowerPC, kernel.org a quad opteron, etc). Now, what's wrong with that ? Well, the fact is that new hardware is only supported by latest kernel, so at the end, you have to upgrade, and so you get more and more complexity whether you like it or not. As an example, for servers, 2.4 is still fine, but laptops already require 2.6 As a result, the complexity versus stability compromise is less and less suited for most real life uses. Now the problem with the kernel complexity is: . ultimate implementation requires much more testing than simple good one (TCP sample) . it makes life harder for device drivers writers (tigon3 or fusion sample) So, back to Linux kernel development model, what is now flowed is to assume that the last development kernel will be the good candidate for the next stable one. It was true as long as the overall complexity was low; it's not any more. The second bad attitude is to not require a new device drivers to be included in the sable kernel (I'm assuming current stable is 2.4) before entering the development kernel because it will make upgrade mandatory sooner. So, basically, we need two trees, one conservative focusing on clean simple implementation (single kernel lock such as in 2.0, good basic algorithms, no more), and one focusing on top performances, with each driver beeing written first for the simple tree, then ported to the advanced one. Now, we can't say, ok there are Linux alternatives that are more conservative, so would fit my conservative kernel definition, because we also need concerted design between the two so that porting from conservative to top performance be as simple as possible, and even more important, so that running on conservative or top performance be transparent for applications. That's the second point where current model starts to fall short: we need planned changed in user land interface (/proc, ifconfig, etc) in both kernels because no change in stable kernel view from user land is probably also not a good idea because it will make it unusable at some point because applications that upgraded will not run fine on it anymore, and upgrading applications is mandatory also because of security issues; not talking about improvements that can also append in the core conservative kernel because finding the simplest implementation is not easy, so takes time. So, we end with: . two lines (conservative and high performance), . a set of patches in each line pending in the unstable queue . a set of patches in each line pending in the API change queue Now you understand why I post right now. If you are designing a patch handling tool, then it's time to think how to handle the all new picture to get back in sync with users. Now, on the other hand, if we remain with the current development mod
Re: 2.6.13-rt1
I gave this one a spin, and my laptop locked hard after something like one hour (everything frozen). As a result what I report is probably not very helpfull. It was the first time I was trying an RT kernel, and the stock kernel works ok on this laptop (except suspend, but one can do without it). CONFIG_1GB: y CONFIG_ACPI: y CONFIG_ACPI_AC: m CONFIG_ACPI_BATTERY: m CONFIG_ACPI_BUTTON: m CONFIG_ACPI_FAN: m CONFIG_ACPI_PROCESSOR: y CONFIG_ACPI_SLEEP: y CONFIG_ACPI_THERMAL: y CONFIG_ACPI_VIDEO: m CONFIG_ACT200L_DONGLE: m CONFIG_ACTISYS_DONGLE: m CONFIG_APM_RTC_IS_GMT: y CONFIG_ATALK: m CONFIG_AUTOFS_FS: m CONFIG_BINFMT_ELF: y CONFIG_BINFMT_MISC: y CONFIG_BLK_DEV_CMD640: y CONFIG_BLK_DEV_FD: m CONFIG_BLK_DEV_GENERIC: y CONFIG_BLK_DEV_IDE: y CONFIG_BLK_DEV_IDECD: m CONFIG_BLK_DEV_IDECS: m CONFIG_BLK_DEV_IDEDISK: y CONFIG_BLK_DEV_IDEDMA: y CONFIG_BLK_DEV_IDEDMA_PCI: y CONFIG_BLK_DEV_IDEPCI: y CONFIG_BLK_DEV_IDESCSI: m CONFIG_BLK_DEV_LOOP: m CONFIG_BLK_DEV_NBD: m CONFIG_BLK_DEV_PIIX: y CONFIG_BLK_DEV_RAM: m CONFIG_BLK_DEV_RZ1000: y CONFIG_BLK_DEV_SD: m CONFIG_BLK_DEV_SR: m CONFIG_BLK_DEV_TRIRON: y CONFIG_BSD_PROCESS_ACCT: y CONFIG_BT: m CONFIG_BT_BNEP: m CONFIG_BT_HCIBCM203X: m CONFIG_BT_HCIBFUSB: m CONFIG_BT_HCIBPA10X: m CONFIG_BT_HCIUART: m CONFIG_BT_HCIUSB: m CONFIG_BT_HCIVHCI: m CONFIG_BT_HIDP: m CONFIG_BT_L2CAP: m CONFIG_BT_RFCOMM: m CONFIG_BT_RFCOMM_TTY: y CONFIG_BT_SCO: m CONFIG_CARDBUS: y CONFIG_CHR_DEV_SG: m CONFIG_CODA_FS: m CONFIG_CPU_FREQ: y CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE: y CONFIG_CPU_FREQ_GOV_ONDEMAND: m CONFIG_CPU_FREQ_GOV_PERFORMANCE: m CONFIG_CPU_FREQ_GOV_POWERSAVE: m CONFIG_CPU_FREQ_GOV_USERSPACE: y CONFIG_CPU_FREQ_TABLE: y CONFIG_DONGLE: m CONFIG_DRM: m CONFIG_DRM_I810: m CONFIG_DRM_MGA: m CONFIG_DRM_R128: m CONFIG_DRM_RADEON: m CONFIG_DRM_SIS: m CONFIG_DUMMY_CONSOLE: y CONFIG_ESI_DONGLE: m CONFIG_EXPERIMENTAL: y CONFIG_EXT2_FS: y CONFIG_EXT3_FS: y CONFIG_EXT3_FS_XATTR: y CONFIG_FAT_FS: m CONFIG_FB: y CONFIG_FB_ATY: m CONFIG_FB_ATY128: m CONFIG_FB_I810: m CONFIG_FB_INTEL: m CONFIG_FB_MATROX: m CONFIG_FB_MODE_HELPER: y CONFIG_FB_NVIDIA: m CONFIG_FB_RADEON: m CONFIG_FB_RIVA: m CONFIG_FB_RIVA_I2C: y CONFIG_FB_VESA: y CONFIG_FILTER: y CONFIG_FRAMEBUFFER_CONSOLE: y CONFIG_GIRBIL_DONGLE: m CONFIG_HFSPLUS_FS: m CONFIG_HFS_FS: m CONFIG_HOTPLUG: y CONFIG_HPET_TIMER: y CONFIG_HPFS_FS: m CONFIG_IDE: y CONFIG_IDEDMA_AUTO: y CONFIG_IDEDMA_ONLYDISK: y CONFIG_IDEDMA_PCI_AUTO: y CONFIG_IDEPCI_SHARE_IRQ: y CONFIG_IDE_GENERIC: y CONFIG_IEEE1394: m CONFIG_IEEE1394_DV1394: m CONFIG_IEEE1394_OHCI1394: m CONFIG_IEEE1394_RAWIO: m CONFIG_IEEE1394_VIDEO1394: m CONFIG_INET: y CONFIG_INOTIFY: y CONFIG_INPUT: y CONFIG_INPUT_KEYBDEV: m CONFIG_INPUT_KEYBOARD: y CONFIG_INPUT_MOUSE: y CONFIG_INPUT_MOUSEDEV: m CONFIG_IP_ALIAS: y CONFIG_IP_ROUTE_VERBOSE: y CONFIG_IRCOMM: m CONFIG_IRDA: m CONFIG_IRDA_CACHE_LAST_LSAP: y CONFIG_IRDA_DEBUG: y CONFIG_IRDA_FAST_RR: y CONFIG_IRLAN: m CONFIG_IRPORT_SIR: m CONFIG_IRQBALANCE: y CONFIG_IRTTY_SIR: m CONFIG_ISA: y CONFIG_ISO9660_FS: m CONFIG_KCORE_ELF: y CONFIG_KEYBOARD_ATKBD: y CONFIG_LEGACY_PTYS: y CONFIG_LITELINK_DONGLE: m CONFIG_LOCKD: m CONFIG_M386: n CONFIG_M486: n CONFIG_M586: n CONFIG_M686: n CONFIG_MA600_DONGLE: m CONFIG_MAC_PARTITION: y CONFIG_MCP2120_DONGLE: m CONFIG_MODULES: y CONFIG_MODULE_UNLOAD: y CONFIG_MOUSE: m CONFIG_MOUSE_PS2: y CONFIG_MPENTIUMM: y CONFIG_MSDOS_FS: m CONFIG_MTRR: y CONFIG_NET: y CONFIG_NETDEVICES: y CONFIG_NET_ETHERNET: y CONFIG_NFSD: m CONFIG_NFS_FS: m CONFIG_NLS: y CONFIG_NLS_CODEPAGE_437: m CONFIG_NLS_CODEPAGE_850: m CONFIG_NLS_ISO8859_1: m CONFIG_NLS_UTF8: m CONFIG_NOHIGHMEM: y CONFIG_NTFS_FS: m CONFIG_OLD_BELKIN_DONGLE: m CONFIG_OOM_KILLER: y CONFIG_PACKET: y CONFIG_PARPORT: m CONFIG_PARPORT_PC: m CONFIG_PCCARD: y CONFIG_PCI: y CONFIG_PCI_BIOS: y CONFIG_PCI_GOANY: y CONFIG_PCI_OLD_PROC: y CONFIG_PCI_QUIRKS: y CONFIG_PCMCIA: y CONFIG_PIIX_TUNING: y CONFIG_PM: y CONFIG_PPP: m CONFIG_PPPOE: m CONFIG_PPP_ASYNC: m CONFIG_PPP_BSDCOMP: m CONFIG_PPP_DEFLATE: m CONFIG_PPP_FILTER: y CONFIG_PPP_SYNC_TTY: m CONFIG_PREEMPT: n CONFIG_PREEMPT_BKL: y CONFIG_PREEMPT_RT: y CONFIG_PREEMPT_VOLUNTARY: n CONFIG_PRINTER: m CONFIG_PRINTER_READBACK: y CONFIG_PROC_FS: y CONFIG_PSMOUSE: y CONFIG_QNX4FS_FS: m CONFIG_REGPARM: y CONFIG_RTC: y CONFIG_SCSI: m CONFIG_SCSI_MULTI_LUN: y CONFIG_SCSI_PROC_FS: y CONFIG_SERIAL: m CONFIG_SERIAL_8250: m CONFIG_SERIAL_8250_CS: m CONFIG_SHAPER: m CONFIG_SLIP: m CONFIG_SMB_FS: m CONFIG_SMC_IRCC_FIR: m CONFIG_SND: m CONFIG_SND_HDA_INTEL: m CONFIG_SND_INTEL8X0: m CONFIG_SND_INTEL8X0M: m CONFIG_SND_MIXER_OSS: m CONFIG_SND_PCM_OSS: m CONFIG_SND_RTCTIMER: m CONFIG_SND_SEQUENCER: m CONFIG_SND_SEQUENCER_OSS: y CONFIG_SND_SEQ_DUMMY: m CONFIG_SND_USB_AUDIO: m CONFIG_SOUND: m CONFIG_SOUND_ICH: m CONFIG_SUNRPC: m CONFIG_SYSCTL: y CONFIG_
2.6.12-rc1 IDE noboot
When switching from 2.6.11 to 2.6.12-rc1, I get a 'cannot open root device' fatal error at end of kernel boot process. Root device is 'hda1'. Hardware content of the box: 8086Intel Corporation 334082855PM 0 Host-Hub Interface Bridge 8086Intel Corporation 334182855PM 0 AGP Bridge 8086Intel Corporation 24C282801DB/DBL/DBM B USB UHCI Controller #1 8086Intel Corporation 24C482801DB/DBL/DBM B USB UHCI Controller #2 8086Intel Corporation 24C782801DB/DBL/DBM B USB UHCI Controller #3 8086Intel Corporation 24CD82801DB/DBL/DBM B USB EHCI Controller 8086Intel Corporation 244882801BAM/CAM/DBM0 Hub Interface to PCI Bridge 8086Intel Corporation 24CC82801DBM0 LPC Interface Bridge 8086Intel Corporation 24CA82801DBMB IDE Controller (UltraATA/100) 8086Intel Corporation 24C582801DB/DBL/DBM B AC97 Audio Controller 8086Intel Corporation 24C682801DB/DBM B AC97 Modem Controller 10DENVIDIA Corporation 0324NV31B NVIDIA NV31GL 14E4Broadcom Corporation165DBCM5705MB Broadcom NetXtreme Gigabit Ethernet 104CTexas Instruments AC477510/4510 B Cardbus 104CTexas Instruments AC4AB 104CTexas Instruments 802BB 104CTexas Instruments 82044610, 4515, 4610FM 0 TI UltraMedia Firmware Loader Device 8086Intel Corporation 4220MPCI3B B Intel 2200 mPCI 3B - RoW 2.6.11 kernel report: <4>Linux version 2.6.11 ([EMAIL PROTECTED]) (gcc version 3.3 (Debian)) #1 Sun Mar 6 12:00:57 CET 2005 <6>BIOS-provided physical RAM map: <4> BIOS-e820: - 0009f000 (usable) <4> BIOS-e820: 0009f000 - 000a (reserved) <4> BIOS-e820: 0010 - 3ffae000 (usable) <4> BIOS-e820: 3ffae000 - 4000 (reserved) <4> BIOS-e820: feda - fee0 (reserved) <4> BIOS-e820: ffb0 - 0001 (reserved) <4>Warning only 896MB will be used. <4>Use a HIGHMEM enabled kernel. <5>896MB LOWMEM available. <7>On node 0 totalpages: 229376 <7> DMA zone: 4096 pages, LIFO batch:1 <7> Normal zone: 225280 pages, LIFO batch:16 <7> HighMem zone: 0 pages, LIFO batch:1 <6>DMI 2.3 present. <7>ACPI: RSDP (v000 DELL ) @ 0x000fdf00 <7>ACPI: RSDT (v001 DELLCPi R 0x27d40903 ASL 0x0061) @ 0x3fff <7>ACPI: FADT (v001 DELLCPi R 0x27d40903 ASL 0x0061) @ 0x3fff0400 <7>ACPI: ASF! (v016 DELLCPi R 0x27d40903 ASL 0x0061) @ 0x3fff0800 <7>ACPI: DSDT (v001 INT430 SYSFexxx 0x1001 MSFT 0x010e) @ 0x <4>Allocating PCI resources starting at 4000 (gap: 4000:beda) <4>Built 1 zonelists <4>Kernel command line: BOOT_IMAGE=recover ro root=301 <4>Local APIC disabled by BIOS -- you can enable it with "lapic" <7>mapped APIC to d000 (01703000) <6>Initializing CPU#0 <4>PID hash table entries: 4096 (order: 12, 65536 bytes) <4>Detected 1998.546 MHz processor. <6>Using tsc for high-res timesource <4>Console: colour VGA+ 80x25 <4>Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) <4>Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) <6>Memory: 906620k/917504k available (1598k kernel code, 10432k reserved, 518k data, 140k init, 0k highmem) <4>Checking if this processor honours the WP bit even in supervisor mode... Ok. <7>Calibrating delay loop... 3956.73 BogoMIPS (lpj=1978368) <4>Mount-cache hash table entries: 512 (order: 0, 4096 bytes) <7>CPU: After generic identify, caps: afe9f9bf 0180 <7>CPU: After vendor identify, caps: afe9f9bf 0180 <6>CPU: L1 I cache: 32K, L1 D cache: 32K <6>CPU: L2 cache: 2048K <7>CPU: After all inits, caps: afe9f9bf 0040 0180 <6>Intel machine check architecture supported. <6>Intel machine check reporting enabled on CPU#0. <4>CPU: Intel(R) Pentium(R) M processor 2.00GHz stepping 06 <6>Enabling fast FPU save and restore... done. <6>Enabling unmasked SIMD FPU exception support... done. <6>Checking 'hlt' instruction... OK. <4>ACPI: setting ELCR to 0200 (from 0800) <6>NET: Registered protocol family 16 <6>PCI: PCI BIOS revision 2.10 entry at 0xfc96e, last bus=2 <6>PCI: Using configuration type 1 <6>mtrr: v2.0 (20020519) <6>ACPI: Subsystem revision 20050211 <6>ACPI: Interpreter enabled <6>ACPI: Using PIC for interrupt routing <6>ACPI: PCI Root Bridge [PCI0] (00:00) <4>PCI: Probing PCI hardware (bus 00) <6>PCI:
MPT fusion still unable to recover properly under 2.6, ok under 2.4
I have a Dell PowerEdge 2600 than run smoothly on Linux 2.6 for 6 monthes, then three days ago, it started to have tiny problems on the SCSI. Now the bug is that 2.6.9 is unable to recover from these tiny problems (it enters an infinit loop that locks all processes attempting to access disk) whereas 2.4.29 recovers nicely. I noticed exactly the same several monthes ago with older 2.6 and 2.4 kernels. Here is the kind of kernel messages in 2.4: <4>scsi : aborting command due to timeout : pid 1035770, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 42 d7 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79b0c00) <4>scsi : aborting command due to timeout : pid 1035771, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 44 17 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79b0e00) <4>scsi : aborting command due to timeout : pid 1035772, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 45 57 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79b1000) <4>scsi : aborting command due to timeout : pid 1035773, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 46 97 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79b1200) <4>scsi : aborting command due to timeout : pid 1035774, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 47 d7 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79b1400) <4>scsi : aborting command due to timeout : pid 1035775, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 49 17 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79b1600) <4>scsi : aborting command due to timeout : pid 1035776, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 4a 57 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79b1800) <4>scsi : aborting command due to timeout : pid 1035777, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 4b 97 00 01 48 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79b1a00) <4>scsi : aborting command due to timeout : pid 1035778, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 4c df 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79b1c00) <4>scsi : aborting command due to timeout : pid 1035779, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 4e 1f 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79b1e00) <4>scsi : aborting command due to timeout : pid 1035780, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 4f 5f 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79b2000) <4>scsi : aborting command due to timeout : pid 1035781, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 50 9f 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79b2200) <4>scsi : aborting command due to timeout : pid 1035782, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 51 df 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79b2400) <4>scsi : aborting command due to timeout : pid 1035783, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 53 1f 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79b2600) <4>scsi : aborting command due to timeout : pid 1035784, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 54 5f 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79b2800) <4>scsi : aborting command due to timeout : pid 1035785, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 55 9f 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79b2a00) <4>scsi : aborting command due to timeout : pid 1035786, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 56 df 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79b2c00) <4>scsi : aborting command due to timeout : pid 1035787, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 58 1f 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79b2e00) <4>scsi : aborting command due to timeout : pid 1035788, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 59 5f 00 01 48 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79bb000) <4>scsi : aborting command due to timeout : pid 1035789, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 5a a7 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79bb200) <4>scsi : aborting command due to timeout : pid 1035790, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 5b e7 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79bb400) <4>scsi : aborting command due to timeout : pid 1035791, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 5d 27 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79bb600) <4>scsi : aborting command due to timeout : pid 1035792, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 5e 67 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79bb800) <4>scsi : aborting command due to timeout : pid 1035793, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 5f a7 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79bba00) <4>scsi : aborting command due to timeout : pid 1035794, scsi0, channel 0, id 0, lun 0 0x2a 00 10 09 60 e7 00 01 40 00 <4>mptscsih: OldAbort scheduling ABORT SCSI IO (sc=f79bbc0
Memory leak report
I have a set of computers that seem to have memory leak under 2.6 kernels (2.6.9 and 2.6.10) The set of machines that suffer this memory leak are the ones using ICH5 SATA and Broadcom gigabit (tigon3) on PCI Express, as opposed to other machines with IDE and Intel gigabit. Both sets of machines use hyper threading. On all machines, the memory report below is after restarting all but init processes, so memory consumed by applications is less than 50 MB. /proc/meminfo just after booting: MemTotal: 906784 kB MemFree:859228 kB Buffers: 1852 kB Cached: 15624 kB SwapCached: 0 kB Active: 27600 kB Inactive:10640 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 906784 kB LowFree:859228 kB SwapTotal: 0 kB SwapFree:0 kB Dirty: 28 kB Writeback: 0 kB Mapped: 21492 kB Slab: 5640 kB CommitLimit:453392 kB Committed_AS:32532 kB PageTables: 80 kB VmallocTotal: 122804 kB VmallocUsed: 8160 kB VmallocChunk: 114416 kB /proc/meminfo after several days of intense activity (after restarting all user land processes except init): MemTotal: 906784 kB MemFree:438796 kB Buffers: 9304 kB Cached: 14088 kB SwapCached: 0 kB Active: 273772 kB Inactive: 179304 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 906784 kB LowFree:438796 kB SwapTotal: 0 kB SwapFree:0 kB Dirty: 40 kB Writeback: 0 kB Mapped: 39700 kB Slab:11256 kB CommitLimit:453392 kB Committed_AS:55308 kB PageTables:120 kB VmallocTotal: 122804 kB VmallocUsed: 8160 kB VmallocChunk: 114416 kB Hardware of boxes having memory leak problems: 8086Intel Corporation 2580915G/P/GV 0 Host Bridge / DRAM Controller 8086Intel Corporation 2581915G/P/GV, 925X/XE? 0 Host-PCI Express Bridge 8086Intel Corporation 258282915G B Graphics device 8086Intel Corporation 27820 8086Intel Corporation 266082801FB/FR/FW/FRW 0 PCI Express Port 1 8086Intel Corporation 266282801FB/FR/FW/FRW 0 PCI Express Port 2 8086Intel Corporation 265882801FB/FR/FW/FRW 15 USB UHCI Controller 8086Intel Corporation 265982801FB/FR/FW/FRW 16 USB UHCI Controller 8086Intel Corporation 265A82801FB/FR/FW/FRW 12 USB UHCI Controller 8086Intel Corporation 265B82801FB/FR/FW/FRW 17 USB UHCI Controller 8086Intel Corporation 265C82801FB/FR/FW/FRW 9 USB 2.0 EHCI Controller 8086Intel Corporation 244E82801BA/CA/DB/DBL/Ex/Fx/FRW, 6300ESB 0 Hub Interface to PCI Bridge 8086Intel Corporation 266E82801FB/FR/FW/FRW A AC '97 Audio Controller 8086Intel Corporation 264082801FB/FR 0 LPC Interface Bridge 8086Intel Corporation 266F10 8086Intel Corporation 265182801FB/FW 14 SATA Controller 8086Intel Corporation 266A82801FB/FR/FW/FRW A SMBus Controller 14E4Broadcom Corporation1677BCM5751 10 NetXtreme Gigabit Ethernet PCI Express Hardware of machines with no memory leak problems: 8086Intel Corporation 257082865G/PE/P, 82848P 0 DRAM Controller / Host-Hub Interface 8086Intel Corporation 257282865G B Integrated Graphics Device 8086Intel Corporation 24D282801EB/ER B USB UHCI Controller #1 8086Intel Corporation 24D782801EB/ER A USB UHCI Controller #3 8086Intel Corporation 24DE82801EB/ER B USB UHCI Controller #4 8086Intel Corporation 24DD82801EB/ER 9 USB EHCI Controller 8086Intel Corporation 244E82801BA/CA/DB, 6300ESB 0 Hub Interface to PCI Bridge 8086Intel Corporation 24D082801EB/ER 0 LPC Interface Bridge 8086Intel Corporation 24DB82801EB/ER 12 EIDE Controller 8086Intel Corporation 24D382801EB/ER 5 SMBus Controller 8086Intel Corporation 24D582801EB/ER 5 AC'97 Audio Controller 8086Intel Corporation 100E82540EM 12 Gigabit Ethernet Controller - 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-i
Re: Network slowdown due to CFS
Ingo Molnar wrote: > > Really, i have never seen a _single_ mainstream app where the use of > sched_yield() was the right choice. Pliant 'FastSem' semaphore implementation (as oppsed to 'Sem') uses 'yield' http://old.fullpliant.org/ Basically, if the ressource you are protecting with the semaphore will be held for a significant time, then a full semaphore might be better, but if the ressource will be held just a fiew cycles, then light aquiering might bring best result because the most significant cost is in aquiering/releasing. So the aquiering algorithm for fast semaphores might be: try to aquire with a hardware atomic read and set instruction, then if it fails, call yield then retry (at least on a single processor single core system). - 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/
