RE: IDE disk and HPA
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of >Etienne Lorrain >Sent: Thursday, August 04, 2005 5:11 AM >To: linux-kernel@vger.kernel.org >Subject: Re: IDE disk and HPA > >> > > My question is now: why is an HPA disabled i.e. disprotected when >> > > detected? Why not let the HPA alone, because a certain >set of disk >> > > sectors shall not be accessible by the OS? >> > >> > Because the HPA is most commonly used to hide all but a >fraction of a >> > disk to work with older BIOSes. >> >> But as to my knowledge, the HPA was had been introduced to allow HW >> vendors to store things like diagnostic programs in a part of the >> disk protected from partitioning and filesystems. >> The point is, IF there is an HPA, there MIGHT be a partitioning >> scheme and some filesystems on the disk which rely on the size of >> disk being the native size MINUS the HPA. > > If those HW vendors want to store software in the HPA of the IDE > hard disk, and they employ people able to read the IDE specifications, > they know that this HPA can be protected by password and so Linux > just display a failure when trying to restore the capacity of the > Hard Disk - because it lacks the unlocking password. Yep, you are right. When used by BIOS/firmware, it is usually protected by password. And interesting enough, as in this particular case, they employ people to not only read them, but to write them as well ;) However, if not protected by the password, it is probably Ok to make it visible (as things currently are). > > Note that this HPA is a good place to store a bootloader too, in fact > I like to think of it as the big floppy drive of the PC which no more > have any floppy drive: create a FAT filesystem of 64 Mbytes there and > copy all the floppy you used to have there. Your bootloader, if it > is good enough, will be able to run software from this area. If your bootloader if the first thing to run in the system, you can use & protect portion of your hardrive for yourself - just make sure you lock with set max with password when passing control to 'normal' OS/loader. Aleks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: IDE disk and HPA
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Etienne Lorrain Sent: Thursday, August 04, 2005 5:11 AM To: linux-kernel@vger.kernel.org Subject: Re: IDE disk and HPA My question is now: why is an HPA disabled i.e. disprotected when detected? Why not let the HPA alone, because a certain set of disk sectors shall not be accessible by the OS? Because the HPA is most commonly used to hide all but a fraction of a disk to work with older BIOSes. But as to my knowledge, the HPA was had been introduced to allow HW vendors to store things like diagnostic programs in a part of the disk protected from partitioning and filesystems. The point is, IF there is an HPA, there MIGHT be a partitioning scheme and some filesystems on the disk which rely on the size of disk being the native size MINUS the HPA. If those HW vendors want to store software in the HPA of the IDE hard disk, and they employ people able to read the IDE specifications, they know that this HPA can be protected by password and so Linux just display a failure when trying to restore the capacity of the Hard Disk - because it lacks the unlocking password. Yep, you are right. When used by BIOS/firmware, it is usually protected by password. And interesting enough, as in this particular case, they employ people to not only read them, but to write them as well ;) However, if not protected by the password, it is probably Ok to make it visible (as things currently are). Note that this HPA is a good place to store a bootloader too, in fact I like to think of it as the big floppy drive of the PC which no more have any floppy drive: create a FAT filesystem of 64 Mbytes there and copy all the floppy you used to have there. Your bootloader, if it is good enough, will be able to run software from this area. If your bootloader if the first thing to run in the system, you can use protect portion of your hardrive for yourself - just make sure you lock with set max with password when passing control to 'normal' OS/loader. Aleks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [linux-usb-devel] Re: 2.6.13-rc4-mm1
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of
>[EMAIL PROTECTED]
>Sent: Sunday, July 31, 2005 7:02 PM
>To: [EMAIL PROTECTED]
>Cc: linux-usb-devel@lists.sourceforge.net;
>linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject: Re: [linux-usb-devel] Re: 2.6.13-rc4-mm1
>
>> Date: Sun, 31 Jul 2005 16:02:44 -0700
>> From: Greg KH <[EMAIL PROTECTED]>
>>
>> On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
>> > I think that "continuing" codepath came from someone at
>Phoenix, FWIW;
That was me.
>> > the problem is that I see the PCI quirks code has evolved
>even farther
>> > from the main copy of the init code in the USB tree. Sigh.
>>
>> I don't like that either, but can't think of a way to make
>it easier to
>> keep them in sync. Can you?
Major problem here is that handoff may be necessary even if whole
USB support is disabled in config. I was thinking of integrating them
into
USB code somehow, but did not have enough time for it, sorry :(
>
>Sure. The problem as I see it is that there are two copies, and one
>of them isn't in the USB part of the tree. So just move it, and cope
>with the consequences during the 2.6.14 cycle:
>
> (a) Move the USB quirks out of the generic PCI drivers directory
> into the USB HCD directory (see the attached patch);
>
> (b) foreach HCD in (ehci ohci uhci) do:
>
> (1) Merge the two different routines: HCD internal init/reset
> and the PCI quirk code are identical in intent, but they
> each address different sets of quirks.
>
> (2) Then the HCD reset() and PCI quirk() code will call those
> single shared routine.
>
Agree, but at least:
- drivers/Makefile & drivers/usb/Makefile have to be modified as well
to include
quirks on CONFIG_PCI
- Constants like EHCI_USBCMD_RUN should probably be replaced with
'native' usb code ones.
Thanks,
Aleks.
>
>At OLS, Vojtech mentioned wanting to make "usb-handoff" be the default.
>That's seem plausible (USB has more than its fair share of
>BIOS issues!)
>but should only kick in sometime after we merge the two different sets
>of quirk handling logic.
>
>- Dave
>
>
>
>This moves the PCI quirk handling for USB host controllers from the
>PCI directory to the USB directory.
>
>Follow-on patches will need to remove code duplication, and probably
>make "usb-handoff" be the system default.
>
>Compile-tested only so far.
>
>Signed-off-by: David Brownell <[EMAIL PROTECTED]>
>
>--- g26.orig/drivers/usb/host/Makefile 2005-06-28
>19:23:13.0 -0700
>+++ g26/drivers/usb/host/Makefile 2005-07-31
>18:41:35.0 -0700
>@@ -1,8 +1,9 @@
> #
>-# Makefile for USB Host Controller Driver
>-# framework and drivers
>+# Makefile for USB Host Controller Drivers
> #
>
>+obj-$(CONFIG_PCI) += pci-quirks.o
>+
> obj-$(CONFIG_USB_EHCI_HCD)+= ehci-hcd.o
> obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
> obj-$(CONFIG_USB_OHCI_HCD)+= ohci-hcd.o
>--- /dev/null 1970-01-01 00:00:00.0 +
>+++ g26/drivers/usb/host/pci-quirks.c 2005-07-31
>17:33:38.0 -0700
>@@ -0,0 +1,279 @@
>+/*
>+ * This file contains work-arounds for many known PCI
>hardware and BIOS
>+ * quirks relating to USB host controllers.
>+ *
>+ * There are a lot of those, especially on hardware that needs to work
>+ * with USB mice and keyboard for booting. And this code
>needs to fire
>+ * early; before the input subsystem gets initialized, and while BIOS
>+ * (or SMI) code has few problems running.
>+ *
>+ * They're collected here since USB host controller drivers
>need to use
>+ * the same code as part of hardware initialization.
>+ *
>+ * Copyright (c) 1999 Martin Mares <[EMAIL PROTECTED]>
>+ * (and others)
>+ */
>+
>+#include
>+#include
>+#include
>+#include
>+#include
>+#include
>+#include
>+
>+// #include "pci.h"
>+
>+/*
>+ * PIIX3 USB: We have to disable USB interrupts that are
>+ * hardwired to PIRQD# and may be shared with an
>+ * external device.
>+ *
>+ * Legacy Support Register (LEGSUP):
>+ * bit13: USB PIRQ Enable (USBPIRQDEN),
>+ * bit4: Trap/SMI On IRQ Enable (USBSMIEN).
>+ *
>+ * We mask out all r/wc bits, too.
>+ */
>+static void __devinit quirk_piix3_usb(struct pci_dev *dev)
>+{
>+ u16 legsup;
>+
>+ pci_read_config_word(dev, 0xc0, );
>+ legsup &= 0x50ef;
>+ pci_write_config_word(dev, 0xc0, legsup);
>+}
>+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,
>PCI_DEVICE_ID_INTEL_82371SB_2, quirk_piix3_usb );
>+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,
>PCI_DEVICE_ID_INTEL_82371AB_2, quirk_piix3_usb );
>+
>+
>+/* FIXME this should be the same code that the USB controllers use...
>+ * the hcd->reset() method basically does this.
>+ */
>+
>+#define UHCI_USBLEGSUP0xc0/*
>legacy support */
>+#define UHCI_USBCMD 0 /* command register */
>+#define UHCI_USBSTS 2 /* status register */
RE: 2.6.13-rc4-mm1
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Michael Thonke >Sent: Sunday, July 31, 2005 8:12 AM >To: Andrew Morton >Cc: linux-kernel@vger.kernel.org >Subject: Re: 2.6.13-rc4-mm1 > >Hello Andrew, > >the ACPI bug or the problems with 2.6.13-rc3-mm[2,3] gone. >The system boots now noiseless, except on problem with USB. > >If my Prolific USB-Serialadapter plugged in on reboot >the ehci_hcd driver complains about a Hand-off bug in Bios. > >-> snip > >ehci_hcd :00:1d.7: EHCI Host Controller > >ehci_hcd :00:1d.7: debug port 1 > >ehci_hcd :00:1d.7: BIOS handoff failed (104, 01010001) > >ehci_hcd :00:1d.7: continuing after BIOS bug... > >ehci_hcd :00:1d.7: new USB bus registered, assigned bus number 1 > >ehci_hcd :00:1d.7: irq 161, io mem 0xd2dffc00 > >-> snip > > >I wonder about this because all other USB devices working without this >message on boot. > >USB Mouse,Keyboard and USB Storage and all mixed from USB 1.1 and 2. > >When I rebooted without plugged Prolific Adapter and plug them in the >same port >the kernel prints this message. > >->snip > >usb 4-1: new full speed USB device using uhci_hcd and address 2 > >pl2303 4-1:1.0: PL-2303 converter detected > >usb 4-1: PL-2303 converter now attached to ttyUSB0 > >-> snip > > >Any Ideas what could be wrong here? > Could you try 'usb-handoff' as a kernel parameter. Is it any better ? Aleks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.13-rc4-mm1
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Thonke Sent: Sunday, July 31, 2005 8:12 AM To: Andrew Morton Cc: linux-kernel@vger.kernel.org Subject: Re: 2.6.13-rc4-mm1 Hello Andrew, the ACPI bug or the problems with 2.6.13-rc3-mm[2,3] gone. The system boots now noiseless, except on problem with USB. If my Prolific USB-Serialadapter plugged in on reboot the ehci_hcd driver complains about a Hand-off bug in Bios. - snip ehci_hcd :00:1d.7: EHCI Host Controller ehci_hcd :00:1d.7: debug port 1 ehci_hcd :00:1d.7: BIOS handoff failed (104, 01010001) ehci_hcd :00:1d.7: continuing after BIOS bug... ehci_hcd :00:1d.7: new USB bus registered, assigned bus number 1 ehci_hcd :00:1d.7: irq 161, io mem 0xd2dffc00 - snip I wonder about this because all other USB devices working without this message on boot. USB Mouse,Keyboard and USB Storage and all mixed from USB 1.1 and 2. When I rebooted without plugged Prolific Adapter and plug them in the same port the kernel prints this message. -snip usb 4-1: new full speed USB device using uhci_hcd and address 2 pl2303 4-1:1.0: PL-2303 converter detected usb 4-1: PL-2303 converter now attached to ttyUSB0 - snip Any Ideas what could be wrong here? Could you try 'usb-handoff' as a kernel parameter. Is it any better ? Aleks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [linux-usb-devel] Re: 2.6.13-rc4-mm1
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, July 31, 2005 7:02 PM
To: [EMAIL PROTECTED]
Cc: linux-usb-devel@lists.sourceforge.net;
linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [linux-usb-devel] Re: 2.6.13-rc4-mm1
Date: Sun, 31 Jul 2005 16:02:44 -0700
From: Greg KH [EMAIL PROTECTED]
On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
I think that continuing codepath came from someone at
Phoenix, FWIW;
That was me.
the problem is that I see the PCI quirks code has evolved
even farther
from the main copy of the init code in the USB tree. Sigh.
I don't like that either, but can't think of a way to make
it easier to
keep them in sync. Can you?
Major problem here is that handoff may be necessary even if whole
USB support is disabled in config. I was thinking of integrating them
into
USB code somehow, but did not have enough time for it, sorry :(
Sure. The problem as I see it is that there are two copies, and one
of them isn't in the USB part of the tree. So just move it, and cope
with the consequences during the 2.6.14 cycle:
(a) Move the USB quirks out of the generic PCI drivers directory
into the USB HCD directory (see the attached patch);
(b) foreach HCD in (ehci ohci uhci) do:
(1) Merge the two different routines: HCD internal init/reset
and the PCI quirk code are identical in intent, but they
each address different sets of quirks.
(2) Then the HCD reset() and PCI quirk() code will call those
single shared routine.
Agree, but at least:
- drivers/Makefile drivers/usb/Makefile have to be modified as well
to include
quirks on CONFIG_PCI
- Constants like EHCI_USBCMD_RUN should probably be replaced with
'native' usb code ones.
Thanks,
Aleks.
At OLS, Vojtech mentioned wanting to make usb-handoff be the default.
That's seem plausible (USB has more than its fair share of
BIOS issues!)
but should only kick in sometime after we merge the two different sets
of quirk handling logic.
- Dave
This moves the PCI quirk handling for USB host controllers from the
PCI directory to the USB directory.
Follow-on patches will need to remove code duplication, and probably
make usb-handoff be the system default.
Compile-tested only so far.
Signed-off-by: David Brownell [EMAIL PROTECTED]
--- g26.orig/drivers/usb/host/Makefile 2005-06-28
19:23:13.0 -0700
+++ g26/drivers/usb/host/Makefile 2005-07-31
18:41:35.0 -0700
@@ -1,8 +1,9 @@
#
-# Makefile for USB Host Controller Driver
-# framework and drivers
+# Makefile for USB Host Controller Drivers
#
+obj-$(CONFIG_PCI) += pci-quirks.o
+
obj-$(CONFIG_USB_EHCI_HCD)+= ehci-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
obj-$(CONFIG_USB_OHCI_HCD)+= ohci-hcd.o
--- /dev/null 1970-01-01 00:00:00.0 +
+++ g26/drivers/usb/host/pci-quirks.c 2005-07-31
17:33:38.0 -0700
@@ -0,0 +1,279 @@
+/*
+ * This file contains work-arounds for many known PCI
hardware and BIOS
+ * quirks relating to USB host controllers.
+ *
+ * There are a lot of those, especially on hardware that needs to work
+ * with USB mice and keyboard for booting. And this code
needs to fire
+ * early; before the input subsystem gets initialized, and while BIOS
+ * (or SMI) code has few problems running.
+ *
+ * They're collected here since USB host controller drivers
need to use
+ * the same code as part of hardware initialization.
+ *
+ * Copyright (c) 1999 Martin Mares [EMAIL PROTECTED]
+ * (and others)
+ */
+
+#include linux/config.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/pci.h
+#include linux/init.h
+#include linux/delay.h
+#include linux/acpi.h
+
+// #include pci.h
+
+/*
+ * PIIX3 USB: We have to disable USB interrupts that are
+ * hardwired to PIRQD# and may be shared with an
+ * external device.
+ *
+ * Legacy Support Register (LEGSUP):
+ * bit13: USB PIRQ Enable (USBPIRQDEN),
+ * bit4: Trap/SMI On IRQ Enable (USBSMIEN).
+ *
+ * We mask out all r/wc bits, too.
+ */
+static void __devinit quirk_piix3_usb(struct pci_dev *dev)
+{
+ u16 legsup;
+
+ pci_read_config_word(dev, 0xc0, legsup);
+ legsup = 0x50ef;
+ pci_write_config_word(dev, 0xc0, legsup);
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_82371SB_2, quirk_piix3_usb );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_82371AB_2, quirk_piix3_usb );
+
+
+/* FIXME this should be the same code that the USB controllers use...
+ * the hcd-reset() method basically does this.
+ */
+
+#define UHCI_USBLEGSUP0xc0/*
legacy support */
+#define UHCI_USBCMD 0 /* command register */
+#define UHCI_USBSTS 2 /* status register */
+#define UHCI_USBINTR 4 /* interrupt register */
+#define
[PATCH 2.4] Fix incorrect Asus k7m irq router detection
Hi Marcello,
Here is 2.4 version of a patch submitted earlier for 2.6 by Giancarlo
Formicuccia.
this patch:
http://marc.theaimsgroup.com/?l=bk-commits-head=111955644929114=2
uncovered a k7m bios bug, where the VT82C686A router is reported as
being "586-compatible". The two chips have different pirq mapping, so
this leads to "irq routing conflict" on many pci devices.
Patch for 2.4.32-pre2
Signed-off-by: Aleksey Gorelov <[EMAIL PROTECTED]>
--- linux-2.4.31-old/arch/i386/kernel/pci-irq.c 2005-07-29
14:44:12.0 -0700
+++ linux-2.4.31/arch/i386/kernel/pci-irq.c 2005-07-29
14:47:44.0 -0700
@@ -664,6 +664,13 @@
static __init int via_router_probe(struct irq_router *r, struct pci_dev
*router, u16 device)
{
/* FIXME: We should move some of the quirk fixup stuff here */
+
+ if (router->device == PCI_DEVICE_ID_VIA_82C686 &&
+ device == PCI_DEVICE_ID_VIA_82C586_0) {
+ /* Asus k7m bios wrongly reports 82C686A as
586-compatible */
+ device = PCI_DEVICE_ID_VIA_82C686;
+ }
+
switch(device)
{
case PCI_DEVICE_ID_VIA_82C586_0:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.4] Fix incorrect Asus k7m irq router detection
Hi Marcello,
Here is 2.4 version of a patch submitted earlier for 2.6 by Giancarlo
Formicuccia.
this patch:
http://marc.theaimsgroup.com/?l=bk-commits-headm=111955644929114w=2
uncovered a k7m bios bug, where the VT82C686A router is reported as
being 586-compatible. The two chips have different pirq mapping, so
this leads to irq routing conflict on many pci devices.
Patch for 2.4.32-pre2
Signed-off-by: Aleksey Gorelov [EMAIL PROTECTED]
--- linux-2.4.31-old/arch/i386/kernel/pci-irq.c 2005-07-29
14:44:12.0 -0700
+++ linux-2.4.31/arch/i386/kernel/pci-irq.c 2005-07-29
14:47:44.0 -0700
@@ -664,6 +664,13 @@
static __init int via_router_probe(struct irq_router *r, struct pci_dev
*router, u16 device)
{
/* FIXME: We should move some of the quirk fixup stuff here */
+
+ if (router-device == PCI_DEVICE_ID_VIA_82C686
+ device == PCI_DEVICE_ID_VIA_82C586_0) {
+ /* Asus k7m bios wrongly reports 82C686A as
586-compatible */
+ device = PCI_DEVICE_ID_VIA_82C686;
+ }
+
switch(device)
{
case PCI_DEVICE_ID_VIA_82C586_0:
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [2.6.13-rc3-git4] VIA686A polymorphs into VIA586!
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of
>Giancarlo Formicuccia
>Sent: Tuesday, July 26, 2005 2:09 PM
>To: Aleksey Gorelov
>Cc: linux-kernel@vger.kernel.org
>Subject: Re: [2.6.13-rc3-git4] VIA686A polymorphs into VIA586!
>
>Does this patch look good for you?
>Who's the right developer to ask for inclusion? I'd like to
>see this problem addressed before 2.6.13...
Yep, this is better. Please add appropriate patch description &
Signed-off-by and resend it to Greg and Andrew.
Aleks.
>
>Thanks,
>Giancarlo
>
>
>--- linux-2.6.13-git4/arch/i386/pci/irq.c.org 2005-07-23
>11:15:12.0 +0200
>+++ linux-2.6.13-git4/arch/i386/pci/irq.c 2005-07-26
>20:53:11.0 +0200
>@@ -550,6 +550,13 @@
> static __init int via_router_probe(struct irq_router *r,
>struct pci_dev *router, u16 device)
> {
> /* FIXME: We should move some of the quirk fixup stuff here */
>+
>+ if (router->device == PCI_DEVICE_ID_VIA_82C686 &&
>+ device == PCI_DEVICE_ID_VIA_82C586_0) {
>+ /* Asus k7m bios wrongly reports 82C686A as
>586-compatible */
>+ device = PCI_DEVICE_ID_VIA_82C686;
>+ }
>+
> switch(device)
> {
> case PCI_DEVICE_ID_VIA_82C586_0:
>-
>To unsubscribe from this list: send the line "unsubscribe
>linux-kernel" in
>the body of a message to [EMAIL PROTECTED]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [2.6.13-rc3-git4] VIA686A polymorphs into VIA586!
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Giancarlo Formicuccia
Sent: Tuesday, July 26, 2005 2:09 PM
To: Aleksey Gorelov
Cc: linux-kernel@vger.kernel.org
Subject: Re: [2.6.13-rc3-git4] VIA686A polymorphs into VIA586!
Does this patch look good for you?
Who's the right developer to ask for inclusion? I'd like to
see this problem addressed before 2.6.13...
Yep, this is better. Please add appropriate patch description
Signed-off-by and resend it to Greg and Andrew.
Aleks.
Thanks,
Giancarlo
--- linux-2.6.13-git4/arch/i386/pci/irq.c.org 2005-07-23
11:15:12.0 +0200
+++ linux-2.6.13-git4/arch/i386/pci/irq.c 2005-07-26
20:53:11.0 +0200
@@ -550,6 +550,13 @@
static __init int via_router_probe(struct irq_router *r,
struct pci_dev *router, u16 device)
{
/* FIXME: We should move some of the quirk fixup stuff here */
+
+ if (router-device == PCI_DEVICE_ID_VIA_82C686
+ device == PCI_DEVICE_ID_VIA_82C586_0) {
+ /* Asus k7m bios wrongly reports 82C686A as
586-compatible */
+ device = PCI_DEVICE_ID_VIA_82C686;
+ }
+
switch(device)
{
case PCI_DEVICE_ID_VIA_82C586_0:
-
To unsubscribe from this list: send the line unsubscribe
linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [2.6.13-rc3-git4] VIA686A polymorphs into VIA586!
>-Original Message-
>From: Giancarlo Formicuccia [mailto:[EMAIL PROTECTED]
>Sent: Saturday, July 23, 2005 3:20 AM
>To: linux-kernel@vger.kernel.org
>Cc: Aleksey Gorelov
>Subject: [2.6.13-rc3-git4] VIA686A polymorphs into VIA586!
>
>[Please CC me in any reply]
>
>Hi *,
>
>I'm getting many "irq routing conflict" with kernel 2.6.13-rc3-git4.
>I have a quite old k7m with a VIA vt82c686a south
>bridge; no apic, no acpi.
>
>After some digging, I found the culprit in this - apparently
>unrelated - patch:
>
>http://marc.theaimsgroup.com/?l=bk-commits-head=111955644929114=2
>
>On my system, the function via_router_probe is called
>with device==0x586 (PCI_DEVICE_ID_VIA_82C586_0).
>
>Then, I looked at these lines in function pirq_find_router:
>
> for( h = pirq_routers; h->vendor; h++) {
> /* First look for a router match */
> if (rt->rtr_vendor == h->vendor && h->probe(r,
>pirq_router_dev, rt->rtr_device))
> break;
> /* Fall back to a device match */
> if (pirq_router_dev->vendor == h->vendor &&
>h->probe(r, pirq_router_dev, pirq_router_dev->device))
> break;
> }
>
>Here, rt->rtr_device==0x586 and pirq_router_dev->device==0x686!
>There is _no_ device 0x586 on my board:
>
>00:00.0 Class 0600: 1022:7006 (rev 25)
>00:01.0 Class 0604: 1022:7007 (rev 01)
>00:04.0 Class 0601: 1106:0686 (rev 1b) <<<
>00:04.1 Class 0101: 1106:0571 (rev 06)
>00:04.2 Class 0c03: 1106:3038 (rev 0e)
>00:04.3 Class 0c03: 1106:3038 (rev 0e)
>00:04.4 Class 0c05: 1106:3057 (rev 20)
>00:04.5 Class 0401: 1106:3058 (rev 21)
>00:0f.0 Class 0200: 10ec:8029
>00:10.0 Class 0400: 109e:036e (rev 02)
>00:10.1 Class 0480: 109e:0878 (rev 02)
>01:05.0 Class 0300: 121a:0005 (rev 01)
Be irq routing table definition, rtr_vendor:rtr_device should contain
COMPATIBLE pci Interrupt Router, and rtr_bus & rtr_devfn - location of
the actual device (pirq_router_dev). So,
1. Apparently, there is a bug in the BIOS - 586 & 686 are not compatible
(different mapping)
2. Does anybody know why compatible device is probed first, and actual
one afterwards ? In other words, is swapping probes in the code above
would give more correct behavior ?
>
>
>This patch brings my board back to the correct behaviour
>[Aleksey Gorelov CC'd for review/comments/suggestions]:
>
>--- linux-2.6.13-git4/arch/i386/pci/irq.c.org 2005-07-23
>11:15:12.0 +0200
>+++ linux-2.6.13-git4/arch/i386/pci/irq.c 2005-07-23
>11:55:50.0 +0200
>@@ -553,10 +553,12 @@
> switch(device)
> {
> case PCI_DEVICE_ID_VIA_82C586_0:
>- r->name = "VIA";
>- r->get = pirq_via586_get;
>- r->set = pirq_via586_set;
>- return 1;
>+ if
>(router->device==PCI_DEVICE_ID_VIA_82C586_0) {
>+ r->name = "VIA";
>+ r->get = pirq_via586_get;
>+ r->set = pirq_via586_set;
>+ return 1;
>+ }
> case PCI_DEVICE_ID_VIA_82C596:
> case PCI_DEVICE_ID_VIA_82C686:
> case PCI_DEVICE_ID_VIA_8231:
>
Probably, comments on buggy BIOS would be nice here..
Aleks.
>
>Can someone explain me what's going on and maybe cook a better fix?
>
>Thanks,
>
>Giancarlo
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Stripping in module
Well, the best you can do is strip -R .note -R .comment --strip-unneeded. If you go for more, module might not be loaded/initialized properlly Aleks. >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Budde, Marco >Sent: Sunday, July 24, 2005 11:24 PM >To: linux-kernel@vger.kernel.org >Subject: Stripping in module > >Hi, > >at the moment I am packaging a Linux module as an RPM archive. > >Therefor I would like to remove some of the not exported/needed >symbols (like e.g. static functions or constants) from the >Linux module. > >What is the best way to do this with v2.6. > >I have tried e.g. to remove all symbols starting with "telos" >from the module like this (after kbuild): > > strip -w -K '!telos*' -K 'telosi2c_usb_driver' telosi2c_linux.ko > >When I try to load such a module, insmod dies with a segmentation >fault or the complete kernel dies (with "invalid operand: "). >What is the reason for this problem? > >What is the correct way using kbuild to remove some symbols? > >cu, Marco > >- >To unsubscribe from this list: send the line "unsubscribe >linux-kernel" in >the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Stripping in module
Well, the best you can do is strip -R .note -R .comment --strip-unneeded. If you go for more, module might not be loaded/initialized properlly Aleks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Budde, Marco Sent: Sunday, July 24, 2005 11:24 PM To: linux-kernel@vger.kernel.org Subject: Stripping in module Hi, at the moment I am packaging a Linux module as an RPM archive. Therefor I would like to remove some of the not exported/needed symbols (like e.g. static functions or constants) from the Linux module. What is the best way to do this with v2.6. I have tried e.g. to remove all symbols starting with telos from the module like this (after kbuild): strip -w -K '!telos*' -K 'telosi2c_usb_driver' telosi2c_linux.ko When I try to load such a module, insmod dies with a segmentation fault or the complete kernel dies (with invalid operand: ). What is the reason for this problem? What is the correct way using kbuild to remove some symbols? cu, Marco - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [2.6.13-rc3-git4] VIA686A polymorphs into VIA586!
-Original Message-
From: Giancarlo Formicuccia [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 23, 2005 3:20 AM
To: linux-kernel@vger.kernel.org
Cc: Aleksey Gorelov
Subject: [2.6.13-rc3-git4] VIA686A polymorphs into VIA586!
[Please CC me in any reply]
Hi *,
I'm getting many irq routing conflict with kernel 2.6.13-rc3-git4.
I have a quite old k7m with a VIA vt82c686a south
bridge; no apic, no acpi.
After some digging, I found the culprit in this - apparently
unrelated - patch:
http://marc.theaimsgroup.com/?l=bk-commits-headm=111955644929114w=2
On my system, the function via_router_probe is called
with device==0x586 (PCI_DEVICE_ID_VIA_82C586_0).
Then, I looked at these lines in function pirq_find_router:
for( h = pirq_routers; h-vendor; h++) {
/* First look for a router match */
if (rt-rtr_vendor == h-vendor h-probe(r,
pirq_router_dev, rt-rtr_device))
break;
/* Fall back to a device match */
if (pirq_router_dev-vendor == h-vendor
h-probe(r, pirq_router_dev, pirq_router_dev-device))
break;
}
Here, rt-rtr_device==0x586 and pirq_router_dev-device==0x686!
There is _no_ device 0x586 on my board:
00:00.0 Class 0600: 1022:7006 (rev 25)
00:01.0 Class 0604: 1022:7007 (rev 01)
00:04.0 Class 0601: 1106:0686 (rev 1b)
00:04.1 Class 0101: 1106:0571 (rev 06)
00:04.2 Class 0c03: 1106:3038 (rev 0e)
00:04.3 Class 0c03: 1106:3038 (rev 0e)
00:04.4 Class 0c05: 1106:3057 (rev 20)
00:04.5 Class 0401: 1106:3058 (rev 21)
00:0f.0 Class 0200: 10ec:8029
00:10.0 Class 0400: 109e:036e (rev 02)
00:10.1 Class 0480: 109e:0878 (rev 02)
01:05.0 Class 0300: 121a:0005 (rev 01)
Be irq routing table definition, rtr_vendor:rtr_device should contain
COMPATIBLE pci Interrupt Router, and rtr_bus rtr_devfn - location of
the actual device (pirq_router_dev). So,
1. Apparently, there is a bug in the BIOS - 586 686 are not compatible
(different mapping)
2. Does anybody know why compatible device is probed first, and actual
one afterwards ? In other words, is swapping probes in the code above
would give more correct behavior ?
This patch brings my board back to the correct behaviour
[Aleksey Gorelov CC'd for review/comments/suggestions]:
--- linux-2.6.13-git4/arch/i386/pci/irq.c.org 2005-07-23
11:15:12.0 +0200
+++ linux-2.6.13-git4/arch/i386/pci/irq.c 2005-07-23
11:55:50.0 +0200
@@ -553,10 +553,12 @@
switch(device)
{
case PCI_DEVICE_ID_VIA_82C586_0:
- r-name = VIA;
- r-get = pirq_via586_get;
- r-set = pirq_via586_set;
- return 1;
+ if
(router-device==PCI_DEVICE_ID_VIA_82C586_0) {
+ r-name = VIA;
+ r-get = pirq_via586_get;
+ r-set = pirq_via586_set;
+ return 1;
+ }
case PCI_DEVICE_ID_VIA_82C596:
case PCI_DEVICE_ID_VIA_82C686:
case PCI_DEVICE_ID_VIA_8231:
Probably, comments on buggy BIOS would be nice here..
Aleks.
Can someone explain me what's going on and maybe cook a better fix?
Thanks,
Giancarlo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Kernel page table and module text
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Allison >Sent: Sunday, April 17, 2005 11:21 PM >To: linux-kernel@vger.kernel.org >Subject: Kernel page table and module text > >Hi, > >Since module is loaded in non-contiguous memory, there has to be an >entry in the kernel page table for all modules that are loaded on the >system. I am trying to find entries corresponding to my module text in >the page tables. > >I am not clear about how the kernel page table is organized after the >system switches to protected mode. > >I printed out the page starting with swapper_pg_dir . But I do not >find the addresses for all the modules loaded in the system. > >Do I still need to read the pg0 and pg1 pages ? > >If somebody can explain how to traverse the kernel page tables, that >would be very helpful. > >thanks, >Allison >- >To unsubscribe from this list: send the line "unsubscribe >linux-kernel" in >the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > You can find some details here: http://www.csn.ul.ie/~mel/projects/vm/guide/pdf/understand.pdf But whatever your purpose is, I doubt you would want to use PTEs. Aleks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Kernel page table and module text
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Allison Sent: Sunday, April 17, 2005 11:21 PM To: linux-kernel@vger.kernel.org Subject: Kernel page table and module text Hi, Since module is loaded in non-contiguous memory, there has to be an entry in the kernel page table for all modules that are loaded on the system. I am trying to find entries corresponding to my module text in the page tables. I am not clear about how the kernel page table is organized after the system switches to protected mode. I printed out the page starting with swapper_pg_dir . But I do not find the addresses for all the modules loaded in the system. Do I still need to read the pg0 and pg1 pages ? If somebody can explain how to traverse the kernel page tables, that would be very helpful. thanks, Allison - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ You can find some details here: http://www.csn.ul.ie/~mel/projects/vm/guide/pdf/understand.pdf But whatever your purpose is, I doubt you would want to use PTEs. Aleks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: mmap() and ioctl()
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Matthew Dharm >Sent: Monday, April 04, 2005 12:20 PM >To: Richard B. Johnson >Cc: Kernel Developer List >Subject: Re: mmap() and ioctl() > [snip] >That's an interesting concept, and one I'm not familiar with. >Any useful >pointers (beyond UTSL)? I'll admit to being much more >familiar with SCSI >and USB internals than I am with something like device-layer >interfacing. Try this: http://lwn.net/Kernel/LDD3/ Aleks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: mmap() and ioctl()
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Dharm Sent: Monday, April 04, 2005 12:20 PM To: Richard B. Johnson Cc: Kernel Developer List Subject: Re: mmap() and ioctl() [snip] That's an interesting concept, and one I'm not familiar with. Any useful pointers (beyond UTSL)? I'll admit to being much more familiar with SCSI and USB internals than I am with something like device-layer interfacing. Try this: http://lwn.net/Kernel/LDD3/ Aleks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: mmap/munmap on linux-2.6.11
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of linux-os >Sent: Friday, March 25, 2005 1:19 PM >To: Linux kernel >Subject: mmap/munmap on linux-2.6.11 > >Memory gurus, > >We have an application where a driver allocates DMA-able memory. >This DMA-able memory is mmap()ed to user-space. To conserve >DMA memory only single pages are obtained using > __get_dma_pages(GFP_KERNEL, 1) (one page at a time). These >pages, that may be scattered all about, are mmap()ed into contiguous >user data-space. The DMA engine uses a scatter-list so we can >write DMA pages anywhere. They don't have to be contiguous. > >Here's a catch. It would be nice to release those DMA pages >when we don't need them. However, there doesn't appear to >be any way for driver code to know when munmap() has been >called and those DMA pages are available to be released. > >How do I know that munmap() has been called? It turns out >that if I release those pages before unmapping the user-mode, >the system will crash. Therefore this could be a DOS attack >if my driver ever allowed the DMA pages to be released. munmap() should do the job for you and release those automatically. Aleks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: mmap/munmap on linux-2.6.11
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of linux-os Sent: Friday, March 25, 2005 1:19 PM To: Linux kernel Subject: mmap/munmap on linux-2.6.11 Memory gurus, We have an application where a driver allocates DMA-able memory. This DMA-able memory is mmap()ed to user-space. To conserve DMA memory only single pages are obtained using __get_dma_pages(GFP_KERNEL, 1) (one page at a time). These pages, that may be scattered all about, are mmap()ed into contiguous user data-space. The DMA engine uses a scatter-list so we can write DMA pages anywhere. They don't have to be contiguous. Here's a catch. It would be nice to release those DMA pages when we don't need them. However, there doesn't appear to be any way for driver code to know when munmap() has been called and those DMA pages are available to be released. How do I know that munmap() has been called? It turns out that if I release those pages before unmapping the user-mode, the system will crash. Therefore this could be a DOS attack if my driver ever allowed the DMA pages to be released. munmap() should do the job for you and release those automatically. Aleks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Kernel modules query
Hi >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of linux lover >Sent: Friday, February 18, 2005 1:36 AM >To: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org >Subject: Kernel modules query > >Hello, >I want to know can a variable be exported by a linux kernel >modules? How can i make a variable getting assigned in kernel module >available to other kernel modules? >regards, >linux.lover. EXPORT_SYMBOL(var_name); For example see arch/i386/kernel/time.c & jiffies_64 (2.6.10 source). Aleks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Kernel modules query
Hi -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of linux lover Sent: Friday, February 18, 2005 1:36 AM To: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org Subject: Kernel modules query Hello, I want to know can a variable be exported by a linux kernel modules? How can i make a variable getting assigned in kernel module available to other kernel modules? regards, linux.lover. EXPORT_SYMBOL(var_name); For example see arch/i386/kernel/time.c jiffies_64 (2.6.10 source). Aleks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: BIOS Bug
>>>-Original Message- >>>From: [EMAIL PROTECTED] >>>[mailto:[EMAIL PROTECTED] On Behalf Of >Enrico Bartky >>>Sent: Monday, February 07, 2005 7:12 AM >>>To: linux-kernel@vger.kernel.org >>>Subject: BIOS Bug >>> >>>Hello, >>> >>>on my notebook, when I plugged in my USB keyboard the kernel >>>doesnt boot correctly, ... >>> >>>... >>>BIOS hangoff failed ( 112, 1010001 ) >>>continuing after BIOS bug >>>irq 192, pci mem 0xfebff000 >>>new usb device registered, assigned bus number 1 >>>... >>> >>>then the notebook hangs. If I boot without the plugged >>>keyboard and plug in when the kernel is ready, there are no >>>problems. I have a SiS USB chipset. >>> >>>Can you help me? >>> >>> >> >>What kernel version are you using ? >>Try 2.6.10 with the following command line parameter: >>usb-handoff >> >>Aleks. >> >> >Thanx, it works! Can you say me, it is really a BIOS Bug, a >buggy ACPI >or a driver problem? It depends. But I believe in your case it is just too late for hand off in USB driver. Try search for usb handoff in this list. Aleks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: BIOS Bug
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Enrico Bartky Sent: Monday, February 07, 2005 7:12 AM To: linux-kernel@vger.kernel.org Subject: BIOS Bug Hello, on my notebook, when I plugged in my USB keyboard the kernel doesnt boot correctly, ... ... BIOS hangoff failed ( 112, 1010001 ) continuing after BIOS bug irq 192, pci mem 0xfebff000 new usb device registered, assigned bus number 1 ... then the notebook hangs. If I boot without the plugged keyboard and plug in when the kernel is ready, there are no problems. I have a SiS USB chipset. Can you help me? What kernel version are you using ? Try 2.6.10 with the following command line parameter: usb-handoff Aleks. Thanx, it works! Can you say me, it is really a BIOS Bug, a buggy ACPI or a driver problem? It depends. But I believe in your case it is just too late for hand off in USB driver. Try search for usb handoff in this list. Aleks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: BIOS Bug
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Enrico Bartky >Sent: Monday, February 07, 2005 7:12 AM >To: linux-kernel@vger.kernel.org >Subject: BIOS Bug > >Hello, > >on my notebook, when I plugged in my USB keyboard the kernel >doesnt boot correctly, ... > >... >BIOS hangoff failed ( 112, 1010001 ) >continuing after BIOS bug >irq 192, pci mem 0xfebff000 >new usb device registered, assigned bus number 1 >... > >then the notebook hangs. If I boot without the plugged >keyboard and plug in when the kernel is ready, there are no >problems. I have a SiS USB chipset. > >Can you help me? What kernel version are you using ? Try 2.6.10 with the following command line parameter: usb-handoff Aleks. > >Thanx, EnricoB >__ >Verschicken Sie romantische, coole und witzige Bilder per SMS! >Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 > >- >To unsubscribe from this list: send the line "unsubscribe >linux-kernel" in >the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: BIOS Bug
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Enrico Bartky Sent: Monday, February 07, 2005 7:12 AM To: linux-kernel@vger.kernel.org Subject: BIOS Bug Hello, on my notebook, when I plugged in my USB keyboard the kernel doesnt boot correctly, ... ... BIOS hangoff failed ( 112, 1010001 ) continuing after BIOS bug irq 192, pci mem 0xfebff000 new usb device registered, assigned bus number 1 ... then the notebook hangs. If I boot without the plugged keyboard and plug in when the kernel is ready, there are no problems. I have a SiS USB chipset. Can you help me? What kernel version are you using ? Try 2.6.10 with the following command line parameter: usb-handoff Aleks. Thanx, EnricoB __ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[no subject]
Hi Matt, Alan, Could you please tell me (link would do) why it makes default delay_use=5 really necessary (from the patch below)? https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-August/00074 7.html It makes USB boot really painfull and slow :( I understand there should be a good reason for it. I've tried to find an answer in archives, without much success though. Thanks, Aleks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux hangs during IDE initialization at boot for 30 sec
>-Original Message- >From: Michael Brade [mailto:[EMAIL PROTECTED] >Sent: Wednesday, February 02, 2005 11:55 AM >To: Aleksey Gorelov >Subject: Re: Linux hangs during IDE initialization at boot for 30 sec > >Hi, > >> Since you don't care about anything except ide0 & ide1, try to add >> the following to the kernel's command line: >> ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe >Awesome! Thanks, booting is finally acceptably fast again :-) >Just strange >that it worked for the last 3 years (in fact, 7 years) with >just about every >kernel version that's out there... but I'm happy with the workaround. > Was it exact same hardware ? >Cheers, >-- >Michael Brade; KDE Developer, Student of >Computer Science > |-mail: echo brade !#|tr -d "c oh"|s\e\d >'s/e/\@/2;s/$/.org/;s/bra/k/2' > °--web: http://www.kde.org/people/michaelb.html > >KDE 3: The Next Generation in Desktop Experience > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux hangs during IDE initialization at boot for 30 sec
Hi, >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Michael Brade >Sent: Tuesday, February 01, 2005 3:58 AM >To: linux-kernel@vger.kernel.org >Subject: Linux hangs during IDE initialization at boot for 30 sec > [snip] > >I found additional lines in the log just before the line above: > >Probing IDE interface ide2... >Probing IDE interface ide3... >Probing IDE interface ide4... >Probing IDE interface ide5... > >But I only have ide0 and ide1. This problem persists even with >2.6.11-rc2. For >the last test I removed every option from the kernel that is >not needed, but >the problem stays. So I'm sure it's not because of ACPI or PNP >or the like. > >With 2.6.11-rc2 I get in my syslog: > >Feb 1 11:30:02 newton kernel: ICH3M: chipset revision 2 >Feb 1 11:30:02 newton kernel: ICH3M: not 100%% native mode: >will probe irqs >later >Feb 1 11:30:02 newton kernel: ide0: BM-DMA at 0xcfa0-0xcfa7, BIOS >settings: hda:DMA, hdb:pio >Feb 1 11:30:02 newton kernel: ide1: BM-DMA at 0xcfa8-0xcfaf, BIOS >settings: hdc:DMA, hdd:pio >Feb 1 11:30:02 newton kernel: Probing IDE interface ide0... >Feb 1 11:30:02 newton kernel: hda: HITACHI_DK23DA-30, ATA DISK drive >Feb 1 11:30:02 newton kernel: DEV: registering device: ID = 'ide0' >Feb 1 11:30:02 newton kernel: PM: Adding info for No Bus:ide0 >Feb 1 11:30:02 newton kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 >Feb 1 11:30:02 newton kernel: DEV: registering device: ID = '0.0' >Feb 1 11:30:02 newton kernel: PM: Adding info for ide:0.0 >Feb 1 11:30:02 newton kernel: bus ide: add device 0.0 >Feb 1 11:30:02 newton kernel: Probing IDE interface ide1... >Feb 1 11:30:02 newton kernel: hdc: TOSHIBA DVD-ROM SD-R2212, >ATAPI CD/DVD-ROM >drive >Feb 1 11:30:02 newton kernel: DEV: registering device: ID = 'ide1' >Feb 1 11:30:02 newton kernel: PM: Adding info for No Bus:ide1 >Feb 1 11:30:02 newton kernel: ide1 at 0x170-0x177,0x376 on irq 15 >Feb 1 11:30:02 newton kernel: DEV: registering device: ID = '1.0' >Feb 1 11:30:02 newton kernel: PM: Adding info for ide:1.0 >Feb 1 11:30:02 newton kernel: bus ide: add device 1.0 >Feb 1 11:30:02 newton kernel: bus pci: add driver PIIX_IDE >Feb 1 11:30:02 newton kernel: bound device ':00:1f.1' to driver >'PIIX_IDE' >Feb 1 11:30:02 newton kernel: bus pci: add driver PCI_IDE >Feb 1 11:30:02 newton kernel: Probing IDE interface ide2... >Feb 1 11:30:02 newton kernel: Probing IDE interface ide3... >Feb 1 11:30:02 newton kernel: Probing IDE interface ide4... >Feb 1 11:30:02 newton kernel: ide4: Wait for ready failed >before probe ! >---> I guess the line above is the reason for the wait <--- >Feb 1 11:30:02 newton kernel: Probing IDE interface ide5... >Feb 1 11:30:02 newton kernel: hda: max request size: 128KiB > Since you don't care about anything except ide0 & ide1, try to add the following to the kernel's command line: ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe Aleks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux hangs during IDE initialization at boot for 30 sec
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Brade Sent: Tuesday, February 01, 2005 3:58 AM To: linux-kernel@vger.kernel.org Subject: Linux hangs during IDE initialization at boot for 30 sec [snip] I found additional lines in the log just before the line above: Probing IDE interface ide2... Probing IDE interface ide3... Probing IDE interface ide4... Probing IDE interface ide5... But I only have ide0 and ide1. This problem persists even with 2.6.11-rc2. For the last test I removed every option from the kernel that is not needed, but the problem stays. So I'm sure it's not because of ACPI or PNP or the like. With 2.6.11-rc2 I get in my syslog: Feb 1 11:30:02 newton kernel: ICH3M: chipset revision 2 Feb 1 11:30:02 newton kernel: ICH3M: not 100%% native mode: will probe irqs later Feb 1 11:30:02 newton kernel: ide0: BM-DMA at 0xcfa0-0xcfa7, BIOS settings: hda:DMA, hdb:pio Feb 1 11:30:02 newton kernel: ide1: BM-DMA at 0xcfa8-0xcfaf, BIOS settings: hdc:DMA, hdd:pio Feb 1 11:30:02 newton kernel: Probing IDE interface ide0... Feb 1 11:30:02 newton kernel: hda: HITACHI_DK23DA-30, ATA DISK drive Feb 1 11:30:02 newton kernel: DEV: registering device: ID = 'ide0' Feb 1 11:30:02 newton kernel: PM: Adding info for No Bus:ide0 Feb 1 11:30:02 newton kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Feb 1 11:30:02 newton kernel: DEV: registering device: ID = '0.0' Feb 1 11:30:02 newton kernel: PM: Adding info for ide:0.0 Feb 1 11:30:02 newton kernel: bus ide: add device 0.0 Feb 1 11:30:02 newton kernel: Probing IDE interface ide1... Feb 1 11:30:02 newton kernel: hdc: TOSHIBA DVD-ROM SD-R2212, ATAPI CD/DVD-ROM drive Feb 1 11:30:02 newton kernel: DEV: registering device: ID = 'ide1' Feb 1 11:30:02 newton kernel: PM: Adding info for No Bus:ide1 Feb 1 11:30:02 newton kernel: ide1 at 0x170-0x177,0x376 on irq 15 Feb 1 11:30:02 newton kernel: DEV: registering device: ID = '1.0' Feb 1 11:30:02 newton kernel: PM: Adding info for ide:1.0 Feb 1 11:30:02 newton kernel: bus ide: add device 1.0 Feb 1 11:30:02 newton kernel: bus pci: add driver PIIX_IDE Feb 1 11:30:02 newton kernel: bound device ':00:1f.1' to driver 'PIIX_IDE' Feb 1 11:30:02 newton kernel: bus pci: add driver PCI_IDE Feb 1 11:30:02 newton kernel: Probing IDE interface ide2... Feb 1 11:30:02 newton kernel: Probing IDE interface ide3... Feb 1 11:30:02 newton kernel: Probing IDE interface ide4... Feb 1 11:30:02 newton kernel: ide4: Wait for ready failed before probe ! --- I guess the line above is the reason for the wait --- Feb 1 11:30:02 newton kernel: Probing IDE interface ide5... Feb 1 11:30:02 newton kernel: hda: max request size: 128KiB Since you don't care about anything except ide0 ide1, try to add the following to the kernel's command line: ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe Aleks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux hangs during IDE initialization at boot for 30 sec
-Original Message- From: Michael Brade [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 11:55 AM To: Aleksey Gorelov Subject: Re: Linux hangs during IDE initialization at boot for 30 sec Hi, Since you don't care about anything except ide0 ide1, try to add the following to the kernel's command line: ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe Awesome! Thanks, booting is finally acceptably fast again :-) Just strange that it worked for the last 3 years (in fact, 7 years) with just about every kernel version that's out there... but I'm happy with the workaround. Was it exact same hardware ? Cheers, -- Michael Brade; KDE Developer, Student of Computer Science |-mail: echo brade !#|tr -d c oh|s\e\d 's/e/\@/2;s/$/.org/;s/bra/k/2' °--web: http://www.kde.org/people/michaelb.html KDE 3: The Next Generation in Desktop Experience - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[no subject]
Hi Matt, Alan, Could you please tell me (link would do) why it makes default delay_use=5 really necessary (from the patch below)? https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-August/00074 7.html It makes USB boot really painfull and slow :( I understand there should be a good reason for it. I've tried to find an answer in archives, without much success though. Thanks, Aleks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
modules strip
Hi, I'm trying to strip modules a bit (2.6, x86) using strip -R .not -R .comment --strip-unneeded module.ko It seems to keep intact relocation & ksymtab symbols, tested on my configuration and seems to reduce the overall size for about 10-15% (usefull for embedded). Does anybody know if there is any pitfalls with that ? Thanks, Aleks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
modules strip
Hi, I'm trying to strip modules a bit (2.6, x86) using strip -R .not -R .comment --strip-unneeded module.ko It seems to keep intact relocation ksymtab symbols, tested on my configuration and seems to reduce the overall size for about 10-15% (usefull for embedded). Does anybody know if there is any pitfalls with that ? Thanks, Aleks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
