Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]
On Fri, 23 Jun 2006 02:50:15 +0100 Sergio Monteiro Basto wrote: > On Thu, 2006-06-22 at 18:39 -0700, Randy.Dunlap wrote: > > This sounds like just running with CONFIG_IO_APIC=n or using > > "noapic" on the kernel boot command line. If that's what is > > needed, we can know that. I just haven't seen info to know > > what the real problem is. > > yes, could be a way, if we know if IO_APIC or LOCAL_APIC is enabled or > not ? I don't know of a current flag or state that tells us that, but it could be added. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]
On Thu, 2006-06-22 at 18:39 -0700, Randy.Dunlap wrote: > This sounds like just running with CONFIG_IO_APIC=n or using > "noapic" on the kernel boot command line. If that's what is > needed, we can know that. I just haven't seen info to know > what the real problem is. yes, could be a way, if we know if IO_APIC or LOCAL_APIC is enabled or not ? thanks, -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature
Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]
Chris, If you keep me posted on the patch when released (I'm not on the kernel list, too high volume for me) I'll be happy to give your patch a whirl on my test box against whichever kernel you patch. Your last point is real good, how DOES Windows figure it out? In saying that, without the VIA drivers I only have USB1.1 support on this motherboard... Again, happy to test some theories if you have some tests you'd like ran... Cheers, :)Johny Chris Wedgwood wrote: On Thu, Jun 22, 2006 at 11:46:38PM +0100, Sergio Monteiro Basto wrote: yap, in my opinion this function should back to +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq); this is *obviousyl* wrong, it should never have been merged like that and there are reports and complaints this causes problems for some people we should first attempt to get all the IDs (some are clearly missing still, patch coming up to address that) and where that fails perhaps have a kernel command-line parameter to be overly aggressive as a stop-gap until we van figure out the proper solution i'd also like to figure out why the quirk is needed/fails when people are using ACPI for interrupt routing as presumbly that must work as windows relies on it - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]
On Thu, 2006-06-22 at 16:25 -0700, Randy.Dunlap wrote: > No idea about that. > I think that you still didn't answer my question, or maybe I > didn't ask it well enough. What device are you having problems > with? I don't mean what chipset, I mean what device that you > touch... > I'd like to give you one answer , but I don't have one problem with one device, I bought (accidentally) one VIA with a Pentium dual-core, which have a bunch of problems. > > > --- orig/drivers/pci/quirks.c 2006-06-21 20:25:41.0 +1000 > > +++ linux-2.6.17-rc6-mm2/drivers/pci/quirks.c 2006-06-21 > 20:25:08.0 +1000 > > @@ -662,13 +662,7 @@ > > pci_write_config_byte(dev, PCI_INTERRUPT_LINE, > new_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); > > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, > quirk_via_irq); > > > > /* > > * VIA VT82C598 has its device ID settable and many BIOSes > > > > > > But do you know or not ? how I know if dev->irq is XT-pic ? > > I don't see a way to know that currently. It could be added > somehow if it's really required. So far I haven't seen a full > problem description or requirement for this. Well, this is based in tests along this 4 years, with my two computers. Like Bjorn said, we don't have any specification of VIA chipsets. But I like to try, use this quirks only if system don't have IO-APICs enabled. Many VIA systems work like that, for example my old laptop. For me, I know that my old laptop needs the quirks and run with interrupts in XT-PIC, and with my new desktop, I quit sure that don't need the quirks and system runs with interrupts in IO-APIC-edge and IO-APIC-level. Based in, what I read in this original thread http://lkml.org/lkml/2005/8/18/92 , seems to me, that we could try this solution, if we have a easy way to know what kind of interrupts have the device. Thanks Randy for your time, -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature
Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]
On Fri, 23 Jun 2006 02:00:44 +0100 Sergio Monteiro Basto wrote: > On Thu, 2006-06-22 at 15:54 -0700, Chris Wedgwood wrote: > > On Thu, Jun 22, 2006 at 11:46:38PM +0100, Sergio Monteiro Basto wrote: > > > > > yap, in my opinion this function should back to > > > > > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq); > > > > > > this is *obviousyl* wrong, it should never have been merged like that > > and there are reports and complaints this causes problems for some > > people > > > > It was like that in kernel 2.6.16 and previous since, I don't know, > 2.6.9 or 2.6.13 > > > > > we should first attempt to get all the IDs (some are clearly missing > > still, patch coming up to address that) and where that fails perhaps > > have a kernel command-line parameter to be overly aggressive as a > > stop-gap until we van figure out the proper solution > > I believe this quirks is just for VIA system with interrupts in XT-PIC > mode (like my old laptop). This sounds like just running with CONFIG_IO_APIC=n or using "noapic" on the kernel boot command line. If that's what is needed, we can know that. I just haven't seen info to know what the real problem is. > > i'd also like to figure out why the quirk is needed/fails when people > > are using ACPI for interrupt routing as presumbly that must work as > > windows relies on it > > yes, this is other mysterious, why boot with acpi=noirq could be one > workaround. But could be other problem more related with usb drives. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]
On Thu, 2006-06-22 at 15:54 -0700, Chris Wedgwood wrote: > On Thu, Jun 22, 2006 at 11:46:38PM +0100, Sergio Monteiro Basto wrote: > > > yap, in my opinion this function should back to > > > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq); > > > this is *obviousyl* wrong, it should never have been merged like that > and there are reports and complaints this causes problems for some > people > It was like that in kernel 2.6.16 and previous since, I don't know, 2.6.9 or 2.6.13 > > we should first attempt to get all the IDs (some are clearly missing > still, patch coming up to address that) and where that fails perhaps > have a kernel command-line parameter to be overly aggressive as a > stop-gap until we van figure out the proper solution I believe this quirks is just for VIA system with interrupts in XT-PIC mode (like my old laptop). > > i'd also like to figure out why the quirk is needed/fails when people > are using ACPI for interrupt routing as presumbly that must work as > windows relies on it yes, this is other mysterious, why boot with acpi=noirq could be one workaround. But could be other problem more related with usb drives. smime.p7s Description: S/MIME cryptographic signature
Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]
On Thu, Jun 22, 2006 at 11:46:38PM +0100, Sergio Monteiro Basto wrote: > yap, in my opinion this function should back to > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq); this is *obviousyl* wrong, it should never have been merged like that and there are reports and complaints this causes problems for some people we should first attempt to get all the IDs (some are clearly missing still, patch coming up to address that) and where that fails perhaps have a kernel command-line parameter to be overly aggressive as a stop-gap until we van figure out the proper solution i'd also like to figure out why the quirk is needed/fails when people are using ACPI for interrupt routing as presumbly that must work as windows relies on it - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]
On Thu, 22 Jun 2006 23:46:38 +0100 Sergio Monteiro Basto wrote:
> On Thu, 2006-06-22 at 14:29 -0700, Randy.Dunlap wrote:
> > On Thu, 22 Jun 2006 12:56:25 +0100 Sergio Monteiro Basto wrote:
> >
> > > On Wed, 2006-06-21 at 21:08 -0700, Randy.Dunlap wrote:
> > > >
> > > > If you have a specific issue/problem, it would probably be
> > > > better just to focus on that.
> > >
> > > on linux-2.6.17/drivers/pci/quirks.c
> > >
> > > * we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
> > > * interrupts delivered properly.
> > > */
> > >
> > > static void quirk_via_irq(struct pci_dev *dev)
> > > {
> > > u8 irq, new_irq;
> > >
> > > I want here put something like: if ( dev->irq != XT-PIC) return and
> > > don't quirk this dev.
> > > else
> >
> > I don't think the interrupt device mode is known by this code (AFAICT
> > with a quick look). The function is only called for certain VIA chipsets.
> >
> > Do you want the quirk for any particular hardware device?
> > You might be able to look at the function's parameter
> > to decide on using the quirk or not.
> >
> >
> > > new_irq = dev->irq & 0xf;
> > > pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
>
> yap, in my opinion this function should back to
No idea about that.
I think that you still didn't answer my question, or maybe I
didn't ask it well enough. What device are you having problems
with? I don't mean what chipset, I mean what device that you
touch...
> --- orig/drivers/pci/quirks.c 2006-06-21 20:25:41.0 +1000
> +++ linux-2.6.17-rc6-mm2/drivers/pci/quirks.c 2006-06-21 20:25:08.0
> +1000
> @@ -662,13 +662,7 @@
> pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_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);
> +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
>
> /*
> * VIA VT82C598 has its device ID settable and many BIOSes
>
>
> But do you know or not ? how I know if dev->irq is XT-pic ?
I don't see a way to know that currently. It could be added
somehow if it's really required. So far I haven't seen a full
problem description or requirement for this.
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]
On Thu, 2006-06-22 at 14:29 -0700, Randy.Dunlap wrote:
> On Thu, 22 Jun 2006 12:56:25 +0100 Sergio Monteiro Basto wrote:
>
> > On Wed, 2006-06-21 at 21:08 -0700, Randy.Dunlap wrote:
> > >
> > > If you have a specific issue/problem, it would probably be
> > > better just to focus on that.
> >
> > on linux-2.6.17/drivers/pci/quirks.c
> >
> > * we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
> > * interrupts delivered properly.
> > */
> >
> > static void quirk_via_irq(struct pci_dev *dev)
> > {
> > u8 irq, new_irq;
> >
> > I want here put something like: if ( dev->irq != XT-PIC) return and don't
> > quirk this dev.
> > else
>
> I don't think the interrupt device mode is known by this code (AFAICT
> with a quick look). The function is only called for certain VIA chipsets.
>
> Do you want the quirk for any particular hardware device?
> You might be able to look at the function's parameter
> to decide on using the quirk or not.
>
>
> > new_irq = dev->irq & 0xf;
> > pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
yap, in my opinion this function should back to
--- orig/drivers/pci/quirks.c 2006-06-21 20:25:41.0 +1000
+++ linux-2.6.17-rc6-mm2/drivers/pci/quirks.c 2006-06-21 20:25:08.0
+1000
@@ -662,13 +662,7 @@
pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_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);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
/*
* VIA VT82C598 has its device ID settable and many BIOSes
But do you know or not ? how I know if dev->irq is XT-pic ?
--
Sérgio M. B.
smime.p7s
Description: S/MIME cryptographic signature
Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]
On Thu, 22 Jun 2006 12:56:25 +0100 Sergio Monteiro Basto wrote:
> On Wed, 2006-06-21 at 21:08 -0700, Randy.Dunlap wrote:
> >
> > If you have a specific issue/problem, it would probably be
> > better just to focus on that.
>
> on linux-2.6.17/drivers/pci/quirks.c
>
> * we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
> * interrupts delivered properly.
> */
>
> static void quirk_via_irq(struct pci_dev *dev)
> {
> u8 irq, new_irq;
>
> I want here put something like: if ( dev->irq != XT-PIC) return and don't
> quirk this dev.
> else
I don't think the interrupt device mode is known by this code (AFAICT
with a quick look). The function is only called for certain VIA chipsets.
Do you want the quirk for any particular hardware device?
You might be able to look at the function's parameter
to decide on using the quirk or not.
> new_irq = dev->irq & 0xf;
> pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Lhms-devel] [RFC] Patch [1/2] for acpi_memhotplug.c
On Thu, 2006-06-22 at 11:29 -0700, keith mannthey wrote:
> On Fri, 2006-06-23 at 02:41 +0900, KAMEZAWA Hiroyuki wrote:
> > On Thu, 22 Jun 2006 10:25:24 -0700
> > keith mannthey <[EMAIL PROTECTED]> wrote:
> > > > Um...my concern is
> > > > - When notify comes, memory hotplug driver is called.
> > > > - but at acpi_bus_add(), PNP0C01 motherboad driver is attached to the
> > > > device.
> > >
> > > The patch I sent keeps the motherboard driver from attaching and allows
> > > the PNP0C80 device to attach.
> > >
> > My point is...motherboard is not memory. Then, it shouldn't have _CRS
> > handler.
> > Because your ME00/ME01 device has both HID for memory and CID for
> > motherboard,
> > motherboard handler is called.
> > (acpi_add_single_object() attaches the driver which is found 1st.)
> > > > ==
> > > > Device (ME01)
> > > > {
> > > > Name (_HID, EisaId ("PNP0C80"))
> > > > Name (_CID, 0x010CD041)
> > > > ==
> > As I wrote in other mail, why memory and motherboard is compatible device in
> > your SSDT ? If this _CID is necessary for some reason, what should we do is
> > acpi handling problem.
> > So, what you should ask to acpi people is
> > ==
> > my device has both _HID and _CID. But the driver for _HID is different from
> > _CID. I'm glad if the driver for _HID is called but driver for _CID is found
> > before driver for _HID. Then, driver for _CID is called.
> > How should I do ? (or make patch to fix this..)
> > ==
>
> I agree this is an acpi_handling problem where the wrong device is
> attached. I am pursuing ACPI folks today.
>
> I have my patch in place to work around the problem and am looking into
> the the memory driver.
>
> In acpi_memory_enable_device
>
> in list_for_each_entry(info, &mem_device->res_list, list) {
>
> if
> printk ("node: %d , start %08lx, end %08lx \n",node,info-
> >start_addr,info->start_addr+info->length);
> before doing the add memory I see
>
> node: -1 , start 1f000, end 27000
> On node -1 totalpages: 0
> node: -1 , start 17000, end 1f000
>
> Finding the 2 ranges (these are the right ranges and the right chunks)
> is great but acpi_get_node is not working for my handle.
>
> I am continuing to debug.
>
if acpi_get_pxm
status = acpi_evaluate_integer(handle, "_PXM", NULL, &pxm);
This is looking to get the _PXM value from the handle. I don't see a
_PXM filed in my SSDT for my memory device. I don't think it is
required to have the _PXM field. It would be nice if it had one but I
don't think Linux should require one.
If the handle doesn't contain the _PXM device it should ask the arch if
it knows. If the arch doesn't know (by way of SRAT at boot) then it
should set the node to 0. I will send along a patch today.
Thanks,
keith mannthey <[EMAIL PROTECTED]>
Linux Technology Center IBM
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Lhms-devel] [RFC] Patch [1/2] for acpi_memhotplug.c
On Fri, 2006-06-23 at 02:41 +0900, KAMEZAWA Hiroyuki wrote:
> On Thu, 22 Jun 2006 10:25:24 -0700
> keith mannthey <[EMAIL PROTECTED]> wrote:
> > > Um...my concern is
> > > - When notify comes, memory hotplug driver is called.
> > > - but at acpi_bus_add(), PNP0C01 motherboad driver is attached to the
> > > device.
> >
> > The patch I sent keeps the motherboard driver from attaching and allows
> > the PNP0C80 device to attach.
> >
> My point is...motherboard is not memory. Then, it shouldn't have _CRS handler.
> Because your ME00/ME01 device has both HID for memory and CID for motherboard,
> motherboard handler is called.
> (acpi_add_single_object() attaches the driver which is found 1st.)
> > > ==
> > > Device (ME01)
> > > {
> > > Name (_HID, EisaId ("PNP0C80"))
> > > Name (_CID, 0x010CD041)
> > > ==
> As I wrote in other mail, why memory and motherboard is compatible device in
> your SSDT ? If this _CID is necessary for some reason, what should we do is
> acpi handling problem.
> So, what you should ask to acpi people is
> ==
> my device has both _HID and _CID. But the driver for _HID is different from
> _CID. I'm glad if the driver for _HID is called but driver for _CID is found
> before driver for _HID. Then, driver for _CID is called.
> How should I do ? (or make patch to fix this..)
> ==
I agree this is an acpi_handling problem where the wrong device is
attached. I am pursuing ACPI folks today.
I have my patch in place to work around the problem and am looking into
the the memory driver.
In acpi_memory_enable_device
in list_for_each_entry(info, &mem_device->res_list, list) {
if
printk ("node: %d , start %08lx, end %08lx \n",node,info-
>start_addr,info->start_addr+info->length);
before doing the add memory I see
node: -1 , start 1f000, end 27000
On node -1 totalpages: 0
node: -1 , start 17000, end 1f000
Finding the 2 ranges (these are the right ranges and the right chunks)
is great but acpi_get_node is not working for my handle.
I am continuing to debug.
Thanks,
Keith
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Lhms-devel] [RFC] Patch [1/2] for acpi_memhotplug.c
On Thu, 22 Jun 2006 10:25:24 -0700
keith mannthey <[EMAIL PROTECTED]> wrote:
> > Um...my concern is
> > - When notify comes, memory hotplug driver is called.
> > - but at acpi_bus_add(), PNP0C01 motherboad driver is attached to the
> > device.
>
> The patch I sent keeps the motherboard driver from attaching and allows
> the PNP0C80 device to attach.
>
My point is...motherboard is not memory. Then, it shouldn't have _CRS handler.
Because your ME00/ME01 device has both HID for memory and CID for motherboard,
motherboard handler is called.
(acpi_add_single_object() attaches the driver which is found 1st.)
> > ==
> > Device (ME01)
> > {
> > Name (_HID, EisaId ("PNP0C80"))
> > Name (_CID, 0x010CD041)
> > ==
As I wrote in other mail, why memory and motherboard is compatible device in
your SSDT ? If this _CID is necessary for some reason, what should we do is
acpi handling problem.
So, what you should ask to acpi people is
==
my device has both _HID and _CID. But the driver for _HID is different from
_CID. I'm glad if the driver for _HID is called but driver for _CID is found
before driver for _HID. Then, driver for _CID is called.
How should I do ? (or make patch to fix this..)
==
Cheers,
-Kame
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Lhms-devel] [RFC] Patch [1/2] for acpi_memhotplug.c
On Thu, 2006-06-22 at 14:20 +0900, KAMEZAWA Hiroyuki wrote:
> On Wed, 21 Jun 2006 20:55:02 -0700
> keith mannthey <[EMAIL PROTECTED]> wrote:
> > > Hmmcurious..but no idead..
> > > Then, could try this ?
> >
> > I am trying to make the motherboard driver fail with it looks for
> > resources and finds node. The motherboard add function alway returns
> > AE_OK which is why the algorithm fails. See attached patch it allows the
> > hot-add event to happen.
> >
> > With the event happening and I see
> >
> Um...my concern is
> - When notify comes, memory hotplug driver is called.
> - but at acpi_bus_add(), PNP0C01 motherboad driver is attached to the device.
The patch I sent keeps the motherboard driver from attaching and allows
the PNP0C80 device to attach.
> I think something is wrongfrom your SSDT, ME00 and ME01 memory device has
> valid HID, PNP0C80.
> ==
> Device (ME01)
> {
> Name (_HID, EisaId ("PNP0C80"))
> Name (_CID, 0x010CD041)
> ==
> What I imagine now is.
>
> - acpi_memory_device_init() -> acpi_memory_register_notify_handler()
> installs notify handler for memory hotplug against device handle of memory
> This doesn't check _CID.
>
> - acpi_bus_add() attachs motherboard driver because of CID.
> Above _CID is 32bit compressed EISA-type ID (HID is string but..),
> it is PNP0C01...motherboad driver is called before PNP0C80 driver.
> (to covert 32bit ID to string, see acpi_ex_eisa_id_to_string(),
>I attached program.)
This is a bug in the motherboard driver where it attached to any device
it is presented to.
> Then what we should do here is...call HID:PNP0C80 driver instead if
> CID:PNP0C01 driver.
> Because it has driver for HID, calling driver for CID looks not good.
> (But we have to ask acpi people about this..)
The patch allows PNP0C80 driver to be used.
--
keith mannthey <[EMAIL PROTECTED]>
Linux Technology Center IBM
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] ACPI: reduce code size, clean up, fix validator message
Hi Ingo, On 22/06/06, Ingo Molnar <[EMAIL PROTECTED]> wrote: * Andrew Morton <[EMAIL PROTECTED]> wrote: > > It complains about this only the 1st time, even though > > this same code sequence runs for every (subsequent) ACPI interrupt. that is because the lock validator turns itself off after the first complaint. > Yes, lockdep uses the callsite of spin_lock_init() to detect the > "type" of a lock. > > But the ACPI obfuscation layers use the same spin_lock_init() site to > initialise two not-the-same locks, so lockdep decides those two locks > are of the same "type" and gets confused. > > We had earlier decided to remove that ACPI code which kmallocs a > single spinlock. When that's done, lockdep will become unconfused. > > AFACIT it's all used for just two statically allocated locks anwyay. Ok, great! Find below the (tested) cleanup that also fixes the validator problem. Problem fixed, thanks. (if ACPI wants to turn this into platform-independent code it should be a build-time and type-correct translation layer that understands things like DEFINE_SPINLOCK as well.) Ingo Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (http://www.stardust.webpages.pl/ltg/wiki/) - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]
On Wed, 2006-06-21 at 21:08 -0700, Randy.Dunlap wrote:
>
> If you have a specific issue/problem, it would probably be
> better just to focus on that.
on linux-2.6.17/drivers/pci/quirks.c
* we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
* interrupts delivered properly.
*/
static void quirk_via_irq(struct pci_dev *dev)
{
u8 irq, new_irq;
I want here put something like: if ( dev->irq != XT-PIC) return and don't
quirk this dev.
else
new_irq = dev->irq & 0xf;
pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
--
Sérgio M. B.
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
not ACPI-aware installer
Hallow All, if an OS knowing nothing about ACPI will be installed on a ACPI equiped computer, can it cause a hardware damage? I mean if it's true than an installer from some GNU/Linux distribution that can't process thermal events from ACPI can lead to a hardware damage during installation of the distribution. Am I thinking right? Best regards, Sergiy Kolesnikov --- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] ACPI: reduce code size, clean up, fix validator message
Ingo, Thanks for the quick reply. An Andrew's advice a while back, Bob already got rid of the allocate part -- it just isn't upstream yet. Re: changing ACPICA code (sub-directories of drivers/acpi/) like this: >- flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock); >+ spin_lock_irqsave(&acpi_gbl_gpe_lock, flags); I can't do that without either 1. diverging between Linux and ACPICA or 2. getting a license back from you to Intel such that Intel can re-distrubute such a change under the Intel license on the file and inventing spin_lock_irqsave() on about 9 other operating systems. #1 is all pain and no gain, unless the 244 net fewer bytes counts as gain. #2 wouldn't make sense either. If this code were performance or size critical, I would still delete acpi_os_acquire_lock from osl.c, but would inline it in aclinux.h. thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.17-mm1 - possible recursive locking detected
On Thu, 22 Jun 2006 03:51:51 -0400 "Brown, Len" <[EMAIL PROTECTED]> wrote: > > >> The key thing here is that our recent changes in > >> how the locks are _used_ is okay -- and I think it is. > > > >Well. We don't know that. We just know that this report of unokayness > >wasn't right. With Ingo's Linux-only patch we're in a > >position to verify > >that the locking is probably OK. > > If this were really recursive, my machine would have deadlocked > instead of booting normally like it did, no? yup. If it's SMP ;) - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 2.6.17-mm1 - possible recursive locking detected
>> The key thing here is that our recent changes in >> how the locks are _used_ is okay -- and I think it is. > >Well. We don't know that. We just know that this report of unokayness >wasn't right. With Ingo's Linux-only patch we're in a >position to verify >that the locking is probably OK. If this were really recursive, my machine would have deadlocked instead of booting normally like it did, no? -Len - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.17-mm1 - possible recursive locking detected
On Thu, 22 Jun 2006 03:40:36 -0400 "Brown, Len" <[EMAIL PROTECTED]> wrote: > >> Nothing jumps out at me as incorrect above, so > >> at this point it looks like a CONFIG_LOCKDEP artifact -- > >> but lets ask the experts:-) > > > >Yes, lockdep uses the callsite of spin_lock_init() to detect > >the "type" of > >a lock. > > > >But the ACPI obfuscation layers use the same spin_lock_init() site to > >initialise two not-the-same locks, so lockdep decides those > >two locks are of the same "type" and gets confused. > > interesting definition of "type". I guess it works > in practice or others would be complaining... It works out that way, yes. > >We had earlier decided to remove that ACPI code which kmallocs a single > >spinlock. When that's done, lockdep will become unconfused. > > Yes, that change is already on the way. Is good. > The key thing here is that our recent changes in > how the locks are _used_ is okay -- and I think it is. Well. We don't know that. We just know that this report of unokayness wasn't right. With Ingo's Linux-only patch we're in a position to verify that the locking is probably OK. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 2.6.17-mm1 - possible recursive locking detected
>> Nothing jumps out at me as incorrect above, so >> at this point it looks like a CONFIG_LOCKDEP artifact -- >> but lets ask the experts:-) > >Yes, lockdep uses the callsite of spin_lock_init() to detect >the "type" of >a lock. > >But the ACPI obfuscation layers use the same spin_lock_init() site to >initialise two not-the-same locks, so lockdep decides those >two locks are of the same "type" and gets confused. interesting definition of "type". I guess it works in practice or others would be complaining... >We had earlier decided to remove that ACPI code which kmallocs a single >spinlock. When that's done, lockdep will become unconfused. Yes, that change is already on the way. The key thing here is that our recent changes in how the locks are _used_ is okay -- and I think it is. thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] ACPI: reduce code size, clean up, fix validator message
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > It complains about this only the 1st time, even though
> > this same code sequence runs for every (subsequent) ACPI interrupt.
that is because the lock validator turns itself off after the first
complaint.
> Yes, lockdep uses the callsite of spin_lock_init() to detect the
> "type" of a lock.
>
> But the ACPI obfuscation layers use the same spin_lock_init() site to
> initialise two not-the-same locks, so lockdep decides those two locks
> are of the same "type" and gets confused.
>
> We had earlier decided to remove that ACPI code which kmallocs a
> single spinlock. When that's done, lockdep will become unconfused.
>
> AFACIT it's all used for just two statically allocated locks anwyay.
Ok, great! Find below the (tested) cleanup that also fixes the validator
problem.
(if ACPI wants to turn this into platform-independent code it should be
a build-time and type-correct translation layer that understands things
like DEFINE_SPINLOCK as well.)
Ingo
Subject: ACPI: reduce code size, clean up, fix validator message
From: Ingo Molnar <[EMAIL PROTECTED]>
this patch:
- reduces ACPI code size by 336 bytes:
textdatabss dec hex filename
218489016941178 4515464 33305543 1fc33c7 vmlinux-before
218485656941270 4515464 33305299 1fc32d3 vmlinux-after
- cleans the code up by going from the opaque (void *) acpi_handle
type to an explicit type-checked spinlock_t and by removing 70
lines of code of unnecessary layering.
- fixes lock validator message by initializing the two static
locks build-time instead of runtime.
- speeds up the code a bit by reducing extra runtime layering and
improving cache footprint.
build and boot tested.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
drivers/acpi/events/evgpe.c | 11 ---
drivers/acpi/events/evgpeblk.c| 20 ++---
drivers/acpi/events/evxface.c |8 ++---
drivers/acpi/hardware/hwregs.c| 19 ++--
drivers/acpi/osl.c| 56 --
drivers/acpi/utilities/utglobal.c |3 ++
drivers/acpi/utilities/utmutex.c | 13
include/acpi/acglobal.h |4 +-
include/acpi/acpiosxf.h |8 -
9 files changed, 35 insertions(+), 107 deletions(-)
Index: linux/drivers/acpi/events/evgpe.c
===
--- linux.orig/drivers/acpi/events/evgpe.c
+++ linux/drivers/acpi/events/evgpe.c
@@ -396,7 +396,7 @@ u32 acpi_ev_gpe_detect(struct acpi_gpe_x
/* We need to hold the GPE lock now, hardware lock in the loop */
- flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
+ spin_lock_irqsave(&acpi_gbl_gpe_lock, flags);
/* Examine all GPE blocks attached to this interrupt level */
@@ -413,7 +413,7 @@ u32 acpi_ev_gpe_detect(struct acpi_gpe_x
gpe_register_info = &gpe_block->register_info[i];
- hw_flags = acpi_os_acquire_lock(acpi_gbl_hardware_lock);
+ spin_lock_irqsave(&acpi_gbl_hardware_lock, hw_flags);
/* Read the Status Register */
@@ -423,7 +423,7 @@ u32 acpi_ev_gpe_detect(struct acpi_gpe_x
&gpe_register_info->
status_address);
if (ACPI_FAILURE(status)) {
- acpi_os_release_lock(acpi_gbl_hardware_lock,
+ spin_unlock_irqrestore(&acpi_gbl_hardware_lock,
hw_flags);
goto unlock_and_exit;
}
@@ -435,7 +435,8 @@ u32 acpi_ev_gpe_detect(struct acpi_gpe_x
&enable_reg,
&gpe_register_info->
enable_address);
- acpi_os_release_lock(acpi_gbl_hardware_lock, hw_flags);
+ spin_unlock_irqrestore(&acpi_gbl_hardware_lock,
+ hw_flags);
if (ACPI_FAILURE(status)) {
goto unlock_and_exit;
@@ -486,7 +487,7 @@ u32 acpi_ev_gpe_detect(struct acpi_gpe_x
unlock_and_exit:
- acpi_os_release_lock(acpi_gbl_gpe_lock, flags);
+ spin_unlock_irqrestore(&acpi_gbl_gpe_lock, flags);
return (int_status);
}
Index: linux/drivers/acpi/events/evgpeblk.c
===
--- linux.orig/drivers/acpi/events/evgpeblk.c
+++ linux/drivers/acpi/events/evgpeblk.c
@@ -140,7 +140,7 @@ acpi_status acpi_ev_walk_gpe_list(acpi_g
ACPI_FUNCTION_TRACE(ev_walk_gpe_list);
- flags = acpi_os_acquir
