Re: 2.6.18-rc5-mm1

Re: 2.6.18-rc5-mm1

[Jeremy Fitzhardinge]

Jeremy Fitzhardinge wrote:
> The NULL EIP is desc->handle_irq in do_IRQ():
>
>         asm volatile(
>             "       xchgl  %%ebx,%%esp      \n"
>             "       call   *%%edi           \n"
>             "       movl   %%ebx,%%esp      \n"
>             : "=a" (arg1), "=d" (arg2), "=c" (arg3), "=b" (ebx)
>             :  "0" (irq),   "1" (desc),  "2" (regs),  "3" (isp),
>                "D" (desc->handle_irq)
>             : "memory", "cc"
>         );
>
> In my case, the IRQ is 0xdb = 219, which is an MSI interrupt for 
> libata (the AHCI SATA controller, presumably).  The exception happens 
> just after the SATA driver has probed all the hard disks.
>
> So it seems to me that the suspects are 1) sata, or 2) MSI.  I'll try 
> turning off MSI to see if it helps.

Yes, that fixed it; with MSI disabled I can boot successfully.

: ezr:pts/0; cd hg/linux-2.6/patches/broken-out/
: ezr:pts/0; ls *msi* | wc -l
23

Hm, where to start...

    J

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Greg KH]

On Sat, Sep 02, 2006 at 01:37:13AM -0700, Jeremy Fitzhardinge wrote:
> Jeremy Fitzhardinge wrote:
> >The NULL EIP is desc->handle_irq in do_IRQ():
> >
> >        asm volatile(
> >            "       xchgl  %%ebx,%%esp      \n"
> >            "       call   *%%edi           \n"
> >            "       movl   %%ebx,%%esp      \n"
> >            : "=a" (arg1), "=d" (arg2), "=c" (arg3), "=b" (ebx)
> >            :  "0" (irq),   "1" (desc),  "2" (regs),  "3" (isp),
> >               "D" (desc->handle_irq)
> >            : "memory", "cc"
> >        );
> >
> >In my case, the IRQ is 0xdb = 219, which is an MSI interrupt for 
> >libata (the AHCI SATA controller, presumably).  The exception happens 
> >just after the SATA driver has probed all the hard disks.
> >
> >So it seems to me that the suspects are 1) sata, or 2) MSI.  I'll try 
> >turning off MSI to see if it helps.
> 
> Yes, that fixed it; with MSI disabled I can boot successfully.
> 
> : ezr:pts/0; cd hg/linux-2.6/patches/broken-out/
> : ezr:pts/0; ls *msi* | wc -l
> 23
> 
> Hm, where to start...

There are 9 MSI patches in my tree that you can just remove.  They were
just recently (a few hours ago) replaced with a total rewrite due to a
number of different problems that were found.  So I'd suggest just
waiting till the next -mm release to see if it works properly or not.

thanks,

greg k-h

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Jeremy Fitzhardinge]

Greg KH wrote:
> There are 9 MSI patches in my tree that you can just remove.  They were
> just recently (a few hours ago) replaced with a total rewrite due to a
> number of different problems that were found.  So I'd suggest just
> waiting till the next -mm release to see if it works properly or not.
>   

This lot?

gregkh-pci-msi-01-merge_msi_disabling_quirks.patch
gregkh-pci-msi-02-factorize_pci_msi_supported.patch
gregkh-pci-msi-03-add_pci_device_exp_type.patch
gregkh-pci-msi-04-use_root_chipset_dev_no_msi_instead_of_pci_bus_flags.patch
gregkh-pci-msi-05-add_no_msi_to_sysfs.patch
gregkh-pci-msi-06-rename_pci_cap_id_ht_irqconf.patch
gregkh-pci-msi-07-check_hypertransport_msi_capabilities.patch
gregkh-pci-msi-08-drop_pci_msi_quirk.patch
gregkh-pci-msi-09-drop_pci_bus_flags.patch

    J

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Greg KH]

On Sat, Sep 02, 2006 at 01:47:43AM -0700, Jeremy Fitzhardinge wrote:
> Greg KH wrote:
> >There are 9 MSI patches in my tree that you can just remove.  They were
> >just recently (a few hours ago) replaced with a total rewrite due to a
> >number of different problems that were found.  So I'd suggest just
> >waiting till the next -mm release to see if it works properly or not.
> >  
> 
> This lot?
> 
> gregkh-pci-msi-01-merge_msi_disabling_quirks.patch
> gregkh-pci-msi-02-factorize_pci_msi_supported.patch
> gregkh-pci-msi-03-add_pci_device_exp_type.patch
> gregkh-pci-msi-04-use_root_chipset_dev_no_msi_instead_of_pci_bus_flags.patch
> gregkh-pci-msi-05-add_no_msi_to_sysfs.patch
> gregkh-pci-msi-06-rename_pci_cap_id_ht_irqconf.patch
> gregkh-pci-msi-07-check_hypertransport_msi_capabilities.patch
> gregkh-pci-msi-08-drop_pci_msi_quirk.patch
> gregkh-pci-msi-09-drop_pci_bus_flags.patch

Yes, try reverting them and see if your machine works again.

thanks,

greg k-h

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Jeremy Fitzhardinge]

Greg KH wrote:
> Yes, try reverting them and see if your machine works again.
>   

Reverting them makes the machine work, with basically the same effect as 
disabling CONFIG_PCI_MSI: no MSI interrupts appear in /proc/interrupts, 
and e1000 & libata are using IO-APIC-fasteoi.  So, a reasonable result 
for now.

Thanks,
    J

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Jeff Garzik]

Jeremy Fitzhardinge wrote:
> Greg KH wrote:
>> Yes, try reverting them and see if your machine works again.
>>   
> 
> Reverting them makes the machine work, with basically the same effect as 
> disabling CONFIG_PCI_MSI: no MSI interrupts appear in /proc/interrupts, 
> and e1000 & libata are using IO-APIC-fasteoi.  So, a reasonable result 
> for now.

Did you re-enable CONFIG_PCI_MSI, after reverting the patches?

	Jeff




-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Jeremy Fitzhardinge]

Jeff Garzik wrote:
>>
>> Reverting them makes the machine work, with basically the same effect 
>> as disabling CONFIG_PCI_MSI: no MSI interrupts appear in 
>> /proc/interrupts, and e1000 & libata are using IO-APIC-fasteoi.  So, 
>> a reasonable result for now.
>
> Did you re-enable CONFIG_PCI_MSI, after reverting the patches?

Yes.  Er.  Hm, perhaps not, it didn't build:

  CC      drivers/pci/htirq.o
drivers/pci/htirq.c: In function 'ht_create_irq':
drivers/pci/htirq.c:126: error: 'PCI_CAP_ID_HT' undeclared (first use in this function)
drivers/pci/htirq.c:126: error: (Each undeclared identifier is reported only once
drivers/pci/htirq.c:126: error: for each function it appears in.)

I'll try again with CONFIG_HT_IRQ disabled...

    J


-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Jeremy Fitzhardinge]

Jeff Garzik wrote:
> Did you re-enable CONFIG_PCI_MSI, after reverting the patches?

Hm, still doesn't link with The GregKH Nine removed but CONFIG_MSI:

drivers/built-in.o: In function `pci_enable_msix':
drivers/pci/msi.c:956: undefined reference to `pci_msi_supported'

I'll just do without for now.

    J

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Jeremy Fitzhardinge]

Greg KH wrote:
> There are 9 MSI patches in my tree that you can just remove.  They were
> just recently (a few hours ago) replaced with a total rewrite due to a
> number of different problems that were found.  So I'd suggest just
> waiting till the next -mm release to see if it works properly or not.
>   

I'm seeing exactly the same oops with CONFIG_MSI on 2.6.18-rc6-mm1.

    J

Re: 2.6.18-rc5-mm1

[Matthias Hentges]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

Am Samstag, den 09.09.2006, 16:47 -0700 schrieb Jeremy Fitzhardinge:
> Greg KH wrote:
> > There are 9 MSI patches in my tree that you can just remove.  They were
> > just recently (a few hours ago) replaced with a total rewrite due to a
> > number of different problems that were found.  So I'd suggest just
> > waiting till the next -mm release to see if it works properly or not.
> >   
> 
> I'm seeing exactly the same oops with CONFIG_MSI on 2.6.18-rc6-mm1.

Same here.
-- 
Matthias 'CoreDump' Hentges 

My OS: Debian SID. Geek by Nature, Linux by Choice

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-mm patch] ATA_JMICRON: remove the superfluous ATA dependency

[Adrian Bunk]

The dependency on ATA is no longer required since this option is now 
inside an "if ATA" block.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.18-rc5-mm1/drivers/ata/Kconfig.old	2006-09-07 00:39:33.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/ata/Kconfig	2006-09-07 00:39:55.000000000 +0200
@@ -309,7 +309,7 @@
 
 config ATA_JMICRON
 	tristate "JMicron non-AHCI support (Experimental)"
-	depends on ATA && PCI && EXPERIMENTAL
+	depends on PCI && EXPERIMENTAL
 	help
 	  This option enables support for Jmicron ATA controllers
 	  ports running in non-AHCI mode. Where possible you should