Re: [ck] Re: Linus 2.6.23-rc1
On Fri, 27 Jul 2007, Linus Torvalds wrote: On Sat, 28 Jul 2007, Kasper Sandberg wrote: Im still not so keen about this, Ingo never did get CFS to match SD in smoothness for 3d applications, where my test subjects are quake(s), world of warcraft via wine, unreal tournament 2004. And this is despite many patches he sent me to try and tweak it. You realize that different people get different behaviour, don't you? Maybe not. People who think SD was "perfect" were simply ignoring reality. Sadly, that seemed to include Con too, which was one of the main reasons that I never ended entertaining the notion of merging SD for very long at all: Con ended up arguing against people who reported problems, rather than trying to work with them. I don't really want to keep all that -ck flamewar going but this sum-up is a little strange for me: If Con was thinking SD was "perfect" why he released 30+ versions of it? And who knows how many versions of his previous scheduler? Besides Con always tried to help people and improve his code if some bugs or problems were reported. Archives of this list prove that. I reported several problems (on list and privately) and all were fixed very fast and with very kind responses. I had run -ck for months and years and it was always very stable (I remember one broken "stable" version). I don't know what exactly are you refering to when you say about those unaddressed reports but maybe it depends on who was asking, how and to do what (for example - purely theoretical one, I don't remember exact emails you refering to so I am not saying it happened - stating at the beginning that the whole design is unacceptable and interactivity hacks are a must-have won't make a friend from any maintainer and for sure lowers his desire to get anything fixed for that guy). Or maybe Con had some bad day or was depressed. Happens. But I really don't remember Con ignoring too many valuable user reports in last 3 years... And no - I am not thinking that SD was "perfect". Nothing is perfect, especially not software. But it was based on months and years of Con's experience with desktop and gaming workloads and extensively tested in similar uses by _many_ others. In nearly all possible desktop configurations, with most games and all video drivers. This is why it was perfectly designed and tuned for such workloads while still being general enough and without any ugly hacks. And because of these tests and Con's believe that the desktop is very (most?) important all bugs and problems in this area were probably killed long ago. I think even design was changed and tuned a little at the early stages to help solve such interactivity/dekstop/gaming problems. So it does not surprise me that CFS is worse in such workloads (at least for some people) because I strongly suspect that the number of people who played games with current version of CFS is limited to about 5, maybe 10. And I also suspect that you (and Ingo) will get many regression reports when 2.6.23 is released (and months later too... or maybe you won't because users will be to "scared" to report such hard to mensure and reproduce "unimportant" bugs). Hopefully such problems when reported will be addressed as soon as they can. And hopefully they will be easy enough to solve without rewriting or redesigning CFS and causing that way even more regressions in other areas. If not people will probably be patching O(1) scheduler back privately... Thanks, Grzegorz Kulewski - 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: [ck] Re: Linus 2.6.23-rc1
On Fri, 27 Jul 2007, Linus Torvalds wrote: On Sat, 28 Jul 2007, Kasper Sandberg wrote: Im still not so keen about this, Ingo never did get CFS to match SD in smoothness for 3d applications, where my test subjects are quake(s), world of warcraft via wine, unreal tournament 2004. And this is despite many patches he sent me to try and tweak it. You realize that different people get different behaviour, don't you? Maybe not. People who think SD was perfect were simply ignoring reality. Sadly, that seemed to include Con too, which was one of the main reasons that I never ended entertaining the notion of merging SD for very long at all: Con ended up arguing against people who reported problems, rather than trying to work with them. I don't really want to keep all that -ck flamewar going but this sum-up is a little strange for me: If Con was thinking SD was perfect why he released 30+ versions of it? And who knows how many versions of his previous scheduler? Besides Con always tried to help people and improve his code if some bugs or problems were reported. Archives of this list prove that. I reported several problems (on list and privately) and all were fixed very fast and with very kind responses. I had run -ck for months and years and it was always very stable (I remember one broken stable version). I don't know what exactly are you refering to when you say about those unaddressed reports but maybe it depends on who was asking, how and to do what (for example - purely theoretical one, I don't remember exact emails you refering to so I am not saying it happened - stating at the beginning that the whole design is unacceptable and interactivity hacks are a must-have won't make a friend from any maintainer and for sure lowers his desire to get anything fixed for that guy). Or maybe Con had some bad day or was depressed. Happens. But I really don't remember Con ignoring too many valuable user reports in last 3 years... And no - I am not thinking that SD was perfect. Nothing is perfect, especially not software. But it was based on months and years of Con's experience with desktop and gaming workloads and extensively tested in similar uses by _many_ others. In nearly all possible desktop configurations, with most games and all video drivers. This is why it was perfectly designed and tuned for such workloads while still being general enough and without any ugly hacks. And because of these tests and Con's believe that the desktop is very (most?) important all bugs and problems in this area were probably killed long ago. I think even design was changed and tuned a little at the early stages to help solve such interactivity/dekstop/gaming problems. So it does not surprise me that CFS is worse in such workloads (at least for some people) because I strongly suspect that the number of people who played games with current version of CFS is limited to about 5, maybe 10. And I also suspect that you (and Ingo) will get many regression reports when 2.6.23 is released (and months later too... or maybe you won't because users will be to scared to report such hard to mensure and reproduce unimportant bugs). Hopefully such problems when reported will be addressed as soon as they can. And hopefully they will be easy enough to solve without rewriting or redesigning CFS and causing that way even more regressions in other areas. If not people will probably be patching O(1) scheduler back privately... Thanks, Grzegorz Kulewski - 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: [ck] Re: -mm merge plans for 2.6.23
On Tue, 10 Jul 2007, Andrew Morton wrote: On Wed, 11 Jul 2007 11:02:56 +1000 "Matthew Hawkins" <[EMAIL PROTECTED]> wrote: We all know swap prefetch has been tested out the wazoo since Moses was a little boy, is compile-time and runtime selectable, and gives an important and quantifiable performance increase to desktop systems. Always interested. Please provide us more details on your usage and testing of that code. Amount of memory, workload, observed results, etc? I am using swap prefetch in -ck kernels since it was introduced. My machine: Athlon XP 2000MHz, 1GB DDR 266, fast SATA disk, different swap configurations but usually heaps of swap (2GB and/or 8GB). My workload: desktop usage, KDE, software development, Firefox (HUGE memory hog), Eclipse and all that stuff (HUGE memory hog), sometimes other applications, sometimes some game such as Americas Army (that one will eat all your memory in any configuration), Konsole with heaps of tabs, usually some heavy compilations in the background. Observed result (of not broken swap prefetch versions): after closing some memory hog (for example stopping playing game and starting to write some code or reloading Firefox after it leaked enough memory to nearly bring the system down) the disk will work for some time and after that everything works as expected, no heavy swap-in when switching between applications and so on, nearly no lags in desktop usage. This is nearly unnoticable. Unless I have to run pure mainline. In that case I can notice that swap prefetch is off very quickly because after closing such memory hog and returning to some other application the system is slow for long time. Worse: after it starts to work reasonably and I try to switch to some other application or even try to use some dialog window or module of current application I have to wait, sometimes > 10s for it to swap back in (even if 70% of my RAM is free at that time, after memory hog is gone). It is painfull. I observed similar results on my laptop (Athlon 64, 512MB RAM, slow ATA disk, similar workload but reduced because hardware is weak). For me swap prefetch makes huge difference. The system lags a lot less in such circumstances. Personaly I think swap prefetch is a hack. Maybe not very dirty and ugly but still a hack. But since: * nobody proposed anything that can replace it and can be considered a no-hack, * swap prefetch is rather well tested and shouldn't cause regressions (no known regressions as far as I know, the patch does not look very invasive, was reviewed several times, ...), * Con said he won't make further -ck relases and won't port these patches to newer kernels, * there are at least several people who see the difference, * if somebody really hates it (s)he can turn it off I think it could get merged, at least temporarily, before somebody can suggest some better or extended solution. Personaly I would be very happy to see it in so people like me don't have to patch it in or (worse) port it (possibly causing bugs and filling additional bug reports and asking additional questions on these lists). I even wonder if adding the opposite of swap prefetch too wouldn't be even better for many workloads. Something like: "when system and swap-disk is idle try to copy some pages to swap so when system needs memory swap-out could be much cheaper". I suspect patch like that can reduce startup times (and other operations) of great memory hogs because disk (the slowest device) will only have to read the application and won't have to swap-out half of the RAM at the same time. I am happy to provide further info if needed. Thanks, Grzegorz Kulewski - 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: [ck] Re: -mm merge plans for 2.6.23
On Tue, 10 Jul 2007, Andrew Morton wrote: On Wed, 11 Jul 2007 11:02:56 +1000 Matthew Hawkins [EMAIL PROTECTED] wrote: We all know swap prefetch has been tested out the wazoo since Moses was a little boy, is compile-time and runtime selectable, and gives an important and quantifiable performance increase to desktop systems. Always interested. Please provide us more details on your usage and testing of that code. Amount of memory, workload, observed results, etc? I am using swap prefetch in -ck kernels since it was introduced. My machine: Athlon XP 2000MHz, 1GB DDR 266, fast SATA disk, different swap configurations but usually heaps of swap (2GB and/or 8GB). My workload: desktop usage, KDE, software development, Firefox (HUGE memory hog), Eclipse and all that stuff (HUGE memory hog), sometimes other applications, sometimes some game such as Americas Army (that one will eat all your memory in any configuration), Konsole with heaps of tabs, usually some heavy compilations in the background. Observed result (of not broken swap prefetch versions): after closing some memory hog (for example stopping playing game and starting to write some code or reloading Firefox after it leaked enough memory to nearly bring the system down) the disk will work for some time and after that everything works as expected, no heavy swap-in when switching between applications and so on, nearly no lags in desktop usage. This is nearly unnoticable. Unless I have to run pure mainline. In that case I can notice that swap prefetch is off very quickly because after closing such memory hog and returning to some other application the system is slow for long time. Worse: after it starts to work reasonably and I try to switch to some other application or even try to use some dialog window or module of current application I have to wait, sometimes 10s for it to swap back in (even if 70% of my RAM is free at that time, after memory hog is gone). It is painfull. I observed similar results on my laptop (Athlon 64, 512MB RAM, slow ATA disk, similar workload but reduced because hardware is weak). For me swap prefetch makes huge difference. The system lags a lot less in such circumstances. Personaly I think swap prefetch is a hack. Maybe not very dirty and ugly but still a hack. But since: * nobody proposed anything that can replace it and can be considered a no-hack, * swap prefetch is rather well tested and shouldn't cause regressions (no known regressions as far as I know, the patch does not look very invasive, was reviewed several times, ...), * Con said he won't make further -ck relases and won't port these patches to newer kernels, * there are at least several people who see the difference, * if somebody really hates it (s)he can turn it off I think it could get merged, at least temporarily, before somebody can suggest some better or extended solution. Personaly I would be very happy to see it in so people like me don't have to patch it in or (worse) port it (possibly causing bugs and filling additional bug reports and asking additional questions on these lists). I even wonder if adding the opposite of swap prefetch too wouldn't be even better for many workloads. Something like: when system and swap-disk is idle try to copy some pages to swap so when system needs memory swap-out could be much cheaper. I suspect patch like that can reduce startup times (and other operations) of great memory hogs because disk (the slowest device) will only have to read the application and won't have to swap-out half of the RAM at the same time. I am happy to provide further info if needed. Thanks, Grzegorz Kulewski - 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: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS
On Wed, 13 Jun 2007, Chris Mason wrote: But, I'm not planning on adding a way to say user X in subvolume Y has quota Z. I'll just be: this subvolume can't get bigger than a given size. (at least for version 1.0). I am affraid that this one is a major stopper for any production usage. Think about OpenVZ (or similar) VPSes. Of course having each VPS in own subvolume on the same device and being able to limit each subvolume is more than cool but on the other hand admin in VPS really needs to be able to set normal quotas for his users. Other than that your project looks really good and interesting. I also wonder if it is (would be) possible to set per-tree quotas like this: /a - 20GB /a/b - 10GB /a/b/c - 2GB /a/d - 5GB /e - 30GB meaning that whole subtree under /a is limited to 20GB, whole tree under /a/b is limited to both 20GB of /a and also by 10GB of /a/b, tree under /a/b/c is limited by 20GB of /a, 10GB of /a/b and 2GB of /a/b/c and so on? Or only /a and /e could be limited? Thanks, Grzegorz Kulewski - 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: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS
On Wed, 13 Jun 2007, Chris Mason wrote: But, I'm not planning on adding a way to say user X in subvolume Y has quota Z. I'll just be: this subvolume can't get bigger than a given size. (at least for version 1.0). I am affraid that this one is a major stopper for any production usage. Think about OpenVZ (or similar) VPSes. Of course having each VPS in own subvolume on the same device and being able to limit each subvolume is more than cool but on the other hand admin in VPS really needs to be able to set normal quotas for his users. Other than that your project looks really good and interesting. I also wonder if it is (would be) possible to set per-tree quotas like this: /a - 20GB /a/b - 10GB /a/b/c - 2GB /a/d - 5GB /e - 30GB meaning that whole subtree under /a is limited to 20GB, whole tree under /a/b is limited to both 20GB of /a and also by 10GB of /a/b, tree under /a/b/c is limited by 20GB of /a, 10GB of /a/b and 2GB of /a/b/c and so on? Or only /a and /e could be limited? Thanks, Grzegorz Kulewski - 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] Further update of the i386 boot documentation
On Thu, 17 May 2007, H. Peter Anvin wrote:
+Field name:kernel_version
+Type: read
+Offset/size: 0x20e/2
+Protocol: 2.00+
+
+ If set to a nonzero value, contains a pointer to a null-terminated
"nil-terminated"? "\0-terminated"?
Uh? That seems more than a little silly. Yes, I guess formally
speaking we're talking about "NUL-terminated", but the term
"null-terminated" has over 800,000 hits on Google -- 10 times as many as
"NUL-terminated" -- and is hardly an ambiguous term ("NUL-terminated" is
ugly, and "zero-terminated" is ambiguous.)
ASCIIZ?
Thanks,
Grzegorz Kulewski
-
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] Further update of the i386 boot documentation
On Thu, 17 May 2007, H. Peter Anvin wrote: +Field name:kernel_version +Type: read +Offset/size: 0x20e/2 +Protocol: 2.00+ + + If set to a nonzero value, contains a pointer to a null-terminated nil-terminated? \0-terminated? Uh? That seems more than a little silly. Yes, I guess formally speaking we're talking about NUL-terminated, but the term null-terminated has over 800,000 hits on Google -- 10 times as many as NUL-terminated -- and is hardly an ambiguous term (NUL-terminated is ugly, and zero-terminated is ambiguous.) ASCIIZ? Thanks, Grzegorz Kulewski - 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: libata_uli puts second channel to PIO4 on 2.6.18
On Wed, 7 Feb 2007, Tejun Heo wrote: Grzegorz Kulewski wrote: It worked very well for half a year but with one disk (IIRC it was even plugged into second channel but I wont bet on it). Now I have second disk (very similar) and it is always put into PIO4 mode: [ 17.404451] libata version 2.00 loaded. [ 17.404916] sata_uli :00:04.0: version 1.0 [ 17.405009] ACPI: PCI Interrupt :00:04.0[A] -> GSI 18 (level, low) -> IRQ 185 [ 17.405223] ata1: SATA max UDMA/133 cmd 0xD400 ctl 0xD002 bmdma 0xB000 irq 185 [ 17.405385] ata2: SATA max UDMA/133 cmd 0xB800 ctl 0xB402 bmdma 0xB008 irq 185 [ 17.405519] scsi2 : sata_uli [ 17.858803] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 17.880541] ata1.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32) [ 17.880660] ata1.00: ata1: dev 0 multi count 16 [ 17.58] ata1.00: configured for UDMA/133 [ 17.888941] scsi3 : sata_uli [ 18.342469] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 18.343573] ata2.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32) [ 18.343691] ata2.00: ata2: dev 0 multi count 16 [ 18.344972] ata2.00: configured for PIO4 Some uli controllers have simplex bit stuck high indicating that they can't perform DMA transfers simultaneously on both channels. In this case, libata configures the second channel as PIO only. This has been worked around by the following commit. commit b2a8bbe67d73631c71492fd60b757fc50a87f182 Author: Tejun Heo <[EMAIL PROTECTED]> Date: Thu Jan 25 19:40:05 2007 +0900 libata: implement ATA_FLAG_IGN_SIMPLEX and use it in sata_uli Some uli controllers have stuck SIMPLEX bit which can't be cleared with ata_pci_clear_simplex(), but the controller is capable of doing DMAs on both channels simultaneously. Implement ATA_FLAG_IGN_SIMPLEX which makes libata ignore the simplex bit and use it in sata_uli. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> For quick fix, just comment out lines which set ATA_HOST_SIMPLEX in drivers/scsi/libata-bmdma.c. e.g. /*if (inb(bmdma + 2) & 0x80) probe_ent->host_set_flags |= ATA_HOST_SIMPLEX;*/ Thanks! After this fix it is working ok. Any chance to see the proper fix in -stable kernels for at least 2.6.18.x and 2.6.19.x? Thanks, Grzegorz Kulewski - 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: libata_uli puts second channel to PIO4 on 2.6.18
On Wed, 7 Feb 2007, Tejun Heo wrote: Grzegorz Kulewski wrote: It worked very well for half a year but with one disk (IIRC it was even plugged into second channel but I wont bet on it). Now I have second disk (very similar) and it is always put into PIO4 mode: [ 17.404451] libata version 2.00 loaded. [ 17.404916] sata_uli :00:04.0: version 1.0 [ 17.405009] ACPI: PCI Interrupt :00:04.0[A] - GSI 18 (level, low) - IRQ 185 [ 17.405223] ata1: SATA max UDMA/133 cmd 0xD400 ctl 0xD002 bmdma 0xB000 irq 185 [ 17.405385] ata2: SATA max UDMA/133 cmd 0xB800 ctl 0xB402 bmdma 0xB008 irq 185 [ 17.405519] scsi2 : sata_uli [ 17.858803] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 17.880541] ata1.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32) [ 17.880660] ata1.00: ata1: dev 0 multi count 16 [ 17.58] ata1.00: configured for UDMA/133 [ 17.888941] scsi3 : sata_uli [ 18.342469] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 18.343573] ata2.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32) [ 18.343691] ata2.00: ata2: dev 0 multi count 16 [ 18.344972] ata2.00: configured for PIO4 Some uli controllers have simplex bit stuck high indicating that they can't perform DMA transfers simultaneously on both channels. In this case, libata configures the second channel as PIO only. This has been worked around by the following commit. commit b2a8bbe67d73631c71492fd60b757fc50a87f182 Author: Tejun Heo [EMAIL PROTECTED] Date: Thu Jan 25 19:40:05 2007 +0900 libata: implement ATA_FLAG_IGN_SIMPLEX and use it in sata_uli Some uli controllers have stuck SIMPLEX bit which can't be cleared with ata_pci_clear_simplex(), but the controller is capable of doing DMAs on both channels simultaneously. Implement ATA_FLAG_IGN_SIMPLEX which makes libata ignore the simplex bit and use it in sata_uli. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Signed-off-by: Jeff Garzik [EMAIL PROTECTED] For quick fix, just comment out lines which set ATA_HOST_SIMPLEX in drivers/scsi/libata-bmdma.c. e.g. /*if (inb(bmdma + 2) 0x80) probe_ent-host_set_flags |= ATA_HOST_SIMPLEX;*/ Thanks! After this fix it is working ok. Any chance to see the proper fix in -stable kernels for at least 2.6.18.x and 2.6.19.x? Thanks, Grzegorz Kulewski - 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/
Strange oops in iret_exc with my own module
when and how much I will get.) Any help on tracing this down would be appreciated. Thanks, Grzegorz Kulewski - 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/
Strange oops in iret_exc with my own module
for further info from the tester but I am not sure when and how much I will get.) Any help on tracing this down would be appreciated. Thanks, Grzegorz Kulewski - 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: libata_uli puts second channel to PIO4 on 2.6.18
Resending since I didn't receive any replies on this. Could somebody please tell me if this is planned? Is there some hardware bug that needs to be worked around this way? Is there some problem with the disk? Should changing controller (for example) to VIA based one help? Or is it some bug in the code? As you may realize this problem is very urgent for me because it blocks one of my important production servers. Thanks in advance, GK On Sat, 3 Feb 2007, Grzegorz Kulewski wrote: Hi, I got this SATA PCI card: 00:04.0 Mass storage controller: ALi Corporation ALi M5281 Serial ATA / RAID Host Controller (rev a4) (prog-if 85) Subsystem: ALi Corporation ALi M5281 Serial ATA / RAID Host Controller Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 128, Cache Line Size: 512 bytes Interrupt: pin A routed to IRQ 185 Region 0: I/O ports at d400 [size=8] Region 1: I/O ports at d000 [size=4] Region 2: I/O ports at b800 [size=8] Region 3: I/O ports at b400 [size=4] Region 4: I/O ports at b000 [size=16] [virtual] Expansion ROM at 8800 [disabled] [size=64K] 00:04.1 Mass storage controller: ALi Corporation M5228 ALi ATA/RAID Controller (rev c6) (prog-if 85) Subsystem: ALi Corporation Unknown device 5281 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 128 Interrupt: pin A routed to IRQ 9 Region 0: I/O ports at a800 [size=8] Region 1: I/O ports at a400 [size=4] Region 2: I/O ports at a000 [size=8] Region 3: I/O ports at 9800 [size=4] Region 4: I/O ports at 9400 [size=16] It worked very well for half a year but with one disk (IIRC it was even plugged into second channel but I wont bet on it). Now I have second disk (very similar) and it is always put into PIO4 mode: [ 17.404451] libata version 2.00 loaded. [ 17.404916] sata_uli :00:04.0: version 1.0 [ 17.405009] ACPI: PCI Interrupt :00:04.0[A] -> GSI 18 (level, low) -> IRQ 185 [ 17.405223] ata1: SATA max UDMA/133 cmd 0xD400 ctl 0xD002 bmdma 0xB000 irq 185 [ 17.405385] ata2: SATA max UDMA/133 cmd 0xB800 ctl 0xB402 bmdma 0xB008 irq 185 [ 17.405519] scsi2 : sata_uli [ 17.858803] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 17.880541] ata1.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32) [ 17.880660] ata1.00: ata1: dev 0 multi count 16 [ 17.58] ata1.00: configured for UDMA/133 [ 17.888941] scsi3 : sata_uli [ 18.342469] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 18.343573] ata2.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32) [ 18.343691] ata2.00: ata2: dev 0 multi count 16 [ 18.344972] ata2.00: configured for PIO4 [ 18.345466] Vendor: ATA Model: ST3250620NS Rev: 3.AE [ 18.346391] Type: Direct-Access ANSI SCSI revision: 05 [ 18.347464] Vendor: ATA Model: ST3250620NS Rev: 3.AE [ 18.348390] Type: Direct-Access ANSI SCSI revision: 05 [ 18.349457] SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) [ 18.350234] sda: Write Protect is off [ 18.350307] sda: Mode Sense: 00 3a 00 00 [ 18.351234] SCSI device sda: drive cache: write back [ 18.352233] SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) [ 18.352444] sda: Write Protect is off [ 18.352517] sda: Mode Sense: 00 3a 00 00 [ 18.353443] SCSI device sda: drive cache: write back [ 18.353522] sda: sda1 sda2 [ 18.371118] sd 2:0:0:0: Attached scsi disk sda [ 18.372221] SCSI device sdb: 488397168 512-byte hdwr sectors (250059 MB) [ 18.372431] sdb: Write Protect is off [ 18.372504] sdb: Mode Sense: 00 3a 00 00 [ 18.373440] SCSI device sdb: drive cache: write back [ 18.374430] SCSI device sdb: 488397168 512-byte hdwr sectors (250059 MB) [ 18.375218] sdb: Write Protect is off [ 18.375291] sdb: Mode Sense: 00 3a 00 00 [ 18.376216] SCSI device sdb: drive cache: write back [ 18.376295] sdb: unknown partition table [ 18.381481] sd 3:0:0:0: Attached scsi disk sdb As you probably know this gives very very poor performance. Is there any way to make it fast? I tried changing cables and reconnecting them but it looks like it does not help. I can't do too much with this hardware since it is used as production server. But testing some patches is of course possible. On the other hand full kernel upgrade to 2.6.19 or .20 is not possible because this kernel has openvz patches and I don't have them for .19 or .20 yet. This is what I am getting from various utilities: # dmesg [0.00] Linux version 2.6.18-028test010 ([EMAIL PROT
Re: libata_uli puts second channel to PIO4 on 2.6.18
Resending since I didn't receive any replies on this. Could somebody please tell me if this is planned? Is there some hardware bug that needs to be worked around this way? Is there some problem with the disk? Should changing controller (for example) to VIA based one help? Or is it some bug in the code? As you may realize this problem is very urgent for me because it blocks one of my important production servers. Thanks in advance, GK On Sat, 3 Feb 2007, Grzegorz Kulewski wrote: Hi, I got this SATA PCI card: 00:04.0 Mass storage controller: ALi Corporation ALi M5281 Serial ATA / RAID Host Controller (rev a4) (prog-if 85) Subsystem: ALi Corporation ALi M5281 Serial ATA / RAID Host Controller 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: 128, Cache Line Size: 512 bytes Interrupt: pin A routed to IRQ 185 Region 0: I/O ports at d400 [size=8] Region 1: I/O ports at d000 [size=4] Region 2: I/O ports at b800 [size=8] Region 3: I/O ports at b400 [size=4] Region 4: I/O ports at b000 [size=16] [virtual] Expansion ROM at 8800 [disabled] [size=64K] 00:04.1 Mass storage controller: ALi Corporation M5228 ALi ATA/RAID Controller (rev c6) (prog-if 85) Subsystem: ALi Corporation Unknown device 5281 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: 128 Interrupt: pin A routed to IRQ 9 Region 0: I/O ports at a800 [size=8] Region 1: I/O ports at a400 [size=4] Region 2: I/O ports at a000 [size=8] Region 3: I/O ports at 9800 [size=4] Region 4: I/O ports at 9400 [size=16] It worked very well for half a year but with one disk (IIRC it was even plugged into second channel but I wont bet on it). Now I have second disk (very similar) and it is always put into PIO4 mode: [ 17.404451] libata version 2.00 loaded. [ 17.404916] sata_uli :00:04.0: version 1.0 [ 17.405009] ACPI: PCI Interrupt :00:04.0[A] - GSI 18 (level, low) - IRQ 185 [ 17.405223] ata1: SATA max UDMA/133 cmd 0xD400 ctl 0xD002 bmdma 0xB000 irq 185 [ 17.405385] ata2: SATA max UDMA/133 cmd 0xB800 ctl 0xB402 bmdma 0xB008 irq 185 [ 17.405519] scsi2 : sata_uli [ 17.858803] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 17.880541] ata1.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32) [ 17.880660] ata1.00: ata1: dev 0 multi count 16 [ 17.58] ata1.00: configured for UDMA/133 [ 17.888941] scsi3 : sata_uli [ 18.342469] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 18.343573] ata2.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32) [ 18.343691] ata2.00: ata2: dev 0 multi count 16 [ 18.344972] ata2.00: configured for PIO4 [ 18.345466] Vendor: ATA Model: ST3250620NS Rev: 3.AE [ 18.346391] Type: Direct-Access ANSI SCSI revision: 05 [ 18.347464] Vendor: ATA Model: ST3250620NS Rev: 3.AE [ 18.348390] Type: Direct-Access ANSI SCSI revision: 05 [ 18.349457] SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) [ 18.350234] sda: Write Protect is off [ 18.350307] sda: Mode Sense: 00 3a 00 00 [ 18.351234] SCSI device sda: drive cache: write back [ 18.352233] SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) [ 18.352444] sda: Write Protect is off [ 18.352517] sda: Mode Sense: 00 3a 00 00 [ 18.353443] SCSI device sda: drive cache: write back [ 18.353522] sda: sda1 sda2 [ 18.371118] sd 2:0:0:0: Attached scsi disk sda [ 18.372221] SCSI device sdb: 488397168 512-byte hdwr sectors (250059 MB) [ 18.372431] sdb: Write Protect is off [ 18.372504] sdb: Mode Sense: 00 3a 00 00 [ 18.373440] SCSI device sdb: drive cache: write back [ 18.374430] SCSI device sdb: 488397168 512-byte hdwr sectors (250059 MB) [ 18.375218] sdb: Write Protect is off [ 18.375291] sdb: Mode Sense: 00 3a 00 00 [ 18.376216] SCSI device sdb: drive cache: write back [ 18.376295] sdb: unknown partition table [ 18.381481] sd 3:0:0:0: Attached scsi disk sdb As you probably know this gives very very poor performance. Is there any way to make it fast? I tried changing cables and reconnecting them but it looks like it does not help. I can't do too much with this hardware since it is used as production server. But testing some patches is of course possible. On the other hand full kernel upgrade to 2.6.19 or .20 is not possible because this kernel has openvz patches and I don't have them for .19 or .20 yet. This is what I am getting from various utilities: # dmesg [0.00] Linux version 2.6.18
libata_uli puts second channel to PIO4 on 2.6.18
tine recommended polling time:( 1) minutes. Extended self-test routine recommended polling time:( 92) minutes. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 112 100 006Pre-fail Always - 49974568 3 Spin_Up_Time0x0003 096 095 000Pre-fail Always - 0 4 Start_Stop_Count0x0032 100 100 020Old_age Always - 6 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 063 060 030Pre-fail Always - 2188910 9 Power_On_Hours 0x0032 100 100 000Old_age Always - 24 10 Spin_Retry_Count0x0013 100 100 097Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020Old_age Always - 22 187 Unknown_Attribute 0x0032 100 100 000Old_age Always - 0 189 Unknown_Attribute 0x003a 100 100 000Old_age Always - 0 190 Unknown_Attribute 0x0022 056 051 045Old_age Always - 757858348 194 Temperature_Celsius 0x0022 044 049 000Old_age Always - 44 (Lifetime Min/Max 0/33) 195 Hardware_ECC_Recovered 0x001a 073 071 000Old_age Always - 193550671 197 Current_Pending_Sector 0x0012 100 100 000Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000Old_age Offline - 0 199 UDMA_CRC_Error_Count0x003e 200 200 000Old_age Always - 0 200 Multi_Zone_Error_Rate 0x 100 253 000Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_DescriptionStatus Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offlineCompleted without error 00% 4 - # 2 Extended offlineInterrupted (host reset) 60% 2 - # 3 Short offline Completed without error 00% 1 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 100 Not_testing 200 Not_testing 300 Not_testing 400 Not_testing 500 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. More info available on request. Any ideas? Thanks in advance, Grzegorz Kulewski - 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/
libata_uli puts second channel to PIO4 on 2.6.18
. Extended self-test routine recommended polling time:( 92) minutes. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 112 100 006Pre-fail Always - 49974568 3 Spin_Up_Time0x0003 096 095 000Pre-fail Always - 0 4 Start_Stop_Count0x0032 100 100 020Old_age Always - 6 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 063 060 030Pre-fail Always - 2188910 9 Power_On_Hours 0x0032 100 100 000Old_age Always - 24 10 Spin_Retry_Count0x0013 100 100 097Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020Old_age Always - 22 187 Unknown_Attribute 0x0032 100 100 000Old_age Always - 0 189 Unknown_Attribute 0x003a 100 100 000Old_age Always - 0 190 Unknown_Attribute 0x0022 056 051 045Old_age Always - 757858348 194 Temperature_Celsius 0x0022 044 049 000Old_age Always - 44 (Lifetime Min/Max 0/33) 195 Hardware_ECC_Recovered 0x001a 073 071 000Old_age Always - 193550671 197 Current_Pending_Sector 0x0012 100 100 000Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000Old_age Offline - 0 199 UDMA_CRC_Error_Count0x003e 200 200 000Old_age Always - 0 200 Multi_Zone_Error_Rate 0x 100 253 000Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_DescriptionStatus Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offlineCompleted without error 00% 4 - # 2 Extended offlineInterrupted (host reset) 60% 2 - # 3 Short offline Completed without error 00% 1 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 100 Not_testing 200 Not_testing 300 Not_testing 400 Not_testing 500 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. More info available on request. Any ideas? Thanks in advance, Grzegorz Kulewski - 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: NTFS
On Thu, 18 Jan 2007, Andrew Morton wrote: On Thu, 18 Jan 2007 22:38:13 + Christoph Hellwig <[EMAIL PROTECTED]> wrote: On Thu, Jan 18, 2007 at 02:35:06PM -0800, Andrew Morton wrote: Cool. That means ->put_inode is gone in -mm. Andrew, what are the plans for sending the patches to make the ext2 preallocation work like ext3 to Linus? Cautious. I'm not sure that we ever want to merge them, really - ext2 is more a reference filesystem than a real one nowadays, and making it more complex detracts from that. The again while the old preallocation code might be simpler it's also utterly braindead and we need to make sure no one is going to copy this :) Good point ;) Are you refering to that particular implementation in ext2 or to the whole method od doing it implemented currently in ext2? When can I read about it (description of the new method/implementation in ext3 and why is it better) some more? Thanks, Grzegorz Kulewski - 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: NTFS
On Thu, 18 Jan 2007, Andrew Morton wrote: On Thu, 18 Jan 2007 22:38:13 + Christoph Hellwig [EMAIL PROTECTED] wrote: On Thu, Jan 18, 2007 at 02:35:06PM -0800, Andrew Morton wrote: Cool. That means -put_inode is gone in -mm. Andrew, what are the plans for sending the patches to make the ext2 preallocation work like ext3 to Linus? Cautious. I'm not sure that we ever want to merge them, really - ext2 is more a reference filesystem than a real one nowadays, and making it more complex detracts from that. The again while the old preallocation code might be simpler it's also utterly braindead and we need to make sure no one is going to copy this :) Good point ;) Are you refering to that particular implementation in ext2 or to the whole method od doing it implemented currently in ext2? When can I read about it (description of the new method/implementation in ext3 and why is it better) some more? Thanks, Grzegorz Kulewski - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel + gcc 4.1 = several problems
On Wed, 3 Jan 2007, Alan wrote: The proper fix for all of this mess is to fix the gcc compiler suite to actually generate i686 code when told to use i686. CMOV is an optional i686 extension which gcc uses without checking. In early PIV days it made sense but on modern processors CMOV is so pointless the bug should be fixed. At that point an i686 kernel would contain i686 instructions and actually run on all i686 processors ending all the i586 pain for most users and distributions. Could you explain why CMOV is pointless now? Are there any benchmarks proving that? Thanks, Grzegorz Kulewski - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel + gcc 4.1 = several problems
On Wed, 3 Jan 2007, Alan wrote: The proper fix for all of this mess is to fix the gcc compiler suite to actually generate i686 code when told to use i686. CMOV is an optional i686 extension which gcc uses without checking. In early PIV days it made sense but on modern processors CMOV is so pointless the bug should be fixed. At that point an i686 kernel would contain i686 instructions and actually run on all i686 processors ending all the i586 pain for most users and distributions. Could you explain why CMOV is pointless now? Are there any benchmarks proving that? Thanks, Grzegorz Kulewski - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
Hi, I think that... On Wed, 13 Dec 2006, Greg KH wrote: From: Greg Kroah-Hartmna <[EMAIL PROTECTED]> ... (most probably) there... Subject: Notify non-GPL module loading will be going away in January 2008 Numerous kernel developers feel that loading non-GPL drivers into the kernel violates the license of the kernel and their copyright. Because of this, a one year notice for everyone to address any non-GPL compatible modules has been set. Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> ... or (less probably) there... is a typo in your name. :-) Thanks, Grzegorz Kulewski PS. Are you _really_ sure you want this change accepted into mainline kernel? - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
Hi, I think that... On Wed, 13 Dec 2006, Greg KH wrote: From: Greg Kroah-Hartmna [EMAIL PROTECTED] ... (most probably) there... Subject: Notify non-GPL module loading will be going away in January 2008 Numerous kernel developers feel that loading non-GPL drivers into the kernel violates the license of the kernel and their copyright. Because of this, a one year notice for everyone to address any non-GPL compatible modules has been set. Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] ... or (less probably) there... is a typo in your name. :-) Thanks, Grzegorz Kulewski PS. Are you _really_ sure you want this change accepted into mainline kernel? - 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: [ATMSAR] Request for review - update #1
On Sun, 4 Sep 2005, Alistair John Strachan wrote: On Sunday 04 September 2005 17:41, Grzegorz Kulewski wrote: On Sun, 4 Sep 2005, Alistair John Strachan wrote: On Sunday 04 September 2005 12:05, Giampaolo Tomassoni wrote: Dears, thanks to Jiri Slaby who found a bug in the AAL0 handling of the ATMSAR module. I attach a fixed version of the atmsar patch as a diff against the 2.6.13 kernel tree. [snip] Just out of curiosity, is there ANY reason why this has to be done in the kernel? The PPPoATM module for pppd implements (via linux-atm) a completely userspace ATM decoder.. if anything, now redundant ATM stack code should be REMOVED from Linux! Most distributions (to my knowledge) supporting the speedtouch modem do so using the method prescribed on speedtouch.sf.net; an entirely userspace procedure. pppd does all the ATM magic. Does this have real-world applications beyond the Speedtouch DSL modems? If not, I propose adding this code to linux-atm, not the kernel, since most users of USB speedtouch DSL modems will not be using the kernel's ATM. I am using SpeedTouch 330 modem with kernel driver (on Gentoo). The instalation is currently (with firmware loader instead of modem_run) very simple: USE="atm" emerge ppp, download firmware and place it in /lib/firmware, compile the kernel with speedtch support. Compared to "place the firmware in /lib/firmware" on many other distros, this sounds like a lot of work! The kernel speedtch provides no advantages to its userspace alternative. Are you saying that you do not need to install ppp and compile (or install binary) kernel on other distros??? I tried to use userspace driver some time ago but it wasn't working for me so I gave up. I was using modem_run with kernel driver for long time to load the firmware but there were many problems with it too (nearly every kernel or modem_run upgrade was breaking something, modem_run was hanging in D state in most unapropriate moments and so on). This is not the case any longer. Maybe. But there were many bugs in modem_run, usbfs, usb drivers in kernel, ACPI, IRQ routing and so on. They caused modem_run to hang or do something stupid without even telling user what is broken. In my experience when one bug was fixed other appeared in the next kernel. So even if now everything works ok you have no guarantee that next release won't break something... :) Now I am using pure kernel driver and firmware loader and it works 100% ok. There were no problems with it for long time. And I don't even want to look at this userspace driver again. Conversely people (including myself) found the kernel implementation to be buggy, and when userspace breaks, you can simply restart it.. when the kernel breaks, you have to reboot. 1. But you still use the kernel even with userspace driver. So it still can break forcing you to reboot. 2. I have no problems with kernel driver. All problems that I saw in the past were problems in other subsystems (usbfs, usb drivers, ACPI, IRQ, ...). 3. Restarting modem_run was never enought for me. I always at least had to unplug the modem from USB port. Or more often reboot. So I see no gain here. Since Linux newer was (or is going to be) userspace-driver OS, maybe we should leave it that way... No. What can be done in userspace, within valid performance constraints, usually should be. This has always been the Linux kernel way. But not device drivers. I do not think that Linux has good infrastructure for drivers in userspace (yes I know that there are some). Also are you sure that performance and latencies are ok with userspace driver even if system is under load? The speedtouch modem is a USB device, and there are many existing userspace "driver" implementations for USB devices. Including speedtouch. I'm not necessarily saying this code shouldn't be in the kernel, I'd just be interested to know why it has to be. Well, as you are saing it hasn't... :) But since it is there and works for me I am interested in not changing this state without really good reason. Grzegorz Kulewski - 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: [ATMSAR] Request for review - update #1
On Sun, 4 Sep 2005, Alistair John Strachan wrote: On Sunday 04 September 2005 12:05, Giampaolo Tomassoni wrote: Dears, thanks to Jiri Slaby who found a bug in the AAL0 handling of the ATMSAR module. I attach a fixed version of the atmsar patch as a diff against the 2.6.13 kernel tree. [snip] Just out of curiosity, is there ANY reason why this has to be done in the kernel? The PPPoATM module for pppd implements (via linux-atm) a completely userspace ATM decoder.. if anything, now redundant ATM stack code should be REMOVED from Linux! Most distributions (to my knowledge) supporting the speedtouch modem do so using the method prescribed on speedtouch.sf.net; an entirely userspace procedure. pppd does all the ATM magic. Does this have real-world applications beyond the Speedtouch DSL modems? If not, I propose adding this code to linux-atm, not the kernel, since most users of USB speedtouch DSL modems will not be using the kernel's ATM. I am using SpeedTouch 330 modem with kernel driver (on Gentoo). The instalation is currently (with firmware loader instead of modem_run) very simple: USE="atm" emerge ppp, download firmware and place it in /lib/firmware, compile the kernel with speedtch support. I tried to use userspace driver some time ago but it wasn't working for me so I gave up. I was using modem_run with kernel driver for long time to load the firmware but there were many problems with it too (nearly every kernel or modem_run upgrade was breaking something, modem_run was hanging in D state in most unapropriate moments and so on). Now I am using pure kernel driver and firmware loader and it works 100% ok. There were no problems with it for long time. And I don't even want to look at this userspace driver again. Since Linux newer was (or is going to be) userspace-driver OS, maybe we should leave it that way... Grzegorz Kulewski - 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: [ATMSAR] Request for review - update #1
On Sun, 4 Sep 2005, Alistair John Strachan wrote: On Sunday 04 September 2005 12:05, Giampaolo Tomassoni wrote: Dears, thanks to Jiri Slaby who found a bug in the AAL0 handling of the ATMSAR module. I attach a fixed version of the atmsar patch as a diff against the 2.6.13 kernel tree. [snip] Just out of curiosity, is there ANY reason why this has to be done in the kernel? The PPPoATM module for pppd implements (via linux-atm) a completely userspace ATM decoder.. if anything, now redundant ATM stack code should be REMOVED from Linux! Most distributions (to my knowledge) supporting the speedtouch modem do so using the method prescribed on speedtouch.sf.net; an entirely userspace procedure. pppd does all the ATM magic. Does this have real-world applications beyond the Speedtouch DSL modems? If not, I propose adding this code to linux-atm, not the kernel, since most users of USB speedtouch DSL modems will not be using the kernel's ATM. I am using SpeedTouch 330 modem with kernel driver (on Gentoo). The instalation is currently (with firmware loader instead of modem_run) very simple: USE=atm emerge ppp, download firmware and place it in /lib/firmware, compile the kernel with speedtch support. I tried to use userspace driver some time ago but it wasn't working for me so I gave up. I was using modem_run with kernel driver for long time to load the firmware but there were many problems with it too (nearly every kernel or modem_run upgrade was breaking something, modem_run was hanging in D state in most unapropriate moments and so on). Now I am using pure kernel driver and firmware loader and it works 100% ok. There were no problems with it for long time. And I don't even want to look at this userspace driver again. Since Linux newer was (or is going to be) userspace-driver OS, maybe we should leave it that way... Grzegorz Kulewski - 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: [ATMSAR] Request for review - update #1
On Sun, 4 Sep 2005, Alistair John Strachan wrote: On Sunday 04 September 2005 17:41, Grzegorz Kulewski wrote: On Sun, 4 Sep 2005, Alistair John Strachan wrote: On Sunday 04 September 2005 12:05, Giampaolo Tomassoni wrote: Dears, thanks to Jiri Slaby who found a bug in the AAL0 handling of the ATMSAR module. I attach a fixed version of the atmsar patch as a diff against the 2.6.13 kernel tree. [snip] Just out of curiosity, is there ANY reason why this has to be done in the kernel? The PPPoATM module for pppd implements (via linux-atm) a completely userspace ATM decoder.. if anything, now redundant ATM stack code should be REMOVED from Linux! Most distributions (to my knowledge) supporting the speedtouch modem do so using the method prescribed on speedtouch.sf.net; an entirely userspace procedure. pppd does all the ATM magic. Does this have real-world applications beyond the Speedtouch DSL modems? If not, I propose adding this code to linux-atm, not the kernel, since most users of USB speedtouch DSL modems will not be using the kernel's ATM. I am using SpeedTouch 330 modem with kernel driver (on Gentoo). The instalation is currently (with firmware loader instead of modem_run) very simple: USE=atm emerge ppp, download firmware and place it in /lib/firmware, compile the kernel with speedtch support. Compared to place the firmware in /lib/firmware on many other distros, this sounds like a lot of work! The kernel speedtch provides no advantages to its userspace alternative. Are you saying that you do not need to install ppp and compile (or install binary) kernel on other distros??? I tried to use userspace driver some time ago but it wasn't working for me so I gave up. I was using modem_run with kernel driver for long time to load the firmware but there were many problems with it too (nearly every kernel or modem_run upgrade was breaking something, modem_run was hanging in D state in most unapropriate moments and so on). This is not the case any longer. Maybe. But there were many bugs in modem_run, usbfs, usb drivers in kernel, ACPI, IRQ routing and so on. They caused modem_run to hang or do something stupid without even telling user what is broken. In my experience when one bug was fixed other appeared in the next kernel. So even if now everything works ok you have no guarantee that next release won't break something... :) Now I am using pure kernel driver and firmware loader and it works 100% ok. There were no problems with it for long time. And I don't even want to look at this userspace driver again. Conversely people (including myself) found the kernel implementation to be buggy, and when userspace breaks, you can simply restart it.. when the kernel breaks, you have to reboot. 1. But you still use the kernel even with userspace driver. So it still can break forcing you to reboot. 2. I have no problems with kernel driver. All problems that I saw in the past were problems in other subsystems (usbfs, usb drivers, ACPI, IRQ, ...). 3. Restarting modem_run was never enought for me. I always at least had to unplug the modem from USB port. Or more often reboot. So I see no gain here. Since Linux newer was (or is going to be) userspace-driver OS, maybe we should leave it that way... No. What can be done in userspace, within valid performance constraints, usually should be. This has always been the Linux kernel way. But not device drivers. I do not think that Linux has good infrastructure for drivers in userspace (yes I know that there are some). Also are you sure that performance and latencies are ok with userspace driver even if system is under load? The speedtouch modem is a USB device, and there are many existing userspace driver implementations for USB devices. Including speedtouch. I'm not necessarily saying this code shouldn't be in the kernel, I'd just be interested to know why it has to be. Well, as you are saing it hasn't... :) But since it is there and works for me I am interested in not changing this state without really good reason. Grzegorz Kulewski - 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: [klibc] Re: [PATCH - RFC] Move initramfs configuration to "General setup"
On Mon, 8 Aug 2005, Olaf Hering wrote: On Mon, Aug 08, Grzegorz Kulewski wrote: From my recent experiments it looks like in order to be able to use initramfs not compiled into the kernel image but loaded from separate file by GRUB or LILO one must also build initrd into the kernel. The file passed from the bootloader to the kernel, which is later eventually recognized as an initrd, can be everything. But the kernel code to deal with the memory range containing the file is behind CONFIG_BLK_DEV_INITRD. The new config options should depend on BLK_DEV_INITRD [ Depend or select? ] So this code should be separated from initrd and put in some other place and depend on initrd || initramfs. From what I saw reading the code initrd is much more than this code so why keep it together? Thanks, Grzegorz Kulewski - 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 - RFC] Move initramfs configuration to "General setup"
On Mon, 8 Aug 2005, Sam Ravnborg wrote: At present the configuration items for initramfs is located in: Device drivers | Block Drivers | xxx This is maybe not the most natural place to have it. So with the following patch it is moved below "General setup", and relevant config items are collected in a file with a new home in usr/. The original reason why I looked into this is the upcoming merge of klibc and I missed a good place to include the KLIBC relevant config options. With the Kconfig file added to usr/ is will be a simple menuconfig in here for all the KLIBC relevant config options. Any comments? From my recent experiments it looks like in order to be able to use initramfs not compiled into the kernel image but loaded from separate file by GRUB or LILO one must also build initrd into the kernel. Am I right? If so, could somebody split initramfs and initrd (not only at configuration level but also at code level)? Shouldn't they be separated (and possibly initrd removed after some time)? In the mean time it should be documented in *config help. Also somebody should add more documentation about initramfs (generating, writing scripts, producing image, the right method for chroot / pivot_root / ...). It took me whole week to find it out myself and I still have some doubths... Thanks, Grzegorz Kulewski - 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 - RFC] Move initramfs configuration to General setup
On Mon, 8 Aug 2005, Sam Ravnborg wrote: At present the configuration items for initramfs is located in: Device drivers | Block Drivers | xxx This is maybe not the most natural place to have it. So with the following patch it is moved below General setup, and relevant config items are collected in a file with a new home in usr/. The original reason why I looked into this is the upcoming merge of klibc and I missed a good place to include the KLIBC relevant config options. With the Kconfig file added to usr/ is will be a simple menuconfig in here for all the KLIBC relevant config options. Any comments? From my recent experiments it looks like in order to be able to use initramfs not compiled into the kernel image but loaded from separate file by GRUB or LILO one must also build initrd into the kernel. Am I right? If so, could somebody split initramfs and initrd (not only at configuration level but also at code level)? Shouldn't they be separated (and possibly initrd removed after some time)? In the mean time it should be documented in *config help. Also somebody should add more documentation about initramfs (generating, writing scripts, producing image, the right method for chroot / pivot_root / ...). It took me whole week to find it out myself and I still have some doubths... Thanks, Grzegorz Kulewski - 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: [klibc] Re: [PATCH - RFC] Move initramfs configuration to General setup
On Mon, 8 Aug 2005, Olaf Hering wrote: On Mon, Aug 08, Grzegorz Kulewski wrote: From my recent experiments it looks like in order to be able to use initramfs not compiled into the kernel image but loaded from separate file by GRUB or LILO one must also build initrd into the kernel. The file passed from the bootloader to the kernel, which is later eventually recognized as an initrd, can be everything. But the kernel code to deal with the memory range containing the file is behind CONFIG_BLK_DEV_INITRD. The new config options should depend on BLK_DEV_INITRD [ Depend or select? ] So this code should be separated from initrd and put in some other place and depend on initrd || initramfs. From what I saw reading the code initrd is much more than this code so why keep it together? Thanks, Grzegorz Kulewski - 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: [swsusp] encrypt suspend data for easy wiping
On Wed, 6 Jul 2005, Pavel Machek wrote: Hi! To prevent data gathering from swap after resume you can encrypt the suspend image with a temporary key that is deleted on resume. Note that the temporary key is stored unencrypted on disk while the system is suspended... still it means that saved data are wiped from disk during resume by simply overwritting the key. hm, how useful is that? swap can still contain sensitive userspace stuff. At least userspace has chance to mark *really* sensitive stuff as unswappable. Unfortunately that does not work against swsusp :-(. [BTW... I was thinking about just generating random key on swapon, and using it, so that data in swap is garbage after reboot; no userspace changes needed. What do you think?] I (and many others) are doing it already in userspace. Don't you know about dm-crypt? I think the idea is described in its docs or wiki... I also think that doing this in swapon is risky. Because nobody will guarantee you that random seed was restored before swapon and basing this random key only on boot time and (rather deterministic) irqs at boot is risky IMHO. In userspace, init scripts should make sure that random seed is restored before using /dev/random for anything. Grzegorz Kulewski - 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: [swsusp] encrypt suspend data for easy wiping
On Wed, 6 Jul 2005, Pavel Machek wrote: Hi! To prevent data gathering from swap after resume you can encrypt the suspend image with a temporary key that is deleted on resume. Note that the temporary key is stored unencrypted on disk while the system is suspended... still it means that saved data are wiped from disk during resume by simply overwritting the key. hm, how useful is that? swap can still contain sensitive userspace stuff. At least userspace has chance to mark *really* sensitive stuff as unswappable. Unfortunately that does not work against swsusp :-(. [BTW... I was thinking about just generating random key on swapon, and using it, so that data in swap is garbage after reboot; no userspace changes needed. What do you think?] I (and many others) are doing it already in userspace. Don't you know about dm-crypt? I think the idea is described in its docs or wiki... I also think that doing this in swapon is risky. Because nobody will guarantee you that random seed was restored before swapon and basing this random key only on boot time and (rather deterministic) irqs at boot is risky IMHO. In userspace, init scripts should make sure that random seed is restored before using /dev/random for anything. Grzegorz Kulewski - 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: /proc/cpuinfo format - arch dependent!
On Tue, 19 Apr 2005, Nico Schottelius wrote: Lee Revell [Tue, Apr 19, 2005 at 04:42:12PM -0400]: On Tue, 2005-04-19 at 22:00 +0200, Nico Schottelius wrote: Can you tell me which ones? Multimedia apps like JACK and mplayer that use the TSC for high res timing need to know the CPU speed, and /proc/cpuinfo is the fast way to get it. Why don't you create sysfs entries instead? It would be better to have all the cpuinfo contents as one value per file anyway (faster application startup). Well, sounds very good. It's a chance for me to learn to program sysfs and also to create something useful. So the right location to place that data would be /sys/devices/system/cpu/cpuX? IIRC there was such patch not very long ago and it was rejected (to not make kernel larger or something like that...). But I can be wrong. I think that all data from /proc that are not user-process data should be exported using sysfs or something similar. Maybe even in future one will write userspace fs (using FUSE?) to emulate old /proc entries using sysfs exported data. This will allow removing all proc code from kernel. Maybe even user processes data should be exported using sysfs (like /sys/processes/123/maps/4161/file)? But this is my personal opinion. Grzegorz Kulewski - 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: /proc/cpuinfo format - arch dependent!
On Tue, 19 Apr 2005, Nico Schottelius wrote: Lee Revell [Tue, Apr 19, 2005 at 04:42:12PM -0400]: On Tue, 2005-04-19 at 22:00 +0200, Nico Schottelius wrote: Can you tell me which ones? Multimedia apps like JACK and mplayer that use the TSC for high res timing need to know the CPU speed, and /proc/cpuinfo is the fast way to get it. Why don't you create sysfs entries instead? It would be better to have all the cpuinfo contents as one value per file anyway (faster application startup). Well, sounds very good. It's a chance for me to learn to program sysfs and also to create something useful. So the right location to place that data would be /sys/devices/system/cpu/cpuX? IIRC there was such patch not very long ago and it was rejected (to not make kernel larger or something like that...). But I can be wrong. I think that all data from /proc that are not user-process data should be exported using sysfs or something similar. Maybe even in future one will write userspace fs (using FUSE?) to emulate old /proc entries using sysfs exported data. This will allow removing all proc code from kernel. Maybe even user processes data should be exported using sysfs (like /sys/processes/123/maps/4161/file)? But this is my personal opinion. Grzegorz Kulewski - 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: Use of C99 int types
On Mon, 4 Apr 2005, Dag Arne Osvik wrote: (...) And, at least in theory, long may even provide less than 32 bits. Are you sure? My copy of famous C book by B. W. Kernighan and D. Ritchie says that sizeof(short) <= sizeof(int) <= sizeof(long) and sizeof(short) >= 16, sizeof(int) >= 16, sizeof(long) >= 32. The book is about ANSI C not C99 but I think this is still valid. Am I wrong? Grzegorz Kulewski - 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: Use of C99 int types
On Mon, 4 Apr 2005, Dag Arne Osvik wrote: (...) And, at least in theory, long may even provide less than 32 bits. Are you sure? My copy of famous C book by B. W. Kernighan and D. Ritchie says that sizeof(short) = sizeof(int) = sizeof(long) and sizeof(short) = 16, sizeof(int) = 16, sizeof(long) = 32. The book is about ANSI C not C99 but I think this is still valid. Am I wrong? Grzegorz Kulewski - 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 (stable and -rc) ACPI breaks USB
On Mon, 21 Mar 2005, Andrew Morton wrote: Grzegorz Kulewski <[EMAIL PROTECTED]> wrote: Hi, I just installed 2.6.11 and I was hit by the same bug (or feature?) I found in -rcs. Basically my USB will work only if acpi=off was passed to the kernel. It looks like without acpi=off it will assign IRQ 10 and with acpi=off it will assign IRQ9. It worked at least with 2.6.9. I do not know if the USB is completly broken but at least my speedtouch modem will not work (the red led will be on for some time then completly black). I didn't really follow all the ins and outs on this one. Will it end up being adequately resolved for 2.6.12? It was identified (by Bjorn) to be some ACPI VIA PCI IRQ routing quirk logic change (as far as I understand it). Unfortunatelly it is not good for my board (AMD 761 North and VIA 686B South). Bjorn (huge thanks to him) produced testing patch that fixed it for me. Further patches were presented and discussed in the other thread. The newest one is waiting for final testing from me (in couple of minutes probably). I will CC you on my reply (if you are not already). As of what to do next with this patch (if it still works) Bjorn and others should reply. Thanks. Thanks for interest, Grzegorz Kulewski - 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: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
01:32:37 kangur ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Mar 22 01:32:37 kangur pnp: match found with the PnP device '00:08' and the driver 'serial' Mar 22 01:32:37 kangur ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A Mar 22 01:32:37 kangur usb 1-2: modprobe timed out on ep0in Mar 22 01:32:37 kangur usbcore: registered new driver speedtch Mar 22 01:32:37 kangur usb 1-2: found stage 1 firmware speedtch-1.bin Mar 22 01:32:37 kangur usb 1-2: found stage 2 firmware speedtch-2.bin Mar 22 01:32:39 kangur eth0: link down Mar 22 01:32:39 kangur eth0: link down Mar 22 01:32:40 kangur NET: Registered protocol family 10 Mar 22 01:32:40 kangur Disabled Privacy Extensions on device b03e6aa0(lo) Mar 22 01:32:40 kangur IPv6 over IPv4 tunneling driver Mar 22 01:32:41 kangur ADSL line is synchronising Mar 22 01:32:41 kangur init: Entering runlevel: 3 Mar 22 01:32:43 kangur init: Activating demand-procedures for 'A' Mar 22 01:32:51 kangur eth0: no IPv6 routers present Mar 22 01:32:53 kangur DSL line goes up Mar 22 01:32:53 kangur ADSL line is up (768 Kib/s down | 192 Kib/s up) By the way - since some time I am getting the above Mar 22 01:32:37 kangur speedtch: Unknown symbol release_firmware messages on modprobing speedtch in my startup scripts. The message did not appeared with 2.6.11 at first (even after some VIA quirk related patches) and it is now 100% reproductible. I do not know what is causing it because I changed nearly nothing in the system setup. The funniest thing is that speedtch still works well. Can anybody say something? Is it harmless or what? And what is this: Mar 22 01:32:37 kangur usb 1-2: modprobe timed out on ep0in ??? Thanks, Grzegorz Kulewski - 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: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
' and the driver 'serial' Mar 22 01:32:37 kangur ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A Mar 22 01:32:37 kangur usb 1-2: modprobe timed out on ep0in Mar 22 01:32:37 kangur usbcore: registered new driver speedtch Mar 22 01:32:37 kangur usb 1-2: found stage 1 firmware speedtch-1.bin Mar 22 01:32:37 kangur usb 1-2: found stage 2 firmware speedtch-2.bin Mar 22 01:32:39 kangur eth0: link down Mar 22 01:32:39 kangur eth0: link down Mar 22 01:32:40 kangur NET: Registered protocol family 10 Mar 22 01:32:40 kangur Disabled Privacy Extensions on device b03e6aa0(lo) Mar 22 01:32:40 kangur IPv6 over IPv4 tunneling driver Mar 22 01:32:41 kangur ADSL line is synchronising Mar 22 01:32:41 kangur init: Entering runlevel: 3 Mar 22 01:32:43 kangur init: Activating demand-procedures for 'A' Mar 22 01:32:51 kangur eth0: no IPv6 routers present Mar 22 01:32:53 kangur DSL line goes up Mar 22 01:32:53 kangur ADSL line is up (768 Kib/s down | 192 Kib/s up) By the way - since some time I am getting the above Mar 22 01:32:37 kangur speedtch: Unknown symbol release_firmware messages on modprobing speedtch in my startup scripts. The message did not appeared with 2.6.11 at first (even after some VIA quirk related patches) and it is now 100% reproductible. I do not know what is causing it because I changed nearly nothing in the system setup. The funniest thing is that speedtch still works well. Can anybody say something? Is it harmless or what? And what is this: Mar 22 01:32:37 kangur usb 1-2: modprobe timed out on ep0in ??? Thanks, Grzegorz Kulewski - 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 (stable and -rc) ACPI breaks USB
On Mon, 21 Mar 2005, Andrew Morton wrote: Grzegorz Kulewski [EMAIL PROTECTED] wrote: Hi, I just installed 2.6.11 and I was hit by the same bug (or feature?) I found in -rcs. Basically my USB will work only if acpi=off was passed to the kernel. It looks like without acpi=off it will assign IRQ 10 and with acpi=off it will assign IRQ9. It worked at least with 2.6.9. I do not know if the USB is completly broken but at least my speedtouch modem will not work (the red led will be on for some time then completly black). I didn't really follow all the ins and outs on this one. Will it end up being adequately resolved for 2.6.12? It was identified (by Bjorn) to be some ACPI VIA PCI IRQ routing quirk logic change (as far as I understand it). Unfortunatelly it is not good for my board (AMD 761 North and VIA 686B South). Bjorn (huge thanks to him) produced testing patch that fixed it for me. Further patches were presented and discussed in the other thread. The newest one is waiting for final testing from me (in couple of minutes probably). I will CC you on my reply (if you are not already). As of what to do next with this patch (if it still works) Bjorn and others should reply. Thanks. Thanks for interest, Grzegorz Kulewski - 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] partitions/msdos.c
On Sat, 19 Mar 2005, Werner Almesberger wrote: Andries Brouwer wrote: The two variants are: (i) partition tells the kernel to do the partition table reading, and (ii) partition uses partx to read the partition table and tells the kernel one-by-one about the partitions found this way. I guess, once you've reached the point where the kernel is unable to find partitions without user-space help, you may as well do everything in user space. I agree. This is userspace job. This can be done very easily using device-mapper. I think EVMS does something similar. I even asked on LKML some time ago about option for disabling kernel partition driver (maybe for some devices) from kernel command line to allow other tools do the job (because now I have unusable /dev/sda1 and usable /dev/evms/sda1 and this leads to stupid mistakes). But there were no replies. Grzegorz Kulewski - 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] partitions/msdos.c
On Sat, 19 Mar 2005, Werner Almesberger wrote: Andries Brouwer wrote: The two variants are: (i) partition tells the kernel to do the partition table reading, and (ii) partition uses partx to read the partition table and tells the kernel one-by-one about the partitions found this way. I guess, once you've reached the point where the kernel is unable to find partitions without user-space help, you may as well do everything in user space. I agree. This is userspace job. This can be done very easily using device-mapper. I think EVMS does something similar. I even asked on LKML some time ago about option for disabling kernel partition driver (maybe for some devices) from kernel command line to allow other tools do the job (because now I have unusable /dev/sda1 and usable /dev/evms/sda1 and this leads to stupid mistakes). But there were no replies. Grzegorz Kulewski - 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] x86: fix ESP corruption CPU bug
On Sun, 13 Mar 2005, Stas Sergeev wrote: Hi Alan. Attached patch works around the corruption of the high word of the ESP register, which is the official bug of x86 CPUs. The bug triggers only when the one is using the 16bit stack segment, and is described here: http://www.intel.com/design/intarch/specupdt/27287402.PDF Does the bug also egsist on AMD CPU's? Does the patch add anything to kernels compiled for AMD CPU's? Thanks, Grzegorz Kulewski - 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: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
56] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :01:05.0 Class 0300: 10de:0150 (rev a4) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 248 (1250ns min, 250ns max) Interrupt: pin A routed to IRQ 10 Region 0: Memory at f400 (32-bit, non-prefetchable) Region 1: Memory at e800 (32-bit, prefetchable) [size=128M] Capabilities: [60] Power Management version 1 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [44] AGP version 2.0 Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=16 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW+ Rate=x4 To me everything works (at least now). Can this patch be pushed into 2.6.12 and/or 2.6.11.4 fast? Thanks, Grzegorz Kulewski - 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: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
at ec00 Region 1: Memory at f7004000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :01:05.0 Class 0300: 10de:0150 (rev a4) 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: 248 (1250ns min, 250ns max) Interrupt: pin A routed to IRQ 10 Region 0: Memory at f400 (32-bit, non-prefetchable) Region 1: Memory at e800 (32-bit, prefetchable) [size=128M] Capabilities: [60] Power Management version 1 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [44] AGP version 2.0 Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=16 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW+ Rate=x4 To me everything works (at least now). Can this patch be pushed into 2.6.12 and/or 2.6.11.4 fast? Thanks, Grzegorz Kulewski - 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] x86: fix ESP corruption CPU bug
On Sun, 13 Mar 2005, Stas Sergeev wrote: Hi Alan. Attached patch works around the corruption of the high word of the ESP register, which is the official bug of x86 CPUs. The bug triggers only when the one is using the 16bit stack segment, and is described here: http://www.intel.com/design/intarch/specupdt/27287402.PDF Does the bug also egsist on AMD CPU's? Does the patch add anything to kernels compiled for AMD CPU's? Thanks, Grzegorz Kulewski - 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: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
prefetchable) Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:0b.0 Class 0401: 1102:0002 (rev 08) Subsystem: 1102:8064 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32 (500ns min, 5000ns max) Interrupt: pin A routed to IRQ 9 Region 0: I/O ports at d000 Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:0b.1 Class 0980: 1102:7002 (rev 08) Subsystem: 1102:0020 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32 Region 0: I/O ports at d400 Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:0d.0 Class 0180: 1095:3112 (rev 02) Subsystem: 1095:3112 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32, cache line size 08 Interrupt: pin A routed to IRQ 11 Region 0: I/O ports at d800 Region 1: I/O ports at dc00 [size=4] Region 2: I/O ports at e000 [size=8] Region 3: I/O ports at e400 [size=4] Region 4: I/O ports at e800 [size=16] Region 5: Memory at f7002000 (32-bit, non-prefetchable) [size=512] Capabilities: [60] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=2 PME- :00:0f.0 Class 0200: 10ec:8139 (rev 10) Subsystem: 10ec:8139 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32 (8000ns min, 16000ns max) Interrupt: pin A routed to IRQ 11 Region 0: I/O ports at ec00 Region 1: Memory at f7004000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :01:05.0 Class 0300: 10de:0150 (rev a4) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 248 (1250ns min, 250ns max) Interrupt: pin A routed to IRQ 10 Region 0: Memory at f400 (32-bit, non-prefetchable) Region 1: Memory at e800 (32-bit, prefetchable) [size=128M] Capabilities: [60] Power Management version 1 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [44] AGP version 2.0 Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=16 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW+ Rate=x4 What do you think about this? I will try new patch in the morning. Thanks, Grzegorz Kulewski - 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: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Fri, 11 Mar 2005, Bjorn Helgaas wrote:
On Fri, 2005-03-11 at 20:36 +0100, Grzegorz Kulewski wrote:
On Fri, 11 Mar 2005, Bjorn Helgaas wrote:
Can you check to see whether there are any BIOS updates available
for your box? It looks to me like your USB controllers are wired
to IRQ9, and that's how the BIOS is leaving them configured.
And if this is a BIOS issue then why it worked for 3 years with all
kernels up to at least 2.6.9
Good point.
Thanks for posting the 2.6.9 output as well. It contains this:
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10
ACPI: PCI interrupt :00:07.2[D] -> GSI 10 (level, low) -> IRQ 10
ACPI: PCI interrupt :00:07.3[D] -> GSI 10 (level, low) -> IRQ 10
PCI: Via IRQ fixup for :00:07.2, from 9 to 10
PCI: Via IRQ fixup for :00:07.3, from 9 to 10
In 2.6.9, we did all the ACPI IRQ routing early, then did the
Via IRQ fixups. In 2.6.11, ACPI IRQ routing is done only when
a driver claims a device, and the Via IRQ fixup is done a little
differently. In fact, the Via fixup happens before we twiddle
the IOAPIC, where in 2.6.9, it happened after.
Can you try the attached patch to see whether it makes any
difference?
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-11 13:45:56 -07:00
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -438,10 +439,19 @@
}
}
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq & 15);
-
dev->irq = acpi_register_gsi(irq, edge_level, active_high_low);
+
+ if (via_interrupt_line_quirk) {
+ u8 old_irq, new_irq = dev->irq & 0xf;
+
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, _irq);
+ if (new_irq != old_irq) {
+ printk(KERN_INFO PREFIX "Via IRQ fixup for %s, from %d "
+ "to %d\n", pci_name(dev), old_irq, new_irq);
+ udelay(15);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
+ }
+ }
printk(KERN_INFO PREFIX "PCI interrupt %s[%c] -> GSI %u "
"(%s, %s) -> IRQ %d\n",
Unfortunatelly no. Here is the log:
Mar 11 23:47:44 kangur Linux version 2.6.11-cko1 ([EMAIL PROTECTED]) (gcc
version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)) #2
Fri Mar 11 23:32:57 CET 2005
Mar 11 23:47:44 kangur BIOS-provided physical RAM map:
Mar 11 23:47:44 kangur BIOS-e820: - 0009fc00
(usable)
Mar 11 23:47:44 kangur BIOS-e820: 0009fc00 - 000a
(reserved)
Mar 11 23:47:44 kangur BIOS-e820: 000f - 0010
(reserved)
Mar 11 23:47:44 kangur BIOS-e820: 0010 - 1fff
(usable)
Mar 11 23:47:44 kangur BIOS-e820: 1fff - 1fff3000
(ACPI NVS)
Mar 11 23:47:44 kangur BIOS-e820: 1fff3000 - 2000
(ACPI data)
Mar 11 23:47:44 kangur BIOS-e820: - 0001
(reserved)
Mar 11 23:47:44 kangur 511MB LOWMEM available.
Mar 11 23:47:44 kangur On node 0 totalpages: 131056
Mar 11 23:47:44 kangur DMA zone: 4096 pages, LIFO batch:1
Mar 11 23:47:44 kangur Normal zone: 126960 pages, LIFO batch:16
Mar 11 23:47:44 kangur HighMem zone: 0 pages, LIFO batch:1
Mar 11 23:47:44 kangur DMI 2.2 present.
Mar 11 23:47:44 kangur ACPI: RSDP (v000 761686
) @ 0x000f6a70
Mar 11 23:47:44 kangur ACPI: RSDT (v001 761686 AWRDACPI 0x42302e31 AWRD
0x) @ 0x1fff3000
Mar 11 23:47:44 kangur ACPI: FADT (v001 761686 AWRDACPI 0x42302e31 AWRD
0x) @ 0x1fff3040
Mar 11 23:47:44 kangur ACPI: DSDT (v001 761686 AWRDACPI 0x1000 MSFT
0x010c) @ 0x
Mar 11 23:47:44 kangur ACPI: PM-Timer IO Port: 0x4008
Mar 11 23:47:44 kangur Allocating PCI resources starting at 2000 (gap:
2000:dfff)
Mar 11 23:47:44 kangur Built 1 zonelists
Mar 11 23:47:44 kangur Kernel command line: ro root=/dev/hdb4
Mar 11 23:47:44 kangur Local APIC disabled by BIOS -- you can enable it
with "lapic"
Mar 11 23:47:44 kangur mapped APIC to d000 (01402000)
Mar 11 23:47:44 kangur Initializing CPU#0
Mar 11 23:47:44 kangur CPU 0 irqstacks, hard=b0477000 soft=b0476000
Mar 11 23:47:44 kangur PID hash table entries: 2048 (order: 11, 32768
bytes)
Mar 11 23:47:44 kangur Detected 1203.228 MHz processor.
Mar 11 23:47:44 kangur Using pmtmr for high-res timesource
Mar 11 23:47:44 kangur Console: colour VGA+ 80x25
Mar 11 23:47:44 kangur Dentry cache hash table entries: 131072 (order: 7,
524288 bytes)
Mar 11 23:47:44 kangur Inode-cache hash table entries: 65536 (order: 6,
262144 bytes)
Mar 11 23:47:44 kangur Memory: 514940k/524224k available (2543k kernel
code, 8732k reserved, 819k data, 156k init, 0k highmem)
Mar 11 23:47:44 kangur Checking if this p
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Hi, Thanks for your prompt anwser. On Fri, 11 Mar 2005, Bjorn Helgaas wrote: On Fri, 2005-03-11 at 00:08 +0100, Grzegorz Kulewski wrote: Anything new about it? Can I provide more usefull info? Can you check to see whether there are any BIOS updates available for your box? It looks to me like your USB controllers are wired to IRQ9, and that's how the BIOS is leaving them configured. Unfortunatelly its 3 years ABIT KG7-Lite. I was begging ABIT for update (to fix some other problems with new CPUs) some time ago but they refused to make new BIOS for this board. And I have the newset release. And if this is a BIOS issue then why it worked for 3 years with all kernels up to at least 2.6.9 (only -mm kernels had some problems with USB and other subsystems since I think 2.6.3-mm? or something like that - I stopped using them soon after)? BTW. My mainboard manual says: "PCI-4 and USB controllers share an IRQ" (the manual is on www.abit.com.tw so you can check it). But ACPI is telling us they're on IRQ10, which seems like a BIOS bug. Maybe this is just some off-by-one in recent kernels? ;-) Can you also post the complete dmesg log without "acpi=off"? There might be an ACPI interrupt link device for the USB controller, and maybe there's something wrong there. Ok, here it goes: Mar 2 23:36:56 kangur syslog-ng[10153]: syslog-ng version 1.6.4 starting Mar 2 23:36:56 kangur syslog-ng[10153]: Changing permissions on special file /dev/tty12 Mar 2 23:36:56 kangur Linux version 2.6.11-cko1 ([EMAIL PROTECTED]) (gcc version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)) #1 Wed Mar 2 20:48:19 CET 2005 Mar 2 23:36:56 kangur BIOS-provided physical RAM map: Mar 2 23:36:56 kangur BIOS-e820: - 0009fc00 (usable) Mar 2 23:36:56 kangur BIOS-e820: 0009fc00 - 000a (reserved) Mar 2 23:36:56 kangur BIOS-e820: 000f - 0010 (reserved) Mar 2 23:36:56 kangur BIOS-e820: 0010 - 1fff (usable) Mar 2 23:36:56 kangur BIOS-e820: 1fff - 1fff3000 (ACPI NVS) Mar 2 23:36:56 kangur BIOS-e820: 1fff3000 - 2000 (ACPI data) Mar 2 23:36:56 kangur BIOS-e820: - 0001 (reserved) Mar 2 23:36:56 kangur 511MB LOWMEM available. Mar 2 23:36:56 kangur On node 0 totalpages: 131056 Mar 2 23:36:56 kangur DMA zone: 4096 pages, LIFO batch:1 Mar 2 23:36:56 kangur Normal zone: 126960 pages, LIFO batch:16 Mar 2 23:36:56 kangur HighMem zone: 0 pages, LIFO batch:1 Mar 2 23:36:56 kangur DMI 2.2 present. Mar 2 23:36:56 kangur ACPI: RSDP (v000 761686 ) @ 0x000f6a70 Mar 2 23:36:56 kangur ACPI: RSDT (v001 761686 AWRDACPI 0x42302e31 AWRD 0x) @ 0x1fff3000 Mar 2 23:36:56 kangur ACPI: FADT (v001 761686 AWRDACPI 0x42302e31 AWRD 0x) @ 0x1fff3040 Mar 2 23:36:56 kangur ACPI: DSDT (v001 761686 AWRDACPI 0x1000 MSFT 0x010c) @ 0x Mar 2 23:36:56 kangur ACPI: PM-Timer IO Port: 0x4008 Mar 2 23:36:56 kangur Allocating PCI resources starting at 2000 (gap: 2000:dfff) Mar 2 23:36:56 kangur Built 1 zonelists Mar 2 23:36:56 kangur Kernel command line: ro root=/dev/hdb4 Mar 2 23:36:56 kangur Local APIC disabled by BIOS -- you can enable it with "lapic" Mar 2 23:36:56 kangur mapped APIC to d000 (01402000) Mar 2 23:36:56 kangur Initializing CPU#0 Mar 2 23:36:56 kangur CPU 0 irqstacks, hard=b0476000 soft=b0475000 Mar 2 23:36:56 kangur PID hash table entries: 2048 (order: 11, 32768 bytes) Mar 2 23:36:56 kangur Detected 1203.036 MHz processor. Mar 2 23:36:56 kangur Using pmtmr for high-res timesource Mar 2 23:36:56 kangur Console: colour VGA+ 80x25 Mar 2 23:36:56 kangur Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Mar 2 23:36:56 kangur Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Mar 2 23:36:56 kangur Memory: 514944k/524224k available (2543k kernel code, 8728k reserved, 815k data, 156k init, 0k highmem) Mar 2 23:36:56 kangur Checking if this processor honours the WP bit even in supervisor mode... Ok. Mar 2 23:36:56 kangur Calibrating delay loop... 2375.68 BogoMIPS (lpj=1187840) Mar 2 23:36:56 kangur Security Framework v1.0.0 initialized Mar 2 23:36:56 kangur Capability LSM initialized Mar 2 23:36:56 kangur Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Mar 2 23:36:56 kangur CPU: After generic identify, caps: 0383f9ff c1cbf9ff Mar 2 23:36:56 kangur CPU: After vendor identify, caps: 0383f9ff c1cbf9ff Mar 2 23:36:56 kangur CPU: CLK_CTL MSR was 60071263. Reprogramming to 20071263 Mar 2 23:36:56 kangur CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) Mar 2 23:36:56 kangur CPU: L2 Cache: 512K (64 bytes/line) Mar 2 23:36:56 kangur CPU: After all inits, caps: 0383f9ff c1cbf9ff 0020 Mar 2
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Hi, Thanks for your prompt anwser. On Fri, 11 Mar 2005, Bjorn Helgaas wrote: On Fri, 2005-03-11 at 00:08 +0100, Grzegorz Kulewski wrote: Anything new about it? Can I provide more usefull info? Can you check to see whether there are any BIOS updates available for your box? It looks to me like your USB controllers are wired to IRQ9, and that's how the BIOS is leaving them configured. Unfortunatelly its 3 years ABIT KG7-Lite. I was begging ABIT for update (to fix some other problems with new CPUs) some time ago but they refused to make new BIOS for this board. And I have the newset release. And if this is a BIOS issue then why it worked for 3 years with all kernels up to at least 2.6.9 (only -mm kernels had some problems with USB and other subsystems since I think 2.6.3-mm? or something like that - I stopped using them soon after)? BTW. My mainboard manual says: PCI-4 and USB controllers share an IRQ (the manual is on www.abit.com.tw so you can check it). But ACPI is telling us they're on IRQ10, which seems like a BIOS bug. Maybe this is just some off-by-one in recent kernels? ;-) Can you also post the complete dmesg log without acpi=off? There might be an ACPI interrupt link device for the USB controller, and maybe there's something wrong there. Ok, here it goes: Mar 2 23:36:56 kangur syslog-ng[10153]: syslog-ng version 1.6.4 starting Mar 2 23:36:56 kangur syslog-ng[10153]: Changing permissions on special file /dev/tty12 Mar 2 23:36:56 kangur Linux version 2.6.11-cko1 ([EMAIL PROTECTED]) (gcc version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)) #1 Wed Mar 2 20:48:19 CET 2005 Mar 2 23:36:56 kangur BIOS-provided physical RAM map: Mar 2 23:36:56 kangur BIOS-e820: - 0009fc00 (usable) Mar 2 23:36:56 kangur BIOS-e820: 0009fc00 - 000a (reserved) Mar 2 23:36:56 kangur BIOS-e820: 000f - 0010 (reserved) Mar 2 23:36:56 kangur BIOS-e820: 0010 - 1fff (usable) Mar 2 23:36:56 kangur BIOS-e820: 1fff - 1fff3000 (ACPI NVS) Mar 2 23:36:56 kangur BIOS-e820: 1fff3000 - 2000 (ACPI data) Mar 2 23:36:56 kangur BIOS-e820: - 0001 (reserved) Mar 2 23:36:56 kangur 511MB LOWMEM available. Mar 2 23:36:56 kangur On node 0 totalpages: 131056 Mar 2 23:36:56 kangur DMA zone: 4096 pages, LIFO batch:1 Mar 2 23:36:56 kangur Normal zone: 126960 pages, LIFO batch:16 Mar 2 23:36:56 kangur HighMem zone: 0 pages, LIFO batch:1 Mar 2 23:36:56 kangur DMI 2.2 present. Mar 2 23:36:56 kangur ACPI: RSDP (v000 761686 ) @ 0x000f6a70 Mar 2 23:36:56 kangur ACPI: RSDT (v001 761686 AWRDACPI 0x42302e31 AWRD 0x) @ 0x1fff3000 Mar 2 23:36:56 kangur ACPI: FADT (v001 761686 AWRDACPI 0x42302e31 AWRD 0x) @ 0x1fff3040 Mar 2 23:36:56 kangur ACPI: DSDT (v001 761686 AWRDACPI 0x1000 MSFT 0x010c) @ 0x Mar 2 23:36:56 kangur ACPI: PM-Timer IO Port: 0x4008 Mar 2 23:36:56 kangur Allocating PCI resources starting at 2000 (gap: 2000:dfff) Mar 2 23:36:56 kangur Built 1 zonelists Mar 2 23:36:56 kangur Kernel command line: ro root=/dev/hdb4 Mar 2 23:36:56 kangur Local APIC disabled by BIOS -- you can enable it with lapic Mar 2 23:36:56 kangur mapped APIC to d000 (01402000) Mar 2 23:36:56 kangur Initializing CPU#0 Mar 2 23:36:56 kangur CPU 0 irqstacks, hard=b0476000 soft=b0475000 Mar 2 23:36:56 kangur PID hash table entries: 2048 (order: 11, 32768 bytes) Mar 2 23:36:56 kangur Detected 1203.036 MHz processor. Mar 2 23:36:56 kangur Using pmtmr for high-res timesource Mar 2 23:36:56 kangur Console: colour VGA+ 80x25 Mar 2 23:36:56 kangur Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Mar 2 23:36:56 kangur Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Mar 2 23:36:56 kangur Memory: 514944k/524224k available (2543k kernel code, 8728k reserved, 815k data, 156k init, 0k highmem) Mar 2 23:36:56 kangur Checking if this processor honours the WP bit even in supervisor mode... Ok. Mar 2 23:36:56 kangur Calibrating delay loop... 2375.68 BogoMIPS (lpj=1187840) Mar 2 23:36:56 kangur Security Framework v1.0.0 initialized Mar 2 23:36:56 kangur Capability LSM initialized Mar 2 23:36:56 kangur Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Mar 2 23:36:56 kangur CPU: After generic identify, caps: 0383f9ff c1cbf9ff Mar 2 23:36:56 kangur CPU: After vendor identify, caps: 0383f9ff c1cbf9ff Mar 2 23:36:56 kangur CPU: CLK_CTL MSR was 60071263. Reprogramming to 20071263 Mar 2 23:36:56 kangur CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) Mar 2 23:36:56 kangur CPU: L2 Cache: 512K (64 bytes/line) Mar 2 23:36:56 kangur CPU: After all inits, caps: 0383f9ff c1cbf9ff 0020 Mar 2 23:36:56 kangur Intel machine check
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Fri, 11 Mar 2005, Bjorn Helgaas wrote:
On Fri, 2005-03-11 at 20:36 +0100, Grzegorz Kulewski wrote:
On Fri, 11 Mar 2005, Bjorn Helgaas wrote:
Can you check to see whether there are any BIOS updates available
for your box? It looks to me like your USB controllers are wired
to IRQ9, and that's how the BIOS is leaving them configured.
And if this is a BIOS issue then why it worked for 3 years with all
kernels up to at least 2.6.9
Good point.
Thanks for posting the 2.6.9 output as well. It contains this:
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10
ACPI: PCI interrupt :00:07.2[D] - GSI 10 (level, low) - IRQ 10
ACPI: PCI interrupt :00:07.3[D] - GSI 10 (level, low) - IRQ 10
PCI: Via IRQ fixup for :00:07.2, from 9 to 10
PCI: Via IRQ fixup for :00:07.3, from 9 to 10
In 2.6.9, we did all the ACPI IRQ routing early, then did the
Via IRQ fixups. In 2.6.11, ACPI IRQ routing is done only when
a driver claims a device, and the Via IRQ fixup is done a little
differently. In fact, the Via fixup happens before we twiddle
the IOAPIC, where in 2.6.9, it happened after.
Can you try the attached patch to see whether it makes any
difference?
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-11 13:45:56 -07:00
@@ -30,6 +30,7 @@
#include linux/module.h
#include linux/init.h
#include linux/types.h
+#include linux/delay.h
#include linux/proc_fs.h
#include linux/spinlock.h
#include linux/pm.h
@@ -438,10 +439,19 @@
}
}
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq 15);
-
dev-irq = acpi_register_gsi(irq, edge_level, active_high_low);
+
+ if (via_interrupt_line_quirk) {
+ u8 old_irq, new_irq = dev-irq 0xf;
+
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, old_irq);
+ if (new_irq != old_irq) {
+ printk(KERN_INFO PREFIX Via IRQ fixup for %s, from %d
+ to %d\n, pci_name(dev), old_irq, new_irq);
+ udelay(15);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
+ }
+ }
printk(KERN_INFO PREFIX PCI interrupt %s[%c] - GSI %u
(%s, %s) - IRQ %d\n,
Unfortunatelly no. Here is the log:
Mar 11 23:47:44 kangur Linux version 2.6.11-cko1 ([EMAIL PROTECTED]) (gcc
version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)) #2
Fri Mar 11 23:32:57 CET 2005
Mar 11 23:47:44 kangur BIOS-provided physical RAM map:
Mar 11 23:47:44 kangur BIOS-e820: - 0009fc00
(usable)
Mar 11 23:47:44 kangur BIOS-e820: 0009fc00 - 000a
(reserved)
Mar 11 23:47:44 kangur BIOS-e820: 000f - 0010
(reserved)
Mar 11 23:47:44 kangur BIOS-e820: 0010 - 1fff
(usable)
Mar 11 23:47:44 kangur BIOS-e820: 1fff - 1fff3000
(ACPI NVS)
Mar 11 23:47:44 kangur BIOS-e820: 1fff3000 - 2000
(ACPI data)
Mar 11 23:47:44 kangur BIOS-e820: - 0001
(reserved)
Mar 11 23:47:44 kangur 511MB LOWMEM available.
Mar 11 23:47:44 kangur On node 0 totalpages: 131056
Mar 11 23:47:44 kangur DMA zone: 4096 pages, LIFO batch:1
Mar 11 23:47:44 kangur Normal zone: 126960 pages, LIFO batch:16
Mar 11 23:47:44 kangur HighMem zone: 0 pages, LIFO batch:1
Mar 11 23:47:44 kangur DMI 2.2 present.
Mar 11 23:47:44 kangur ACPI: RSDP (v000 761686
) @ 0x000f6a70
Mar 11 23:47:44 kangur ACPI: RSDT (v001 761686 AWRDACPI 0x42302e31 AWRD
0x) @ 0x1fff3000
Mar 11 23:47:44 kangur ACPI: FADT (v001 761686 AWRDACPI 0x42302e31 AWRD
0x) @ 0x1fff3040
Mar 11 23:47:44 kangur ACPI: DSDT (v001 761686 AWRDACPI 0x1000 MSFT
0x010c) @ 0x
Mar 11 23:47:44 kangur ACPI: PM-Timer IO Port: 0x4008
Mar 11 23:47:44 kangur Allocating PCI resources starting at 2000 (gap:
2000:dfff)
Mar 11 23:47:44 kangur Built 1 zonelists
Mar 11 23:47:44 kangur Kernel command line: ro root=/dev/hdb4
Mar 11 23:47:44 kangur Local APIC disabled by BIOS -- you can enable it
with lapic
Mar 11 23:47:44 kangur mapped APIC to d000 (01402000)
Mar 11 23:47:44 kangur Initializing CPU#0
Mar 11 23:47:44 kangur CPU 0 irqstacks, hard=b0477000 soft=b0476000
Mar 11 23:47:44 kangur PID hash table entries: 2048 (order: 11, 32768
bytes)
Mar 11 23:47:44 kangur Detected 1203.228 MHz processor.
Mar 11 23:47:44 kangur Using pmtmr for high-res timesource
Mar 11 23:47:44 kangur Console: colour VGA+ 80x25
Mar 11 23:47:44 kangur Dentry cache hash table entries: 131072 (order: 7,
524288 bytes)
Mar 11 23:47:44 kangur Inode-cache hash table entries: 65536 (order: 6,
262144 bytes)
Mar 11 23:47:44 kangur Memory: 514940k/524224k available (2543k kernel
code, 8732k reserved, 819k data, 156k init, 0k highmem)
Mar 11 23:47:44 kangur Checking
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
+ Latency: 32 (1000ns min, 63750ns max) Interrupt: pin A routed to IRQ 5 Region 0: Memory at f7001000 (32-bit, prefetchable) Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:0b.0 Class 0401: 1102:0002 (rev 08) Subsystem: 1102:8064 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: 32 (500ns min, 5000ns max) Interrupt: pin A routed to IRQ 9 Region 0: I/O ports at d000 Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:0b.1 Class 0980: 1102:7002 (rev 08) Subsystem: 1102:0020 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: 32 Region 0: I/O ports at d400 Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:0d.0 Class 0180: 1095:3112 (rev 02) Subsystem: 1095:3112 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: 32, cache line size 08 Interrupt: pin A routed to IRQ 11 Region 0: I/O ports at d800 Region 1: I/O ports at dc00 [size=4] Region 2: I/O ports at e000 [size=8] Region 3: I/O ports at e400 [size=4] Region 4: I/O ports at e800 [size=16] Region 5: Memory at f7002000 (32-bit, non-prefetchable) [size=512] Capabilities: [60] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=2 PME- :00:0f.0 Class 0200: 10ec:8139 (rev 10) Subsystem: 10ec:8139 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: 32 (8000ns min, 16000ns max) Interrupt: pin A routed to IRQ 11 Region 0: I/O ports at ec00 Region 1: Memory at f7004000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :01:05.0 Class 0300: 10de:0150 (rev a4) 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: 248 (1250ns min, 250ns max) Interrupt: pin A routed to IRQ 10 Region 0: Memory at f400 (32-bit, non-prefetchable) Region 1: Memory at e800 (32-bit, prefetchable) [size=128M] Capabilities: [60] Power Management version 1 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [44] AGP version 2.0 Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=16 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW+ Rate=x4 What do you think about this? I will try new patch in the morning. Thanks, Grzegorz Kulewski - 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: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Anything new about it? Can I provide more usefull info? Thanks, Grzegorz Kulewski On Fri, 4 Mar 2005, Andrew Morton wrote: Begin forwarded message: Date: Fri, 4 Mar 2005 21:40:19 +0100 (CET) From: Grzegorz Kulewski <[EMAIL PROTECTED]> To: linux-kernel@vger.kernel.org Subject: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB [ I posted it before but nobody anwsered... ] Hi, I just installed 2.6.11 and I was hit by the same bug (or feature?) I found in -rcs. Basically my USB will work only if acpi=off was passed to the kernel. It looks like without acpi=off it will assign IRQ 10 and with acpi=off it will assign IRQ9. It worked at least with 2.6.9. I do not know if the USB is completly broken but at least my speedtouch modem will not work (the red led will be on for some time then completly black). My lspci -vvv (2.6.11 with acpi=off): # lspci -vvv :00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-760 [IGD4-1P] System Controller (rev 13) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- :00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-760 [IGD4-1P] AGP Bridge (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B- :00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) Subsystem: ABIT Computer Corp. KG7-Lite Mainboard Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- :00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: VIA Technologies, Inc. VT82C586/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- :00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 1a) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- :00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 1a) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- :00:07.4 SMBus: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) Subsystem: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- :00:09.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- :00:09.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- :00:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 08) Subsystem: Creative Labs SB Live! 5.1 Model SB0100 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- :00:0b.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 08) Subsystem: Creative Labs Gameport Joystick Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- :00:0d.0 Unknown mass storage controller: CMD Technology Inc Silicon Image SiI 3112 SATARaid Controller (rev 02) Subsystem: CMD Technology Inc Silicon Image SiI 3112 SATARaid Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- :00:0f.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RT8139 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+
Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Anything new about it? Can I provide more usefull info? Thanks, Grzegorz Kulewski On Fri, 4 Mar 2005, Andrew Morton wrote: Begin forwarded message: Date: Fri, 4 Mar 2005 21:40:19 +0100 (CET) From: Grzegorz Kulewski [EMAIL PROTECTED] To: linux-kernel@vger.kernel.org Subject: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB [ I posted it before but nobody anwsered... ] Hi, I just installed 2.6.11 and I was hit by the same bug (or feature?) I found in -rcs. Basically my USB will work only if acpi=off was passed to the kernel. It looks like without acpi=off it will assign IRQ 10 and with acpi=off it will assign IRQ9. It worked at least with 2.6.9. I do not know if the USB is completly broken but at least my speedtouch modem will not work (the red led will be on for some time then completly black). My lspci -vvv (2.6.11 with acpi=off): # lspci -vvv :00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-760 [IGD4-1P] System Controller (rev 13) 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: 32 Region 0: Memory at f000 (32-bit, prefetchable) Region 1: Memory at f7003000 (32-bit, prefetchable) [size=4K] Region 2: I/O ports at c000 [disabled] [size=4] Capabilities: [a0] AGP version 2.0 Status: RQ=16 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW+ Rate=x4 :00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-760 [IGD4-1P] AGP Bridge (prog-if 00 [Normal decode]) 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: 32 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 I/O behind bridge: f000-0fff Memory behind bridge: f400-f5ff Prefetchable memory behind bridge: e800-efff BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- Reset- FastB2B- :00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) Subsystem: ABIT Computer Corp. KG7-Lite Mainboard 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 Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: VIA Technologies, Inc. VT82C586/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE 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: 32 Region 4: I/O ports at c400 [size=16] Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 1a) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller 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: 32, cache line size 08 Interrupt: pin D routed to IRQ 9 Region 4: I/O ports at c800 [size=32] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 1a) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller 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: 32, cache line size 08 Interrupt: pin D routed to IRQ 9 Region 4: I/O ports at cc00 [size=32] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:07.4 SMBus: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) Subsystem: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] 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 ? routed to IRQ
Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
1:45:48 kangur usbcore: registered new driver usbfs Mar 3 01:45:48 kangur usbcore: registered new driver hub Mar 3 01:45:48 kangur PCI: Found IRQ 9 for device :00:0b.0 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:07.2 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:07.3 Mar 3 01:45:48 kangur parport_pc: VIA 686A/8231 detected Mar 3 01:45:48 kangur parport_pc: probing current configuration Mar 3 01:45:48 kangur parport_pc: Current parallel port base: 0x378 Mar 3 01:45:48 kangur parport_pc: Strange, can't probe VIA parallel port: io=0x378, irq=7, dma=-1 Mar 3 01:45:48 kangur pnp: the driver 'parport_pc' has been registered Mar 3 01:45:48 kangur parport0: PC-style at 0x378 [PCSPP(,...)] Mar 3 01:45:48 kangur USB Universal Host Controller Interface driver v2.2 Mar 3 01:45:48 kangur PCI: Found IRQ 9 for device :00:07.2 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:07.3 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:0b.0 Mar 3 01:45:48 kangur uhci_hcd :00:07.2: UHCI Host Controller Mar 3 01:45:48 kangur uhci_hcd :00:07.2: irq 9, io base 0xc800 Mar 3 01:45:48 kangur uhci_hcd :00:07.2: new USB bus registered, assigned bus number 1 Mar 3 01:45:48 kangur hub 1-0:1.0: USB hub found Mar 3 01:45:48 kangur hub 1-0:1.0: 2 ports detected Mar 3 01:45:48 kangur PCI: Found IRQ 9 for device :00:07.3 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:07.2 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:0b.0 Mar 3 01:45:48 kangur uhci_hcd :00:07.3: UHCI Host Controller Mar 3 01:45:48 kangur uhci_hcd :00:07.3: irq 9, io base 0xcc00 Mar 3 01:45:48 kangur uhci_hcd :00:07.3: new USB bus registered, assigned bus number 2 Mar 3 01:45:48 kangur hub 2-0:1.0: USB hub found Mar 3 01:45:48 kangur hub 2-0:1.0: 2 ports detected Mar 3 01:45:48 kangur usb 1-2: new full speed USB device using uhci_hcd and address 2 Could somebody produce fast patch for me? Thanks in advance, Grzegorz Kulewski - 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/
Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
on ep0out Mar 2 23:36:56 kangur usb 1-2: khubd timed out on ep0out Mar 2 23:36:56 kangur usb 1-2: device not accepting address 3, error -110 My log (2.6.11 with acpi=off): Mar 3 01:45:48 kangur usbcore: registered new driver usbfs Mar 3 01:45:48 kangur usbcore: registered new driver hub Mar 3 01:45:48 kangur PCI: Found IRQ 9 for device :00:0b.0 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:07.2 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:07.3 Mar 3 01:45:48 kangur parport_pc: VIA 686A/8231 detected Mar 3 01:45:48 kangur parport_pc: probing current configuration Mar 3 01:45:48 kangur parport_pc: Current parallel port base: 0x378 Mar 3 01:45:48 kangur parport_pc: Strange, can't probe VIA parallel port: io=0x378, irq=7, dma=-1 Mar 3 01:45:48 kangur pnp: the driver 'parport_pc' has been registered Mar 3 01:45:48 kangur parport0: PC-style at 0x378 [PCSPP(,...)] Mar 3 01:45:48 kangur USB Universal Host Controller Interface driver v2.2 Mar 3 01:45:48 kangur PCI: Found IRQ 9 for device :00:07.2 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:07.3 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:0b.0 Mar 3 01:45:48 kangur uhci_hcd :00:07.2: UHCI Host Controller Mar 3 01:45:48 kangur uhci_hcd :00:07.2: irq 9, io base 0xc800 Mar 3 01:45:48 kangur uhci_hcd :00:07.2: new USB bus registered, assigned bus number 1 Mar 3 01:45:48 kangur hub 1-0:1.0: USB hub found Mar 3 01:45:48 kangur hub 1-0:1.0: 2 ports detected Mar 3 01:45:48 kangur PCI: Found IRQ 9 for device :00:07.3 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:07.2 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:0b.0 Mar 3 01:45:48 kangur uhci_hcd :00:07.3: UHCI Host Controller Mar 3 01:45:48 kangur uhci_hcd :00:07.3: irq 9, io base 0xcc00 Mar 3 01:45:48 kangur uhci_hcd :00:07.3: new USB bus registered, assigned bus number 2 Mar 3 01:45:48 kangur hub 2-0:1.0: USB hub found Mar 3 01:45:48 kangur hub 2-0:1.0: 2 ports detected Mar 3 01:45:48 kangur usb 1-2: new full speed USB device using uhci_hcd and address 2 Could somebody produce fast patch for me? Thanks in advance, Grzegorz Kulewski - 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.11 (stable and -rc) ACPI breaks USB
= 3) is a 16550A Mar 2 23:36:56 kangur usb 1-2: khubd timed out on ep0out Mar 2 23:36:56 kangur eth0: link down Mar 2 23:36:56 kangur eth0: link down Mar 2 23:36:56 kangur usb 1-2: khubd timed out on ep0out Mar 2 23:36:56 kangur usb 1-2: device not accepting address 2, error -110 Mar 2 23:36:56 kangur usb 1-2: new full speed USB device using uhci_hcd and address 3 Mar 2 23:36:56 kangur usb 1-2: khubd timed out on ep0in Mar 2 23:36:56 kangur usb 1-2: khubd timed out on ep0out Mar 2 23:36:56 kangur usb 1-2: khubd timed out on ep0out Mar 2 23:36:56 kangur usb 1-2: device not accepting address 3, error -110 My log (2.6.11 with acpi=off): Mar 3 01:45:48 kangur usbcore: registered new driver usbfs Mar 3 01:45:48 kangur usbcore: registered new driver hub Mar 3 01:45:48 kangur PCI: Found IRQ 9 for device :00:0b.0 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:07.2 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:07.3 Mar 3 01:45:48 kangur parport_pc: VIA 686A/8231 detected Mar 3 01:45:48 kangur parport_pc: probing current configuration Mar 3 01:45:48 kangur parport_pc: Current parallel port base: 0x378 Mar 3 01:45:48 kangur parport_pc: Strange, can't probe VIA parallel port: io=0x378, irq=7, dma=-1 Mar 3 01:45:48 kangur pnp: the driver 'parport_pc' has been registered Mar 3 01:45:48 kangur parport0: PC-style at 0x378 [PCSPP(,...)] Mar 3 01:45:48 kangur USB Universal Host Controller Interface driver v2.2 Mar 3 01:45:48 kangur PCI: Found IRQ 9 for device :00:07.2 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:07.3 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:0b.0 Mar 3 01:45:48 kangur uhci_hcd :00:07.2: UHCI Host Controller Mar 3 01:45:48 kangur uhci_hcd :00:07.2: irq 9, io base 0xc800 Mar 3 01:45:48 kangur uhci_hcd :00:07.2: new USB bus registered, assigned bus number 1 Mar 3 01:45:48 kangur hub 1-0:1.0: USB hub found Mar 3 01:45:48 kangur hub 1-0:1.0: 2 ports detected Mar 3 01:45:48 kangur PCI: Found IRQ 9 for device :00:07.3 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:07.2 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:0b.0 Mar 3 01:45:48 kangur uhci_hcd :00:07.3: UHCI Host Controller Mar 3 01:45:48 kangur uhci_hcd :00:07.3: irq 9, io base 0xcc00 Mar 3 01:45:48 kangur uhci_hcd :00:07.3: new USB bus registered, assigned bus number 2 Mar 3 01:45:48 kangur hub 2-0:1.0: USB hub found Mar 3 01:45:48 kangur hub 2-0:1.0: 2 ports detected Mar 3 01:45:48 kangur usb 1-2: new full speed USB device using uhci_hcd and address 2 Could somebody produce fast patch for me? Thanks in advance, Grzegorz Kulewski - 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.11 (stable and -rc) ACPI breaks USB
kangur ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Mar 2 23:36:56 kangur pnp: match found with the PnP device '00:08' and the driver 'serial' Mar 2 23:36:56 kangur ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A Mar 2 23:36:56 kangur usb 1-2: khubd timed out on ep0out Mar 2 23:36:56 kangur eth0: link down Mar 2 23:36:56 kangur eth0: link down Mar 2 23:36:56 kangur usb 1-2: khubd timed out on ep0out Mar 2 23:36:56 kangur usb 1-2: device not accepting address 2, error -110 Mar 2 23:36:56 kangur usb 1-2: new full speed USB device using uhci_hcd and address 3 Mar 2 23:36:56 kangur usb 1-2: khubd timed out on ep0in Mar 2 23:36:56 kangur usb 1-2: khubd timed out on ep0out Mar 2 23:36:56 kangur usb 1-2: khubd timed out on ep0out Mar 2 23:36:56 kangur usb 1-2: device not accepting address 3, error -110 My log (2.6.11 with acpi=off): Mar 3 01:45:48 kangur usbcore: registered new driver usbfs Mar 3 01:45:48 kangur usbcore: registered new driver hub Mar 3 01:45:48 kangur PCI: Found IRQ 9 for device :00:0b.0 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:07.2 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:07.3 Mar 3 01:45:48 kangur parport_pc: VIA 686A/8231 detected Mar 3 01:45:48 kangur parport_pc: probing current configuration Mar 3 01:45:48 kangur parport_pc: Current parallel port base: 0x378 Mar 3 01:45:48 kangur parport_pc: Strange, can't probe VIA parallel port: io=0x378, irq=7, dma=-1 Mar 3 01:45:48 kangur pnp: the driver 'parport_pc' has been registered Mar 3 01:45:48 kangur parport0: PC-style at 0x378 [PCSPP(,...)] Mar 3 01:45:48 kangur USB Universal Host Controller Interface driver v2.2 Mar 3 01:45:48 kangur PCI: Found IRQ 9 for device :00:07.2 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:07.3 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:0b.0 Mar 3 01:45:48 kangur uhci_hcd :00:07.2: UHCI Host Controller Mar 3 01:45:48 kangur uhci_hcd :00:07.2: irq 9, io base 0xc800 Mar 3 01:45:48 kangur uhci_hcd :00:07.2: new USB bus registered, assigned bus number 1 Mar 3 01:45:48 kangur hub 1-0:1.0: USB hub found Mar 3 01:45:48 kangur hub 1-0:1.0: 2 ports detected Mar 3 01:45:48 kangur PCI: Found IRQ 9 for device :00:07.3 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:07.2 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:0b.0 Mar 3 01:45:48 kangur uhci_hcd :00:07.3: UHCI Host Controller Mar 3 01:45:48 kangur uhci_hcd :00:07.3: irq 9, io base 0xcc00 Mar 3 01:45:48 kangur uhci_hcd :00:07.3: new USB bus registered, assigned bus number 2 Mar 3 01:45:48 kangur hub 2-0:1.0: USB hub found Mar 3 01:45:48 kangur hub 2-0:1.0: 2 ports detected Mar 3 01:45:48 kangur usb 1-2: new full speed USB device using uhci_hcd and address 2 Could somebody produce fast patch for me? Thanks in advance, Grzegorz Kulewski - 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: Kylix application no longer works?
On Mon, 7 Feb 2005, Andrew Morton wrote: Daniel Drake <[EMAIL PROTECTED]> wrote: # fs/binfmt_elf.c # 2005/01/17 13:37:56-08:00 [EMAIL PROTECTED] +43 -19 # [SPARC64]: Missing user access return value checks in fs/binfmt_elf.c and fs/compat.c # I think so. For a short period we applied this patch to the Gentoo 2.6.10 kernel... http://dev.gentoo.org/~dsd/gentoo-dev-sources/release-10.01/dist/1900_umem_catch.patch ...but removed it once users complained it stopped kylix binaries from running. Bah. That's what happens when you fix stuff. What's kylix? The Borland C++ builder thing? Rather Delphi (== Object Pascal) thing. How should one set about reproducing this problem? IIRC, Some minimal "personal" version can be downloaded from borland.com. Grzegorz Kulewski - 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: Kylix application no longer works?
On Mon, 7 Feb 2005, Andrew Morton wrote: Daniel Drake [EMAIL PROTECTED] wrote: # fs/binfmt_elf.c # 2005/01/17 13:37:56-08:00 [EMAIL PROTECTED] +43 -19 # [SPARC64]: Missing user access return value checks in fs/binfmt_elf.c and fs/compat.c # I think so. For a short period we applied this patch to the Gentoo 2.6.10 kernel... http://dev.gentoo.org/~dsd/gentoo-dev-sources/release-10.01/dist/1900_umem_catch.patch ...but removed it once users complained it stopped kylix binaries from running. Bah. That's what happens when you fix stuff. What's kylix? The Borland C++ builder thing? Rather Delphi (== Object Pascal) thing. How should one set about reproducing this problem? IIRC, Some minimal personal version can be downloaded from borland.com. Grzegorz Kulewski - 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/
