* Re: yenta_socket hangs sager laptop in kernel 2.4.6 [not found] <Pine.LNX.4.21.0107121802310.17665-100000@cobalt.deepthought.org> @ 2001-07-13 0:38 ` Linus Torvalds 2001-07-17 20:15 ` Martin Murray 0 siblings, 1 reply; 21+ messages in thread From: Linus Torvalds @ 2001-07-13 0:38 UTC (permalink / raw) To: Martin Murray; +Cc: Jeff Garzik, Kernel Mailing List Well, I think I've found the reason for your hang. Your video card is also on irq11. And I bet you don't have a driver that knows about it. So let's run a thought experiment: - enabling yenta enables the irq routing for "link 0x01", which is the first IRQ input into the southbridge. - some time later a vertical refresh happens - the video card, that is also routed to link 0x01, raises the vertical refresh irq. - Linux has a irq handler for irq11, but no yenta state changes, so the irq handler returns immediately without doing anything. - the video card (being a PCI card) still raises the irq. Forever. Repeat. Ho humm.. I'd love to test this out some way, but the video card does seem to be physically routed to the same southbridge interupt pin, so while I can move that interrupt around, the video card will always move with it. So it wouldn't help, for example, to try to make pci-irq.c try to select another irq line. So you can try two things: - if you have a BIOS setting for VGA interrupts, turn it OFF. - if you don't (or you just think you're too manly to resort to BIOS settings), you could try to add something like this as a hack to yenta.c (somewhere in the init routines) struct pci_dev * video; video = pci_find_class(PCI_CLASS_DISPLAY_VGA, NULL); if (video) { char * base = ioremap(pci_resource_start(dev, 2), 4096); /* Turn off interrupts for ATI Rage graphics card */ writel(0, base + 0x40); } Note, that "writel()" may or may not work. It's a guess from some rather limited documentation, namely the header #defines of the XFree86 driver. The above is a complete hack, and assumes that the only VGA-compatible controller in the system is an ATI card. But if you can't find a VGA irq enable thing in the BIOS setup, it might be worth trying. Linus ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: yenta_socket hangs sager laptop in kernel 2.4.6 2001-07-13 0:38 ` yenta_socket hangs sager laptop in kernel 2.4.6 Linus Torvalds @ 2001-07-17 20:15 ` Martin Murray 2001-07-17 21:33 ` Linus Torvalds 2001-07-21 13:35 ` kuznet 0 siblings, 2 replies; 21+ messages in thread From: Martin Murray @ 2001-07-17 20:15 UTC (permalink / raw) To: Linus Torvalds; +Cc: Jeff Garzik, Kernel Mailing List Sorry, I've been away for a few days. > Well, I think I've found the reason for your hang. > Your video card is also on irq11. So does my usb controller. It seems that all the integrated stuff use IRQ 11. > And I bet you don't have a driver that knows about it. You know. 2.2.19 uses my cardbus controller on IRQ 11 without a problem. Could it be something in the way the yenta_socket driver sets up the controller? I was thinking of dumping the read/write's from the i82365 from 2.2.19, and comparing it to the yenta_socket driver. Do you think this is worthwhile? I know your time is precious, but I'd like to fix this problem and will happily do the work if you can spare a few brain cycles on the problem. ;) Thanks, Martin ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: yenta_socket hangs sager laptop in kernel 2.4.6 2001-07-17 20:15 ` Martin Murray @ 2001-07-17 21:33 ` Linus Torvalds 2001-07-17 21:35 ` Martin Murray 2001-07-21 13:35 ` kuznet 1 sibling, 1 reply; 21+ messages in thread From: Linus Torvalds @ 2001-07-17 21:33 UTC (permalink / raw) To: Martin Murray; +Cc: Jeff Garzik, Kernel Mailing List On Tue, 17 Jul 2001, Martin Murray wrote: > > > And I bet you don't have a driver that knows about it. > > You know. 2.2.19 uses my cardbus controller on IRQ 11 without a > problem. Does it actually _use_ the cardbus PCI interrupt at all? At least older versions of the external pcmcia package didn't use the PCI interrupt by default at all, and relied on polling the state and the old ISA interrupts instead.. Linus ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: yenta_socket hangs sager laptop in kernel 2.4.6 2001-07-17 21:33 ` Linus Torvalds @ 2001-07-17 21:35 ` Martin Murray 0 siblings, 0 replies; 21+ messages in thread From: Martin Murray @ 2001-07-17 21:35 UTC (permalink / raw) To: Linus Torvalds; +Cc: Jeff Garzik, Kernel Mailing List > On Tue, 17 Jul 2001, Martin Murray wrote: > > > > > And I bet you don't have a driver that knows about it. > > > > You know. 2.2.19 uses my cardbus controller on IRQ 11 without a > > problem. > > Does it actually _use_ the cardbus PCI interrupt at all? At least older > versions of the external pcmcia package didn't use the PCI interrupt by > default at all, and relied on polling the state and the old ISA interrupts > instead.. Near as I can tell, it's listed in /proc/interrupts, and inserting/removing cards definately causes the counter to increment. I'm using pcmcia-cs-3.1.27's i82365. Also, dmesg shows it requesting the PCI IRQ. Ie, I get messages like: ... Linux PCMCIA Card Services 3.1.27 kernel build: 2.2.19 #2 Sat Jul 14 12:21:14 EDT 2001 options: [pci] [cardbus] [apm] PCI routing table version 1.0 at 0xfdf60 00:03.0 -> irq 11 00:03.1 -> irq 11 Intl PCIC probe: TI 1251B rev 00 PCI-to-CardBus at slot 00:03, mem 0x6800000 ... I just inserted and removed my aironet card, and the value in /proc/interrupts went from 9 to 14.. Could this be a problem in yenta_socket()'s initialization sequence? Thanks, Martin ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: yenta_socket hangs sager laptop in kernel 2.4.6 2001-07-17 20:15 ` Martin Murray 2001-07-17 21:33 ` Linus Torvalds @ 2001-07-21 13:35 ` kuznet 2001-07-21 15:47 ` Ben Greear 2001-08-20 14:17 ` Gerd Knorr 1 sibling, 2 replies; 21+ messages in thread From: kuznet @ 2001-07-21 13:35 UTC (permalink / raw) To: Martin Murray; +Cc: linux-kernel Hello! > You know. 2.2.19 uses my cardbus controller on IRQ 11 without a > problem. Could it be something in the way the yenta_socket driver sets up > the controller? I was thinking of dumping the read/write's from the i82365 > from 2.2.19, and comparing it to the yenta_socket driver. Do you think > this is worthwhile? Did you make any progress on this? I have similar problem. Probably, we could cooperate to find a way to solve this. Seems, you are right, yenta.c corrupts something in hardware and the problem is not related to irqs. Observations are: * No irqs are generated at all after lockup. Printk added at do_IRQ, no activity. (Moreover, here yenta irq is not shared with vga, but shared with firewire port though.) Nothing. I did not find any software activity at all. * No activity at pcmcia is required to lockup. Loading yenta_socket is enough. * Unloading yenta before lockup happened does not help, i.e. something is corrupted at time of yenta_init(). * Lockup _inevitably_ happens when yenta_init was executed once and I make any operation from set: 1. any call to APM bios, except for cpu idle. 2. Pressing any hotkey, including change of LCD brightness (Sic! The last event is _absolutely_ invisible to software, so that yenta_init does something terrible with hardware). linux-2.2 with pcmcia does work, so that puzzle really can be solved comparing operations made by both implementations. Did you make this? Alexey Kuznetsov ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: yenta_socket hangs sager laptop in kernel 2.4.6 2001-07-21 13:35 ` kuznet @ 2001-07-21 15:47 ` Ben Greear 2001-08-20 14:17 ` Gerd Knorr 1 sibling, 0 replies; 21+ messages in thread From: Ben Greear @ 2001-07-21 15:47 UTC (permalink / raw) To: kuznet; +Cc: Martin Murray, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2778 bytes --] kuznet@ms2.inr.ac.ru wrote: > > Hello! > > > You know. 2.2.19 uses my cardbus controller on IRQ 11 without a > > problem. Could it be something in the way the yenta_socket driver sets up > > the controller? I was thinking of dumping the read/write's from the i82365 > > from 2.2.19, and comparing it to the yenta_socket driver. Do you think > > this is worthwhile? > > Did you make any progress on this? > > I have similar problem. Probably, we could cooperate to find a way to solve > this. > This sounds suspiciously like the problem(s) I'm seeing with my Sony VAIO and the 2.4.5 and 2.4.6* kernels. It seems to work with RH 7.1 kernel (2.4.2+) though.... I did notice some messages about IRQ routing problems, but I'm not sure if they are really a problem... Here is a piece of the boot sequence from the 2.4.2 RH 7.1 kernel, via dmesg: ..... Via 686a audio driver 1.1.14b PCI: Found IRQ 10 for device 00:07.5 IRQ routing conflict in pirq table for device 00:07.5 IRQ routing conflict in pirq table for device 00:07.6 PCI: The same IRQ used for device 00:0a.1 PCI: The same IRQ used for device 00:10.0 via82cxxx: timeout while reading AC97 codec (0xAA0000) ..... The full dmesg output is attached in case that helps. > Seems, you are right, yenta.c corrupts something in hardware > and the problem is not related to irqs. Observations are: > > * No irqs are generated at all after lockup. Printk added at do_IRQ, no activity. > (Moreover, here yenta irq is not shared with vga, but shared with firewire > port though.) Nothing. I did not find any software activity at all. > * No activity at pcmcia is required to lockup. Loading yenta_socket is enough. > * Unloading yenta before lockup happened does not help, i.e. something > is corrupted at time of yenta_init(). > * Lockup _inevitably_ happens when yenta_init was executed once > and I make any operation from set: > 1. any call to APM bios, except for cpu idle. > 2. Pressing any hotkey, including change of LCD brightness > (Sic! The last event is _absolutely_ invisible to software, > so that yenta_init does something terrible with hardware). > > linux-2.2 with pcmcia does work, so that puzzle really can be solved > comparing operations made by both implementations. Did you make this? > > Alexey Kuznetsov > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Ben Greear <greearb@candelatech.com> <Ben_Greear@excite.com> President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear [-- Attachment #2: foo.txt --] [-- Type: text/plain, Size: 8156 bytes --] Linux version 2.4.2-2 (root@porky.devel.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-79)) #1 Sun Apr 8 20:41:30 EDT 2001 BIOS-provided physical RAM map: BIOS-e820: 000000000009f800 @ 0000000000000000 (usable) BIOS-e820: 0000000000000800 @ 000000000009f800 (reserved) BIOS-e820: 0000000000015c00 @ 00000000000ea400 (reserved) BIOS-e820: 0000000007ef0000 @ 0000000000100000 (usable) BIOS-e820: 000000000000fc00 @ 0000000007ff0000 (ACPI data) BIOS-e820: 0000000000000400 @ 0000000007fffc00 (ACPI NVS) BIOS-e820: 0000000000020000 @ 00000000fffe0000 (reserved) On node 0 totalpages: 32752 zone(0): 4096 pages. zone DMA has max 32 cached pages. zone(1): 28656 pages. zone Normal has max 223 cached pages. zone(2): 0 pages. zone HighMem has max 1 cached pages. Kernel command line: auto BOOT_IMAGE=linux ro root=305 BOOT_FILE=/boot/vmlinuz-2.4.2-2 Initializing CPU#0 Detected 800.052 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1595.80 BogoMIPS Memory: 126412k/131008k available (1365k kernel code, 4208k reserved, 92k data, 236k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 32768 (order: 6, 262144 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) VFS: Diskquotas version dquot_6.5.0 initialized CPU: Before vendor init, caps: 0183f9ff c1c7f9ff 00000000, vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 64K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff 00000000 00000000 CPU: After generic, caps: 0183f9ff c1c7f9ff 00000000 00000000 CPU: Common caps: 0183f9ff c1c7f9ff 00000000 00000000 CPU: AMD Duron(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 (rgooch@atnf.csiro.au) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xfd83d, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 2: assuming transparent PCI: Using IRQ router VIA [1106/0686] at 00:07.0 got res[10000000:10000fff] for resource 0 of Texas Instruments PCI1420 got res[10001000:10001fff] for resource 0 of Texas Instruments PCI1420 (#2) 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 83866kB/27955kB, 256 slots per queue RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize 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 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1 ide0: BM-DMA at 0x1c40-0x1c47, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x1c48-0x1c4f, BIOS settings: hdc:DMA, hdd:pio hda: FUJITSU MHM2100AT, ATA DISK drive hdc: HITACHI DVD-ROM GD-S200, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 19640880 sectors (10056 MB) w/2048KiB Cache, CHS=1222/255/63, UDMA(33) Partition check: hda: hda1 hda2 < hda5 hda6 > Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 Serial driver version 5.02 (2000-08-09) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A Real Time Clock Driver v1.10d md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md.c: sizeof(mdp_super_t) = 4096 autodetecting RAID arrays autorun ... ... autorun DONE. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 8192 bind 8192) Linux IP multicast router 0.06 plus PIM-SM NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 236k freed Adding Swap: 265032k swap-space (priority -1) usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-uhci.c: $Revision: 1.251 $ time 20:53:29 Apr 8 2001 usb-uhci.c: High bandwidth mode enabled PCI: Assigned IRQ 9 for device 00:07.2 PCI: The same IRQ used for device 00:07.3 PCI: The same IRQ used for device 00:0e.0 PCI: Setting latency timer of device 00:07.2 to 64 usb-uhci.c: USB UHCI at I/O 0x1c00, IRQ 9 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected PCI: Found IRQ 9 for device 00:07.3 PCI: The same IRQ used for device 00:07.2 PCI: The same IRQ used for device 00:0e.0 PCI: Setting latency timer of device 00:07.3 to 64 usb-uhci.c: USB UHCI at I/O 0x1c20, IRQ 9 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 2 ports detected Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ... SMSC Super-IO detection, now testing Ports 2F0, 370 ... 0x378: FIFO is 16 bytes 0x378: writeIntrThreshold is 8 0x378: readIntrThreshold is 8 0x378: PWord is 8 bits 0x378: Interrupts are ISA-Pulses 0x378: possible IRQ conflict! 0x378: ECP port cfgA=0x10 cfgB=0x00 0x378: ECP settings irq=<none or set by other means> dma=<none or set by other means> parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,COMPAT,ECP] parport0: cpp_daisy: aa5500ff(38) parport0: assign_addrs: aa5500ff(38) parport0: cpp_daisy: aa5500ff(38) parport0: assign_addrs: aa5500ff(38) parport_pc: Via 686A parallel port: io=0x378, irq=7 8139too Fast Ethernet driver 0.9.15 loaded PCI: Assigned IRQ 10 for device 00:10.0 IRQ routing conflict in pirq table for device 00:07.5 IRQ routing conflict in pirq table for device 00:07.6 PCI: The same IRQ used for device 00:0a.1 PCI: Setting latency timer of device 00:10.0 to 64 eth0: RealTek RTL8139 Fast Ethernet at 0xc883d800, 08:00:46:1d:7b:d8, IRQ 10 eth0: Identified 8139 chip type 'RTL-8139C' eth0: Setting half-duplex based on auto-negotiated partner ability 0000. Linux PCMCIA Card Services 3.1.22 options: [pci] [cardbus] [pm] PCI: Assigned IRQ 9 for device 00:0a.0 PCI: Found IRQ 10 for device 00:0a.1 IRQ routing conflict in pirq table for device 00:07.5 IRQ routing conflict in pirq table for device 00:07.6 PCI: The same IRQ used for device 00:10.0 Yenta IRQ list 0808, PCI irq9 Socket status: 30000010 Yenta IRQ list 0808, PCI irq10 Socket status: 30000010 cs: IO port probe 0x0c00-0x0cff: clean. cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x4d0-0x4d7 cs: IO port probe 0x0a00-0x0aff: clean. cs: memory probe 0xa0000000-0xa0ffffff: clean. eth1: NE2000 (DL10022 rev 30): io 0x300, irq 3, hw_addr 00:50:BA:70:69:F1 eth2: NE2000 (DL10022 rev 30): io 0x320, irq 11, hw_addr 00:50:BA:70:69:EC NET4: Linux IPX 0.46 for NET4.0 IPX Portions Copyright (c) 1995 Caldera, Inc. IPX Portions Copyright (c) 2000, 2001 Conectiva, Inc. NET4: AppleTalk 0.18a for Linux NET4.0 eth1: MII is missing! eth1: found link beat eth1: autonegotiation complete: 100baseT-FD selected eth2: MII is missing! eth2: found link beat eth2: autonegotiation complete: 100baseT-FD selected mtrr: type mismatch for f5000000,800000 old: write-back new: write-combining mtrr: type mismatch for f5000000,800000 old: write-back new: write-combining Via 686a audio driver 1.1.14b PCI: Found IRQ 10 for device 00:07.5 IRQ routing conflict in pirq table for device 00:07.5 IRQ routing conflict in pirq table for device 00:07.6 PCI: The same IRQ used for device 00:0a.1 PCI: The same IRQ used for device 00:10.0 via82cxxx: timeout while reading AC97 codec (0xAA0000) ac97_codec: AC97 Audio codec, id: 0x4144:0x5348 (Analog Devices AD1881A) via82cxxx: board #1 at 0x1000, IRQ 5 hdc: ATAPI 24X DVD-ROM drive, 512kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.12 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: yenta_socket hangs sager laptop in kernel 2.4.6 2001-07-21 13:35 ` kuznet 2001-07-21 15:47 ` Ben Greear @ 2001-08-20 14:17 ` Gerd Knorr 2001-08-20 22:52 ` Alexey Kuznetsov 2001-08-21 20:37 ` Gerd Knorr 1 sibling, 2 replies; 21+ messages in thread From: Gerd Knorr @ 2001-08-20 14:17 UTC (permalink / raw) To: linux-kernel > Seems, you are right, yenta.c corrupts something in hardware > and the problem is not related to irqs. It is not IRQ-related at all. > Observations are: > > * No irqs are generated at all after lockup. Printk added at do_IRQ, no activity. > (Moreover, here yenta irq is not shared with vga, but shared with firewire > port though.) Nothing. I did not find any software activity at all. > * No activity at pcmcia is required to lockup. Loading yenta_socket is enough. > * Unloading yenta before lockup happened does not help, i.e. something > is corrupted at time of yenta_init(). > * Lockup _inevitably_ happens when yenta_init was executed once > and I make any operation from set: > 1. any call to APM bios, except for cpu idle. > 2. Pressing any hotkey, including change of LCD brightness > (Sic! The last event is _absolutely_ invisible to software, > so that yenta_init does something terrible with hardware). Same problem here. I've spend some time today to figure what is going on. Workaround: ---------------------------- cut here ----------------------------- --- 2.4.9/drivers/pcmcia/yenta.c.fix Mon Aug 20 11:02:23 2001 +++ 2.4.9/drivers/pcmcia/yenta.c Mon Aug 20 14:21:33 2001 @@ -729,7 +729,7 @@ if (type & IORESOURCE_IO) { align = 1024; size = 256; - min = PCIBIOS_MIN_IO; + min = 0x4000 /* PCIBIOS_MIN_IO */; max = 0xffff; } ---------------------------- cut here ----------------------------- Looks like a ressource conflict to me. The kernel gives I/O ranges to the cardbus socket which it thinks are free but which are *not* free for some reason (and probably used for APM stuff). BIOS bug? PCI quirks time? /proc/ioports looks like this (with patch): 0000-001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 01f0-01f7 : ide0 02f8-02ff : nsc-ircc 03c0-03df : vesafb 03f6-03f6 : ide0 0cf8-0cff : PCI conf1 1100-110f : Intel Corporation 82440MX EIDE Controller 1100-1107 : ide0 1200-121f : Intel Corporation 82440MX USB Universal Host Controller 1200-121f : usb-uhci 1500-153f : Intel Corporation 82440MX AC'97 Audio Controller 1500-153f : Intel 440MX 1600-16ff : Intel Corporation 82440MX AC'97 Audio Controller 1600-16ff : Intel 440MX 1700-177f : PCI device 8086:7196 (Intel Corporation) 1800-18ff : PCI device 8086:7196 (Intel Corporation) 3000-30ff : ATI Technologies Inc 3D Rage P/M Mobility 3e00-3eff : Realtek Semiconductor Co., Ltd. RTL-8139 3e00-3eff : 8139too 4000-40ff : PCI CardBus #01 4400-44ff : PCI CardBus #01 lspci says: 00:00.0 Host bridge: Intel Corporation 82440MX I/O Controller (rev 01) Subsystem: Mitac: Unknown device 7722 Flags: bus master, medium devsel, latency 64 00:00.1 Multimedia audio controller: Intel Corporation 82440MX AC'97 Audio Controller Subsystem: Mitac: Unknown device 7722 Flags: bus master, fast devsel, latency 0, IRQ 5 I/O ports at 1600 [size=256] I/O ports at 1500 [size=64] 00:00.2 Modem: Intel Corporation: Unknown device 7196 (prog-if 00 [Generic]) Subsystem: Mitac: Unknown device 7722 Flags: bus master, fast devsel, latency 0, IRQ 5 I/O ports at 1800 [size=256] I/O ports at 1700 [size=128] 00:07.0 ISA bridge: Intel Corporation 82440MX PCI to ISA Bridge (rev 01) Flags: bus master, medium devsel, latency 0 00:07.1 IDE interface: Intel Corporation 82440MX EIDE Controller (prog-if 80 [Master]) Flags: bus master, medium devsel, latency 64 I/O ports at 1100 [size=16] 00:07.2 USB Controller: Intel Corporation 82440MX USB Universal Host Controller (prog-if 00 [UHCI]) Flags: bus master, medium devsel, latency 240, IRQ 11 I/O ports at 1200 [size=32] 00:07.3 Bridge: Intel Corporation 82440MX Power Management Controller Flags: medium devsel 00:08.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01) Subsystem: Mitac: Unknown device 7722 Flags: bus master, medium devsel, latency 168, IRQ 10 Memory at 10000000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=01, subordinate=04, sec-latency=176 Memory window 0: 10400000-107ff000 (prefetchable) Memory window 1: 10800000-10bff000 I/O window 0: 00004000-000040ff I/O window 1: 00004400-000044ff 16-bit legacy interface ports at 0001 00:09.0 VGA compatible controller: ATI Technologies Inc 3D Rage P/M Mobility (rev 64) (prog-if 00 [VGA]) Subsystem: Mitac: Unknown device 7722 Flags: bus master, stepping, medium devsel, latency 0 Memory at c0000000 (32-bit, non-prefetchable) [size=16M] I/O ports at 3000 [size=256] Memory at c1000000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at <unassigned> [disabled] [size=128K] Capabilities: [5c] Power Management version 1 00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10) Subsystem: Mitac: Unknown device 7722 Flags: bus master, medium devsel, latency 128, IRQ 11 I/O ports at 3e00 [size=256] Memory at e9100000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 00:0b.0 FireWire (IEEE 1394): NEC Corporation: Unknown device 00cd (rev 02) (prog-if 10 [OHCI]) Subsystem: Mitac: Unknown device 7722 Flags: bus master, medium devsel, latency 64, IRQ 10 Memory at 10001000 (32-bit, non-prefetchable) [size=4K] Capabilities: [60] Power Management version 1 Gerd -- Damn lot people confuse usability and eye-candy. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: yenta_socket hangs sager laptop in kernel 2.4.6 2001-08-20 14:17 ` Gerd Knorr @ 2001-08-20 22:52 ` Alexey Kuznetsov 2001-08-21 20:37 ` Gerd Knorr 1 sibling, 0 replies; 21+ messages in thread From: Alexey Kuznetsov @ 2001-08-20 22:52 UTC (permalink / raw) To: Gerd Knorr; +Cc: linux-kernel Hello! > Same problem here. I've spend some time today to figure what is going > on. Workaround: > > ---------------------------- cut here ----------------------------- > --- 2.4.9/drivers/pcmcia/yenta.c.fix Mon Aug 20 11:02:23 2001 > +++ 2.4.9/drivers/pcmcia/yenta.c Mon Aug 20 14:21:33 2001 > @@ -729,7 +729,7 @@ > if (type & IORESOURCE_IO) { > align = 1024; > size = 256; > - min = PCIBIOS_MIN_IO; > + min = 0x4000 /* PCIBIOS_MIN_IO */; > max = 0xffff; > } > > ---------------------------- cut here ----------------------------- I do not know how to thank you... You saved my life. :-) How did you guess this? > Looks like a ressource conflict to me. The kernel gives I/O ranges to > the cardbus socket which it thinks are free but which are *not* free for > some reason (and probably used for APM stuff). BIOS bug? PCI quirks > time? The same hardware is here, Mitac M722. :-) BTW what bios is installed on your one? Anyway, Windows with the _same_ bios manages to guess and to reserve a few of ports tagged as some obscure "motherboard resources": 230-233, 398-399, 4d0-4d1, 1000-103f(!), 1400-140f(!) and 3810-381f. yenta_socket eats ones marked with !. At least 1400 is really critical, it is interface to SM mode. So, probably, more correct fix is something sort of: --- mitac-quirk.c #include <linux/config.h> #include <linux/version.h> #include <linux/module.h> #include <linux/kernel.h> #include <linux/ioport.h> #include <linux/init.h> static __init int mitac_init(void) { /* No guesses */ request_region(0x230, 4, "Mitac"); /* Hmm... look at 0x64 @ 0:7.3, 0x398 is set there, no doubts. * What is this? */ request_region(0x398, 2, "Mitac"); /* 82440MX: ELCR 1&2, Edge/Level Control Regs */ request_region(0x4D0, 2, "82440MX INT CNTRL"); /* No guesses */ request_region(0x1000, 0x40, "Mitac"); /* SMBus: selected with bits 4:15 at 0x90 @ 0:7.3 */ request_region(0x1400, 0x10, "82440MX SMBus"); /* No guesses. */ request_region(0x3810, 0x10, "Mitac"); return 0; } module_init(mitac_init); /* * Local variables: * compile-command: "gcc -DMODULE -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -c mitac.c" * End: */ Alexey ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: yenta_socket hangs sager laptop in kernel 2.4.6 2001-08-20 14:17 ` Gerd Knorr 2001-08-20 22:52 ` Alexey Kuznetsov @ 2001-08-21 20:37 ` Gerd Knorr 2001-08-22 17:35 ` yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver Gunther Mayer 1 sibling, 1 reply; 21+ messages in thread From: Gerd Knorr @ 2001-08-21 20:37 UTC (permalink / raw) To: Alexey Kuznetsov; +Cc: linux-kernel In lists.linux.kernel, you wrote: > Hello! > > > Same problem here. I've spend some time today to figure what is going > > on. Workaround: > > - min = PCIBIOS_MIN_IO; > > + min = 0x4000 /* PCIBIOS_MIN_IO */; > > I do not know how to thank you... You saved my life. :-) > How did you guess this? Long trial-and-error session. Deactivate code and see if it still does crash to narrow down the code lines which trigger the lockup. Once I've figured that enabling the I/O-Windows triggers the lookup the guess was easy ... > > Looks like a ressource conflict to me. The kernel gives I/O ranges to > > the cardbus socket which it thinks are free but which are *not* free for > > some reason (and probably used for APM stuff). BIOS bug? PCI quirks > > time? > > The same hardware is here, Mitac M722. :-) BTW what bios is installed > on your one? "SYSTEM BIOS R1.02" > Anyway, Windows with the _same_ bios manages to guess and to reserve > a few of ports tagged as some obscure "motherboard resources": > 230-233, 398-399, 4d0-4d1, 1000-103f(!), 1400-140f(!) and 3810-381f. > yenta_socket eats ones marked with !. At least 1400 is really critical, > it is interface to SM mode. 0x1000 is critical too. Activating the first I/O window only is enough to hang the notebook on any APM activity. > So, probably, more correct fix > is something sort of: > > --- mitac-quirk.c > [ reserve resources ] I've also noticed this in the boot messages: PCI: PCI BIOS revision 2.10 entry at 0xeb1d0, last bus=0 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router PIIX [8086/7198] at 00:07.0 PCI: Cannot allocate resource region 0 of device 00:0b.0 got res[10000000:10000fff] for resource 0 of Texas Instruments PCI1410 PC card Cardbus Controller got res[10001000:10001fff] for resource 0 of PCI device 1033:00cd (NEC Corporation) PCI: BIOS reporting unknown device 00:01 PCI: BIOS reporting unknown device 00:02 The "unknown device" looks suspicious to me ... Gerd -- Damn lot people confuse usability and eye-candy. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver 2001-08-21 20:37 ` Gerd Knorr @ 2001-08-22 17:35 ` Gunther Mayer 0 siblings, 0 replies; 21+ messages in thread From: Gunther Mayer @ 2001-08-22 17:35 UTC (permalink / raw) To: Gerd Knorr, Alexey Kuznetsov, alan; +Cc: linux-kernel Gerd Knorr wrote: > > In lists.linux.kernel, you wrote: > > Hello! > > > > > Same problem here. I've spend some time today to figure what is going > > > on. Workaround: > > > - min = PCIBIOS_MIN_IO; > > > + min = 0x4000 /* PCIBIOS_MIN_IO */; > > > > I do not know how to thank you... You saved my life. :-) > > How did you guess this? > > Long trial-and-error session. Deactivate code and see if it still does > crash to narrow down the code lines which trigger the lockup. Once I've > figured that enabling the I/O-Windows triggers the lookup the guess was > easy ... > > > > Looks like a ressource conflict to me. The kernel gives I/O ranges to > > > the cardbus socket which it thinks are free but which are *not* free for > > > some reason (and probably used for APM stuff). BIOS bug? PCI quirks > > > time? Longstanding Linux Bug: "ignore a _seven_ year old standard called PNPBIOS". > > > > The same hardware is here, Mitac M722. :-) BTW what bios is installed > > on your one? > > "SYSTEM BIOS R1.02" > > > Anyway, Windows with the _same_ bios manages to guess and to reserve > > a few of ports tagged as some obscure "motherboard resources": > > 230-233, 398-399, 4d0-4d1, 1000-103f(!), 1400-140f(!) and 3810-381f. > > yenta_socket eats ones marked with !. At least 1400 is really critical, > > it is interface to SM mode. > > 0x1000 is critical too. Activating the first I/O window only is enough > to hang the notebook on any APM activity. PNPBIOS _easily_ resolves this problem ! Try -ac Kernels with integrated PNPBIOS and "lspnp -v", then you will see your "motherboard resources". No magic. Note: Linux currently does _not_ yet reserve these resources automatically (although I think the standalone pcmcia package has such an option). By confirming (and posting your lspnp results) you could encourage some developers to rectify this situation :-) Alan, 2.4 would largely benefit from PNPBIOS, do you plan to submit this to LT (probably with the proposed life saver fix) ? - Gunther ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <no.id>]
* Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver [not found] <no.id> @ 2001-08-22 18:18 ` Alan Cox 2001-08-22 18:32 ` Gunther Mayer 2001-08-23 9:11 ` Gerd Knorr 0 siblings, 2 replies; 21+ messages in thread From: Alan Cox @ 2001-08-22 18:18 UTC (permalink / raw) To: Gunther Mayer; +Cc: Gerd Knorr, Alexey Kuznetsov, alan, linux-kernel > Try -ac Kernels with integrated PNPBIOS and "lspnp -v", > then you will see your "motherboard resources". No magic. Except on the intel boards where your machine crashes, the vaio's where some queries corrupt memory, the boxes where an interrupt during a pnpbios call crashes the box, the machines where pnpbios called from both cpus at the same time is a crash case, the wonderful weird tiny races on some boxes that use smm traps and fail if random undefined things occur between the two out instructions... > Alan, 2.4 would largely benefit from PNPBIOS, do you plan > to submit this to LT (probably with the proposed life saver fix) ? Experience is that PnpBIOS services are so astoundingly buggy in many bioses that they are probably not worth the risk. Ie more boxes break by calling pnpbios than by assuming the vendor used a sane resource layout. Before PnPBIOS can go mainstream we'd have to generate a detailed list of buggy bios signatures Alan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver 2001-08-22 18:18 ` Alan Cox @ 2001-08-22 18:32 ` Gunther Mayer 2001-08-23 9:11 ` Gerd Knorr 1 sibling, 0 replies; 21+ messages in thread From: Gunther Mayer @ 2001-08-22 18:32 UTC (permalink / raw) To: Alan Cox; +Cc: linux-kernel Alan Cox wrote: > > > Try -ac Kernels with integrated PNPBIOS and "lspnp -v", > > then you will see your "motherboard resources". No magic. > > Except on the intel boards where your machine crashes, the vaio's where > some queries corrupt memory, the boxes where an interrupt during a pnpbios > call crashes the box, the machines where pnpbios called from both cpus at > the same time is a crash case, the wonderful weird tiny races on some boxes > that use smm traps and fail if random undefined things occur between the > two out instructions... So call it only once early on boot (in real mode) and save the table for later use (we don't need the fancy features ...) ? > > Alan, 2.4 would largely benefit from PNPBIOS, do you plan > > to submit this to LT (probably with the proposed life saver fix) ? > > Experience is that PnpBIOS services are so astoundingly buggy in many > bioses that they are probably not worth the risk. Ie more boxes break by > calling pnpbios than by assuming the vendor used a sane resource layout. How are these bugs handled by Windows ? Must we only mimick the Windows call layout to enter bios-writer's well tested code path ? > Before PnPBIOS can go mainstream we'd have to generate a detailed list > of buggy bios signatures ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver 2001-08-22 18:18 ` Alan Cox 2001-08-22 18:32 ` Gunther Mayer @ 2001-08-23 9:11 ` Gerd Knorr 2001-08-23 12:50 ` Gerd Knorr 2001-08-23 13:00 ` Alan Cox 1 sibling, 2 replies; 21+ messages in thread From: Gerd Knorr @ 2001-08-23 9:11 UTC (permalink / raw) To: Alan Cox; +Cc: Gunther Mayer, Alexey Kuznetsov, alan, linux-kernel On Wed, Aug 22, 2001 at 07:18:20PM +0100, Alan Cox wrote: > > Try -ac Kernels with integrated PNPBIOS and "lspnp -v", > > then you will see your "motherboard resources". No magic. > > Except on the intel boards [ ... bios bugs list snipped ... ] 2.4.8-ac8 works for me, and lspnp does list these "obscure" ressources: bytesex kraxel ~# /root/bin/lspnp -v 00 PNP0c01 memory controller: RAM mem 0x00000000-0x0009ffff mem 0x00100000-0x0bfdffff mem 0x0bfe0000-0x0bfeffff mem 0x000e0000-0x000fffff mem 0xffff0000-0xffffffff io 0x0398-0x0399 io 0x0024-0x003d io 0x0062-0x0062 io 0x0066-0x0066 io 0x0090-0x009f io 0x00a4-0x00bd io 0x0230-0x0233 io 0x1000-0x103f io 0x1400-0x140f io 0x3810-0x381f 01 PNP0c02 reserved: other io 0x0cf8-0x0cff io 0x04d0-0x04d1 02 PNP0c04 system peripheral: other irq 13 io 0x00f0-0x00ff 03 PNP0000 system peripheral: programmable interrupt controller [ ... more standard PC hardware follows ... ] But it seems they are _not_ reserved by the pnp bios code, at least they are not listed in /proc/ioports > Before PnPBIOS can go mainstream we'd have to generate a detailed list > of buggy bios signatures Why? It shouldn't harm if disabled, so IMHO it should be fine when flagged "experimental" and with a warning label about broken bioses in Configure.help ... Gerd -- Damn lot people confuse usability and eye-candy. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver 2001-08-23 9:11 ` Gerd Knorr @ 2001-08-23 12:50 ` Gerd Knorr 2001-08-23 13:00 ` Alan Cox 1 sibling, 0 replies; 21+ messages in thread From: Gerd Knorr @ 2001-08-23 12:50 UTC (permalink / raw) To: linux-kernel > But it seems they are _not_ reserved by the pnp bios code, at least they > are not listed in /proc/ioports I've hacked up a small piece of code which does the ressource registering: ----------------- cut here ------------------ #include <linux/config.h> #include <linux/module.h> #include <linux/init.h> #include <asm/io.h> #include <asm/dma.h> #include <asm/uaccess.h> #include <linux/pnp_bios.h> static void register_stuff(struct pci_dev *dev) { struct resource *res; int i; for (i = 0; i < DEVICE_COUNT_RESOURCE && (dev->resource[i].start || dev->resource[i].end); i++) { if (dev->resource[i].start <= 0xffff) { res = request_region(dev->resource[i].start, dev->resource[i].end - dev->resource[i].start, dev->name); printk("mboard: alloc io: 0x%04lx-0x%04lx [%s,%s]\n", dev->resource[i].start, dev->resource[i].end, dev->name, res ? "ok" : "failed"); } } if (i == DEVICE_COUNT_RESOURCE) printk("mboard: warning: >= %d resources\n", DEVICE_COUNT_RESOURCE); } static int mboard_init(void) { struct pci_dev *dev; int found; dev = NULL; found = 0; while ((dev=pnpbios_find_device("PNP0c01",dev))) { register_stuff(dev); found++; } if (found) MOD_INC_USE_COUNT; return 0; } static void mboard_fini(void) { } module_init(mboard_init); module_exit(mboard_fini); ----------------- cut here ------------------ A full patch with this + pnpbios support (pulled out of -ac) for 2.4.9 is available from http://bytesex.org/notebook/pnpbios-2.4.9.diff Now I have this in my /proc/ioports: 0000-001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 0090-009f : PNPBIOS 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 01f0-01f7 : ide0 0230-0233 : PNPBIOS 02f8-02ff : nsc-ircc 0398-0399 : PNPBIOS 03c0-03df : vesafb 03f6-03f6 : ide0 0cf8-0cff : PCI conf1 1000-103f : PNPBIOS 1100-110f : Intel Corporation 82440MX EIDE Controller 1100-1107 : ide0 1200-121f : Intel Corporation 82440MX USB Universal Host Controller 1200-121f : usb-uhci 1400-140f : PNPBIOS 1500-153f : Intel Corporation 82440MX AC'97 Audio Controller 1500-153f : Intel 440MX 1600-16ff : Intel Corporation 82440MX AC'97 Audio Controller 1600-16ff : Intel 440MX 1700-177f : PCI device 8086:7196 (Intel Corporation) 1800-18ff : PCI device 8086:7196 (Intel Corporation) 1c00-1cff : PCI CardBus #01 2000-20ff : PCI CardBus #01 3000-30ff : ATI Technologies Inc 3D Rage P/M Mobility 3810-381f : PNPBIOS 3e00-3eff : Realtek Semiconductor Co., Ltd. RTL-8139 3e00-3eff : 8139too Note that DEVICE_COUNT_RESOURCE == 12 is too small to hold all the resources, so I've bumped that to 16. Gerd -- Damn lot people confuse usability and eye-candy. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver 2001-08-23 9:11 ` Gerd Knorr 2001-08-23 12:50 ` Gerd Knorr @ 2001-08-23 13:00 ` Alan Cox 2001-08-23 16:58 ` kuznet 2001-08-24 10:18 ` Gerd Knorr 1 sibling, 2 replies; 21+ messages in thread From: Alan Cox @ 2001-08-23 13:00 UTC (permalink / raw) To: Gerd Knorr; +Cc: Alan Cox, Gunther Mayer, Alexey Kuznetsov, alan, linux-kernel > > Before PnPBIOS can go mainstream we'd have to generate a detailed list > > of buggy bios signatures > > Why? It shouldn't harm if disabled, so IMHO it should be fine when > flagged "experimental" and with a warning label about broken bioses in > Configure.help ... We will see what happens. Certainly if someone wants to provide pnpbios code patches for -ac that grab and reserve the motherboard resources from the PCI code go ahead. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver 2001-08-23 13:00 ` Alan Cox @ 2001-08-23 16:58 ` kuznet 2001-08-23 18:23 ` Gunther Mayer 2001-08-24 10:18 ` Gerd Knorr 1 sibling, 1 reply; 21+ messages in thread From: kuznet @ 2001-08-23 16:58 UTC (permalink / raw) To: Alan Cox; +Cc: kraxel, alan, Gunther.Mayer, alan, linux-kernel Hello! > We will see what happens. Certainly if someone wants to provide pnpbios code > patches for -ac that grab and reserve the motherboard resources from the PCI > code go ahead. Khm... this does not look simple. Seems, right way involves modification of each place, where the same ports are used by kernel. pcmcia-cs had completely private resource manager, so that it just did not worry about other subsystems and they still were able to allocate the same resources. Look f.e. at extermal example, pnpbios announces as "system" resource all the memory. :-) Pallaitive soultions, sort of reserving of ports >= 0x1000 using this information do not look cool too. Alexey ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver 2001-08-23 16:58 ` kuznet @ 2001-08-23 18:23 ` Gunther Mayer 2001-08-23 18:34 ` kuznet 0 siblings, 1 reply; 21+ messages in thread From: Gunther Mayer @ 2001-08-23 18:23 UTC (permalink / raw) To: kuznet; +Cc: linux-kernel kuznet@ms2.inr.ac.ru wrote: > > Hello! > > > We will see what happens. Certainly if someone wants to provide pnpbios code > > patches for -ac that grab and reserve the motherboard resources from the PCI > > code go ahead. > > Khm... this does not look simple. Seems, right way involves modification > of each place, where the same ports are used by kernel. The PNP0C01 ports are not used by the kernel ! No modifications necessary. Of course you can teach each driver about their PNP devices, e.g. my patch for parport_pc.c makes perfect io/irq/dma detection and saves users from the error-prone procedure to supply module parameters. Even serial now autodetects IRQ 10 when I give this in my BIOS setup ! > pcmcia-cs had completely private resource manager, so that it just > did not worry about other subsystems and they still were able to allocate > the same resources. > > Look f.e. at extermal example, pnpbios announces as "system" resource > all the memory. :-) So we have another way besides several INTs to detect the avail mem :-) > > Pallaitive soultions, sort of reserving of ports >= 0x1000 using > this information do not look cool too. Gerd's patch rules out your objections and should be included unconditionally with pnpbios.o. Probably PNP0C02 wants to be reserved, too. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver 2001-08-23 18:23 ` Gunther Mayer @ 2001-08-23 18:34 ` kuznet 2001-08-25 10:27 ` Gunther Mayer 0 siblings, 1 reply; 21+ messages in thread From: kuznet @ 2001-08-23 18:34 UTC (permalink / raw) To: Gunther Mayer; +Cc: linux-kernel Hello! > So we have another way besides several INTs to detect the avail mem :-) Well, if this memory is available then I guess port 0x1000 is "available" as well and all the rest of ports are not available. :-) No, something is rotted in this kingdom. > Probably PNP0C02 wants to be reserved, too. What's about these, they are nice port and could be used by our irq handler. According to docs they replace functionality missing in standard int. controller ports for this chipset. What's about passing parameters from bios setup to linux... This is amusing, but not more. I am sorry, I still prefer to use usual kernel command line instead of some ugly foreign interface. Alexey ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver 2001-08-23 18:34 ` kuznet @ 2001-08-25 10:27 ` Gunther Mayer 2001-08-25 17:00 ` kuznet 0 siblings, 1 reply; 21+ messages in thread From: Gunther Mayer @ 2001-08-25 10:27 UTC (permalink / raw) To: kuznet; +Cc: linux-kernel kuznet@ms2.inr.ac.ru wrote: > > Hello! > > > So we have another way besides several INTs to detect the avail mem :-) > > Well, if this memory is available then I guess port 0x1000 is "available" > as well and all the rest of ports are not available. :-) Read "available" as "onboard". Before you use onboard resources you should know what it is ! Surely you don't want to place a PCI ioport window over unknown ports (as this is what yenta did). > No, something is rotted in this kingdom. > > > Probably PNP0C02 wants to be reserved, too. > > What's about these, they are nice port and could be used by our irq handler. These ports are not nice here and should not be user by the irq handler: PNP0c02 Motherboard resources io 0x0290-0x0297 > According to docs they replace functionality missing in standard > int. controller ports for this chipset. What docs ? > > What's about passing parameters from bios setup to linux... The BIOS setup uses PNPBIOS to pass parameters to Linux :-) > This is amusing, but not more. I am sorry, I still prefer to use usual > kernel command line instead of some ugly foreign interface. You miss the point of PNP and user-friendliness. This is a necessary interface to prevent (nearly undebuggable) linux hard hangs ! However, Gerd's debugging forces and his new patch already solve this thread by giving a working solution. - Gunther ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver 2001-08-25 10:27 ` Gunther Mayer @ 2001-08-25 17:00 ` kuznet 0 siblings, 0 replies; 21+ messages in thread From: kuznet @ 2001-08-25 17:00 UTC (permalink / raw) To: Gunther Mayer; +Cc: linux-kernel Hello! > Before you use onboard resources you should know what it is ! > Surely you don't want to place a PCI ioport window over unknown ports > (as this is what yenta did). This is right. Though, to make situation more clean explain me one much simpler thing: look at these lines from beginning of my lspnp -v: 00 PNP0c01 System board mem 0x00000000-0x0009ffff mem 0x00100000-0x0bfdffff mem 0x0bfe0000-0x0bfeffff mem 0x000e0000-0x000fffff mem 0xffff0000-0xffffffff Look at line mem 0x0bfe0000-0x0bfeffff. I hope you never saw this motherboard before, like this happens with our poor kernel, so you are not in better position. Imagine, you are kernel, and decide are you allowed to use these 64K or not? :-) Additional information: bios-e820 reports this area as ram in one block with all the rest of memory 0x00100000-0x0bfeffff. > What docs ? Intel datashits from developer.intel.com. Alexey ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver 2001-08-23 13:00 ` Alan Cox 2001-08-23 16:58 ` kuznet @ 2001-08-24 10:18 ` Gerd Knorr 1 sibling, 0 replies; 21+ messages in thread From: Gerd Knorr @ 2001-08-24 10:18 UTC (permalink / raw) To: Alan Cox; +Cc: Gunther Mayer, Alexey Kuznetsov, alan, linux-kernel On Thu, Aug 23, 2001 at 02:00:35PM +0100, Alan Cox wrote: > We will see what happens. Certainly if someone wants to provide pnpbios code > patches for -ac that grab and reserve the motherboard resources from the PCI > code go ahead. Here is. Gerd ---------------------- cut here ------------------------- --- 2.4.8-ac8/include/linux/pci.h.fix Fri Aug 24 11:40:14 2001 +++ 2.4.8-ac8/include/linux/pci.h Fri Aug 24 11:40:28 2001 @@ -317,7 +317,7 @@ #define DEVICE_COUNT_COMPATIBLE 4 #define DEVICE_COUNT_IRQ 2 #define DEVICE_COUNT_DMA 2 -#define DEVICE_COUNT_RESOURCE 12 +#define DEVICE_COUNT_RESOURCE 16 #define PCI_ANY_ID (~0) --- 2.4.8-ac8/drivers/pnp/Makefile.fix Thu Aug 23 10:08:57 2001 +++ 2.4.8-ac8/drivers/pnp/Makefile Fri Aug 24 11:47:27 2001 @@ -17,7 +17,7 @@ isa-pnp-objs := isapnp.o quirks.o $(proc-y) procpnp-$(CONFIG_PROC_FS) = pnp_proc.o -pnpbios-objs := pnp_bios.o $(procpnp-y) +pnpbios-objs := pnp_bios.o mboard.o $(procpnp-y) obj-$(CONFIG_ISAPNP) += isa-pnp.o obj-$(CONFIG_PNPBIOS) += pnpbios.o --- 2.4.8-ac8/drivers/pnp/pnp_bios.c.fix Thu Aug 23 10:08:57 2001 +++ 2.4.8-ac8/drivers/pnp/pnp_bios.c Fri Aug 24 11:39:21 2001 @@ -49,6 +49,7 @@ void pnp_proc_init(void); static void pnpbios_build_devlist(void); +int pnpbios_request_mboard(void); /* * This is the standard structure used to identify the entry point @@ -605,6 +606,7 @@ break; } pnpbios_build_devlist(); + pnpbios_request_mboard(); #ifdef CONFIG_PROC_FS pnp_proc_init(); #endif --- 2.4.8-ac8/drivers/pnp/mboard.c.fix Fri Aug 24 11:39:50 2001 +++ 2.4.8-ac8/drivers/pnp/mboard.c Fri Aug 24 11:38:38 2001 @@ -0,0 +1,73 @@ +/* + * request I/O ports which are used according to the PnP BIOS. + * + * (c) 2001 Gerd Knorr <kraxel@bytesex.org> + */ +#include <linux/config.h> +#include <linux/module.h> +#include <linux/init.h> + +#include <asm/io.h> +#include <asm/dma.h> +#include <asm/uaccess.h> + +#include <linux/pnp_bios.h> + +static int request_stuff(char *pnp, struct pci_dev *dev) +{ + struct resource *res; + int i,count = 0; + + printk(KERN_INFO "%s: request ports [%s]:",dev->name,pnp); + for (i = 0; i < DEVICE_COUNT_RESOURCE && + (dev->resource[i].start || dev->resource[i].end); i++) { + if (dev->resource[i].start > 0xffff || + dev->resource[i].end > 0xffff) { + /* + * these are memory ressources -- ignore them. + * The PnP BIOS reports the main memory layout + * this way. + */ + continue; + } + if (dev->resource[i].end < 0x100) { + /* + * below 0x100 is only standard PC hardware + * (pics, kbd, timer, dma, ...) + * + * We should not get ressource conflicts there, + * and the kernel reserves these anyway + * (see arch/i386/kernel/setup.c). + */ + continue; + } + /* + * anything else we'll reserve to avoid these ranges are + * assigned to someone (CardBus bridges for example) and + * thus are triggering resource conflicts. + */ + res = request_region(dev->resource[i].start, + dev->resource[i].end - dev->resource[i].start, + dev->name); + printk(" 0x%lx-0x%lx", + dev->resource[i].start, dev->resource[i].end); + count++; + } + printk("\n"); + if (i == DEVICE_COUNT_RESOURCE) + printk("%s: warning: >= %d resources, overflow?\n", + dev->name,DEVICE_COUNT_RESOURCE); + return count; +} + +int pnpbios_request_mboard(void) +{ + struct pci_dev *dev = NULL; + int count = 0; + + while ((dev=pnpbios_find_device("PNP0c01",dev))) + count += request_stuff("PNP0c01",dev); + while ((dev=pnpbios_find_device("PNP0c02",dev))) + count += request_stuff("PNP0c02",dev); + return count; +} ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2001-08-25 17:01 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <Pine.LNX.4.21.0107121802310.17665-100000@cobalt.deepthought.org>
2001-07-13 0:38 ` yenta_socket hangs sager laptop in kernel 2.4.6 Linus Torvalds
2001-07-17 20:15 ` Martin Murray
2001-07-17 21:33 ` Linus Torvalds
2001-07-17 21:35 ` Martin Murray
2001-07-21 13:35 ` kuznet
2001-07-21 15:47 ` Ben Greear
2001-08-20 14:17 ` Gerd Knorr
2001-08-20 22:52 ` Alexey Kuznetsov
2001-08-21 20:37 ` Gerd Knorr
2001-08-22 17:35 ` yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver Gunther Mayer
[not found] <no.id>
2001-08-22 18:18 ` Alan Cox
2001-08-22 18:32 ` Gunther Mayer
2001-08-23 9:11 ` Gerd Knorr
2001-08-23 12:50 ` Gerd Knorr
2001-08-23 13:00 ` Alan Cox
2001-08-23 16:58 ` kuznet
2001-08-23 18:23 ` Gunther Mayer
2001-08-23 18:34 ` kuznet
2001-08-25 10:27 ` Gunther Mayer
2001-08-25 17:00 ` kuznet
2001-08-24 10:18 ` Gerd Knorr
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®