Re: [ALSA PATCH] 1.0.9b+
On 29.07.2005, at 09:39, Jaroslav Kysela wrote: Note that most of lines are from new Sparc and ARM drivers. Other changes are mostly small bugfixes, cleanups and new hardware ID additions. The all changes goes through all ALSA developers (our CVS server sends us whole diffs back), so all of them review/verify new code and can fix it ASAP. It works quite well. FWIW the current ALSA patch against 2.6.12 works much better than the original version for my Asus W3V with Intel HDA ALC880 in the sense that there's a possibility to prevent crashing the kernel when loading the module. However apart from the ID fixes this involves disabling the autodetection code and hardcoding the correct type in the realtek code. As it stands the code seems to be really buggy and I'd love to test the driver after someone wiser than me in this area reviewed and fixed the code. Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [ALSA PATCH] 1.0.9b+
On 29.07.2005, at 09:39, Jaroslav Kysela wrote: Note that most of lines are from new Sparc and ARM drivers. Other changes are mostly small bugfixes, cleanups and new hardware ID additions. The all changes goes through all ALSA developers (our CVS server sends us whole diffs back), so all of them review/verify new code and can fix it ASAP. It works quite well. FWIW the current ALSA patch against 2.6.12 works much better than the original version for my Asus W3V with Intel HDA ALC880 in the sense that there's a possibility to prevent crashing the kernel when loading the module. However apart from the ID fixes this involves disabling the autodetection code and hardcoding the correct type in the realtek code. As it stands the code seems to be really buggy and I'd love to test the driver after someone wiser than me in this area reviewed and fixed the code. Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode
On 14.04.2005, at 19:25, Ross Biro wrote: Just to be clear, we can have two users A and B with the exact same hardware. A setting of =y will screw user A and a setting of =n will screw user B. Ideally, they would both get better hardware, but that is not always an option. You tell me a better[1] 32bit GigE PCI adapter than Intel E1000 and I sure do this. It's pretty interesting to see that those who buy some not-so-cheeep hardware are being screwed in this case; it should be in Intels best interest to help fix this issue ASAP and permantently for all users. [1] better performance at less CPU utilization + good diagnostics and negotiation capabilities Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode
On 14.04.2005, at 19:25, Ross Biro wrote: Just to be clear, we can have two users A and B with the exact same hardware. A setting of =y will screw user A and a setting of =n will screw user B. Ideally, they would both get better hardware, but that is not always an option. You tell me a better[1] 32bit GigE PCI adapter than Intel E1000 and I sure do this. It's pretty interesting to see that those who buy some not-so-cheeep hardware are being screwed in this case; it should be in Intels best interest to help fix this issue ASAP and permantently for all users. [1] better performance at less CPU utilization + good diagnostics and negotiation capabilities Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode
On 05.04.2005, at 21:33, Ross Biro wrote: The problem with always setting the bit is that some PCI hardware, notably some Intel E-1000 chips (Ethernet controller: Intel Corporation: Unknown device 1076) cannot properly handle the target abort bit. In the case of the E-1000 chip, the driver must reset the chip to recover. This usually leads to the machine being off the network for several seconds, or sometimes even minutes, which can be bad for servers. This sounds *exactly* like my problem since I swapped motherboards. I'll see whether there's some option in the BIOS that fixes it and if not bite the bullet and compile a generic kernel Thanks a lot for investigating this. Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode
On 05.04.2005, at 21:33, Ross Biro wrote: The problem with always setting the bit is that some PCI hardware, notably some Intel E-1000 chips (Ethernet controller: Intel Corporation: Unknown device 1076) cannot properly handle the target abort bit. In the case of the E-1000 chip, the driver must reset the chip to recover. This usually leads to the machine being off the network for several seconds, or sometimes even minutes, which can be bad for servers. This sounds *exactly* like my problem since I swapped motherboards. I'll see whether there's some option in the BIOS that fixes it and if not bite the bullet and compile a generic kernel Thanks a lot for investigating this. Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: PCI interrupt problem: e1000 & Super-Micro X6DVA motherboard
On 24.03.2005, at 03:03, Ben Greear wrote: When trying to send/receive traffic, I get TX watchdog timeouts. The other interfaces seem to work just fine. No idea whether my problem is related but due to a broken motherboard I had to switch from a SiS based Athlon board (ECS K7S5A) to a new one which is VIA based: :00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge (rev 80) :00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge :00:09.0 VGA compatible controller: Cirrus Logic GD 5446 :00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) :00:0b.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller :00:0d.0 FireWire (IEEE 1394): NEC Corporation uPD72874 IEEE1394 OHCI 1.1 3-port PHY-Link Ctrlr (rev 01) :00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) :00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) :00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) :00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [K8T800 South] :00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) :00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78) Strange enough the beforehand very reliable Intel Pro/1000 MT controller would also see watchdog errors in an otherwise unchanged environment (same kernel, cards, CPU, etc.). I tried different kernels 2.6.8-2.6.10, but no change; I tried without ACPI information for IRQ routing -- nope. I tried swapping PCI slots -- negative, sir. As a temporary counter measure (this box is not only a ethernet bridge between 100Mbit and 1000Mbit switched networks but also the primary fileserver for my netboot TFTP/NFS environment, so dropouts are especially nasty since it takes some time until the NFS machines on the Gbit network will resume operation) I popped in the chp RealTek card (which caused some slight problems like permanent hangs and bad performance before) and everything works like a charm. Of course, after throwing in some extra money to get at least somewhat professional equipment, I'd like to use it, too. This is the (strange?) ethtool output: Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised auto-negotiation: Yes Speed: Unknown! (65535) Duplex: Unknown! (255) Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: umbg Wake-on: g Current message level: 0x0007 (7) Link detected: no The card is still in the system and running, so if someone wants me to run to more tests or diagnostic, please be my guest. Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: PCI interrupt problem: e1000 Super-Micro X6DVA motherboard
On 24.03.2005, at 03:03, Ben Greear wrote: When trying to send/receive traffic, I get TX watchdog timeouts. The other interfaces seem to work just fine. No idea whether my problem is related but due to a broken motherboard I had to switch from a SiS based Athlon board (ECS K7S5A) to a new one which is VIA based: :00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge (rev 80) :00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge :00:09.0 VGA compatible controller: Cirrus Logic GD 5446 :00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) :00:0b.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller :00:0d.0 FireWire (IEEE 1394): NEC Corporation uPD72874 IEEE1394 OHCI 1.1 3-port PHY-Link Ctrlr (rev 01) :00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) :00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) :00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) :00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [K8T800 South] :00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) :00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78) Strange enough the beforehand very reliable Intel Pro/1000 MT controller would also see watchdog errors in an otherwise unchanged environment (same kernel, cards, CPU, etc.). I tried different kernels 2.6.8-2.6.10, but no change; I tried without ACPI information for IRQ routing -- nope. I tried swapping PCI slots -- negative, sir. As a temporary counter measure (this box is not only a ethernet bridge between 100Mbit and 1000Mbit switched networks but also the primary fileserver for my netboot TFTP/NFS environment, so dropouts are especially nasty since it takes some time until the NFS machines on the Gbit network will resume operation) I popped in the chp RealTek card (which caused some slight problems like permanent hangs and bad performance before) and everything works like a charm. Of course, after throwing in some extra money to get at least somewhat professional equipment, I'd like to use it, too. This is the (strange?) ethtool output: Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised auto-negotiation: Yes Speed: Unknown! (65535) Duplex: Unknown! (255) Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: umbg Wake-on: g Current message level: 0x0007 (7) Link detected: no The card is still in the system and running, so if someone wants me to run to more tests or diagnostic, please be my guest. Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [PATCH] Reading deterministic cache parameters and exporting it in /sysfs
On 16.03.2005, at 00:36, Dave Jones wrote: I really want to live to see the death of /proc/cpuinfo one day, Please don't. cpuinfo contains a vast amount of useful information for a quick inspection which cannot be determined usefully from userspace (think embedded devices) for very little code. Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [PATCH] Reading deterministic cache parameters and exporting it in /sysfs
On 16.03.2005, at 00:36, Dave Jones wrote: I really want to live to see the death of /proc/cpuinfo one day, Please don't. cpuinfo contains a vast amount of useful information for a quick inspection which cannot be determined usefully from userspace (think embedded devices) for very little code. Servus, Daniel PGP.sig Description: This is a digitally signed message part
