Re: 2.4.0-test12: SiS pirq handling..
On Mon, 29 Jan 2001, Linus Torvalds wrote: > Now, will the two people in the world who know the pirq black magic now > stand up and confirm or deride my interpretation? since I'm certainly not the other one, I'm not going to confirm it ;-) But, besides it sounds reasonable, I could give some more ammu: my IDE controller is located in the SiS5591 hostbridge (device 00:00) and the BIOS didn't provide a routing table entry for this device. Hence, instead of the confusing conflict messages, I get: SIS5513: IDE controller on PCI bus 00 dev 01 IRQ for 00:00.1:0 -> not found in routing table which you may take for a vice-versa prove of your explanation. Martin - 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..
On Mon, 29 Jan 2001, Linus Torvalds wrote: Now, will the two people in the world who know the pirq black magic now stand up and confirm or deride my interpretation? since I'm certainly not the other one, I'm not going to confirm it ;-) But, besides it sounds reasonable, I could give some more ammu: my IDE controller is located in the SiS5591 hostbridge (device 00:00) and the BIOS didn't provide a routing table entry for this device. Hence, instead of the confusing conflict messages, I get: SIS5513: IDE controller on PCI bus 00 dev 01 IRQ for 00:00.1:0 - not found in routing table which you may take for a vice-versa prove of your explanation. Martin - 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..
> Despite the latest ACPI update, I still get the ACPI slowdown on > initialisation which started with the -pre10 changes. Also, the uhci > module doesn't work for me (the latest patch from Johannes > Erdfelt does > work). This is an Abit KA7-100, which has the KX133 chipset. Here is > the dmesg output for this kernel (I had to turn off ACPI in > the BIOS in > order to have a usable system): Hi Adam. I am working right now on improving acpi idle. However, I'm somewhat confused by the trace below which includes: > ACPI: System description tables not found The ACPI driver's thread *should* then exit, and never register as the idle handler. My next update will also have some more diagnostic printk's so hopefully that will help, because right now I can't see how we can be failing to find tables, yet still registering as the idle handler. I'll look at it tomorrow morning, and maybe then it will be obvious. ;-) Regards -- Andy - 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..
> The other changes in pre12 aren't likely to be all that noticeable, unless > you happen to be hit by just that detail.. As always, fedback is > appreciated. > > Linus > > > > pre12: > - Get non-cpuid Cyrix probing right (it's not a NexGen) > - Jens Axboe: cdrom tray status and queing cleanups > - AGP GART: don't disable VIA, and allow i815 with external AGP > - Coda: use iget4() in order to have big inode numbers without clashes. > - Fix UDF writepage() page locking > - NIIBE Yutaka: SuperH update > - Martin Diehl and others: SiS pirq routing fixes > - Andy Grover: ACPI update > - Andrea Arkangeli: LVM update > - Ingo Molnar: RAID cleanups > - David Miller: sparc and networking updates > - Make NFS really be able to handle large files > Despite the latest ACPI update, I still get the ACPI slowdown on initialisation which started with the -pre10 changes. Also, the uhci module doesn't work for me (the latest patch from Johannes Erdfelt does work). This is an Abit KA7-100, which has the KX133 chipset. Here is the dmesg output for this kernel (I had to turn off ACPI in the BIOS in order to have a usable system): Linux version 2.4.1-pre12 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.0)) #3 Mon Jan 29 22:24:04 GMT 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (usable) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0001 @ (reserved) BIOS-e820: 0ff0 @ 0010 (usable) On node 0 totalpages: 65536 zone(0): 4096 pages. zone(1): 61440 pages. zone(2): 0 pages. Kernel command line: root=/dev/hde6 vga=1 mem=262144K Initializing CPU#0 Detected 800.059 MHz processor. Console: colour VGA+ 80x50 Calibrating delay loop... 1595.80 BogoMIPS Memory: 255488k/262144k available (1096k kernel code, 6268k reserved, 369k data, 184k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Before vendor init, caps: 0183f9ff c1c3f9ff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c3f9ff CPU: After generic, caps: 0183f9ff c1c3f9ff CPU: Common caps: 0183f9ff c1c3f9ff CPU: AMD Athlon(tm) Processor stepping 01 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xfb4d0, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent PCI: Using IRQ router VIA [1106/0686] at 00:07.0 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 DMI 2.3 present. 42 structures occupying 1165 bytes. DMI table at 0x000F0800. BIOS Vendor: Award Software International, Inc. BIOS Version: 6.00 PG BIOS Release: 07/20/2000 System Vendor: VIA Technologies, Inc.. Product Name: VT8371. Version . Serial Number . Starting kswapd v1.8 Detected PS/2 Mouse Port. pty: 256 Unix98 ptys configured block: queued sectors max/low 169765kB/56588kB, 512 slots per queue RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: enabling 8 loop devices Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 39 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1 ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:DMA, hdd:pio HPT370: IDE controller on PCI bus 00 dev 98 PCI: Found IRQ 11 for device 00:13.0 HPT370: chipset revision 3 HPT370: not 100% native mode: will probe irqs later ide2: BM-DMA at 0xe800-0xe807, BIOS settings: hde:DMA, hdf:pio ide3: BM-DMA at 0xe808-0xe80f, BIOS settings: hdg:DMA, hdh:pio hda: Maxtor 92049U6, ATA DISK drive ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx hdc: Pioneer DVD-ROM ATAPIModel DVD-104S 020, ATAPI CD/DVD-ROM drive hde: IBM-DTLA-307030, ATA DISK drive hdg: IBM-DTLA-307030, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 ide2 at 0xd800-0xd807,0xdc02 on irq 11 ide3 at 0xe000-0xe007,0xe402 on irq 11 hda: 40026672 sectors (20494 MB) w/2048KiB Cache, CHS=2491/255/63, UDMA(66) hde: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63,
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..
On Mon, 29 Jan 2001, Aaron Tiensivu wrote: > > Problem still exists, diffed to last kernel: Yes. But everything works for you, no? Including USB? 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. The trouble is that the routing table entry _also_ gets a false match to the IDE chip (PCI id 00:01.1), which doesn't get routed through the above AT ALL. So every time it sees either the USB or the IDE device, it will notice that there is a bogus routing table entry associated with the IDE device. As a result, 2.4.1-pre12 will now complain (twice - once when it tries to find the IDE irq route, the other time when it tries to find the USB irq route) that there seems to be a routing table conflict for device 00:01.1. In reality, the IDE device is routed with a fixed routing by the BIOS, and the BIOS has also set the device "irqline" config space entry to point to the proper table. So the IDE controller should work fine - and in fact it is this second piece of information from the PCI config space that makes Linux notice the conflict in the first place. So it does appear that everything is fine. Linux should be doing exactly the right thing on your board now, and USB _should_ work for you. The complaints are real, and more importantly I now think we understand _why_ they happen. It probably all used to work for you before, but we didn't really know _why_. Which is almost as nasty a situation as not working at all. 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"). But the BIOS didn't do this properly, and as a result we get these pirq clashes. Which are real, but should be harmless. Now, will the two people in the world who know the pirq black magic now stand up and confirm or deride my interpretation? Linus - 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..
On Mon, 29 Jan 2001, Linus Torvalds wrote: > give 2.4.0-test12 a final whirl before I release it as 2.4.1? We got a lot [...] > The other changes in pre12 aren't likely to be all that noticeable, unless [...] > Linus Seems that even you are still confused with -testXX and -preXX ;) *SCNR* sven -- The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/) - 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.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. The other changes in pre12 aren't likely to be all that noticeable, unless you happen to be hit by just that detail.. As always, fedback is appreciated. Linus pre12: - Get non-cpuid Cyrix probing right (it's not a NexGen) - Jens Axboe: cdrom tray status and queing cleanups - AGP GART: don't disable VIA, and allow i815 with external AGP - Coda: use iget4() in order to have big inode numbers without clashes. - Fix UDF writepage() page locking - NIIBE Yutaka: SuperH update - Martin Diehl and others: SiS pirq routing fixes - Andy Grover: ACPI update - Andrea Arkangeli: LVM update - Ingo Molnar: RAID cleanups - David Miller: sparc and networking updates - Make NFS really be able to handle large files pre11: - Trond Myklebust: NFS/RPC client SMP fixes - rth: alpha pyxis and cabriolet fixes - remove broken sys_wait4() declarations - disable radeon debugging code - VIA IDE driver should not enable autodma unless asked for - Andrey Savochkin: eepro100 update. Should fix the resource timing problems. - Jeff Garzik: via82cxxx_audio update - YMF7xx PCI audio update: get rid of old broken driver, make new driver handle legacy control too. - fix missed wakeup on block device request list - hpt366 controller doesn't play nice with some IBM harddisks - remove inode pages from the page cache only after having removed them from the page tables. - shared memory out-of-swap writepage() fixup (no more magic return) pre10: - got a few too-new R128 #defines in the Radeon merge. Fix. - tulip driver update from Jeff Garzik - more cpq and DAC elevator fixes from Jens. Looks good. - Petr Vandrovec: nicer ncpfs behaviour - Andy Grover: APCI update - Cort Dougan: PPC update - David Miller: sparc updates - David Miller: networking updates - Neil Brown: RAID5 fixes pre9: - cpq array driver elevator fixes - merge radeon driver from X CVS tree - ispnp cleanups - emu10k unlock on error fixes - hpfs doesn't allow truncate to larger pre8: - Don't drop a megabyte off the old-style memory size detection - remember to UnlockPage() in ramfs_writepage() - 3c59x driver update from Andrew Morton - egcs-1.1.2 miscompiles depca: workaround by Andrew Morton - dmfe.c module init fix: Andrew Morton - dynamic XMM support. Andrea Arkangeli. - ReiserFS merge - USB hotplug updates/fixes - boots on real i386 machines - blk-14 from Jens Axboe - fix DRM R128/AGP dependency - fix n_tty "canon" mode SMP race - ISDN fixes - ppp UP deadlock attack fix - FAT fat_cache SMP race fix - VM balancing tuning - Locked SHM segment deadlock fix - fork() page table copy race 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.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. The other changes in pre12 aren't likely to be all that noticeable, unless you happen to be hit by just that detail.. As always, fedback is appreciated. Linus pre12: - Get non-cpuid Cyrix probing right (it's not a NexGen) - Jens Axboe: cdrom tray status and queing cleanups - AGP GART: don't disable VIA, and allow i815 with external AGP - Coda: use iget4() in order to have big inode numbers without clashes. - Fix UDF writepage() page locking - NIIBE Yutaka: SuperH update - Martin Diehl and others: SiS pirq routing fixes - Andy Grover: ACPI update - Andrea Arkangeli: LVM update - Ingo Molnar: RAID cleanups - David Miller: sparc and networking updates - Make NFS really be able to handle large files pre11: - Trond Myklebust: NFS/RPC client SMP fixes - rth: alpha pyxis and cabriolet fixes - remove broken sys_wait4() declarations - disable radeon debugging code - VIA IDE driver should not enable autodma unless asked for - Andrey Savochkin: eepro100 update. Should fix the resource timing problems. - Jeff Garzik: via82cxxx_audio update - YMF7xx PCI audio update: get rid of old broken driver, make new driver handle legacy control too. - fix missed wakeup on block device request list - hpt366 controller doesn't play nice with some IBM harddisks - remove inode pages from the page cache only after having removed them from the page tables. - shared memory out-of-swap writepage() fixup (no more magic return) pre10: - got a few too-new R128 #defines in the Radeon merge. Fix. - tulip driver update from Jeff Garzik - more cpq and DAC elevator fixes from Jens. Looks good. - Petr Vandrovec: nicer ncpfs behaviour - Andy Grover: APCI update - Cort Dougan: PPC update - David Miller: sparc updates - David Miller: networking updates - Neil Brown: RAID5 fixes pre9: - cpq array driver elevator fixes - merge radeon driver from X CVS tree - ispnp cleanups - emu10k unlock on error fixes - hpfs doesn't allow truncate to larger pre8: - Don't drop a megabyte off the old-style memory size detection - remember to UnlockPage() in ramfs_writepage() - 3c59x driver update from Andrew Morton - egcs-1.1.2 miscompiles depca: workaround by Andrew Morton - dmfe.c module init fix: Andrew Morton - dynamic XMM support. Andrea Arkangeli. - ReiserFS merge - USB hotplug updates/fixes - boots on real i386 machines - blk-14 from Jens Axboe - fix DRM R128/AGP dependency - fix n_tty "canon" mode SMP race - ISDN fixes - ppp UP deadlock attack fix - FAT fat_cache SMP race fix - VM balancing tuning - Locked SHM segment deadlock fix - fork() page table copy race 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/
Re: 2.4.0-test12: SiS pirq handling..
On Mon, 29 Jan 2001, Linus Torvalds wrote: give 2.4.0-test12 a final whirl before I release it as 2.4.1? We got a lot [...] The other changes in pre12 aren't likely to be all that noticeable, unless [...] Linus Seems that even you are still confused with -testXX and -preXX ;) *SCNR* sven -- The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/) - 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..
On Mon, 29 Jan 2001, Aaron Tiensivu wrote: Problem still exists, diffed to last kernel: Yes. But everything works for you, no? Including USB? 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. The trouble is that the routing table entry _also_ gets a false match to the IDE chip (PCI id 00:01.1), which doesn't get routed through the above AT ALL. So every time it sees either the USB or the IDE device, it will notice that there is a bogus routing table entry associated with the IDE device. As a result, 2.4.1-pre12 will now complain (twice - once when it tries to find the IDE irq route, the other time when it tries to find the USB irq route) that there seems to be a routing table conflict for device 00:01.1. In reality, the IDE device is routed with a fixed routing by the BIOS, and the BIOS has also set the device "irqline" config space entry to point to the proper table. So the IDE controller should work fine - and in fact it is this second piece of information from the PCI config space that makes Linux notice the conflict in the first place. So it does appear that everything is fine. Linux should be doing exactly the right thing on your board now, and USB _should_ work for you. The complaints are real, and more importantly I now think we understand _why_ they happen. It probably all used to work for you before, but we didn't really know _why_. Which is almost as nasty a situation as not working at all. 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"). But the BIOS didn't do this properly, and as a result we get these pirq clashes. Which are real, but should be harmless. Now, will the two people in the world who know the pirq black magic now stand up and confirm or deride my interpretation? Linus - 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..
| 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..
Despite the latest ACPI update, I still get the ACPI slowdown on initialisation which started with the -pre10 changes. Also, the uhci module doesn't work for me (the latest patch from Johannes Erdfelt does work). This is an Abit KA7-100, which has the KX133 chipset. Here is the dmesg output for this kernel (I had to turn off ACPI in the BIOS in order to have a usable system): Hi Adam. I am working right now on improving acpi idle. However, I'm somewhat confused by the trace below which includes: ACPI: System description tables not found The ACPI driver's thread *should* then exit, and never register as the idle handler. My next update will also have some more diagnostic printk's so hopefully that will help, because right now I can't see how we can be failing to find tables, yet still registering as the idle handler. I'll look at it tomorrow morning, and maybe then it will be obvious. ;-) Regards -- Andy - 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/
