Re: Part I of Lameness...
> General bitching pisses me off, especially when you are dead wrong. A little maturity goes a long way. - 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: Part I of Lameness...
General bitching pisses me off, especially when you are dead wrong. A little maturity goes a long way. - 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: REVISED: Experimentation with Athlon and fast_page_copy
> What still stands out is that exactly _zero_ people have reported the same > problem with non VIA chipset Athlons. This might be grasping at straws I remember VIA problem in the "good old days" of Socket 7 with CPU/PCI Prefetches and especially Read-around-Write settings that would cause issues like we're seeing with the Athlon pre-fetches. This could be (total conjecture) related somehow to the corruption bugs they are admitting to in the 686B although they are blaming the SB Live now. - 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: REVISED: Experimentation with Athlon and fast_page_copy
What still stands out is that exactly _zero_ people have reported the same problem with non VIA chipset Athlons. This might be grasping at straws I remember VIA problem in the good old days of Socket 7 with CPU/PCI Prefetches and especially Read-around-Write settings that would cause issues like we're seeing with the Athlon pre-fetches. This could be (total conjecture) related somehow to the corruption bugs they are admitting to in the 686B although they are blaming the SB Live now. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac22
> o Fix ppp memory corruption (Kevin Buhr) > | Bizzarely enough a direct re-invention of a 1.2 ppp bug Could this explain my MPPP skb corruption I've reported since 2.3.x? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac22
o Fix ppp memory corruption (Kevin Buhr) | Bizzarely enough a direct re-invention of a 1.2 ppp bug Could this explain my MPPP skb corruption I've reported since 2.3.x? - 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 2.4.3 and new aic7xxx
> I suspect it's easier to just make the PCI layer call the probe function > in that order, instead of working around it in your driver. Jeff? Would 'pci=reverse' do the trick already? - 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 2.4.3 and new aic7xxx
I suspect it's easier to just make the PCI layer call the probe function in that order, instead of working around it in your driver. Jeff? Would 'pci=reverse' do the trick already? - 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] New version of the WRR network scheduler
Umm.. where is it located? :) - 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] New version of the WRR network scheduler
Umm.. where is it located? :) - 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: XOR [ was: Linux stifles innovation.]
| Since that time, about 1986, I learned that there is a whole cottage | industry of going through old, but not too old, patents and seeing how | they can be misconstrued to apply to current technology, buying the | patent for cheap, and then threatening "infringers". More or less | an extortion racket. Generally the license fee demanded is low enough | that is more cost effective, in the short term, to pay. And with | shareholder lawsuits the way they are, short term thinking | is the only thinking shareholders accept, and the extortionists | know it. Those of them that didn't end up in jail went on to form RAMBUS in the 90s. - 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: XOR [ was: Linux stifles innovation.]
| Since that time, about 1986, I learned that there is a whole cottage | industry of going through old, but not too old, patents and seeing how | they can be misconstrued to apply to current technology, buying the | patent for cheap, and then threatening "infringers". More or less | an extortion racket. Generally the license fee demanded is low enough | that is more cost effective, in the short term, to pay. And with | shareholder lawsuits the way they are, short term thinking | is the only thinking shareholders accept, and the extortionists | know it. Those of them that didn't end up in jail went on to form RAMBUS in the 90s. - 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: XOR [ was: Linux stifles innovation.]
| Since that time, about 1986, I learned that there is a whole cottage | industry of going through old, but not too old, patents and seeing how | they can be misconstrued to apply to current technology, buying the | patent for cheap, and then threatening "infringers". More or less | an extortion racket. Generally the license fee demanded is low enough | that is more cost effective, in the short term, to pay. And with | shareholder lawsuits the way they are, short term thinking | is the only thinking shareholders accept, and the extortionists | know it. Those of them that didn't end up in jail went on to form RAMBUS in the 90s. - 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: XOR [ was: Linux stifles innovation.]
| Since that time, about 1986, I learned that there is a whole cottage | industry of going through old, but not too old, patents and seeing how | they can be misconstrued to apply to current technology, buying the | patent for cheap, and then threatening "infringers". More or less | an extortion racket. Generally the license fee demanded is low enough | that is more cost effective, in the short term, to pay. And with | shareholder lawsuits the way they are, short term thinking | is the only thinking shareholders accept, and the extortionists | know it. Those of them that didn't end up in jail went on to form RAMBUS in the 90s. - 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.4.0-test12: SiS pirq handling..
| > Problem still exists, diffed to last kernel: | Yes. But everything works for you, no? Including USB? Mmmhmm.. | The problem is that you have this routing table entry: | | 00:01 slot=00 0:62/1eb8 1:00/ 2:00/ 3:00/ | | which is really for the USB chip (PCI id 00:01.2), and which the PCI code | _does_ find for the USB chip. So it should set up the routing happily, and | everything should be ok. Leave it to me to have goofy hardware.. :) | Basically, the way your chipset is laid out PCI-wise, they are | subfunctions of the same device (subfunction 1 is IDE, subfunction 2 is | USB. Because of this they share an irq routing entry, and if they were to | NOT clash they should have been given separate "irq pin" numbers in their | config space. So a _good_ routing entry might have looked like | | 00:01 slot=00 0:fe/4000 1:62/1eb8 2:00/ 3:00/ | | where the IDE device has "irqpin=1" and the USB device has "irqpin=2", and | USB points to link 62, while IDE points to link fe (ie "hardcode to 14"). Does anyone know who to prod at ASUS to maybe update their BIOS with a proper routing table? Maybe even adding proper K6-2+/K6-3+ ids in the BIOS (we can dream I suppose).. This is a simple packet-pumping routing box so one of those chips would be overkill anyway. | Now, will the two people in the world who know the pirq black magic now | stand up and confirm or deride my interpretation? It sounds correct to me.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12: SiS pirq handling..
| Could people that had problems with SiS interrupt handling before please | give 2.4.0-test12 a final whirl before I release it as 2.4.1? We got a lot | of pirq tables from people, and Martin Diehl put them together with the | hardware specs to come up with what looks to be the "final and correct" | SiS pirq routing, but as always it would be good to have this verified by | as many people as possible. Linux version 2.4.1-pre12 ([EMAIL PROTECTED]) (gcc version 2.95.3 20010125 (prerelease)) #2 Mon Jan 29 17:53:38 EST 2001 BIOS-provided physical RAM map: BIOS-e820: 000a @ (usable) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 03efd000 @ 0010 (usable) BIOS-e820: 2000 @ 03ffd000 (ACPI data) BIOS-e820: 1000 @ 03fff000 (ACPI NVS) BIOS-e820: 0001 @ (reserved) On node 0 totalpages: 16381 zone(0): 4096 pages. zone(1): 12285 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=lnew ro root=341 BOOT_FILE=/home/kernel/kernel/linux/arch/i386/boot/bzImage Initializing CPU#0 Detected 374.229 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 747.11 BogoMIPS Memory: 62404k/65524k available (928k kernel code, 2736k reserved, 312k data, 180k init, 0k highmem) Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) VFS: Diskquotas version dquot_6.4.0 initialized CPU: Before vendor init, caps: 008021bf 808029bf , vendor = 2 CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line) CPU: After vendor init, caps: 008021bf 808029bf 0002 CPU: After generic, caps: 008021bf 808029bf 0002 CPU: Common caps: 008021bf 808029bf 0002 CPU: AMD-K6(tm) 3D processor stepping 0c Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: AMD K6 PCI: BIOS32 Service Directory structure at 0xc00f9b50 PCI: BIOS32 Service Directory entry at 0xf04d0 PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=00 PCI: PCI BIOS revision 2.10 entry at 0xf0500, last bus=0 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Setting max latency to 32 PCI: IDE base address trash cleared for 00:01.1 PCI: IDE base address fixup for 00:01.1 PCI: Scanning for ghost devices on bus 0 PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00f0af0 00:0c slot=01 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8 00:0b slot=02 0:42/1eb8 1:43/1eb8 2:44/1eb8 3:41/1eb8 00:0a slot=03 0:43/1eb8 1:44/1eb8 2:41/1eb8 3:42/1eb8 00:09 slot=04 0:44/1eb8 1:41/1eb8 2:42/1eb8 3:43/1eb8 00:01 slot=00 0:62/1eb8 1:00/ 2:00/ 3:00/ 00:13 slot=00 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8 PCI: Using IRQ router SIS [1039/0008] at 00:01.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource d000-d00f (f=101, d=0, p=0) PCI: Resource dd00-dd000fff (f=200, d=0, p=0) PCI: Resource b800-b807 (f=101, d=0, p=0) PCI: Resource dc80-dc87 (f=200, d=0, p=0) PCI: Resource e000-e7ff (f=1208, d=0, p=0) PCI: Resource df00-df000fff (f=1208, d=0, p=0) PCI: Resource b400-b41f (f=101, d=0, p=0) PCI: Resource dc00-dc0f (f=200, d=0, p=0) PCI: Resource de00-de3f (f=1208, d=1, p=1) PCI: Resource db80-db80 (f=200, d=1, p=1) PCI: Resource b000-b07f (f=101, d=1, p=1) PCI: Sorting device list... Disabling direct PCI/PCI transfers. isapnp: Scanning for Pnp cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket DMI 2.0 present. 28 structures occupying 890 bytes. DMI table at 0x000F540A. BIOS Vendor: Award Software, Inc. BIOS Version: ASUS SP97-V ACPI BIOS Revision 1001 B03/18/99 BIOS Release: System Vendor: System Manufacturer. Product Name: System Name. Version System Version. Serial Number SYS-1234567890. Board Vendor: ASUSTeK Computer INC.. Board Name: SP97-V. Board Version: REV 1.XX. Asset Tag: Asset-1234567890. apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 41365kB/13788kB, 128 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx SIS5513: IDE controller on PCI bus 00 dev 09 IRQ for 00:01.1:0 -> PIRQ 62, mask 1eb8, excl -> newirq=10 -> got IRQ 7 PCI: Found IRQ 7 for device 00:01.1 IRQ routing conflict in pirq table for device 00:01.1 PCI: The same IRQ used for device 00:01.2 SIS5513: chipset revision 208 SIS5513: not 100% native mode: will probe irqs later SiS5597 ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at
Re: 2.4.0-test12: SiS pirq handling..
| Problem still exists, diffed to last kernel: | Yes. But everything works for you, no? Including USB? Mmmhmm.. | The problem is that you have this routing table entry: | | 00:01 slot=00 0:62/1eb8 1:00/ 2:00/ 3:00/ | | which is really for the USB chip (PCI id 00:01.2), and which the PCI code | _does_ find for the USB chip. So it should set up the routing happily, and | everything should be ok. Leave it to me to have goofy hardware.. :) | Basically, the way your chipset is laid out PCI-wise, they are | subfunctions of the same device (subfunction 1 is IDE, subfunction 2 is | USB. Because of this they share an irq routing entry, and if they were to | NOT clash they should have been given separate "irq pin" numbers in their | config space. So a _good_ routing entry might have looked like | | 00:01 slot=00 0:fe/4000 1:62/1eb8 2:00/ 3:00/ | | where the IDE device has "irqpin=1" and the USB device has "irqpin=2", and | USB points to link 62, while IDE points to link fe (ie "hardcode to 14"). Does anyone know who to prod at ASUS to maybe update their BIOS with a proper routing table? Maybe even adding proper K6-2+/K6-3+ ids in the BIOS (we can dream I suppose).. This is a simple packet-pumping routing box so one of those chips would be overkill anyway. | Now, will the two people in the world who know the pirq black magic now | stand up and confirm or deride my interpretation? It sounds correct to me.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI IRQ routing problem in 2.4.0 (SiS results part 2)
| Which one was it you got a PIRQ conflict for before? as it te device at | 00:01.00 with the strange "0x62" entry? Yes. | How about you try adding the line | pirq = (pirq-1) & 3; | at the top of both pirq_sis_get() and pirq_sis_set() (with my "alternate" | SiS routines). What happens then? Done. Linux version 2.4.0-ac12 ([EMAIL PROTECTED]) (gcc version 2.95.3 20010125 (prerelease)) #4 Mon Jan 29 01:53:12 EST 2001 BIOS-provided physical RAM map: BIOS-e820: 000a @ (usable) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 03efd000 @ 0010 (usable) BIOS-e820: 2000 @ 03ffd000 (ACPI data) BIOS-e820: 1000 @ 03fff000 (ACPI NVS) BIOS-e820: 0001 @ (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c000 for 4096 bytes. On node 0 totalpages: 16381 zone(0): 4096 pages. zone(1): 12285 pages. zone(2): 0 pages. APIC turned off by hardware. mapped APIC to e000 (01112000) Kernel command line: auto BOOT_IMAGE=lnew ro root=341 BOOT_FILE=/home/kernel/kernel/linux/arch/i386/boot/bzImage Initializing CPU#0 Detected 374.227 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 747.11 BogoMIPS Memory: 62368k/65524k available (940k kernel code, 2772k reserved, 327k data, 188k init, 0k highmem) Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) VFS: Diskquotas version dquot_6.5.0 initialized CPU: Before vendor init, caps: 008021bf 808029bf , vendor = 2 CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line) CPU: After vendor init, caps: 008021bf 808029bf 0002 CPU: After generic, caps: 008021bf 808029bf 0002 CPU: Common caps: 008021bf 808029bf 0002 CPU: AMD-K6(tm) 3D processor stepping 0c Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: AMD K6 PCI: BIOS32 Service Directory structure at 0xc00f9b50 PCI: BIOS32 Service Directory entry at 0xf04d0 PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=00 PCI: PCI BIOS revision 2.10 entry at 0xf0500, last bus=0 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Setting max latency to 32 PCI: IDE base address trash cleared for 00:01.1 PCI: IDE base address fixup for 00:01.1 PCI: Scanning for ghost devices on bus 0 PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00f0af0 00:0c slot=01 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8 00:0b slot=02 0:42/1eb8 1:43/1eb8 2:44/1eb8 3:41/1eb8 00:0a slot=03 0:43/1eb8 1:44/1eb8 2:41/1eb8 3:42/1eb8 00:09 slot=04 0:44/1eb8 1:41/1eb8 2:42/1eb8 3:43/1eb8 00:01 slot=00 0:62/1eb8 1:00/ 2:00/ 3:00/ 00:13 slot=00 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8 PCI: Using IRQ router SIS [1039/0008] at 00:01.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource d000-d00f (f=101, d=0, p=0) PCI: Resource dd00-dd000fff (f=200, d=0, p=0) PCI: Resource b800-b807 (f=101, d=0, p=0) PCI: Resource dc80-dc87 (f=200, d=0, p=0) PCI: Resource e000-e7ff (f=1208, d=0, p=0) PCI: Resource df00-df000fff (f=1208, d=0, p=0) PCI: Resource b400-b41f (f=101, d=0, p=0) PCI: Resource dc00-dc0f (f=200, d=0, p=0) PCI: Resource de00-de3f (f=1208, d=1, p=1) PCI: Resource db80-db80 (f=200, d=1, p=1) PCI: Resource b000-b07f (f=101, d=1, p=1) PCI: Sorting device list... Disabling direct PCI/PCI transfers. isapnp: Scanning for Pnp cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 41341kB/31006kB, 128 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx SIS5513: IDE controller on PCI bus 00 dev 09 IRQ for 00:01.1:0 -> PIRQ 62, mask 1eb8, excl -> newirq=10 -> got IRQ 10 PCI: Found IRQ 10 for device 00:01.1 PCI: The same IRQ used for device 00:01.2 SIS5513: chipset revision 208 SIS5513: not 100% native mode: will probe irqs later SiS5597 ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio keyboard: Timeout - AT keyboard not present? keyboard: Timeout - AT keyboard not present? hda: ST5660A, ATA DISK drive hdb: IBM-DJAA-31700, ATA DISK drive hdc: Maxtor 72700 AP, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 1066184 sectors (546 MB) w/256KiB
Re: PCI IRQ routing problem in 2.4.0 (SiS results part 2)
| Which one was it you got a PIRQ conflict for before? as it te device at | 00:01.00 with the strange "0x62" entry? Yes. | How about you try adding the line | pirq = (pirq-1) & 3; | at the top of both pirq_sis_get() and pirq_sis_set() (with my "alternate" | SiS routines). What happens then? Done. Linux version 2.4.0-ac12 ([EMAIL PROTECTED]) (gcc version 2.95.3 20010125 (prerelease)) #4 Mon Jan 29 01:53:12 EST 2001 BIOS-provided physical RAM map: BIOS-e820: 000a @ (usable) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 03efd000 @ 0010 (usable) BIOS-e820: 2000 @ 03ffd000 (ACPI data) BIOS-e820: 1000 @ 03fff000 (ACPI NVS) BIOS-e820: 0001 @ (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c000 for 4096 bytes. On node 0 totalpages: 16381 zone(0): 4096 pages. zone(1): 12285 pages. zone(2): 0 pages. APIC turned off by hardware. mapped APIC to e000 (01112000) Kernel command line: auto BOOT_IMAGE=lnew ro root=341 BOOT_FILE=/home/kernel/kernel/linux/arch/i386/boot/bzImage Initializing CPU#0 Detected 374.227 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 747.11 BogoMIPS Memory: 62368k/65524k available (940k kernel code, 2772k reserved, 327k data, 188k init, 0k highmem) Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) VFS: Diskquotas version dquot_6.5.0 initialized CPU: Before vendor init, caps: 008021bf 808029bf , vendor = 2 CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line) CPU: After vendor init, caps: 008021bf 808029bf 0002 CPU: After generic, caps: 008021bf 808029bf 0002 CPU: Common caps: 008021bf 808029bf 0002 CPU: AMD-K6(tm) 3D processor stepping 0c Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: AMD K6 PCI: BIOS32 Service Directory structure at 0xc00f9b50 PCI: BIOS32 Service Directory entry at 0xf04d0 PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=00 PCI: PCI BIOS revision 2.10 entry at 0xf0500, last bus=0 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Setting max latency to 32 PCI: IDE base address trash cleared for 00:01.1 PCI: IDE base address fixup for 00:01.1 PCI: Scanning for ghost devices on bus 0 PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00f0af0 00:0c slot=01 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8 00:0b slot=02 0:42/1eb8 1:43/1eb8 2:44/1eb8 3:41/1eb8 00:0a slot=03 0:43/1eb8 1:44/1eb8 2:41/1eb8 3:42/1eb8 00:09 slot=04 0:44/1eb8 1:41/1eb8 2:42/1eb8 3:43/1eb8 00:01 slot=00 0:62/1eb8 1:00/ 2:00/ 3:00/ 00:13 slot=00 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8 PCI: Using IRQ router SIS [1039/0008] at 00:01.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource d000-d00f (f=101, d=0, p=0) PCI: Resource dd00-dd000fff (f=200, d=0, p=0) PCI: Resource b800-b807 (f=101, d=0, p=0) PCI: Resource dc80-dc87 (f=200, d=0, p=0) PCI: Resource e000-e7ff (f=1208, d=0, p=0) PCI: Resource df00-df000fff (f=1208, d=0, p=0) PCI: Resource b400-b41f (f=101, d=0, p=0) PCI: Resource dc00-dc0f (f=200, d=0, p=0) PCI: Resource de00-de3f (f=1208, d=1, p=1) PCI: Resource db80-db80 (f=200, d=1, p=1) PCI: Resource b000-b07f (f=101, d=1, p=1) PCI: Sorting device list... Disabling direct PCI/PCI transfers. isapnp: Scanning for Pnp cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 41341kB/31006kB, 128 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx SIS5513: IDE controller on PCI bus 00 dev 09 IRQ for 00:01.1:0 -> PIRQ 62, mask 1eb8, excl -> newirq=10 -> got IRQ 10 PCI: Found IRQ 10 for device 00:01.1 PCI: The same IRQ used for device 00:01.2 SIS5513: chipset revision 208 SIS5513: not 100% native mode: will probe irqs later SiS5597 ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio keyboard: Timeout - AT keyboard not present? keyboard: Timeout - AT keyboard not present? hda: ST5660A, ATA DISK drive hdb: IBM-DJAA-31700, ATA DISK drive hdc: Maxtor 72700 AP, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 1066184 sectors (546 MB) w/256KiB
Re: PCI IRQ routing problem in 2.4.0 (SiS results)
| Your "link" values are in the range 1-4. Which makes perfect sense, but | that's absolutely _not_ what the Linux SiS routing code expects (the code | seems to expect them to be ASCII 'A' - 'D'). | It looks very much like "pirq_sis_get()" and "pirq_sis_set()" in | arch/i386/kernel/pci-irq.c are broken for your setup. My ASUS SP97-V complains about PIRQ conflicts so I gave this a whirl (It is SiS 5598 based) | Anybody else with SiS chipsets that want to try the above? Please.. Here is my dmesg: Linux version 2.4.0-ac12 ([EMAIL PROTECTED]) (gcc version 2.95.3 20010125 (prerelease)) #3 Mon Jan 29 00:16:07 EST 2001 BIOS-provided physical RAM map: BIOS-e820: 000a @ (usable) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 03efd000 @ 0010 (usable) BIOS-e820: 2000 @ 03ffd000 (ACPI data) BIOS-e820: 1000 @ 03fff000 (ACPI NVS) BIOS-e820: 0001 @ (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c000 for 4096 bytes. On node 0 totalpages: 16381 zone(0): 4096 pages. zone(1): 12285 pages. zone(2): 0 pages. APIC turned off by hardware. mapped APIC to e000 (01112000) Kernel command line: auto BOOT_IMAGE=lnew ro root=341 BOOT_FILE=/home/kernel/kernel/linux/arch/i386/boot/bzImage Initializing CPU#0 Detected 374.229 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 747.11 BogoMIPS Memory: 62368k/65524k available (940k kernel code, 2772k reserved, 327k data, 188k init, 0k highmem) Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) VFS: Diskquotas version dquot_6.5.0 initialized CPU: Before vendor init, caps: 008021bf 808029bf , vendor = 2 CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line) CPU: After vendor init, caps: 008021bf 808029bf 0002 CPU: After generic, caps: 008021bf 808029bf 0002 CPU: Common caps: 008021bf 808029bf 0002 CPU: AMD-K6(tm) 3D processor stepping 0c Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: AMD K6 PCI: BIOS32 Service Directory structure at 0xc00f9b50 PCI: BIOS32 Service Directory entry at 0xf04d0 PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=00 PCI: PCI BIOS revision 2.10 entry at 0xf0500, last bus=0 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Setting max latency to 32 PCI: IDE base address trash cleared for 00:01.1 PCI: IDE base address fixup for 00:01.1 PCI: Scanning for ghost devices on bus 0 PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00f0af0 00:0c slot=01 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8 00:0b slot=02 0:42/1eb8 1:43/1eb8 2:44/1eb8 3:41/1eb8 00:0a slot=03 0:43/1eb8 1:44/1eb8 2:41/1eb8 3:42/1eb8 00:09 slot=04 0:44/1eb8 1:41/1eb8 2:42/1eb8 3:43/1eb8 00:01 slot=00 0:62/1eb8 1:00/ 2:00/ 3:00/ 00:13 slot=00 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8 PCI: Using IRQ router SIS [1039/0008] at 00:01.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource d000-d00f (f=101, d=0, p=0) PCI: Resource dd00-dd000fff (f=200, d=0, p=0) PCI: Resource b800-b807 (f=101, d=0, p=0) PCI: Resource dc80-dc87 (f=200, d=0, p=0) PCI: Resource e000-e7ff (f=1208, d=0, p=0) PCI: Resource df00-df000fff (f=1208, d=0, p=0) PCI: Resource b400-b41f (f=101, d=0, p=0) PCI: Resource dc00-dc0f (f=200, d=0, p=0) PCI: Resource de00-de3f (f=1208, d=1, p=1) PCI: Resource db80-db80 (f=200, d=1, p=1) PCI: Resource b000-b07f (f=101, d=1, p=1) PCI: Sorting device list... Disabling direct PCI/PCI transfers. isapnp: Scanning for Pnp cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 41341kB/31006kB, 128 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx SIS5513: IDE controller on PCI bus 00 dev 09 IRQ for 00:01.1:0 -> PIRQ 62, mask 1eb8, excl -> newirq=10Unknown SiS pirq value 98 -> assigning IRQ 10Unknown SiS pirq value 98 ... failed SIS5513: chipset revision 208 SIS5513: not 100% native mode: will probe irqs later SiS5597 ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio keyboard: Timeout - AT keyboard not present? keyboard: Timeout - AT keyboard not present? hda: ST5660A, ATA
Re: PCI IRQ routing problem in 2.4.0 (SiS results)
| Your "link" values are in the range 1-4. Which makes perfect sense, but | that's absolutely _not_ what the Linux SiS routing code expects (the code | seems to expect them to be ASCII 'A' - 'D'). | It looks very much like "pirq_sis_get()" and "pirq_sis_set()" in | arch/i386/kernel/pci-irq.c are broken for your setup. My ASUS SP97-V complains about PIRQ conflicts so I gave this a whirl (It is SiS 5598 based) | Anybody else with SiS chipsets that want to try the above? Please.. Here is my dmesg: Linux version 2.4.0-ac12 ([EMAIL PROTECTED]) (gcc version 2.95.3 20010125 (prerelease)) #3 Mon Jan 29 00:16:07 EST 2001 BIOS-provided physical RAM map: BIOS-e820: 000a @ (usable) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 03efd000 @ 0010 (usable) BIOS-e820: 2000 @ 03ffd000 (ACPI data) BIOS-e820: 1000 @ 03fff000 (ACPI NVS) BIOS-e820: 0001 @ (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c000 for 4096 bytes. On node 0 totalpages: 16381 zone(0): 4096 pages. zone(1): 12285 pages. zone(2): 0 pages. APIC turned off by hardware. mapped APIC to e000 (01112000) Kernel command line: auto BOOT_IMAGE=lnew ro root=341 BOOT_FILE=/home/kernel/kernel/linux/arch/i386/boot/bzImage Initializing CPU#0 Detected 374.229 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 747.11 BogoMIPS Memory: 62368k/65524k available (940k kernel code, 2772k reserved, 327k data, 188k init, 0k highmem) Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) VFS: Diskquotas version dquot_6.5.0 initialized CPU: Before vendor init, caps: 008021bf 808029bf , vendor = 2 CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line) CPU: After vendor init, caps: 008021bf 808029bf 0002 CPU: After generic, caps: 008021bf 808029bf 0002 CPU: Common caps: 008021bf 808029bf 0002 CPU: AMD-K6(tm) 3D processor stepping 0c Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: AMD K6 PCI: BIOS32 Service Directory structure at 0xc00f9b50 PCI: BIOS32 Service Directory entry at 0xf04d0 PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=00 PCI: PCI BIOS revision 2.10 entry at 0xf0500, last bus=0 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Setting max latency to 32 PCI: IDE base address trash cleared for 00:01.1 PCI: IDE base address fixup for 00:01.1 PCI: Scanning for ghost devices on bus 0 PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00f0af0 00:0c slot=01 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8 00:0b slot=02 0:42/1eb8 1:43/1eb8 2:44/1eb8 3:41/1eb8 00:0a slot=03 0:43/1eb8 1:44/1eb8 2:41/1eb8 3:42/1eb8 00:09 slot=04 0:44/1eb8 1:41/1eb8 2:42/1eb8 3:43/1eb8 00:01 slot=00 0:62/1eb8 1:00/ 2:00/ 3:00/ 00:13 slot=00 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8 PCI: Using IRQ router SIS [1039/0008] at 00:01.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource d000-d00f (f=101, d=0, p=0) PCI: Resource dd00-dd000fff (f=200, d=0, p=0) PCI: Resource b800-b807 (f=101, d=0, p=0) PCI: Resource dc80-dc87 (f=200, d=0, p=0) PCI: Resource e000-e7ff (f=1208, d=0, p=0) PCI: Resource df00-df000fff (f=1208, d=0, p=0) PCI: Resource b400-b41f (f=101, d=0, p=0) PCI: Resource dc00-dc0f (f=200, d=0, p=0) PCI: Resource de00-de3f (f=1208, d=1, p=1) PCI: Resource db80-db80 (f=200, d=1, p=1) PCI: Resource b000-b07f (f=101, d=1, p=1) PCI: Sorting device list... Disabling direct PCI/PCI transfers. isapnp: Scanning for Pnp cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 41341kB/31006kB, 128 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx SIS5513: IDE controller on PCI bus 00 dev 09 IRQ for 00:01.1:0 -> PIRQ 62, mask 1eb8, excl -> newirq=10Unknown SiS pirq value 98 -> assigning IRQ 10Unknown SiS pirq value 98 ... failed SIS5513: chipset revision 208 SIS5513: not 100% native mode: will probe irqs later SiS5597 ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio keyboard: Timeout - AT keyboard not present? keyboard: Timeout - AT keyboard not present? hda: ST5660A, ATA
Re: PCI IRQ routing problem in 2.4.0 (SiS results)
| Your "link" values are in the range 1-4. Which makes perfect sense, but | that's absolutely _not_ what the Linux SiS routing code expects (the code | seems to expect them to be ASCII 'A' - 'D'). | It looks very much like "pirq_sis_get()" and "pirq_sis_set()" in | arch/i386/kernel/pci-irq.c are broken for your setup. My ASUS SP97-V complains about PIRQ conflicts so I gave this a whirl (It is SiS 5598 based) | Anybody else with SiS chipsets that want to try the above? Please.. Here is my dmesg: Linux version 2.4.0-ac12 ([EMAIL PROTECTED]) (gcc version 2.95.3 20010125 (prerelease)) #3 Mon Jan 29 00:16:07 EST 2001 BIOS-provided physical RAM map: BIOS-e820: 000a @ (usable) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 03efd000 @ 0010 (usable) BIOS-e820: 2000 @ 03ffd000 (ACPI data) BIOS-e820: 1000 @ 03fff000 (ACPI NVS) BIOS-e820: 0001 @ (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c000 for 4096 bytes. On node 0 totalpages: 16381 zone(0): 4096 pages. zone(1): 12285 pages. zone(2): 0 pages. APIC turned off by hardware. mapped APIC to e000 (01112000) Kernel command line: auto BOOT_IMAGE=lnew ro root=341 BOOT_FILE=/home/kernel/kernel/linux/arch/i386/boot/bzImage Initializing CPU#0 Detected 374.229 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 747.11 BogoMIPS Memory: 62368k/65524k available (940k kernel code, 2772k reserved, 327k data, 188k init, 0k highmem) Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) VFS: Diskquotas version dquot_6.5.0 initialized CPU: Before vendor init, caps: 008021bf 808029bf , vendor = 2 CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line) CPU: After vendor init, caps: 008021bf 808029bf 0002 CPU: After generic, caps: 008021bf 808029bf 0002 CPU: Common caps: 008021bf 808029bf 0002 CPU: AMD-K6(tm) 3D processor stepping 0c Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: AMD K6 PCI: BIOS32 Service Directory structure at 0xc00f9b50 PCI: BIOS32 Service Directory entry at 0xf04d0 PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=00 PCI: PCI BIOS revision 2.10 entry at 0xf0500, last bus=0 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Setting max latency to 32 PCI: IDE base address trash cleared for 00:01.1 PCI: IDE base address fixup for 00:01.1 PCI: Scanning for ghost devices on bus 0 PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00f0af0 00:0c slot=01 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8 00:0b slot=02 0:42/1eb8 1:43/1eb8 2:44/1eb8 3:41/1eb8 00:0a slot=03 0:43/1eb8 1:44/1eb8 2:41/1eb8 3:42/1eb8 00:09 slot=04 0:44/1eb8 1:41/1eb8 2:42/1eb8 3:43/1eb8 00:01 slot=00 0:62/1eb8 1:00/ 2:00/ 3:00/ 00:13 slot=00 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8 PCI: Using IRQ router SIS [1039/0008] at 00:01.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource d000-d00f (f=101, d=0, p=0) PCI: Resource dd00-dd000fff (f=200, d=0, p=0) PCI: Resource b800-b807 (f=101, d=0, p=0) PCI: Resource dc80-dc87 (f=200, d=0, p=0) PCI: Resource e000-e7ff (f=1208, d=0, p=0) PCI: Resource df00-df000fff (f=1208, d=0, p=0) PCI: Resource b400-b41f (f=101, d=0, p=0) PCI: Resource dc00-dc0f (f=200, d=0, p=0) PCI: Resource de00-de3f (f=1208, d=1, p=1) PCI: Resource db80-db80 (f=200, d=1, p=1) PCI: Resource b000-b07f (f=101, d=1, p=1) PCI: Sorting device list... Disabling direct PCI/PCI transfers. isapnp: Scanning for Pnp cards... isapnp: No Plug Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 41341kB/31006kB, 128 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx SIS5513: IDE controller on PCI bus 00 dev 09 IRQ for 00:01.1:0 - PIRQ 62, mask 1eb8, excl - newirq=10Unknown SiS pirq value 98 - assigning IRQ 10Unknown SiS pirq value 98 ... failed SIS5513: chipset revision 208 SIS5513: not 100% native mode: will probe irqs later SiS5597 ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio keyboard: Timeout - AT keyboard not present? keyboard: Timeout - AT keyboard not present? hda: ST5660A, ATA DISK
Re: PCI IRQ routing problem in 2.4.0 (SiS results)
| Your "link" values are in the range 1-4. Which makes perfect sense, but | that's absolutely _not_ what the Linux SiS routing code expects (the code | seems to expect them to be ASCII 'A' - 'D'). | It looks very much like "pirq_sis_get()" and "pirq_sis_set()" in | arch/i386/kernel/pci-irq.c are broken for your setup. My ASUS SP97-V complains about PIRQ conflicts so I gave this a whirl (It is SiS 5598 based) | Anybody else with SiS chipsets that want to try the above? Please.. Here is my dmesg: Linux version 2.4.0-ac12 ([EMAIL PROTECTED]) (gcc version 2.95.3 20010125 (prerelease)) #3 Mon Jan 29 00:16:07 EST 2001 BIOS-provided physical RAM map: BIOS-e820: 000a @ (usable) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 03efd000 @ 0010 (usable) BIOS-e820: 2000 @ 03ffd000 (ACPI data) BIOS-e820: 1000 @ 03fff000 (ACPI NVS) BIOS-e820: 0001 @ (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c000 for 4096 bytes. On node 0 totalpages: 16381 zone(0): 4096 pages. zone(1): 12285 pages. zone(2): 0 pages. APIC turned off by hardware. mapped APIC to e000 (01112000) Kernel command line: auto BOOT_IMAGE=lnew ro root=341 BOOT_FILE=/home/kernel/kernel/linux/arch/i386/boot/bzImage Initializing CPU#0 Detected 374.229 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 747.11 BogoMIPS Memory: 62368k/65524k available (940k kernel code, 2772k reserved, 327k data, 188k init, 0k highmem) Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) VFS: Diskquotas version dquot_6.5.0 initialized CPU: Before vendor init, caps: 008021bf 808029bf , vendor = 2 CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line) CPU: After vendor init, caps: 008021bf 808029bf 0002 CPU: After generic, caps: 008021bf 808029bf 0002 CPU: Common caps: 008021bf 808029bf 0002 CPU: AMD-K6(tm) 3D processor stepping 0c Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: AMD K6 PCI: BIOS32 Service Directory structure at 0xc00f9b50 PCI: BIOS32 Service Directory entry at 0xf04d0 PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=00 PCI: PCI BIOS revision 2.10 entry at 0xf0500, last bus=0 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Setting max latency to 32 PCI: IDE base address trash cleared for 00:01.1 PCI: IDE base address fixup for 00:01.1 PCI: Scanning for ghost devices on bus 0 PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00f0af0 00:0c slot=01 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8 00:0b slot=02 0:42/1eb8 1:43/1eb8 2:44/1eb8 3:41/1eb8 00:0a slot=03 0:43/1eb8 1:44/1eb8 2:41/1eb8 3:42/1eb8 00:09 slot=04 0:44/1eb8 1:41/1eb8 2:42/1eb8 3:43/1eb8 00:01 slot=00 0:62/1eb8 1:00/ 2:00/ 3:00/ 00:13 slot=00 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8 PCI: Using IRQ router SIS [1039/0008] at 00:01.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource d000-d00f (f=101, d=0, p=0) PCI: Resource dd00-dd000fff (f=200, d=0, p=0) PCI: Resource b800-b807 (f=101, d=0, p=0) PCI: Resource dc80-dc87 (f=200, d=0, p=0) PCI: Resource e000-e7ff (f=1208, d=0, p=0) PCI: Resource df00-df000fff (f=1208, d=0, p=0) PCI: Resource b400-b41f (f=101, d=0, p=0) PCI: Resource dc00-dc0f (f=200, d=0, p=0) PCI: Resource de00-de3f (f=1208, d=1, p=1) PCI: Resource db80-db80 (f=200, d=1, p=1) PCI: Resource b000-b07f (f=101, d=1, p=1) PCI: Sorting device list... Disabling direct PCI/PCI transfers. isapnp: Scanning for Pnp cards... isapnp: No Plug Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 41341kB/31006kB, 128 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx SIS5513: IDE controller on PCI bus 00 dev 09 IRQ for 00:01.1:0 - PIRQ 62, mask 1eb8, excl - newirq=10Unknown SiS pirq value 98 - assigning IRQ 10Unknown SiS pirq value 98 ... failed SIS5513: chipset revision 208 SIS5513: not 100% native mode: will probe irqs later SiS5597 ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio keyboard: Timeout - AT keyboard not present? keyboard: Timeout - AT keyboard not present? hda: ST5660A, ATA DISK
Re: PCI IRQ routing problem in 2.4.0 (SiS results part 2)
| Which one was it you got a PIRQ conflict for before? as it te device at | 00:01.00 with the strange "0x62" entry? Yes. | How about you try adding the line | pirq = (pirq-1) 3; | at the top of both pirq_sis_get() and pirq_sis_set() (with my "alternate" | SiS routines). What happens then? Done. Linux version 2.4.0-ac12 ([EMAIL PROTECTED]) (gcc version 2.95.3 20010125 (prerelease)) #4 Mon Jan 29 01:53:12 EST 2001 BIOS-provided physical RAM map: BIOS-e820: 000a @ (usable) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 03efd000 @ 0010 (usable) BIOS-e820: 2000 @ 03ffd000 (ACPI data) BIOS-e820: 1000 @ 03fff000 (ACPI NVS) BIOS-e820: 0001 @ (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c000 for 4096 bytes. On node 0 totalpages: 16381 zone(0): 4096 pages. zone(1): 12285 pages. zone(2): 0 pages. APIC turned off by hardware. mapped APIC to e000 (01112000) Kernel command line: auto BOOT_IMAGE=lnew ro root=341 BOOT_FILE=/home/kernel/kernel/linux/arch/i386/boot/bzImage Initializing CPU#0 Detected 374.227 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 747.11 BogoMIPS Memory: 62368k/65524k available (940k kernel code, 2772k reserved, 327k data, 188k init, 0k highmem) Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) VFS: Diskquotas version dquot_6.5.0 initialized CPU: Before vendor init, caps: 008021bf 808029bf , vendor = 2 CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line) CPU: After vendor init, caps: 008021bf 808029bf 0002 CPU: After generic, caps: 008021bf 808029bf 0002 CPU: Common caps: 008021bf 808029bf 0002 CPU: AMD-K6(tm) 3D processor stepping 0c Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: AMD K6 PCI: BIOS32 Service Directory structure at 0xc00f9b50 PCI: BIOS32 Service Directory entry at 0xf04d0 PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=00 PCI: PCI BIOS revision 2.10 entry at 0xf0500, last bus=0 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Setting max latency to 32 PCI: IDE base address trash cleared for 00:01.1 PCI: IDE base address fixup for 00:01.1 PCI: Scanning for ghost devices on bus 0 PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00f0af0 00:0c slot=01 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8 00:0b slot=02 0:42/1eb8 1:43/1eb8 2:44/1eb8 3:41/1eb8 00:0a slot=03 0:43/1eb8 1:44/1eb8 2:41/1eb8 3:42/1eb8 00:09 slot=04 0:44/1eb8 1:41/1eb8 2:42/1eb8 3:43/1eb8 00:01 slot=00 0:62/1eb8 1:00/ 2:00/ 3:00/ 00:13 slot=00 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8 PCI: Using IRQ router SIS [1039/0008] at 00:01.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource d000-d00f (f=101, d=0, p=0) PCI: Resource dd00-dd000fff (f=200, d=0, p=0) PCI: Resource b800-b807 (f=101, d=0, p=0) PCI: Resource dc80-dc87 (f=200, d=0, p=0) PCI: Resource e000-e7ff (f=1208, d=0, p=0) PCI: Resource df00-df000fff (f=1208, d=0, p=0) PCI: Resource b400-b41f (f=101, d=0, p=0) PCI: Resource dc00-dc0f (f=200, d=0, p=0) PCI: Resource de00-de3f (f=1208, d=1, p=1) PCI: Resource db80-db80 (f=200, d=1, p=1) PCI: Resource b000-b07f (f=101, d=1, p=1) PCI: Sorting device list... Disabling direct PCI/PCI transfers. isapnp: Scanning for Pnp cards... isapnp: No Plug Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 41341kB/31006kB, 128 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx SIS5513: IDE controller on PCI bus 00 dev 09 IRQ for 00:01.1:0 - PIRQ 62, mask 1eb8, excl - newirq=10 - got IRQ 10 PCI: Found IRQ 10 for device 00:01.1 PCI: The same IRQ used for device 00:01.2 SIS5513: chipset revision 208 SIS5513: not 100% native mode: will probe irqs later SiS5597 ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio keyboard: Timeout - AT keyboard not present? keyboard: Timeout - AT keyboard not present? hda: ST5660A, ATA DISK drive hdb: IBM-DJAA-31700, ATA DISK drive hdc: Maxtor 72700 AP, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 1066184 sectors (546 MB) w/256KiB
Re: PCI IRQ routing problem in 2.4.0 (SiS results part 2)
| Which one was it you got a PIRQ conflict for before? as it te device at | 00:01.00 with the strange "0x62" entry? Yes. | How about you try adding the line | pirq = (pirq-1) 3; | at the top of both pirq_sis_get() and pirq_sis_set() (with my "alternate" | SiS routines). What happens then? Done. Linux version 2.4.0-ac12 ([EMAIL PROTECTED]) (gcc version 2.95.3 20010125 (prerelease)) #4 Mon Jan 29 01:53:12 EST 2001 BIOS-provided physical RAM map: BIOS-e820: 000a @ (usable) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 03efd000 @ 0010 (usable) BIOS-e820: 2000 @ 03ffd000 (ACPI data) BIOS-e820: 1000 @ 03fff000 (ACPI NVS) BIOS-e820: 0001 @ (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c000 for 4096 bytes. On node 0 totalpages: 16381 zone(0): 4096 pages. zone(1): 12285 pages. zone(2): 0 pages. APIC turned off by hardware. mapped APIC to e000 (01112000) Kernel command line: auto BOOT_IMAGE=lnew ro root=341 BOOT_FILE=/home/kernel/kernel/linux/arch/i386/boot/bzImage Initializing CPU#0 Detected 374.227 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 747.11 BogoMIPS Memory: 62368k/65524k available (940k kernel code, 2772k reserved, 327k data, 188k init, 0k highmem) Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) VFS: Diskquotas version dquot_6.5.0 initialized CPU: Before vendor init, caps: 008021bf 808029bf , vendor = 2 CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line) CPU: After vendor init, caps: 008021bf 808029bf 0002 CPU: After generic, caps: 008021bf 808029bf 0002 CPU: Common caps: 008021bf 808029bf 0002 CPU: AMD-K6(tm) 3D processor stepping 0c Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: AMD K6 PCI: BIOS32 Service Directory structure at 0xc00f9b50 PCI: BIOS32 Service Directory entry at 0xf04d0 PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=00 PCI: PCI BIOS revision 2.10 entry at 0xf0500, last bus=0 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Setting max latency to 32 PCI: IDE base address trash cleared for 00:01.1 PCI: IDE base address fixup for 00:01.1 PCI: Scanning for ghost devices on bus 0 PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00f0af0 00:0c slot=01 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8 00:0b slot=02 0:42/1eb8 1:43/1eb8 2:44/1eb8 3:41/1eb8 00:0a slot=03 0:43/1eb8 1:44/1eb8 2:41/1eb8 3:42/1eb8 00:09 slot=04 0:44/1eb8 1:41/1eb8 2:42/1eb8 3:43/1eb8 00:01 slot=00 0:62/1eb8 1:00/ 2:00/ 3:00/ 00:13 slot=00 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8 PCI: Using IRQ router SIS [1039/0008] at 00:01.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource d000-d00f (f=101, d=0, p=0) PCI: Resource dd00-dd000fff (f=200, d=0, p=0) PCI: Resource b800-b807 (f=101, d=0, p=0) PCI: Resource dc80-dc87 (f=200, d=0, p=0) PCI: Resource e000-e7ff (f=1208, d=0, p=0) PCI: Resource df00-df000fff (f=1208, d=0, p=0) PCI: Resource b400-b41f (f=101, d=0, p=0) PCI: Resource dc00-dc0f (f=200, d=0, p=0) PCI: Resource de00-de3f (f=1208, d=1, p=1) PCI: Resource db80-db80 (f=200, d=1, p=1) PCI: Resource b000-b07f (f=101, d=1, p=1) PCI: Sorting device list... Disabling direct PCI/PCI transfers. isapnp: Scanning for Pnp cards... isapnp: No Plug Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 41341kB/31006kB, 128 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx SIS5513: IDE controller on PCI bus 00 dev 09 IRQ for 00:01.1:0 - PIRQ 62, mask 1eb8, excl - newirq=10 - got IRQ 10 PCI: Found IRQ 10 for device 00:01.1 PCI: The same IRQ used for device 00:01.2 SIS5513: chipset revision 208 SIS5513: not 100% native mode: will probe irqs later SiS5597 ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio keyboard: Timeout - AT keyboard not present? keyboard: Timeout - AT keyboard not present? hda: ST5660A, ATA DISK drive hdb: IBM-DJAA-31700, ATA DISK drive hdc: Maxtor 72700 AP, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 1066184 sectors (546 MB) w/256KiB
Linux 2.4.0ac12 (ppp-generic)
| o Set last_rx on ppp_generic (Jeff Garzik) Is this related to my MPPP crashes or is this an unrelated fix? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.0ac12 (ppp-generic)
| o Set last_rx on ppp_generic (Jeff Garzik) Is this related to my MPPP crashes or is this an unrelated fix? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[2.4.1-p10] Multilink PPP crash fix
I took out my can of RAID and went bug hunting. The kernel was always crashing in this subroutine and the comment near the list walk clued me in. I've run this fixed kernel all night and can no longer make it OOPS from a racy list walk. It may be overkill to use ppp_lock instead of the finer grained locks but it works great so far and I don't believe this routine gets called a lot. --- Life is like a box of chocolates: Mass produced and usually stale. 2.4.1-p10-mppp-fix.patch
[2.4.1-p10] Multilink PPP crash fix
I took out my can of RAID and went bug hunting. The kernel was always crashing in this subroutine and the comment near the list walk clued me in. I've run this fixed kernel all night and can no longer make it OOPS from a racy list walk. It may be overkill to use ppp_lock instead of the finer grained locks but it works great so far and I don't believe this routine gets called a lot. --- Life is like a box of chocolates: Mass produced and usually stale. 2.4.1-p10-mppp-fix.patch
[2.4.1-p8 More MPPP oops]
Always the glutton for punishment, I did it again tonite. A different oops now. See my last message for prior info. ksymoops 2.3.7 on i586 2.4.1-pre8. Options used -v /usr/src/linux/vmlinux (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.1-pre8/ (default) -m /usr/src/linux/System.map (default) Unable to handle kernel NULL pointer dereference at virtual address c49c957d *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010297 eax: c20200b4 ebx: ecx: c20200b4 edx: c0632460 esi: 000240cb edi: c023b6ec ebp: c1902dc0 esp: c2a65e5c ds: 0018 es: 0018 ss: 0018 Process dnetc (pid: 705, stackpage=c2a65000) Stack: 000240ca c18a6c60 fffe c2020044 000c c1902960 c1902960 c20200b4 000240ca c49c9270 c202 c202 0010 c28b8920 0002 c20200b4 c49c8b04 c202 c18a6c60 c28b8920 c18a6c60 c49c8a1b c202 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 13 8b 43 04 c7 03 00 00 00 00 c7 43 04 00 00 00 00 c7 43 >>EIP; c49c957d <[ppp_generic]ppp_mp_reconstruct+289/2d8> <= Trace; c49c9270 <[ppp_generic]ppp_receive_mp_frame+1cc/20c> Trace; c49c8b04 <[ppp_generic]ppp_receive_frame+30/7c> Trace; c49c8a1b <[ppp_generic]ppp_input+12f/164> Trace; c49ccf86 <[ppp_async]ppp_async_input+3ae/458> Trace; c49cc383 <[ppp_async]ppp_asynctty_receive+27/58> Trace; c01726e5 Trace; c0172774 Trace; c0181487 Trace; c0181766 Trace; c0109f3c Trace; c010a09e Trace; c0108e00 Code; c49c957d <[ppp_generic]ppp_mp_reconstruct+289/2d8> <_EIP>: Code; c49c957d <[ppp_generic]ppp_mp_reconstruct+289/2d8> <= 0: 8b 13 mov(%ebx),%edx <= Code; c49c957f <[ppp_generic]ppp_mp_reconstruct+28b/2d8> 2: 8b 43 04 mov0x4(%ebx),%eax Code; c49c9582 <[ppp_generic]ppp_mp_reconstruct+28e/2d8> 5: c7 03 00 00 00 00 movl $0x0,(%ebx) Code; c49c9588 <[ppp_generic]ppp_mp_reconstruct+294/2d8> b: c7 43 04 00 00 00 00 movl $0x0,0x4(%ebx) Code; c49c958f <[ppp_generic]ppp_mp_reconstruct+29b/2d8> 12: c7 43 00 00 00 00 00 movl $0x0,0x0(%ebx) Kernel panic: Aiee, killing interrupt handler! Unable to handle kernel NULL pointer dereference at virtual address 0068 c49c92d8 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010213 eax: 000240dd ebx: 000240dd ecx: c20200b4 edx: esi: c18c8ac0 edi: ebp: c2020044 esp: c2a65bd4 ds: 0018 es: 0018 ss: 0018 Process dnetc (pid: 705, stackpage=c2a65000) Stack: 000240ca c18c8ac0 c49c922c c202 c18c8ac0 c202 025d c293ed40 0005 c20200b4 c49c8b04 c202 c18c8ac0 c293ed40 c18c8ac0 c49c8a1b c202 c18c8ac0 c293ed40 c18c8ac0 025d 0005 c49cc383 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [ [] [] [] [] [] [] [] [ [] [] [] [] [] [] [] [ [] [] [] [] [] [] [] [ Code: 2b 42 68 79 f3 8b 42 04 89 56 00 89 46 04 89 72 04 89 30 89 >>EIP; c49c92d8 <[ppp_generic]ppp_mp_insert+28/44> <= Trace; c49c922c <[ppp_generic]ppp_receive_mp_frame+188/20c> Trace; c49c8b04 <[ppp_generic]ppp_receive_frame+30/7c> Trace; c49c8a1b <[ppp_generic]ppp_input+12f/164> Trace; c49cc383 <[ppp_async]ppp_asynctty_receive+27/58> Trace; c49ccf86 <[ppp_async]ppp_async_input+3ae/458> Trace; c49cc383 <[ppp_async]ppp_asynctty_receive+27/58> Trace; c01726e5 Trace; c0172774 Trace; c0181487 Trace; df00 Trace; c0181766 Trace; c0109f3c Trace; c010a09e Trace; c0108e00 Trace; c0113900 Trace; c01162bf Trace; c010928c Trace; c065 Trace; c0110e44 Trace; c0172774 Trace; c0181487 Trace; c0181563 Trace; c0181796 Trace; c0109f3c Trace; c010a0d2 Trace; c0108e84 Trace; c49c957d <[ppp_generic]ppp_mp_reconstruct+289/2d8> Trace; c49c9270 <[ppp_generic]ppp_receive_mp_frame+1cc/20c> Trace; c49c8b04 <[ppp_generic]ppp_receive_frame+30/7c> Trace; c49c8a1b <[ppp_generic]ppp_input+12f/164> Trace; c49ccf86 <[ppp_async]ppp_async_input+3ae/458> Trace; c49cc383 <[ppp_async]ppp_asynctty_receive+27/58> Trace; c01726e5 Trace; c0172774 Trace; c0181487 Trace; c0181766 Trace; c0109f3c Trace; c010a09e Trace; c0108e00 Code; c49c92d8 <[ppp_generic]ppp_mp_insert+28/44> <_EIP>: Code; c49c92d8 <[ppp_generic]ppp_mp_insert+28/44> <= 0: 2b 42 68 sub0x68(%edx),%eax <= Code; c49c92db <[ppp_generic]ppp_mp_insert+2b/44> 3: 79 f3 jnsfff8 <_EIP+0xfff8> c49c92d0 <[ppp_generic]ppp_mp_insert+20/4> Code; c49c92dd <[ppp_generic]ppp_mp_insert+2d/44> 5: 8b 42 04 mov0x4(%edx),%eax Code; c49c92e0 <[ppp_generic]ppp_mp_insert+30/44> 8: 89 56 00 mov%edx,0x0(%esi) Code; c49c92e3 <[ppp_generic]ppp_mp_insert+33/44> b: 89 46 04 mov
[2.4.1-p8 More MPPP oops]
Always the glutton for punishment, I did it again tonite. A different oops now. See my last message for prior info. ksymoops 2.3.7 on i586 2.4.1-pre8. Options used -v /usr/src/linux/vmlinux (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.1-pre8/ (default) -m /usr/src/linux/System.map (default) Unable to handle kernel NULL pointer dereference at virtual address c49c957d *pde = Oops: CPU:0 EIP:0010:[c49c957d] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010297 eax: c20200b4 ebx: ecx: c20200b4 edx: c0632460 esi: 000240cb edi: c023b6ec ebp: c1902dc0 esp: c2a65e5c ds: 0018 es: 0018 ss: 0018 Process dnetc (pid: 705, stackpage=c2a65000) Stack: 000240ca c18a6c60 fffe c2020044 000c c1902960 c1902960 c20200b4 000240ca c49c9270 c202 c202 0010 c28b8920 0002 c20200b4 c49c8b04 c202 c18a6c60 c28b8920 c18a6c60 c49c8a1b c202 Call Trace: [c49c9270] [c49c8b04] [c49c8a1b] [c49ccf86] [c49cc383] [c01726e5] [c0172774] [c0181487] [c0181766] [c0109f3c] [c010a09e] [c0108e00] Code: 8b 13 8b 43 04 c7 03 00 00 00 00 c7 43 04 00 00 00 00 c7 43 EIP; c49c957d [ppp_generic]ppp_mp_reconstruct+289/2d8 = Trace; c49c9270 [ppp_generic]ppp_receive_mp_frame+1cc/20c Trace; c49c8b04 [ppp_generic]ppp_receive_frame+30/7c Trace; c49c8a1b [ppp_generic]ppp_input+12f/164 Trace; c49ccf86 [ppp_async]ppp_async_input+3ae/458 Trace; c49cc383 [ppp_async]ppp_asynctty_receive+27/58 Trace; c01726e5 flush_to_ldisc+dd/e4 Trace; c0172774 tty_flip_buffer_push+14/5c Trace; c0181487 receive_chars+1f3/200 Trace; c0181766 rs_interrupt_single+42/88 Trace; c0109f3c handle_IRQ_event+30/5c Trace; c010a09e do_IRQ+6e/b0 Trace; c0108e00 ret_from_intr+0/20 Code; c49c957d [ppp_generic]ppp_mp_reconstruct+289/2d8 _EIP: Code; c49c957d [ppp_generic]ppp_mp_reconstruct+289/2d8 = 0: 8b 13 mov(%ebx),%edx = Code; c49c957f [ppp_generic]ppp_mp_reconstruct+28b/2d8 2: 8b 43 04 mov0x4(%ebx),%eax Code; c49c9582 [ppp_generic]ppp_mp_reconstruct+28e/2d8 5: c7 03 00 00 00 00 movl $0x0,(%ebx) Code; c49c9588 [ppp_generic]ppp_mp_reconstruct+294/2d8 b: c7 43 04 00 00 00 00 movl $0x0,0x4(%ebx) Code; c49c958f [ppp_generic]ppp_mp_reconstruct+29b/2d8 12: c7 43 00 00 00 00 00 movl $0x0,0x0(%ebx) Kernel panic: Aiee, killing interrupt handler! Unable to handle kernel NULL pointer dereference at virtual address 0068 c49c92d8 *pde = Oops: CPU:0 EIP:0010:[c49c92d8] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010213 eax: 000240dd ebx: 000240dd ecx: c20200b4 edx: esi: c18c8ac0 edi: ebp: c2020044 esp: c2a65bd4 ds: 0018 es: 0018 ss: 0018 Process dnetc (pid: 705, stackpage=c2a65000) Stack: 000240ca c18c8ac0 c49c922c c202 c18c8ac0 c202 025d c293ed40 0005 c20200b4 c49c8b04 c202 c18c8ac0 c293ed40 c18c8ac0 c49c8a1b c202 c18c8ac0 c293ed40 c18c8ac0 025d 0005 c49cc383 Call Trace: [c49c922c] [c49c8b04] [c49c8a1b] [c49cc383] [c49ccf86] [c49cc383] [c01726e5] [c0172774] [c0181487] [df00] [c0181766] [c0109f3c] [c010a09e] [c0108e00] [c0113900 [c01162bf] [c010928c] [c065] [c0110e44] [c0172774] [c0181487] [c0181563] [c0181796 [c0109f3c] [c010a0d2] [c0108e84] [c49c957d] [c49c9270] [c49c8b04] [c49c8a1b] [c49ccf86 [c49cc383] [c01726e5] [c0172774] [c0181487] [c0181766] [c0109f3c] [c010a09e] [c0108e00 Code: 2b 42 68 79 f3 8b 42 04 89 56 00 89 46 04 89 72 04 89 30 89 EIP; c49c92d8 [ppp_generic]ppp_mp_insert+28/44 = Trace; c49c922c [ppp_generic]ppp_receive_mp_frame+188/20c Trace; c49c8b04 [ppp_generic]ppp_receive_frame+30/7c Trace; c49c8a1b [ppp_generic]ppp_input+12f/164 Trace; c49cc383 [ppp_async]ppp_asynctty_receive+27/58 Trace; c49ccf86 [ppp_async]ppp_async_input+3ae/458 Trace; c49cc383 [ppp_async]ppp_asynctty_receive+27/58 Trace; c01726e5 flush_to_ldisc+dd/e4 Trace; c0172774 tty_flip_buffer_push+14/5c Trace; c0181487 receive_chars+1f3/200 Trace; df00 END_OF_CODE+1a5d75e5/ Trace; c0181766 rs_interrupt_single+42/88 Trace; c0109f3c handle_IRQ_event+30/5c Trace; c010a09e do_IRQ+6e/b0 Trace; c0108e00 ret_from_intr+0/20 Trace; c0113900 panic+c0/d0 Trace; c01162bf do_exit+27/230 Trace; c010928c do_divide_error+0/ac Trace; c065 do_page_fault+321/40c Trace; c0110e44 do_page_fault+0/40c Trace; c0172774 tty_flip_buffer_push+14/5c Trace; c0181487 receive_chars+1f3/200 Trace; c0181563 transmit_chars+cf/d8 Trace; c0181796 rs_interrupt_single+72/88 Trace; c0109f3c handle_IRQ_event+30/5c Trace; c010a0d2 do_IRQ+a2/b0 Trace; c0108e84 error_code+34/40 Trace; c49c957d [ppp_generic]ppp_mp_reconstruct+289/2d8 Trace; c49c9270 [ppp_generic]ppp_receive_mp_frame+1cc/20c Trace; c49c8b04 [ppp_generic]ppp_receive_frame+30/7c Trace; c49c8a1b
[2.4.1-pre8] MPP related OPPS
I reported this a few months ago without much details and the machine involved died shortly after which made me think that this oops was merely bad hardware. This is a brand new machine and the opps popped up again. Thankfully I armed myself with a serial console and captured this beast. Definitely bad mojo involved in the MPPP code, this only occurs when 2 modems are bonded together over serial lines connected to a 3com TotalControl PPP server. I can recreate it with a bare-minimum kernel up to a full featured kernel, going all the way back into 2.3.x land. It isn't limited to this machine either. :) Master link is on COM1 using an oldie but goodie USR Dual Standard V.Everything Slave link is on a USR PCI controller-full 56k modem With the master link configured with MPP without the slave attached, I can run it for days. With the master link having the slave attached, I can run it for 5 minutes to 30 minutes. I've even switched master/slave configurations and tried different modems. Details to follow: [1.] One line summary of the problem: After a few minutes of heavy load, MPPP over serial lines oops's. [2.] Full description of the problem/report: See above. [4.] Kernel version (from /proc/version): Linux version 2.4.1-pre8 ([EMAIL PROTECTED]) (gcc version 2.95.3 20010101 (prerelease)) #1 Thu Jan 18 21:15:51 EST 2001 Note that this happens with egcs also, and gcc 2.95.2 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) Script started on Fri Jan 19 00:17:52 2001 [root@usr1-ip028-cs ~]# ksymoops -v /usr/src/linux/vmlinux -k /proc/ksyms -l /pr oc/modules -m /usr/src/linux/System.map ] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: 01010101 ebx: c1ce7eb4 ecx: c209c000 edx: esi: 3fd2 edi: ebp: c3d839e0 esp: c209de44 ds: 0018 es: 0018 ss: 0018 Process dnetc (pid: 695, stackpage=c209d000) Stack: c01accd2 c1ce7eb4 c1ce7eb4 c49c95b3 c1ce7eb4 3fd2 c2e5d1e0 fffe c1ce7e44 05bd c2e5d1e0 c2e5d1e0 c1ce7eb4 3fd2 c49c9270 c1ce7e00 c1ce7e00 05c3 c20a3be0 0001 c1ce7eb4 c49c8b04 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: Bad EIP value. >>EIP; 01010101 Before first symbol <= Trace; c01accd2 <__kfree_skb+7e/134> Trace; c49c95b3 <[ppp_generic]ppp_mp_reconstruct+2bf/2d8> Trace; c49c9270 <[ppp_generic]ppp_receive_mp_frame+1cc/20c> Trace; c49c8b04 <[ppp_generic]ppp_receive_frame+30/7c> Trace; c49c8a1b <[ppp_generic]ppp_input+12f/164> Trace; c49ccf86 <[ppp_async]ppp_async_input+3ae/458> Trace; c49cc383 <[ppp_async]ppp_asynctty_receive+27/58> Trace; c01726e5 Trace; c0172774 Trace; c0181487 Trace; c0181766 Trace; c0109f3c Trace; c010a09e Trace; c0108e00 Kernel panic: Aiee, killing interrupt handler! [root@usr1-ip028-cs ~]# Script done on Fri Jan 19 00:18:38 2001 [6.] A small shell script or example program which triggers the problem (if possible) Fire up a MPPP link and watch it burn. :) [7.1.] Software (add the output of the ver_linux script here) Kernel modules 2.3.21 Gnu C 2.95.3 Gnu Make 3.79.1 Binutils 2.10.1.0.2 Linux C Library> libc.2.2 Dynamic linker ldd (GNU libc) 2.2 Procps 2.0.7 Mount 2.10m Net-tools 1.56 Console-tools 0.3.3 Sh-utils 2.0 [7.2.] Processor information (from /proc/cpuinfo): processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 8 model name : AMD-K6(tm) 3D processor stepping: 12 cpu MHz : 374.229 cache size : 64 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr bogomips: 747.11 Yes it's sick to have a K6-2 just routing packets. :) [7.3.] Module information (from /proc/modules): nls_iso8859-1 2848 1 (autoclean) smbfs 31216 1 (autoclean) nfs74240 1 (autoclean) ipt_unclean 6912 0 (autoclean) (unused) ipt_TOS 1104 0 (autoclean) (unused) ipt_tos 720 0 (autoclean) (unused) ipt_state800 0 (autoclean) (unused) ipt_REJECT 2080 0 (autoclean) (unused) ipt_REDIRECT 960 4 (autoclean) ipt_owner 1360 0 (autoclean) (unused) ipt_multiport880 0 (autoclean) (unused) ipt_MIRROR 1152 0 (autoclean) (unused) ipt_MASQUERADE 1312 1 (autoclean) ipt_MARK 944 0 (autoclean) (unused) ipt_mark 720 0 (autoclean) (unused) ipt_mac 880 0 (autoclean) (unused) ipt_LOG 3312 1 (autoclean) ipt_limit 1040
[2.4.1-pre8] MPP related OPPS
I reported this a few months ago without much details and the machine involved died shortly after which made me think that this oops was merely bad hardware. This is a brand new machine and the opps popped up again. Thankfully I armed myself with a serial console and captured this beast. Definitely bad mojo involved in the MPPP code, this only occurs when 2 modems are bonded together over serial lines connected to a 3com TotalControl PPP server. I can recreate it with a bare-minimum kernel up to a full featured kernel, going all the way back into 2.3.x land. It isn't limited to this machine either. :) Master link is on COM1 using an oldie but goodie USR Dual Standard V.Everything Slave link is on a USR PCI controller-full 56k modem With the master link configured with MPP without the slave attached, I can run it for days. With the master link having the slave attached, I can run it for 5 minutes to 30 minutes. I've even switched master/slave configurations and tried different modems. Details to follow: [1.] One line summary of the problem: After a few minutes of heavy load, MPPP over serial lines oops's. [2.] Full description of the problem/report: See above. [4.] Kernel version (from /proc/version): Linux version 2.4.1-pre8 ([EMAIL PROTECTED]) (gcc version 2.95.3 20010101 (prerelease)) #1 Thu Jan 18 21:15:51 EST 2001 Note that this happens with egcs also, and gcc 2.95.2 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) Script started on Fri Jan 19 00:17:52 2001 [root@usr1-ip028-cs ~]# ksymoops -v /usr/src/linux/vmlinux -k /proc/ksyms -l /pr oc/modules -m /usr/src/linux/System.map oops.txt ksymoops 2.3.7 on i586 2.4.1-pre8. Options used -v /usr/src/linux/vmlinux (specified) -k /proc/ksyms (specified) -l /proc/modules (specified) -o /lib/modules/2.4.1-pre8/ (default) -m /usr/src/linux/System.map (specified) Unable to handle kernel paging request at virtual address 01010101 01010101 *pde = Oops: CPU:0 EIP:0010:[01010101] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: 01010101 ebx: c1ce7eb4 ecx: c209c000 edx: esi: 3fd2 edi: ebp: c3d839e0 esp: c209de44 ds: 0018 es: 0018 ss: 0018 Process dnetc (pid: 695, stackpage=c209d000) Stack: c01accd2 c1ce7eb4 c1ce7eb4 c49c95b3 c1ce7eb4 3fd2 c2e5d1e0 fffe c1ce7e44 05bd c2e5d1e0 c2e5d1e0 c1ce7eb4 3fd2 c49c9270 c1ce7e00 c1ce7e00 05c3 c20a3be0 0001 c1ce7eb4 c49c8b04 Call Trace: [c01accd2] [c49c95b3] [c49c9270] [c49c8b04] [c49c8a1b] [c49ccf86] [c49cc383] [c01726e5] [c0172774] [c0181487] [c0181766] [c0109f3c] [c010a09e] [c0108e00] Code: Bad EIP value. EIP; 01010101 Before first symbol = Trace; c01accd2 __kfree_skb+7e/134 Trace; c49c95b3 [ppp_generic]ppp_mp_reconstruct+2bf/2d8 Trace; c49c9270 [ppp_generic]ppp_receive_mp_frame+1cc/20c Trace; c49c8b04 [ppp_generic]ppp_receive_frame+30/7c Trace; c49c8a1b [ppp_generic]ppp_input+12f/164 Trace; c49ccf86 [ppp_async]ppp_async_input+3ae/458 Trace; c49cc383 [ppp_async]ppp_asynctty_receive+27/58 Trace; c01726e5 flush_to_ldisc+dd/e4 Trace; c0172774 tty_flip_buffer_push+14/5c Trace; c0181487 receive_chars+1f3/200 Trace; c0181766 rs_interrupt_single+42/88 Trace; c0109f3c handle_IRQ_event+30/5c Trace; c010a09e do_IRQ+6e/b0 Trace; c0108e00 ret_from_intr+0/20 Kernel panic: Aiee, killing interrupt handler! [root@usr1-ip028-cs ~]# Script done on Fri Jan 19 00:18:38 2001 [6.] A small shell script or example program which triggers the problem (if possible) Fire up a MPPP link and watch it burn. :) [7.1.] Software (add the output of the ver_linux script here) Kernel modules 2.3.21 Gnu C 2.95.3 Gnu Make 3.79.1 Binutils 2.10.1.0.2 Linux C Library libc.2.2 Dynamic linker ldd (GNU libc) 2.2 Procps 2.0.7 Mount 2.10m Net-tools 1.56 Console-tools 0.3.3 Sh-utils 2.0 [7.2.] Processor information (from /proc/cpuinfo): processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 8 model name : AMD-K6(tm) 3D processor stepping: 12 cpu MHz : 374.229 cache size : 64 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr bogomips: 747.11 Yes it's sick to have a K6-2 just routing packets. :) [7.3.] Module information (from /proc/modules): nls_iso8859-1 2848 1 (autoclean) smbfs 31216 1 (autoclean) nfs74240 1 (autoclean) ipt_unclean 6912 0 (autoclean) (unused) ipt_TOS 1104 0 (autoclean) (unused) ipt_tos
Re: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12
| 2.2.18-pre26 was compiled with gcc 2.91.66 (kgcc). | 2.4.0-test12-pre7 was compiled with gcc 2.95.3. That's your answer right there. GCC 2.95.3 compiles much slower than kgcc. Rerun the 2.4.0 with kgcc to be fair. :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI detection in 2.2.x and 2.4.0
> By the way, does 2.2.x behave in the same way? No. 2.2.x and if I remember right, even 2.0.x all get it right. > I'm interested in lspci -vvx outputs for all the cases and also in effect > of "pci=bios", "pci=conf1" and "pci=conf2" switches. Will do. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI detection in 2.2.x and 2.4.0
> at the kernel command line. I admit it isn't a nice solution, but I > don't know any way which would be 100% reliable on all machines > and your machine is the only case I know about where the current > algorithm breaks. Me me me me. :) I have an odd situation.. in 2.4.x on my old P60, if I choose 'any', the machine has ghost devices and all PCI cards stop working. If I choose 'direct', it almost works. If I choose 'BIOS', it works correctly. If you want an lspci from each various boot I can do so.. it is a strange strange machine. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI detection in 2.2.x and 2.4.0
at the kernel command line. I admit it isn't a nice solution, but I don't know any way which would be 100% reliable on all machines and your machine is the only case I know about where the current algorithm breaks. Me me me me. :) I have an odd situation.. in 2.4.x on my old P60, if I choose 'any', the machine has ghost devices and all PCI cards stop working. If I choose 'direct', it almost works. If I choose 'BIOS', it works correctly. If you want an lspci from each various boot I can do so.. it is a strange strange machine. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI detection in 2.2.x and 2.4.0
By the way, does 2.2.x behave in the same way? No. 2.2.x and if I remember right, even 2.0.x all get it right. I'm interested in lspci -vvx outputs for all the cases and also in effect of "pci=bios", "pci=conf1" and "pci=conf2" switches. Will do. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.2.17final crashed Update
| > It screams like a banshee when enabled.
| yup.
| How annoying but interesting. You'd think they'd mention it (ASUS). Do you have
|this
| website anywhere still?
On my hard drive :)
I will repost it soon, hopefully later tonite.
Keep an eye out on http://www.mojomofo.com
N§²æìr¸yúèØb²X¬¶Ç§vØ^)Þº{.nÇ+·¥{±êçzX§¶¡Ü¨}©²Æ zÚ:+v¨¾«êçzZ+ù^jÇ«y§m
á@A«a¶Úÿ
0¶ìh®åi
Re: [BUG] 2.2.17final crashed Update
| > ASUS P5A with delayed transactions enabled? | Oh, you know this critter? I'm assuming disabling delayed transactions fixes the | speaker solos? I used to have a website dedicated to all the quirks that motherboard had. :) It's either delayed transactions or passive release that causes it. It is whatever option is lower in the bios (I have a photographic memory but otherwise a bad one overall :) ) It screams like a banshee when enabled. ¢éì¹» ®&Þ~º&¶¬+-±éݶ¥w®Ë±Êâmébìdz¹Þ)í æèw* jg¬±¨ ¶Ý¢j/êäz¹Þà>W±êÞiÛaxPjØm¶ÿà -»+ùd_
Re: [BUG] 2.2.17final crashed Update
| ASUS P5A with delayed transactions enabled? | Oh, you know this critter? I'm assuming disabling delayed transactions fixes the | speaker solos? I used to have a website dedicated to all the quirks that motherboard had. :) It's either delayed transactions or passive release that causes it. It is whatever option is lower in the bios (I have a photographic memory but otherwise a bad one overall :) ) It screams like a banshee when enabled. ¢éì¹» ®Þ~º¶¬+-±éݶ¥w®Ë±Êâmébìdz¹Þ)í æèw* jg¬±¨ ¶Ý¢j/êäz¹ÞàW±êÞiÛaxPjØm¶ÿà -»+ùd_
[2.4.x] Pentium FPU memcpy
The last version I've spotted was for mid-2.2 and was filled with gcc 2.7-isms in the assembler code. I was curious if anyone has updated this to version 2.4 at all because it makes all the difference in the world for me with my P60. Now that the memcpy stuff is somewhat modularized (with the Althon MMX copy stuff), it might be easier to adapt. I've tried converting it but I don't know the differences enough between currentgcc and old 2.7.2 assembler syntax. Thanks! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[2.4.x] Pentium FPU memcpy
The last version I've spotted was for mid-2.2 and was filled with gcc 2.7-isms in the assembler code. I was curious if anyone has updated this to version 2.4 at all because it makes all the difference in the world for me with my P60. Now that the memcpy stuff is somewhat modularized (with the Althon MMX copy stuff), it might be easier to adapt. I've tried converting it but I don't know the differences enough between currentgcc and old 2.7.2 assembler syntax. Thanks! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
