HI,
also with 2.5.7, as with 2.5.6, I have problems at boot.
I get the usual oops while initialising IDE.
my ide controller is:
00:1f.1 IDE interface: Intel Corporation 82801AA IDE (rev 02) (prog-if 80
[Master])
Subsystem: Intel Corporation 82801AA IDE
Flags: bus master, medium devsel, latency 0
I/O ports at 2460 [size=16]
unfortunatelly, I do not have even the time to write down oops message,
but eip is c0135068, but then I do not find a similar entry in system.map
any hint
my rootfs in reiserFS, but i do not even reach the mount ...
Luigi Genoni wrote:
> HI,
>
> also with 2.5.7, as with 2.5.6, I have problems at boot.
> I get the usual oops while initialising IDE.
>
> my ide controller is:
>
> 00:1f.1 IDE interface: Intel Corporation 82801AA IDE (rev 02) (prog-if 80
> [Master])
> Subsystem: Intel Corporation 82801AA IDE
> Flags: bus master, medium devsel, latency 0
> I/O ports at 2460 [size=16]
>
> unfortunatelly, I do not have even the time to write down oops message,
> but eip is c0135068, but then I do not find a similar entry in system.map
>
> any hint
The entries found there are just the starting points of functions.
You can therefore look up the function where th oops happens
by looking at the nearest lower number in System.map.
> my rootfs in reiserFS, but i do not even reach the mount ...
That should not matter.
Luigi Genoni wrote:
> HI,
>
> also with 2.5.7, as with 2.5.6, I have problems at boot.
> I get the usual oops while initialising IDE.
>
> my ide controller is:
>
> 00:1f.1 IDE interface: Intel Corporation 82801AA IDE (rev 02) (prog-if 80
> [Master])
> Subsystem: Intel Corporation 82801AA IDE
> Flags: bus master, medium devsel, latency 0
> I/O ports at 2460 [size=16]
>
> unfortunatelly, I do not have even the time to write down oops message,
> but eip is c0135068, but then I do not find a similar entry in system.map
>
> any hint
This device is behaving quite like the 440MX chipset
I have myself I can't therefore the oops expect beeing caused
by a trivial programming error in the actual ide driver.
I don't see much pointer acces in piix.c code as well.
However you could eventually just try apply the following
pseudo diff to piix.c and then try again:
-
{ PCI_DEVICE_ID_INTEL_82801AA_1, PIIX_UDMA_66 | PIIX_PINGPONG },
+
{ PCI_DEVICE_ID_INTEL_82801AA_1, PIIX_UDMA_66 },
Replaceing PIIX_UDMA_33 with PIIX_UDMA_33 could be worth a try as well.
On Tue, Mar 19, 2002 at 06:09:29PM +0100, Martin Dalecki wrote:
> Luigi Genoni wrote:
> >HI,
> >
> >also with 2.5.7, as with 2.5.6, I have problems at boot.
> >I get the usual oops while initialising IDE.
> >
> >my ide controller is:
> >
> >00:1f.1 IDE interface: Intel Corporation 82801AA IDE (rev 02) (prog-if 80
> >[Master])
> > Subsystem: Intel Corporation 82801AA IDE
> > Flags: bus master, medium devsel, latency 0
> > I/O ports at 2460 [size=16]
> >
> >unfortunatelly, I do not have even the time to write down oops message,
> >but eip is c0135068, but then I do not find a similar entry in system.map
> >
> >any hint
>
> This device is behaving quite like the 440MX chipset
> I have myself I can't therefore the oops expect beeing caused
> by a trivial programming error in the actual ide driver.
> I don't see much pointer acces in piix.c code as well.
>
> However you could eventually just try apply the following
> pseudo diff to piix.c and then try again:
>
> -
> { PCI_DEVICE_ID_INTEL_82801AA_1, PIIX_UDMA_66 | PIIX_PINGPONG },
> +
> { PCI_DEVICE_ID_INTEL_82801AA_1, PIIX_UDMA_66 },
>
> Replaceing PIIX_UDMA_33 with PIIX_UDMA_33 could be worth a try as well.
>
replace what with what?
This did not work, nor with DMA_66 neighter with DMA_33
On Tue, 19 Mar 2002, Martin Dalecki wrote:
> Luigi Genoni wrote:
> > HI,
> >
> > also with 2.5.7, as with 2.5.6, I have problems at boot.
> > I get the usual oops while initialising IDE.
> >
> > my ide controller is:
> >
> > 00:1f.1 IDE interface: Intel Corporation 82801AA IDE (rev 02) (prog-if 80
> > [Master])
> > Subsystem: Intel Corporation 82801AA IDE
> > Flags: bus master, medium devsel, latency 0
> > I/O ports at 2460 [size=16]
> >
> > unfortunatelly, I do not have even the time to write down oops message,
> > but eip is c0135068, but then I do not find a similar entry in system.map
> >
> > any hint
>
> This device is behaving quite like the 440MX chipset
> I have myself I can't therefore the oops expect beeing caused
> by a trivial programming error in the actual ide driver.
> I don't see much pointer acces in piix.c code as well.
>
> However you could eventually just try apply the following
> pseudo diff to piix.c and then try again:
>
> -
> { PCI_DEVICE_ID_INTEL_82801AA_1, PIIX_UDMA_66 | PIIX_PINGPONG },
> +
> { PCI_DEVICE_ID_INTEL_82801AA_1, PIIX_UDMA_66 },
>
> Replaceing PIIX_UDMA_33 with PIIX_UDMA_33 could be worth a try as well.
>
>
>
>
that is: __get_hash_table
On Tue, 19 Mar 2002, Martin Dalecki wrote:
> Luigi Genoni wrote:
> > HI,
> >
> > also with 2.5.7, as with 2.5.6, I have problems at boot.
> > I get the usual oops while initialising IDE.
> >
> > my ide controller is:
> >
> > 00:1f.1 IDE interface: Intel Corporation 82801AA IDE (rev 02) (prog-if 80
> > [Master])
> > Subsystem: Intel Corporation 82801AA IDE
> > Flags: bus master, medium devsel, latency 0
> > I/O ports at 2460 [size=16]
> >
> > unfortunatelly, I do not have even the time to write down oops message,
> > but eip is c0135068, but then I do not find a similar entry in system.map
> >
> > any hint
>
> The entries found there are just the starting points of functions.
> You can therefore look up the function where th oops happens
> by looking at the nearest lower number in System.map.
>
> > my rootfs in reiserFS, but i do not even reach the mount ...
>
> That should not matter.
>
Luigi Genoni wrote:
> that is: __get_hash_table
The only code which could use this can propably be
the partition table grocking code!
So apparently the driver is oopsing on the first actual transfer attempts.
By the way I have found the following on my desktop system:
00:1f.1 IDE interface: Intel Corporation 82801AA IDE (rev 02) (prog-if 80 [Master])
Subsystem: Intel Corporation 82801AA IDE
Flags: bus master, medium devsel, latency 0
I/O ports at 1020 [size=16]
So heck this is precisely the same chipset as yours!
And I'm writing this message exactly on very this system!
However what may be significant is the following:
VFS: Diskquotas version dquot_6.4.0 initialized
Journalled Block Device driver loaded
pty: 2048 Unix98 ptys configured
Real Time Clock Driver v1.11
block: 256 slots per queue, batch=32
Uniform Multi-Platform E-IDE driver ver.:7.0.0
ide: system bus speed 33MHz
Intel Corp. 82801AA IDE: IDE controller on PCI slot 00:1f.1
Intel Corp. 82801AA IDE: chipset revision 2
Intel Corp. 82801AA IDE: not 100% native mode: will probe irqs later
PIIX: Intel Corp. 82801AA IDE UDMA66 controller on pci00:1f.1
ide0: BM-DMA at 0x1020-0x1027, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x1028-0x102f, BIOS settings: hdc:pio, hdd:DMA
hda: IBM-DPTA-372050, ATA DISK drive
hdc: IOMEGA ZIP 100 ATAPI, ATAPI FLOPPY drive
hdd: LTN485S, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
blk: queue c02c076c, I/O limit 4095Mb (mask 0xffffffff)
hda: 40088160 sectors (20525 MB) w/1961KiB Cache, CHS=39770/16/63, UDMA(66)
Partition check:
hda: hda1 hda2
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 2048 buckets, 16Kbytes
Could you please just underline where the oops occurs above?
I would rather expect it to happen before the Parition check part.
Please note as well that the only single real disk in this system
is enabled to do UDMA by default. What's the status of yours?
It could well be that the PIO code is the culprit here.
Do you have the ATA floppy driver enabled?
I use a setup on this system where everything with the exception of
hard disks is compiled as module.
On Tue, 19 Mar 2002, Martin Dalecki wrote:
> Luigi Genoni wrote:
> > that is: __get_hash_table
>
> The only code which could use this can propably be
> the partition table grocking code!
> So apparently the driver is oopsing on the first actual transfer attempts.
> By the way I have found the following on my desktop system:
>
>
> 00:1f.1 IDE interface: Intel Corporation 82801AA IDE (rev 02) (prog-if 80 [Master])
> Subsystem: Intel Corporation 82801AA IDE
> Flags: bus master, medium devsel, latency 0
> I/O ports at 1020 [size=16]
>
>
> So heck this is precisely the same chipset as yours!
> And I'm writing this message exactly on very this system!
>
> However what may be significant is the following:
>
> VFS: Diskquotas version dquot_6.4.0 initialized
> Journalled Block Device driver loaded
> pty: 2048 Unix98 ptys configured
> Real Time Clock Driver v1.11
> block: 256 slots per queue, batch=32
> Uniform Multi-Platform E-IDE driver ver.:7.0.0
> ide: system bus speed 33MHz
> Intel Corp. 82801AA IDE: IDE controller on PCI slot 00:1f.1
> Intel Corp. 82801AA IDE: chipset revision 2
> Intel Corp. 82801AA IDE: not 100% native mode: will probe irqs later
> PIIX: Intel Corp. 82801AA IDE UDMA66 controller on pci00:1f.1
> ide0: BM-DMA at 0x1020-0x1027, BIOS settings: hda:DMA, hdb:pio
> ide1: BM-DMA at 0x1028-0x102f, BIOS settings: hdc:pio, hdd:DMA
> hda: IBM-DPTA-372050, ATA DISK drive
> hdc: IOMEGA ZIP 100 ATAPI, ATAPI FLOPPY drive
> hdd: LTN485S, ATAPI CD/DVD-ROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> blk: queue c02c076c, I/O limit 4095Mb (mask 0xffffffff)
> hda: 40088160 sectors (20525 MB) w/1961KiB Cache, CHS=39770/16/63, UDMA(66)
> Partition check:
> hda: hda1 hda2
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP
> IP: routing cache hash table of 2048 buckets, 16Kbytes
>
> Could you please just underline where the oops occurs above?
Intel Corp. 82801AA IDE: IDE controller on PCI slot 00:1f.1
Intel Corp. 82801AA IDE: chipset revision 2
Intel Corp. 82801AA IDE: not 100% native mode: will probe irqs later
PIIX: Intel Corp. 82801AA IDE UDMA66 controller on pci00:1f.1
wait a couple of seconds
ide0: BM-DMA at 0x1020-0x1027, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x1028-0x102f, BIOS settings: hdc:pio, hdd:DMA
OOPS!!
>
> I would rather expect it to happen before the Parition check part.
>
> Please note as well that the only single real disk in this system
> is enabled to do UDMA by default. What's the status of yours?
> It could well be that the PIO code is the culprit here.
I have just hdam which is configured to use DMA66 as default, as I can see
from 2.4.18 boot messages.
Then i have an ATA cdrom on hdc.
>
> Do you have the ATA floppy driver enabled?
no
> I use a setup on this system where everything with the exception of
> hard disks is compiled as module.
me too.
Tomorrow I will provide more details on the disk. I use DMA as default,
and not PIO.
Luigi
Luigi Genoni wrote:
>
> On Tue, 19 Mar 2002, Martin Dalecki wrote:
>
>
>>Luigi Genoni wrote:
>>
>>>that is: __get_hash_table
OK I have been looking that the correspodning function
and found it only to be related to filesystem super-block
operations as well as buffer_head manipulation... Quite
out of order if you ask me. So the chances are that there
are just particular problems with your compiler/build
In esp. fs/buffer is the only place where it get's used!
/fs/buffer.c:struct buffer_head * __get_hash_table(struct block_device *bdev,
sector_t block, int size)
./fs/buffer.c: bh = __get_hash_table(bdev, block, size);
./fs/buffer.c: old_bh = __get_hash_table(bh->b_bdev, bh->b_blocknr, bh->b_size);
Let me guess: You root partition is on a ReiserFS?
yes, as I said at the beginning
On Wed, 20 Mar 2002, Martin Dalecki wrote:
> Luigi Genoni wrote:
> >
> > On Tue, 19 Mar 2002, Martin Dalecki wrote:
> >
> >
> >>Luigi Genoni wrote:
> >>
> >>>that is: __get_hash_table
>
> OK I have been looking that the correspodning function
> and found it only to be related to filesystem super-block
> operations as well as buffer_head manipulation... Quite
> out of order if you ask me. So the chances are that there
> are just particular problems with your compiler/build
>
> In esp. fs/buffer is the only place where it get's used!
>
> /fs/buffer.c:struct buffer_head * __get_hash_table(struct block_device *bdev,
> sector_t block, int size)
> ./fs/buffer.c: bh = __get_hash_table(bdev, block, size);
> ./fs/buffer.c: old_bh = __get_hash_table(bh->b_bdev, bh->b_blocknr, bh->b_size);
>
> Let me guess: You root partition is on a ReiserFS?
>
> -
> 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/
>
Luigi Genoni wrote:
> yes, as I said at the beginning
>
Ohhh... I did miss this apparently...
OK. Anyway I'm quite confident that *this* particular
flaw is nto caused by the ICH host chip code but by a dance between Hand and
Alexander... instead.
Maybe you are right.
I tested a 2.5 kernel with another server with scsi adaptec, and
it worked with ext2 but oops while mounting reiserFS.
It seems that a lot of users had oops mounting reiserFS with 2.5.6, but
then a patch fixed that. Now I think this patch is in 2.5.7, (it should),
but there are other changes i think to reiserFS code. So i have other
oopses.
I think this could be a proof of a reiserFS bug.
If people at namesys need it (maybe they already know this, and have a
patch to try), tomorrow i will post the oop mounting
reiserFS.
Luigi
On Wed, 20 Mar 2002, Martin Dalecki wrote:
> Luigi Genoni wrote:
> > yes, as I said at the beginning
> >
>
> Ohhh... I did miss this apparently...
>
> OK. Anyway I'm quite confident that *this* particular
> flaw is nto caused by the ICH host chip code but by a dance between Hand and
> Alexander... instead.
>
> -
> 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/
>