Resulta que me he visto obligado a usar un kernel desactualizado y con algún fallo debido a que en la transición entre el 2.6.16-1-k7 y el 2.6.16-2-k7 se aplicó la revisión 2.6.16.17 que contenía un parche con el que dejaba de funcionar el modo USB 2.0 en mi portatil.
Mi lscpi:
# lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT8378 [KM400/A] Chipset Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8235 PCI Bridge
00:07.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 02)
00:08.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50)
00:11.6 Communication controller: VIA Technologies, Inc. AC'97 Modem Controller (rev 80)
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8378 [S3 UniChrome] Integrated Video (rev 01)
Al usar un disco duro externo usb para casi todo, no podía permitirme usar un kernel más nuevo que el 2.6.16-1-k7 que ya no está en los repositorios.
He estado buscando diferencias entre los parches que aplica debian a los kernel 2.6.16-1 y 2.6.16-2 y en el
Changelog encontré esto:
commit dc0f369552b491d1578e8a8c6f6512e17246241c
Author: Chris Wedgwood
Date: Mon May 15 09:43:55 2006 -0700
[PATCH] VIA quirk fixup, additional PCI IDs
An earlier commit (75cf7456dd87335f574dcd53c4ae616a2ad71a11) changed an
overly-zealous PCI quirk to only poke those VIA devices that need it.
However, some PCI devices were not included in what I hope is now the full
list. Consequently we're failing to run the quirk on all machines which need
it, causing IRQ routing failures.
This should I hope correct this.
Thanks to Masoud Sharbiani for pointing this out
and testing the fix.
Signed-off-by: Chris Wedgwood
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Chris Wright
El parche tiene esta pinta:
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index dda6099..381f36b 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -631,6 +631,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_V
* non-x86 architectures (yes Via exists on PPC among other places),
* we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
* interrupts delivered properly.
+ *
+ * Some of the on-chip devices are actually '586 devices' so they are
+ * listed here.
*/
static void quirk_via_irq(struct pci_dev *dev)
{
@@ -639,13 +642,19 @@ static void quirk_via_irq(struct pci_dev
new_irq = dev->irq & 0xf;
pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
if (new_irq != irq) {
- printk(KERN_INFO "PCI: Via IRQ fixup for %s, from %d to %dn",
+ printk(KERN_INFO "PCI: VIA IRQ fixup for %s, from %d to %dn",
pci_name(dev), irq, new_irq);
udelay(15); /* unknown if delay really needed */
pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
}
}
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
/*
* VIA VT82C598 has its device ID settable and many BIOSes
Así que he creado un "antiparche", he compilado el kernel 2.6.17 con la configuración del 2.6.17-2-k7 y voilá !!! el usb 2.0 vuelve a funcionar.
Mi antiparche:
--- drivers/pci/quirks.c 2006-08-23 12:35:02.000000000 +0200
+++ drivers/pci/quirks.c.orig 2006-08-23 12:34:51.000000000 +0200
@@ -652,6 +652,9 @@
}
}
+/* mariodebian unpatch 2.6.16.17 */
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
+/*
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq);
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq);
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq);
@@ -659,6 +662,7 @@
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
+*/
/*
Tan sencillo como comentar todos los defines y volver a poner el original.
Os presento a mi nuevo kernel:
# cat /proc/version
Linux version 2.6.17-3-k7 (2.6.17-7) (root@mariodebian)
(gcc versión 4.1.2 20060814 (prerelease) (Debian 4.1.1-11))
#1 SMP Wed Aug 23 11:07:58 CEST 2006
Como no me suelo cansar cuando me dan largas, he vuelto a enviar información al
bug #376652 de debian que en su día encontré con lo que pasaba.
Lo que más me fastidia es que si no se soluciona me veo compilando uno por uno todos los kernel que vayan saliendo para aplicar un parche de una mísera línea. Me alegra saber que por lo menos se donde está el fallo aunque no sepa que coño hace el parche.
