repeated kernel crashes with PCI passthru
Hi all, I have recently upgraded one of my Debian servers from XEN 3.2 / Kernel 2.6.26 to XEN 4.0 / Kernel 2.6.32. I have configured PCI passthru for a NIC. Since the current Debian pvops kernel does not have the xen pci frontend driver required for PCI passthru, I am running a XEN kernel in both dom0 and domU, so actual kernel versions are: dom0: 2.6.32-5-xen-amd64 #1 SMP Tue Jun 1 domU: 2.6.32-5-xen-686 #1 SMP Tue Jul 6 the hypervisor is 4.0.1-rc3 (Random notes: 1. the dom0 is 64bit, this domU is 32bit. 2. The dom0 kernel is not the latest (-16), but the one before (-15), because the current one won't boot up, see #588509 and #588426. ) * * * So, the system boots up as it should, but sometimes the domU crashes, with messages like these: - [27047.101954] BUG: unable to handle kernel paging request at 00d90200 [27047.101979] IP: [c11f01aa] skb_release_data+0x71/0x90 [27047.102000] *pdpt = 01c21027 *pde = [27047.102019] Thread overran stack, or stack corrupted [27047.102031] Oops: [#1] SMP [27047.102047] last sysfs file: /sys/devices/virtual/net/ppp0/uevent [27047.102060] Modules linked in: tun xt_limit nf_nat_irc nf_nat_ftp ipt_LOG ipt_MASQUERADE xt_DSCP ipt_REJECT nf_conntrack_irc nf_conntrack_ftp xt_state xt_TCPMSS xt_tcpmss xt_tcpudp pppoe pppox ppp_generic slhc sundance mii iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables x_tables dm_snapshot dm_mirror dm_region_hash dm_log dm_mod loop evdev snd_pcsp snd_pcm snd_timer snd xen_netfront soundcore snd_page_alloc ext3 jbd mbcache thermal_sys xen_blkfront [27047.102275] [27047.102285] Pid: 0, comm: swapper Not tainted (2.6.32-5-xen-686 #1) [27047.102298] EIP: 0061:[c11f01aa] EFLAGS: 00010206 CPU: 0 [27047.102310] EIP is at skb_release_data+0x71/0x90 [27047.102321] EAX: 00d90200 EBX: ECX: c2939c10 EDX: cec6b500 [27047.102333] ESI: cf8f0a80 EDI: cf8f09c0 EBP: c13919c8 ESP: c1383eec [27047.102346] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069 [27047.102358] Process swapper (pid: 0, ti=c1382000 task=c13c2ba0 task.ti=c13820 [27047.102371] Stack: [27047.102379] cf8f0a80 c293a700 c11efdfb cf8f09c0 c11f4c35 0011 c138 0002 [27047.102415] 0 0008 c13919c8 c103c1ec c14594b0 0001 000a 0100 [27047.102455] 0 c138 c13c5d18 c103c2c4 c1383f5c c103c39a [27047.102499] Call Trace: [27047.102512] [c11efdfb] ? __kfree_skb+0xf/0x6e [27047.102527] [c11f4c35] ? net_tx_action+0x58/0xf9 [27047.102542] [c103c1ec] ? __do_softirq+0xaa/0x151 [27047.102557] [c103c2c4] ? do_softirq+0x31/0x3c [27047.102570] [c103c39a] ? irq_exit+0x26/0x58 [27047.102586] [c1198a46] ? xen_evtchn_do_upcall+0x22/0x2c [27047.102604] [c1009b7f] ? xen_do_upcall+0x7/0xc [27047.102630] [c10023a7] ? hypercall_page+0x3a7/0x1001 [27047.102647] [c1006169] ? xen_safe_halt+0xf/0x1b [27047.102661] [c10042bf] ? xen_idle+0x23/0x30 [27047.102676] [c1008168] ? cpu_idle+0x89/0xa5 [27047.102691] [c13fb80d] ? start_kernel+0x318/0x31d [27047.102706] [c13fd3c3] ? xen_start_kernel+0x615/0x61c [27047.102721] [c1409045] ? print_local_APIC+0x61/0x380 [27047.102732] Code: 8b 44 02 30 e8 9a 4f ea ff 8b 96 a4 00 00 00 0f b7 42 04 39 c3 7c e5 8b 96 a4 00 00 00 8b 42 1c 85 c0 74 16 c7 42 1c 00 00 00 00 8b 18 e8 d2 fc ff ff 85 db 74 04 89 d8 eb f1 8b 86 a8 00 00 00 [27047.102981] EIP: [c11f01aa] skb_release_data+0x71/0x90 SS:ESP 0069:c1383eec [27047.103003] CR2: 00d90200 [27047.103018] ---[ end trace a577dfc0e629cd07 ]--- [27047.103028] Kernel panic - not syncing: Fatal exception in interrupt [27047.103042] Pid: 0, comm: swapper Tainted: G D2.6.32-5-xen-686 #1 [27047.103053] Call Trace: [27047.103065] [c128ae0d] ? panic+0x38/0xe4 [27047.103078] [c128d419] ? oops_end+0x91/0x9d [27047.103092] [c1021b5a] ? no_context+0x134/0x13d [27047.103106] [c1021c78] ? __bad_area_nosemaphore+0x115/0x11d [27047.103121] [c10067f0] ? check_events+0x8/0xc [27047.103135] [c10067e7] ? xen_restore_fl_direct_end+0x0/0x1 [27047.103155] [d0823fdb] ? xennet_poll+0xaeb/0xb04 [xen_netfront] [27047.103170] [c10211df] ? pvclock_clocksource_read+0xf9/0x10f [27047.103185] [c10060e8] ? xen_force_evtchn_callback+0xc/0x10 [27047.103200] [c114a00f] ? xen_swiotlb_unmap_page+0x0/0x7 [27047.103214] [c10067f0] ? check_events+0x8/0xc [27047.103227] [c10060e8] ? xen_force_evtchn_callback+0xc/0x10 [27047.103242] [c128e3f4] ? do_page_fault+0x115/0x307 [27047.103255] [c128e2df] ? do_page_fault+0x0/0x307 [27047.103268] [c1021c8a] ? bad_area_nosemaphore+0xa/0xc [27047.103282] [c128cb0b] ? error_code+0x73/0x78 [27047.103295] [c11f01aa] ? skb_release_data+0x71/0x90 [27047.103308] [c11efdfb] ? __kfree_skb+0xf/0x6e [27047.103321] [c11f4c35] ? net_tx_action+0x58/0xf9 [27047.103335] [c103c1ec] ? __do_softirq+0xaa/0x151 [27047.103348] [c103c2c4] ? do_softirq+0x31/0x3c [27047.103361] [c103c39a] ? irq_exit+0x26/0x58 [27047.103374]
reviving xen-3.2 for testing?
Hi there, Since the current XEN 3.4 and XEN 4.0 in debian lack HVM support, but the XEN 3.2 packages has it, I was wondering how much work would it require to revive the old 3.2 packages, so that they can be installed in current testing/unstable? (They were perfectly fine until a few weeks ago; only the recent python upgrade made them uninstallable. I have been using it until yesterday.) So, as far as I can tell, all they need is some re-packaging. (And maybe some small python fixes, but I'm sure you know that better than me.) Thank you for your help: Kristof -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c2ca1c6.5000...@gmail.com
xen kernel features
Hi all, I am trying to migrate my XEN 3.2 installation to XEN 4.0, on a 64-bit server. The dom0 kernel is 2.6.32-5-xen-amd64. I have run into a few problems: - The current xen-utils-4.0 does not support KVM guests, only PV. (This has nothing to with the kernel, though) - PCI passthru to PV guests does not work, because CONFIG_XEN_PCI_PASSTHROUGH is disabled in kernel config. - USB passthru via PVUSB does not seem to work, because the required PVUSB drivers are not available in the kernel. Could someone please advise me a solution to these problems? (Or at least give me some insight into the reasons why these don't work, when will they, and what am I supposed to do until then.) Thank you for your help: Kristof Csillag -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c2b93f3.2070...@gmail.com
Re: xen kernel features
At 2010-06-30 22:53, Ian Campbell wrote: On Wed, 2010-06-30 at 20:58 +0200, Csillag Kristof wrote: Hi all, I am trying to migrate my XEN 3.2 installation to XEN 4.0, on a 64-bit server. The dom0 kernel is 2.6.32-5-xen-amd64. I have run into a few problems: - The current xen-utils-4.0 does not support KVM guests, only PV. (This has nothing to with the kernel, though) (you mean HVM) Exactly. Please check the archives for pkg-xen-devel mailing list on alioth. Someone is working on packaging the necessary qemu-dm, I think there are packages available for testing too. I think that's Thomas Goirand, and the package is available here: http://ftparchive.gplhost.com/debian/pool/lenny/main/x/xen-qemu-dm-4.0/ However, I do not like fetching core packages from external sources, so I guess I will just have to wait until it's packages properly. - PCI passthru to PV guests does not work, because CONFIG_XEN_PCI_PASSTHROUGH is disabled in kernel config. I think this should be trivial to enable -- does any one on debian-kernel object to enabling it in trunk and sid branches? That would be great. Note that this functionality is only in the xen flavours and not the pvops based regular flavours (-amd64 and -686-bigmem). - USB passthru via PVUSB does not seem to work, because the required PVUSB drivers are not available in the kernel. I don't think the PVUSB front or backends have been ported to the PVops kernel yet, Indeed, they are not yet ready. most likely because nobody has asked for them. If you are interested I recommend raising it on the xen-devel mailing list, or better yet, sending patches to that list ;-). If I can get PCI passthru going, then this is not necessary. Thank you for your help: Kristof Csillag -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c2bb367.1050...@gmail.com
Re: Re: xen kernel features
It have no effect, so no: | $ grep XEN_PCI_PASSTHROUGH -r * | arch/x86/xen/Kconfig:config XEN_PCI_PASSTHROUGH Full quote looks like this: config XEN_PCI_PASSTHROUGH bool Enable support for Xen PCI passthrough devices depends on XEN PCI select PCI_XEN select SWIOTLB_XEN So it does seem to have some effect, in the right circumstances. (However, in this case, both options are already selected, so it really would not change much.) * * * What I do not understand is this: XEN_PCIDEV_BACKEND is enabled, but xen-pciback.ko is not built. Any idea what could cause this? Thank you: Kristof Csillag -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c2bd2e8.10...@gmail.com
Re: xen kernel features
2010-07-01 01:27 keltezéssel, Csillag Kristof írta: What I do not understand is this: XEN_PCIDEV_BACKEND is enabled, but xen-pciback.ko is not built. That's because it's compiled in, silly me. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c2be848.2000...@gmail.com
Re: [RESEND] 2.6.20/2.6.21
Hi there! On Mon, Apr 09, 2007 at 04:51:59PM +0200, Bastian Blank wrote: Hi folks I think we should upload 2.6.20 to unstable ASAP. It seems to work for most of us, except that the xen patch is not of that good quality. Could someone give me some details about what's wrong with XEN? I would like to use it, and I need 2.6.20 for some very new hardware. Where can I find more information about the problems mentioned above? Thank you for your help: Kristof
linux 2.6.20 with XEN
Hi there! I would like to ask whether someone has some information about when is kernel 2.6.20 with XEN support going to arrive in Debian? I need this to get my hardware working properly. (It has the latest intel graphics chipset, which requires the latest intel X server, which requires 2.6.20.) I know that most uploads to Unstable are withheld because of the Etch freeze, but something in Experimental, or even at something unofficial at http://kernel-archive.buildserver.net/debian-kernel would be fine. * * * AFAIK, the Debian Kernel Team usually fetches the XEN patches from the Fedora kernels. Unfortunately, the latest thing the Fedora guys have uploaded is 2.6.19 with XEN support, so no luck here. However, OpenSuse has already compiled a XEN-enabled 2.6.20 kernel. (GregKH uploaded it on on 09-03-2007.) Is it possible to extract the relavent patches from the OpenSuse version, and apply them to the Debian kernel? (I am not familiar with OpenSuse packaging policies and practices, so I am not apt to this job.) Does somebody know whether something like this is going to happen soon? Or is there some other roadmap for this? Thank you for the information: Kristof Csillag
Bug#321403: kernel 2.6.12.3 does not work either
2006-01-03, k keltezéssel 20.53-kor David Schmitt ezt írta: Tomorrow, 2.6.15 will be released to unstable, since 2.6.13 should have received ACPI updates it might be interesting to test this again. I have just tested it with 2.6.15-2. It still does not work. I have attached the dmesg outputs for normal kernel booting, for pci=routeirq and for acpi=off. * * * On Tue, 3 Jan 2006, Christian Aichinger [EMAIL PROTECTED] wrote: -- According to the kernel.org bugtracker this problem seems to be related to a broken DSDT table supplied by the BIOS, and there doesn't seem to be a simple generic way to work around this in the Linux kernel. -- Well, kernels up to 2.6.8 managed to parse it somehow. Would it be impossible to brink back the old behavior somehow? (Maybe enabled with a kernel param.) Kristof Csillag Linux version 2.6.15 (2.6.15-10.00.Custom) ([EMAIL PROTECTED]) (gcc version 4.0.3 20060104 (prerelease) (Debian 4.0.2-6)) #1 SMP PREEMPT Thu Jan 12 08:54:27 CET 2006 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1fff (usable) BIOS-e820: 1fff - 1fff3000 (ACPI NVS) BIOS-e820: 1fff3000 - 2000 (ACPI data) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: - 0001 (reserved) 511MB LOWMEM available. found SMP MP-table at 000f5f20 On node 0 totalpages: 131056 DMA zone: 4096 pages, LIFO batch:0 DMA32 zone: 0 pages, LIFO batch:0 Normal zone: 126960 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:0 DMI 2.2 present. ACPI: RSDP (v000 VIA694) @ 0x000f7850 ACPI: RSDT (v001 VIA694 AWRDACPI 0x42302e31 AWRD 0x) @ 0x1fff3000 ACPI: FADT (v001 VIA694 AWRDACPI 0x42302e31 AWRD 0x) @ 0x1fff3040 ACPI: MADT (v001 VIA694 0x 0x) @ 0x1fff5880 ACPI: DSDT (v001 VIA694 AWRDACPI 0x1000 MSFT 0x010c) @ 0x ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 17 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 6:8 APIC version 17 ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 17, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 dfl dfl) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 3000 (gap: 2000:dec0) Built 1 zonelists Kernel command line: root=/dev/hda5 ro video=matroxfb:vesa:0x1B8 mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 801.951 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 513828k/524224k available (2879k kernel code, 9868k reserved, 795k data, 244k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 1607.59 BogoMIPS (lpj=3215183) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0387fbff CPU: After vendor identify, caps: 0387fbff CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K CPU serial number disabled. CPU: After all inits, caps: 0383fbff 0040 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. mtrr: v2.0 (20020519) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. CPU0: Intel Pentium III (Coppermine) stepping 06 Booting processor 1/1 eip 2000 Initializing CPU#1 Calibrating delay using timer specific routine.. 1603.77 BogoMIPS (lpj=3207556) CPU: After generic identify, caps: 0387fbff CPU: After vendor identify, caps: 0387fbff CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K CPU serial number disabled. CPU: After all inits, caps: 0383fbff 0040 Intel machine check architecture supported. Intel machine check reporting enabled on
Bug#321403: 8139too network driver won't work with my card (it did with 2.6.8)
Hi, 2006-01-03, k keltezéssel 22.16-kor Christian Aichinger ezt írta: could you try out that bios workaround: http://www.ussg.iu.edu/hypermail/linux/kernel/0403.1/1537.html did you have time to test it? Did it work out? To quote a former letter of mine: Forwarded message -- From: Csillag Kristof [EMAIL PROTECTED] To: maximilian attems [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: Bug#321403: 8139too network driver won't work with my card (it did with 2.6.8) Date: Tue, 23 Aug 2005 18:19:34 +0200 2005-08-21, v keltezéssel 12.12-kor maximilian attems ezt írta: urrgs, but that seem to match upstream bugs thread. could you try out that bios workaround: http://www.ussg.iu.edu/hypermail/linux/kernel/0403.1/1537.html That won't work, since there is no such setting in my bios. Kristof - According to the kernel.org bugtracker this problem seems to be related to a broken DSDT table supplied by the BIOS, and there doesn't seem to be a simple generic way to work around this in the Linux kernel. But then why do older kernel versions (up to 2.6.8) work ok? So I'm closing this bug now, if the problem persists and you think there's a way for Linux to detect the broken BIOS and work around it, feel free to reopen the bug. I am sad to hear it, but since I don't have enough time to dig into this right now, I have no other option but to accept this, and keep going on using the box with ACPI=off. Best wishes: Kristof Csillag -- Csillag Kristof [EMAIL PROTECTED] SZTAKI/DSD
Bug#321403: 8139too network driver won't work with my card (it did with 2.6.8)
2005-08-12, p keltezéssel 10.50-kor Maximilian Attems ezt írta: could you test latest -rc6 from linus and followup there, if you still see the bug. With -rc7, the bug still exists: When booting with ACPI, the whole PCI subsystem (including fb, usb, sound, networking) is down, but with acpi=off, everything is fine. (Except ACPI stuff, off course.) Kristof signature.asc Description: This is a digitally signed message part
Bug#321403: 8139too network driver won't work with my card (it did with 2.6.8)
2005-08-21, v keltezéssel 12.12-kor maximilian attems ezt írta: With 2.6.13-rc6, my whole PCI system seems to be broken. (No sound, no usb, lspci finds no devices at all.) With ACPI=off, the PCI devices (including the 8139too) work OK. urrgs, but that seem to match upstream bugs thread. could you try out that bios workaround: http://www.ussg.iu.edu/hypermail/linux/kernel/0403.1/1537.html That won't work, since there is no such setting in my bios. Kristof signature.asc Description: This is a digitally signed message part
Bug#321403: 8139too network driver won't work with my card (it did with 2.6.8)
2005-08-21, v keltezéssel 12.12-kor maximilian attems ezt írta: urrgs, but that seem to match upstream bugs thread. I don't know whether I should be happy about this.. could you try out that bios workaround: http://www.ussg.iu.edu/hypermail/linux/kernel/0403.1/1537.html I can test it on tuesday. (I don't have physical access to the machine right now.) your lspci -v would be nice for the record. Attached. Kristof :00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4) Flags: bus master, medium devsel, latency 0 Memory at d000 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 :00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: d600-d8ff Prefetchable memory behind bridge: d400-d5ff Capabilities: [80] Power Management version 2 :00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge Flags: bus master, stepping, medium devsel, latency 0 :00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at 9000 [size=16] Capabilities: [c0] Power Management version 2 :00:07.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 10) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller Flags: bus master, medium devsel, latency 32, IRQ 5 I/O ports at 9400 [size=32] Capabilities: [80] Power Management version 2 :00:07.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 10) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller Flags: bus master, medium devsel, latency 32, IRQ 5 I/O ports at 9800 [size=32] Capabilities: [80] Power Management version 2 :00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Flags: medium devsel, IRQ 9 Capabilities: [68] Power Management version 2 :00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 20) Subsystem: VIA Technologies, Inc. VT82C686 AC97 Audio Controller Flags: medium devsel, IRQ 11 I/O ports at 9c00 [size=256] I/O ports at a000 [size=4] I/O ports at a400 [size=4] Capabilities: [c0] Power Management version 2 :00:0c.0 Unknown mass storage controller: Promise Technology, Inc. PDC20265 (FastTrak100 Lite/Ultra100) (rev 02) Subsystem: Promise Technology, Inc. Ultra100 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at ac00 [size=8] I/O ports at b000 [size=4] I/O ports at b400 [size=8] I/O ports at b800 [size=4] I/O ports at bc00 [size=64] Memory at da00 (32-bit, non-prefetchable) [size=128K] Capabilities: [58] Power Management version 1 :00:0e.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RT8139 Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at c000 [size=256] Memory at da02 (32-bit, non-prefetchable) [size=256] :01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 82) (prog-if 00 [VGA]) Subsystem: Matrox Graphics, Inc. Millennium G450 Dual Head LE Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at d400 (32-bit, prefetchable) [size=32M] Memory at d600 (32-bit, non-prefetchable) [size=16K] Memory at d700 (32-bit, non-prefetchable) [size=8M] Capabilities: [dc] Power Management version 2 Capabilities: [f0] AGP version 2.0
Bug#321403: 8139too network driver won't work with my card (it did with 2.6.8)
2005-08-12, p keltezéssel 10.50-kor Maximilian Attems ezt írta: reassign 321403 linux-2.6 thanks this seems to be a known upstream bug: http://bugzilla.kernel.org/show_bug.cgi?id=4773 unfortunately i don't see a resolution yet. could you test latest -rc6 from linus and followup there, if you still see the bug. if not we would be happy to know too. thanks for your feedback. With 2.6.13-rc6, my whole PCI system seems to be broken. (No sound, no usb, lspci finds no devices at all.) With ACPI=off, the PCI devices (including the 8139too) work OK. I have just found out that the 2.6.11 kernel works ok With ACPI=off, too. (I have not rested 2.6.9, 2.6.10, 2.6.12.) * * * Here is my dmesg from 2.6.13-rc6, with and without acpi. Kristof ps. Sorry for the delay Linux version 2.6.13-rc6 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #2 SMP Tue Aug 16 15:25:29 CEST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1fff (usable) BIOS-e820: 1fff - 1fff3000 (ACPI NVS) BIOS-e820: 1fff3000 - 2000 (ACPI data) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: - 0001 (reserved) 511MB LOWMEM available. found SMP MP-table at 000f5f20 On node 0 totalpages: 131056 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 126960 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 DMI 2.2 present. Intel MultiProcessor Specification v1.1 Virtual Wire compatibility mode. OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 Processor #0 6:8 APIC version 17 Processor #1 6:8 APIC version 17 I/O APIC #2 Version 17 at 0xFEC0. Enabling APIC mode: Flat. Using 1 I/O APICs Processors: 2 Allocating PCI resources starting at 2000 (gap: 2000:dec0) Built 1 zonelists Kernel command line: root=/dev/hda5 ro acpi=off mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 801.966 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 514256k/524224k available (2701k kernel code, 9420k reserved, 1051k data, 232k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 1607.56 BogoMIPS (lpj=3215129) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0387fbff CPU: After vendor identify, caps: 0387fbff CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K CPU serial number disabled. CPU: After all inits, caps: 0383fbff 0040 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. mtrr: v2.0 (20020519) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. CPU0: Intel Pentium III (Coppermine) stepping 06 Booting processor 1/1 eip 2000 Initializing CPU#1 Calibrating delay using timer specific routine.. 1603.77 BogoMIPS (lpj=3207559) CPU: After generic identify, caps: 0387fbff CPU: After vendor identify, caps: 0387fbff CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K CPU serial number disabled. CPU: After all inits, caps: 0383fbff 0040 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#1. CPU1: Intel Pentium III (Coppermine) stepping 06 Total of 2 processors activated (3211.34 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 pin1=2 pin2=0 checking TSC synchronization across 2 CPUs: passed. Brought up 2 CPUs NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfb2d0, last bus=1 PCI: Using configuration type 1 mtrr: your CPUs had inconsistent variable MTRR settings mtrr: probably your BIOS does not setup all CPUs. mtrr: corrected configuration. ACPI: Subsystem revision 20050408 ACPI: Interpreter disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI: disabled SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) Boot video device is :01:00.0 PCI: Using IRQ router VIA [1106/0686] at :00:07.0 PCI: Bridge: :00:01.0 IO window: disabled. MEM
Bug#321403: 8139too network driver won't work with my card (it did with 2.6.8)
Package: kernel-source-2.6.11 Version: 2.6.11-7 Severity: important Hi there! When I tried to upgrade my kernel from 2.6.8 to 2.6.11, I was shocked to see that my Ethernet card stopped working. I am using the standard Debian kernel sources to build my own kernels. I tested kernel-source-2.6.10, and (because kernel-source-2.6.9 is no longer in Debian) the vanilla linux-2.6.9 from kernel.org, and neither of them worked. So it seems the thing broke from 2.6.8 to 2.6.9. * * * My card is: (lspci output on 2.6.8) :00:0e.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) The 2.6.8 kernel says this, then loading the driver: 8139too Fast Ethernet driver 0.9.27 eth0: RealTek RTL8139 at 0xe281c000, 00:20:18:8d:3d:40, IRQ 10 eth0: Identified 8139 chip type 'RTL-8139B' With, 2.6.11, at first it seems to be OK, too: eth0: RealTek RTL8139 at 0xe2a38000, 00:20:18:8d:3d:40, IRQ 10 eth0: Identified 8139 chip type 'RTL-8139B' eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 ...but when I try to send out data, it says: NETDEV WATCHDOG: eth0: transmit timed out eth0: Transmit timeout, status 0c 0005 c07f media 00. eth0: Tx queue start entry 4 dirty entry 0. eth0: Tx descriptor 0 is 0008a156. (queue head) eth0: Tx descriptor 1 is 0008a156. eth0: Tx descriptor 2 is 0008a156. eth0: Tx descriptor 3 is 0008a156. eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 * * * Since until this is resolved, I am stucked to 2.6.8, I am very eager to help you debugging this. Please tell me how can I help you to fix this. Kristof Csillag -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8 Locale: LANG=hu_HU, LC_CTYPE=hu_HU (charmap=ISO-8859-2) Versions of packages kernel-source-2.6.11 depends on: (irrelevant) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321403: kernel 2.6.12.3 does not work either
Hi there! I tested with the vanilla 2.6.12.3, and it does not work either. The relevant output of kernel is this: eth0: RealTek RTL8139 at 0xe0802000, 00:20:18:8d:3d:40, IRQ 10 eth0: Identified 8139 chip type 'RTL-8139B' ... eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 NETDEV WATCHDOG: eth0: transmit timed out eth0: Transmit timeout, status 0c 0005 c07f media 00. eth0: Tx queue start entry 4 dirty entry 0. eth0: Tx descriptor 0 is 0008a156. (queue head) eth0: Tx descriptor 1 is 0008a156. eth0: Tx descriptor 2 is 0008a156. eth0: Tx descriptor 3 is 0008a156. eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 Kristof signature.asc Description: Ez az üzenetrész digitális aláírással van ellátva
