Ben Bridgwater wrote:
> Jeff Garzik wrote:
>
> >
> > Setting DEBUG to 1 in arch/i386/kernel/pci-i386.h gives you lots of
> > info, including PIRQ debug data.
>
> I can try this tonite with 2.4.4 if this is going to be useful.
>
Well, I don't know how useful this is going to be, since the kernel
Ben Bridgwater wrote:
Jeff Garzik wrote:
Setting DEBUG to 1 in arch/i386/kernel/pci-i386.h gives you lots of
info, including PIRQ debug data.
I can try this tonite with 2.4.4 if this is going to be useful.
Well, I don't know how useful this is going to be, since the kernel booted
> The only way a motherboard BIOS would know if the PCI BIOS used polling
> methods instead of interrupt methods is if it was a built in device. For all
Such as the motherboard IDE ?
> for all bootable devices on the system, regardless of PnPOS settings. Name
> one concrete example of a
Alan Cox wrote:
> > setup all possible boot devices, only devices non-essential to the boot
> > process (sound cards, modems, crap like that) get left unconfigured. Not
>
> It only has to do minimal setup on them. If the BIOS calls are polled then
> assigning an IRQ is quite optional
The only
> Which is what I said also in my last email. I'm more than happy to write this
> off as a BIOS bug, and it is highly likely that the fact that Windows doesn't
> see a problem is because of the exact test I mentioned above. The BIOS has to
I very much doubt windows is using that test.
> setup
Mine is a Micronics W6LI with Phoenix BIOS.
Andy Carlson |\ _,,,---,,_
[EMAIL PROTECTED]ZZZzz /,`.-'`'-. ;-;;,_
BJC Health System |,4- ) )-,_. ,\ ( `'-'
St. Louis, Missouri '---''(_/--' `-'\_)
Cat Pics:
Alan Cox wrote:
>
> > > IRQ11 appearing on IRQ10 sounds exactly like the INTA-D line setting for IRQ
> > > 11 is wrong and we connected it to IRQ 10
> >
> > Which brings me back to my question in my previous email. Why are we
> > remapping working configs again? I'm at a loss here. This isn't
> > IRQ11 appearing on IRQ10 sounds exactly like the INTA-D line setting for IRQ
> > 11 is wrong and we connected it to IRQ 10
>
> Which brings me back to my question in my previous email. Why are we
> remapping working configs again? I'm at a loss here. This isn't a hot plug
> capably
> EXTREMELY unlikely. Under a 2.2 no-apic kernel, the aic7xxx card uses IRQ 11
> and works. Under a 2.2 ioapic kernel, it uses high interrupts and works.
non SMP that is clueless ignorance mode, SMP that is MP table mode
> situation. Specifically, if the eepro100 or e100 drivers are not
Alan Cox wrote:
> The tables are then described by the $PIRQ table in the BIOS. We use that to
> load the mapping registers in the PCI bridge (and also to read them). If the
> tables are wrong then we will mismap interrupt INTA-D lines to IRQ lines.
>
> IRQ11 appearing on IRQ10 sounds exactly
Alan Cox wrote:
>
> > This has been reported to both Mandrake and Redhat:
> >
> > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=29555
> >
> > I've been trying to find out if there's a fix (if it's aic7xxx 6.1.13
> > that's great!), but Redhat seem to believe it's a 2.4 kernel PCI bug:
>
>
> This has been reported to both Mandrake and Redhat:
>
> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=29555
>
> I've been trying to find out if there's a fix (if it's aic7xxx 6.1.13
> that's great!), but Redhat seem to believe it's a 2.4 kernel PCI bug:
Personally I still think its a
Justin Gibbs wrote:
> >I have a dual ppro 200MHZ W6LI motherboard. I put 2.4.4-ac5 on last
> >night, and the machine hung at Freeing unused Kernel memory. I
> >selectively backed off what I thought were relevant patches. I got to
> >aic7xxx, and ac5 without it worked. I attached
Justin Gibbs wrote:
I have a dual ppro 200MHZ W6LI motherboard. I put 2.4.4-ac5 on last
night, and the machine hung at Freeing unused Kernel memory. I
selectively backed off what I thought were relevant patches. I got to
aic7xxx, and ac5 without it worked. I attached /proc/scsi/aic7xxx/0.
This has been reported to both Mandrake and Redhat:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=29555
I've been trying to find out if there's a fix (if it's aic7xxx 6.1.13
that's great!), but Redhat seem to believe it's a 2.4 kernel PCI bug:
Personally I still think its a BIOS
Alan Cox wrote:
This has been reported to both Mandrake and Redhat:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=29555
I've been trying to find out if there's a fix (if it's aic7xxx 6.1.13
that's great!), but Redhat seem to believe it's a 2.4 kernel PCI bug:
Personally I
EXTREMELY unlikely. Under a 2.2 no-apic kernel, the aic7xxx card uses IRQ 11
and works. Under a 2.2 ioapic kernel, it uses high interrupts and works.
non SMP that is clueless ignorance mode, SMP that is MP table mode
situation. Specifically, if the eepro100 or e100 drivers are not
Alan Cox wrote:
The tables are then described by the $PIRQ table in the BIOS. We use that to
load the mapping registers in the PCI bridge (and also to read them). If the
tables are wrong then we will mismap interrupt INTA-D lines to IRQ lines.
IRQ11 appearing on IRQ10 sounds exactly like
IRQ11 appearing on IRQ10 sounds exactly like the INTA-D line setting for IRQ
11 is wrong and we connected it to IRQ 10
Which brings me back to my question in my previous email. Why are we
remapping working configs again? I'm at a loss here. This isn't a hot plug
capably motherboard,
Alan Cox wrote:
IRQ11 appearing on IRQ10 sounds exactly like the INTA-D line setting for IRQ
11 is wrong and we connected it to IRQ 10
Which brings me back to my question in my previous email. Why are we
remapping working configs again? I'm at a loss here. This isn't a hot plug
Mine is a Micronics W6LI with Phoenix BIOS.
Andy Carlson |\ _,,,---,,_
[EMAIL PROTECTED]ZZZzz /,`.-'`'-. ;-;;,_
BJC Health System |,4- ) )-,_. ,\ ( `'-'
St. Louis, Missouri '---''(_/--' `-'\_)
Cat Pics:
Which is what I said also in my last email. I'm more than happy to write this
off as a BIOS bug, and it is highly likely that the fact that Windows doesn't
see a problem is because of the exact test I mentioned above. The BIOS has to
I very much doubt windows is using that test.
setup all
Alan Cox wrote:
setup all possible boot devices, only devices non-essential to the boot
process (sound cards, modems, crap like that) get left unconfigured. Not
It only has to do minimal setup on them. If the BIOS calls are polled then
assigning an IRQ is quite optional
The only way a
The only way a motherboard BIOS would know if the PCI BIOS used polling
methods instead of interrupt methods is if it was a built in device. For all
Such as the motherboard IDE ?
for all bootable devices on the system, regardless of PnPOS settings. Name
one concrete example of a
>I have a dual ppro 200MHZ W6LI motherboard. I put 2.4.4-ac5 on last
>night, and the machine hung at Freeing unused Kernel memory. I
>selectively backed off what I thought were relevant patches. I got to
>aic7xxx, and ac5 without it worked. I attached /proc/scsi/aic7xxx/0.
This problem was
It works fine on my dual ppro 200 (not sure what mobo). Here is lcpci:
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:06.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev
01)
00:07.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA
It works fine on my dual ppro 200 (not sure what mobo). Here is lcpci:
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:06.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev
01)
00:07.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA
I have a dual ppro 200MHZ W6LI motherboard. I put 2.4.4-ac5 on last
night, and the machine hung at Freeing unused Kernel memory. I
selectively backed off what I thought were relevant patches. I got to
aic7xxx, and ac5 without it worked. I attached /proc/scsi/aic7xxx/0.
This problem was fixed
28 matches
Mail list logo
