I now see that PCI_DEVICE_ID_INTEL_82801DB_11 has been inserted
into pci_ids.h, ide-pci.c and piix.c of kernel-source-2.4.19-15mdk,
as prescribed in Andre's "mini-patch", so this cannot be the problem.
The error in dmesg reads:
ICH4: (ide_setup_pci_device:) Could not enable device.
This string is found in ide-pci.c:
if (pci_enable_device(dev)) {
printk(KERN_WARNING "%s: (ide_setup_pci_device:) Could
not enable device.\n", d->name);
return;
}
pci_enable_device calls pci_enable_device_bars in pci.c:
pci_enable_device(struct pci_dev *dev)
{
return pci_enable_device_bars(dev, 0x3F);
}
pci_enable_device_bars calls pcibios_enable_device in pci.c:
pci_enable_device_bars(struct pci_dev *dev, int bars)
{
int err;
pci_set_power_state(dev, 0);
if ((err = pcibios_enable_device(dev, bars)) < 0)
return err;
return 0;
}
pcibios_enable_device calls pcibios_enable_resources in pci-pc.c:
int pcibios_enable_device(struct pci_dev *dev, int mask)
{
int err;
if ((err = pcibios_enable_resources(dev, mask)) < 0)
return err;
pcibios_enable_irq(dev);
return 0;
}
pcibios_enable_resources is defined in
The problem happens in this code:
pci_read_config_word(dev, PCI_COMMAND, &cmd);
old_cmd = cmd;
for(idx=0; idx<6; idx++) {
/* Only set up the requested stuff */
if (!(mask & (1<<idx)))
continue;
r = &dev->resource[idx];
if (!r->start && r->end) {
printk(KERN_ERR "PCI: Device %s not available
because of resource collisions\n", dev->slot_name);
return -EINVAL;
}
if (r->flags & IORESOURCE_IO)
cmd |= PCI_COMMAND_IO;
if (r->flags & IORESOURCE_MEM)
cmd |= PCI_COMMAND_MEMORY;
}
It does look as if the device has not been properly initialized.
What am I supposed to do? Write angry emails to ASUS?
We did update to the latest stable BIOS for P4B533.
There is a new beta version of the BIOS; but I am not
going to use a beta version.
Bjarne Thomsen
On Sun, 2002-09-22 at 09:20, Bjarne Thomsen wrote:
> I adviced a friend to buy a PC based on Intel chipsets because of
> problems I have seen with some AMD chipsets.
> Little did I know that there was a problem with 845G.
> It is not absolutely necessary that this is solved before
> the release of 9.0, but I certainly hope that it will be
> shortly after. The situation is quite frustrating considering
> the problem has already been solved by Andre Hedrick.
>
> Below, I have pasted the following dialogue from the kernel list.
>
> -- Bjarne Thomsen
>
> From: Kjartan Maraas ([EMAIL PROTECTED])
> Date: Mon Jun 03 2002 - 14:49:26 EEST
> > If you look at why it fails it fails not because it isnt in the table
> > but because the PCI device has not been allocated resources
> > properly by the BIOS
> >
>
> Back when I talked to Andre about this problem it sounded to me like he
> said it was a genuine bug that was fixed in the ide-convert patches.
> Maybe I'm confusing two issues here...
>
> Cheers
> Kjartan
>
> From: Andre Hedrick ([EMAIL PROTECTED])
> Date: Mon Jun 03 2002 - 13:10:10 EEST
> Kjartan,
>
> Please do not confuse them, they have a hard enough time reading.
> The docs state it can only do X, but lets overclock it and do X+1.
> Maybe the hardware is smart and knows which drivers are safe and sane.
>
> Anthony, I sent you a mini-patch to add the 845G to the sane driver.
> It will work, as Kjartan has stated. His system suffered the exact same
> events.
>
> Cheers,
>
> Andre Hedrick
> LAD Storage Consulting Group
>
> From: Anthony Spinillo ([EMAIL PROTECTED])
> Date: Tue Jun 04 2002 - 02:35:31 EEST
>
> I just tried Andre's patch. I applied it on top of 2.4.19pre9-ac3.
> (Patch attached below.) It pulled me up to DMA.
> I tested by setting hdparm -d1 /dev/hdc (my DVD drive) and played
> a DVD with Xine. It played great!
>
> I do not have an IDE hard drive to test, since my HD is SCSI.
>
> I will try Vojtech's patch next, and report in.
>
> Thanks for all your help! (Andre, Vojtech, JeffN and everyone else.)
>
> Tony
>
>
>
> On Sun, 2002-09-22 at 04:53, Ben Reser wrote:
> > On Sun, Sep 22, 2002 at 02:38:06AM +0000, SI Reasoning wrote:
> > > I have heard this argument before but don't buy it. I am not talking about
>waiting
> > > years here... Just taking the time to release the product when it is ready
>instead
> > > of forcing a deadline. Mandrake 8.2 was released despite a known serious issue
>with
> > > smb with the kernel. That was something that definately should have been fixed
> > > before release. This is not to say you don't aim for a deadline, but even
>Microsoft
> > > will fearlessly delay release, often for months.
> >
> > Start paying attention. 9.0 was supposed to be released last week. It
> > got pushed back a week to fix an issue. But you're arguing that we
> > should delay it so we can fix some guys error where the kernel doesn't
> > think he has a PS/2 mouse port and nobody else has seen this issue. For
> > all we know fixing his issue will break something for a huge group of
> > people.
> >
> > Sometimes fixing things for one thing will break things for other
> > people. Take for instance the machines that don't turn themselves off.
> > Apparently this has something to do with the Mandrake kernel not having
> > ACPI support in it. But if we enable ACPI support then other people
> > will have even worse problems.
> >
> > Face it. There will be bugs and there will be tradeoffs. Mandrake does
> > the best that they can.
> >
> > --
> > Ben Reser <[EMAIL PROTECTED]>
> > http://ben.reser.org
> >
> > Never take no as an answer from someone who isn't authorized to say yes.
> >
>
>
>
