Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[rwhron]

It sounds like Jens and Martin have a handle on this
already.  Just in case this helps.  No modules.  

Oops on 2.5.9 at boot time.

Here is the last part of the boot message:

Uniform Multi-Platform E-IDE driver ver.:7.0.0
ide: system bus speed 33MHz
VIA Technologies, Inc. Bus Master IDE: IDE controller on PCI slot 00:07.1
VIA Technologies, Inc. Bus Master IDE: chipset revision 6
VIA Technologies, Inc. Bus Master IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c586b (rev 47) IDE UDMA33 controller on pci00:07.1
    ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:DMA
hda: Maxtor 51536U3, ATA DISK drive
hdb: ATAPI CDROM, ATAPI CD/DVD-ROM drive
hdc: Maxtor 52049U4, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide: unexpected interrupt 0 14
hda: 30015216 sectors (15368 MB) w/2048KiB Cache, CHS=29777/16/63, UDMA(33)
ide: unexpected interrupt 1 15
hdc: 40020624 sectors (20491 MB) w/2048KiB Cache, CHS=39703/16/63, UDMA(33)
ide: unexpected interrupt 0 14
(oops here)


ksymoops output

No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Unable to handle kernel NULL pointer dereference at virtual address 00000004
c01bf5f6
*pde = 00000000
Oops: 0002
CPU:    0
EIP:    0010:[<c01bf5f6>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010002
eax: 00000004   ebx: d7f61eb4   ecx: 00000001   edx: 00000000
esi: d7f61e30   edi: c02c8b6c   ebp: 00000292   esp: c026bedc
ds: 0018   es: 0018   ss: 0018
Stack: d7f61e30 00000001 c02c8b6c 00000003 00000001 c01c2f1b c02c8b6c 00000001
       00000000 c01c9a52 c02c8b6c 00000001 00000018 d7f61eb4 d7f61e30 c01ca783
       c02c8b6c 00000001 00000000 c02c8b6c d7f622c0 c02c8840 c02c8f0c d7f62380
Call Trace: [<c01c2f1b>] [<c01c9a52>] [<c01ca783>] [<c01c11ba>] [<c01ca6bc>]
   [<c01080fc>] [<c0108262>] [<c0105000>] [<c0106eff>] [<c0105240>] [<c0105000>]
   [<c0105263>] [<c01052d4>] [<c0105019>]
Code: c7 04 02 00 00 00 00 8b 53 0c 8b 87 34 02 00 00 0f b3 10 8b


>>EIP; c01bf5f6 <__ide_end_request+fe/140>   <=====

>>ebx; d7f61eb4 <END_OF_CODE+17c930f8/????>
>>esi; d7f61e30 <END_OF_CODE+17c93074/????>
>>edi; c02c8b6c <ide_hwifs+32c/3a70>
>>esp; c026bedc <init_thread_union+1edc/2000>

Trace; c01c2f1b <ide_end_request+f/14>
Trace; c01c9a52 <cdrom_end_request+42/4c>
Trace; c01ca783 <cdrom_pc_intr+c7/1d0>
Trace; c01c11ba <ide_intr+c6/13c>
Trace; c01ca6bc <cdrom_pc_intr+0/1d0>
Trace; c01080fc <handle_IRQ_event+30/5c>
Trace; c0108262 <do_IRQ+6a/a8>
Trace; c0105000 <_stext+0/0>
Trace; c0106eff <common_interrupt+1f/30>
Trace; c0105240 <default_idle+0/28>
Trace; c0105000 <_stext+0/0>
Trace; c0105263 <default_idle+23/28>
Trace; c01052d4 <cpu_idle+28/38>
Trace; c0105019 <rest_init+19/1c>

Code;  c01bf5f6 <__ide_end_request+fe/140>
00000000 <_EIP>:
Code;  c01bf5f6 <__ide_end_request+fe/140>   <=====
   0:   c7 04 02 00 00 00 00      movl   $0x0,(%edx,%eax,1)   <=====
Code;  c01bf5fd <__ide_end_request+105/140>
   7:   8b 53 0c                  mov    0xc(%ebx),%edx
Code;  c01bf600 <__ide_end_request+108/140>
   a:   8b 87 34 02 00 00         mov    0x234(%edi),%eax
Code;  c01bf606 <__ide_end_request+10e/140>
  10:   0f b3 10                  btr    %edx,(%eax)
Code;  c01bf609 <__ide_end_request+111/140>
  13:   8b 00                     mov    (%eax),%eax

 <0>Kernel panic: Aiee, killing interrupt handler!

This config has been working with other kernels, including 2.5.8.

grep ^CONFIG .config
CONFIG_X86=y
CONFIG_ISA=y
CONFIG_UID16=y
CONFIG_EXPERIMENTAL=y
CONFIG_NET=y
CONFIG_SYSVIPC=y
CONFIG_SYSCTL=y
CONFIG_MK6=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_TSC=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_BLK_DEV_FD=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_IDEDMA_AUTO=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_NET_PCI=y
CONFIG_8139TOO=y
CONFIG_SOUND_GAMEPORT=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=64
CONFIG_REISERFS_FS=y
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=y
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_EXT2_FS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_MSDOS_PARTITION=y
CONFIG_VGA_CONSOLE=y
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y

lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3] (rev 04)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 47)
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 02)
00:07.3 Host bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10)
00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)
01:00.0 VGA compatible controller: nVidia Corporation Vanta [NV6] (rev 15)

-- 
Randy Hron

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[Martin Dalecki]

Uz.ytkownik rwhron@earthlink.net napisa?:
> It sounds like Jens and Martin have a handle on this
> already.  Just in case this helps.  No modules.  

Yeep.

> Oops on 2.5.9 at boot time.

That is indeed a bit surprising. In esp. since the oops happens at boot time.
Maybe some goot order problem.
Could you please introduce two printk("BANG\n") printk("BOOM\n")
aroung the ata_ar_get() in ide-cd? Just to see whatever the
command queue is already up and initialized.

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[Melchior FRANZ]

* Martin Dalecki -- Wednesday 24 April 2002 10:15:
> Could you please introduce two printk("BANG\n") printk("BOOM\n")
> aroung the ata_ar_get() in ide-cd? Just to see whatever the
> command queue is already up and initialized.

I mentioned already yesterday, that I have exactly the same oops.
So I added several printk's and found out that it isn't really the
if-branch with the ata_ar_get, that is executed immediately before
the oops. (Neither of your suggested messages is reached.)
   It's rather that ide_cdrom_do_request is entered with rq->falgs=0x420
and hence the following branch called:

        } else if (rq->flags & (REQ_PC | REQ_SENSE)) {
                return cdrom_do_packet_command(drive);

m.



BTW: I'm using the same VIA IDE PIC controller like Randy. But it
   worked with all stable releases and all unstable until 2.5.9.

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[Linus Torvalds]

In article <20020425173439.GM3542@suse.de>, Jens Axboe  <axboe@suse.de> wrote:
>On Thu, Apr 25 2002, Jens Axboe wrote:
>> - Make the ata_request the general means of passing down request in the
>>   IDE layer -- start by making hwgroup->rq into hwgroup->ar and _never_
>>   store ar in ->special (you don't have to, you will always just go from
>>   ar -> rq, which is of course ar->ar_rq). This is what I wanted to do.
>
>I'll do this on monday, I'm away friday and through the weekend. Lets
>get this fixed _properly_.

The only _proper_ fix is to not abuse "special" at all. Mid-level layers
simpyl should not use it.

Please don't use "special" for mid-level things that clash like this. 
There are real reasons why Linux tries hard to avoid stupidly overloaded
"void *" things, and if IDE is to be cleaned up (which I sure hope), it
should NOT use "special" at all.

And it should _definitely_ not use it for multiple different things,
depending on what kind of disk it is.  Checking whether the target is a
disk or a CD is _absolutely_ the wrong thing to do, and will just make
the code continue the current mistake of now being able to integrate the
packet command stuff between them. 

Jens, please don't make it worse. Add a new field if you have to, with a
proper type, don't overload crap.

		Linus

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[Jens Axboe]

On Thu, Apr 25 2002, Jens Axboe wrote:
> - Make the ata_request the general means of passing down request in the
>   IDE layer -- start by making hwgroup->rq into hwgroup->ar and _never_
>   store ar in ->special (you don't have to, you will always just go from
>   ar -> rq, which is of course ar->ar_rq). This is what I wanted to do.

I'll do this on monday, I'm away friday and through the weekend. Lets
get this fixed _properly_.

-- 
Jens Axboe

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[Jens Axboe]

On Thu, Apr 25 2002, Martin Dalecki wrote:
> Uz.ytkownik Jens Axboe napisa?:
> >On Wed, Apr 24 2002, Martin Dalecki wrote:
> 
> >>OK I assume that the oops happens inside the ide-scsi module.
> >>This will be fixed in one of the forthcomming patch sets.
> >
> >
> >Are you sure this isn't just due to ->special being set, and
> >ide_end_request() assuming it's an ar? From ide-cd, that is.
> 
> 
> Yes I know it's all the same. However unfortunately
> it's *not easy* to back out the ->special use from
> the drivers that do it. We have the following sutuation:
> 
> 1. Generic BIO code checking for ->special and deciding whatever
> it should trying to merge request or not.
> 
> 2. Gneric ATA code setting ->special for ata_request passing.
> 
> 3. CD-ROM ATAPI code using ->special for passing packet commands
> and failed commands.
> 
> 4. ide-scsi using it for the same purspose as CD-ROM
> 
> 5. ide-floppy not using it at all buf abusing the ->buffer member
>    for precisely the same purpose.
> 
> And unfortunately there is *no* easy solution for any of the
> above circumstances without breaking far too many things.

You don't _have_ to back out the ->special usage. As I mentioned, it was
always just a quick hack for ide-disk so I didn't have to change every
single driver out there.

There are two options, as I see it:

- Keep ata_request as an ide-disk speciality. This is pretty trivial
  even though other drivers use ->special, because the ata_ar_put()
  path simply needs to do

	struct ata_request *ar = rq->special;

	if (ar && drive->media == ide_disk)
		ata_ar_put(ar);

  and that is it.

- Make the ata_request the general means of passing down request in the
  IDE layer -- start by making hwgroup->rq into hwgroup->ar and _never_
  store ar in ->special (you don't have to, you will always just go from
  ar -> rq, which is of course ar->ar_rq). This is what I wanted to do.

> The conclusion simply is: unless the above issues are fixed
> the TCQ stuff has simply to be backed out again anbd live
> separately from the main code chain. :-(.

If you didn't persist on pushing half-done stuff to Linus all the time,
I would have had the time to implement this properly... Now you keep
doing hackish work-arounds to make things limp along. So please calm
down for a moment, sick back, and think about it. It's a heck of a lot
better than going full throttle with an axe.

-- 
Jens Axboe

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[Martin Dalecki]

Uz.ytkownik Jens Axboe napisa?:
> On Wed, Apr 24 2002, Martin Dalecki wrote:

>>OK I assume that the oops happens inside the ide-scsi module.
>>This will be fixed in one of the forthcomming patch sets.
> 
> 
> Are you sure this isn't just due to ->special being set, and
> ide_end_request() assuming it's an ar? From ide-cd, that is.


Yes I know it's all the same. However unfortunately
it's *not easy* to back out the ->special use from
the drivers that do it. We have the following sutuation:

1. Generic BIO code checking for ->special and deciding whatever
it should trying to merge request or not.

2. Gneric ATA code setting ->special for ata_request passing.

3. CD-ROM ATAPI code using ->special for passing packet commands
and failed commands.

4. ide-scsi using it for the same purspose as CD-ROM

5. ide-floppy not using it at all buf abusing the ->buffer member
    for precisely the same purpose.

And unfortunately there is *no* easy solution for any of the
above circumstances without breaking far too many things.

The conclusion simply is: unless the above issues are fixed
the TCQ stuff has simply to be backed out again anbd live
separately from the main code chain. :-(.

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[rwhron]

>> > > Oops on 2.5.9 at boot time.

> Look, the problem is easy. Backout the changes to ide_cdrom_do_request()
> and cdrom_start_read(), then re-add the
> 
>        HWGROUP(drive)->rq->special = NULL;
>
> in cdrom_end_request() before calling ide_end_request()
>
> Something ala, completely untested (not even compiled). See the thread
> about the ide-cd changes being broken.

That works!  Applied to 2.5.10, compiled and booted.
Mounted a cdrom and that works too.

Thanks!
-- 
Randy Hron

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[Martin Dalecki]

Uz.ytkownik rwhron@earthlink.net napisa?:
>>>>>Oops on 2.5.9 at boot time.
>>>>
> 
>>Look, the problem is easy. Backout the changes to ide_cdrom_do_request()
>>and cdrom_start_read(), then re-add the
>>
>>       HWGROUP(drive)->rq->special = NULL;
>>
>>in cdrom_end_request() before calling ide_end_request()
>>
>>Something ala, completely untested (not even compiled). See the thread
>>about the ide-cd changes being broken.
> 
> 
> That works!  Applied to 2.5.10, compiled and booted.
> Mounted a cdrom and that works too.
> 
> Thanks!

Yes but if you look at ide_start_dma() in ide-dma.c you will notice
that the if (!ar) path is taken, which will cause fallback from
DMA to PIO transfer:

/*
  * Start DMA engine.
  */
int ide_start_dma(struct ata_channel *hwif, ide_drive_t *drive, ide_dma_action_t 
func)
{
	unsigned int reading = 0, count;
	unsigned long dma_base = hwif->dma_base;
	struct ata_request *ar = IDE_CUR_AR(drive);

	/* This can happen with drivers abusing the special request field.
	 */

	if (!ar) {
		printk(KERN_ERR "DMA without ATA request\n");

		return 1;
	}





-- 
- phone: +49 214 8656 283
- job:   eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!)
- langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[Martin Dalecki]

Uz.ytkownik Jens Axboe napisa?:
> On Wed, Apr 24 2002, rwhron@earthlink.net wrote:
> 
>>>>Oops on 2.5.9 at boot time.
>>>
>>>Could you please introduce two printk("BANG\n") printk("BOOM\n")
>>>aroung the ata_ar_get() in ide-cd? Just to see whatever the
>>>command queue is already up and initialized.
>>
>>This may not be what you wanted:
>>
>>	printk("BANG\n");
>>        ar = ata_ar_get(drive);
>>        printk("BOOM\n");
>>
>>If it is, neither BANG nor BOOM printed before oops.
> 
> 
> Look, the problem is easy. Backout the changes to ide_cdrom_do_request()
> and cdrom_start_read(), then re-add the
> 
> 	HWGROUP(drive)->rq->special = NULL;
> 
> in cdrom_end_request() before calling ide_end_request()
> 
> Something ala, completely untested (not even compiled). See the thread
> about the ide-cd changes being broken.
> 

Jens - this is *not going to work* becouse the DMA methods are
expecting an full ata_request right now.

Uunfortunately pulling the whole ata_ar_get() stuff one
level up to the ide.c file where ->do_request get's called
doesn't work right now.

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[Jens Axboe]

On Wed, Apr 24 2002, rwhron@earthlink.net wrote:
> >> Oops on 2.5.9 at boot time.
> 
> > Could you please introduce two printk("BANG\n") printk("BOOM\n")
> > aroung the ata_ar_get() in ide-cd? Just to see whatever the
> > command queue is already up and initialized.
> 
> This may not be what you wanted:
> 
> 	printk("BANG\n");
>         ar = ata_ar_get(drive);
>         printk("BOOM\n");
> 
> If it is, neither BANG nor BOOM printed before oops.

Look, the problem is easy. Backout the changes to ide_cdrom_do_request()
and cdrom_start_read(), then re-add the

	HWGROUP(drive)->rq->special = NULL;

in cdrom_end_request() before calling ide_end_request()

Something ala, completely untested (not even compiled). See the thread
about the ide-cd changes being broken.

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.558   -> 1.559  
#	drivers/ide/ide-cd.c	1.35    -> 1.36   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/04/24	axboe@burns.home.kernel.dk	1.559
# "fix" rq->special and ar usage, needs proper fixing
# --------------------------------------------
#
diff -Nru a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
--- a/drivers/ide/ide-cd.c	Wed Apr 24 15:32:59 2002
+++ b/drivers/ide/ide-cd.c	Wed Apr 24 15:32:59 2002
@@ -558,10 +558,7 @@
 	if ((rq->flags & REQ_CMD) && !rq->current_nr_sectors)
 		uptodate = 1;
 
-#if 0
-	/* FIXME --mdcki */
 	HWGROUP(drive)->rq->special = NULL;
-#endif
 	ide_end_request(drive, uptodate);
 }
 
@@ -1217,22 +1214,13 @@
 /*
  * Start a read request from the CD-ROM.
  */
-static ide_startstop_t cdrom_start_read(struct ata_device *drive, struct ata_request *ar, unsigned int block)
+static ide_startstop_t cdrom_start_read(struct ata_device *drive, unsigned int block)
 {
 	struct cdrom_info *info = drive->driver_data;
-	struct request *rq = ar->ar_rq;
-
-	if (ar->ar_flags & ATA_AR_QUEUED) {
-//		spin_lock_irqsave(DRIVE_LOCK(drive), flags);
-		blkdev_dequeue_request(rq);
-//		spin_unlock_irqrestore(DRIVE_LOCK(drive), flags);
-	}
-
+	struct request *rq = HWGROUP(drive)->rq;
 
 	restore_request(rq);
 
-	rq->special = ar;
-
 	/* Satisfy whatever we can of this request from our cached sector. */
 	if (cdrom_read_from_buffer(drive))
 		return ide_stopped;
@@ -1665,30 +1653,8 @@
 		if (IDE_LARGE_SEEK(info->last_block, block, IDECD_SEEK_THRESHOLD) && drive->dsc_overlap)
 			action = cdrom_start_seek (drive, block);
 		else {
-			unsigned long flags;
-			struct ata_request *ar;
-
-			/*
-			 * get a new command (push ar further down to avoid grabbing lock here
-			 */
-			spin_lock_irqsave(DRIVE_LOCK(drive), flags);
-
-			ar = ata_ar_get(drive);
-
-			/*
-			 * we've reached maximum queue depth, bail
-			 */
-			if (!ar) {
-				spin_unlock_irqrestore(DRIVE_LOCK(drive), flags);
-
-				return ide_started;
-			}
-
-			ar->ar_rq = rq;
-			spin_unlock_irqrestore(DRIVE_LOCK(drive), flags);
-
 			if (rq_data_dir(rq) == READ)
-				action = cdrom_start_read(drive, ar, block);
+				action = cdrom_start_read(drive, block);
 			else
 				action = cdrom_start_write(drive, rq);
 		}

-- 
Jens Axboe

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[rwhron]

>> Oops on 2.5.9 at boot time.

> Could you please introduce two printk("BANG\n") printk("BOOM\n")
> aroung the ata_ar_get() in ide-cd? Just to see whatever the
> command queue is already up and initialized.

This may not be what you wanted:

	printk("BANG\n");
        ar = ata_ar_get(drive);
        printk("BOOM\n");

If it is, neither BANG nor BOOM printed before oops.

I see Melchior may have narrowed down the code path in 
this thread.  

2.5.10 gives very similar oops to 2.5.9:

Unable to handle kernel NULL pointer dereference at virtual address 00000004
c01bf7f6
*pde = 00000000
Oops: 0002
CPU:    0
EIP:    0010:[<c01bf7f6>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010002
eax: 00000004   ebx: d7f61eb4   ecx: 00000001   edx: 00000000
esi: d7f61e30   edi: c02c8b6c   ebp: 00000292   esp: c026bedc
ds: 0018   es: 0018   ss: 0018
Stack: d7f61e30 00000001 c02c8b6c 00000003 00000001 c01c311b c02c8b6c 00000001
       00000000 c01c9c52 c02c8b6c 00000001 00000018 d7f61eb4 d7f61e30 c01ca983
       c02c8b6c 00000001 00000000 c02c8b6c d7f622c0 c02c8840 c02c8f0c d7f62380
Call Trace: [<c01c311b>] [<c01c9c52>] [<c01ca983>] [<c01c13ba>] [<c01ca8bc>]
   [<c01080fc>] [<c0108262>] [<c0105000>] [<c0106eff>] [<c0105240>] [<c0105000>]
   [<c0105263>] [<c01052d4>] [<c0105019>]
Code: c7 04 02 00 00 00 00 8b 53 0c 8b 87 34 02 00 00 0f b3 10 8b


>>EIP; c01bf7f6 <__ide_end_request+fe/140>   <=====

>>ebx; d7f61eb4 <END_OF_CODE+17c930f8/????>
>>esi; d7f61e30 <END_OF_CODE+17c93074/????>
>>edi; c02c8b6c <ide_hwifs+32c/3a70>
>>esp; c026bedc <init_thread_union+1edc/2000>

Trace; c01c311b <ide_end_request+f/14>
Trace; c01c9c52 <cdrom_end_request+42/4c>
Trace; c01ca983 <cdrom_pc_intr+c7/1d0>
Trace; c01c13ba <ide_intr+c6/13c>
Trace; c01ca8bc <cdrom_pc_intr+0/1d0>
Trace; c01080fc <handle_IRQ_event+30/5c>
Trace; c0108262 <do_IRQ+6a/a8>
Trace; c0105000 <_stext+0/0>
Trace; c0106eff <common_interrupt+1f/30>
Trace; c0105240 <default_idle+0/28>
Trace; c0105000 <_stext+0/0>
Trace; c0105263 <default_idle+23/28>
Trace; c01052d4 <cpu_idle+28/38>
Trace; c0105019 <rest_init+19/1c>

Code;  c01bf7f6 <__ide_end_request+fe/140>
00000000 <_EIP>:
Code;  c01bf7f6 <__ide_end_request+fe/140>   <=====
   0:   c7 04 02 00 00 00 00      movl   $0x0,(%edx,%eax,1)   <=====
Code;  c01bf7fd <__ide_end_request+105/140>
   7:   8b 53 0c                  mov    0xc(%ebx),%edx
Code;  c01bf800 <__ide_end_request+108/140>
   a:   8b 87 34 02 00 00         mov    0x234(%edi),%eax
Code;  c01bf806 <__ide_end_request+10e/140>
  10:   0f b3 10                  btr    %edx,(%eax)
Code;  c01bf809 <__ide_end_request+111/140>
  13:   8b 00                     mov    (%eax),%eax

 <0>Kernel panic: Aiee, killing interrupt handler!


-- 
Randy Hron

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[Luigi Genoni]

I had a similar oops loading ide-cd module, without ide-scsi or similar.
EIP is the same, but since loading the module freezes the system, I do not
have a complite oops.
The system il a PentiumIII 512 MB ram,with i810 chipset.
Unfortunatelly all the other test systems I have right now are scsi based
even for the cd reader, so I cannot test on other chipset.



On Wed, 24 Apr 2002, Martin Dalecki wrote:

> U¿ytkownik Miles Lane napisa³:
> > On Tue, 2002-04-23 at 10:39, Miles Lane wrote:
> >
> >>On Tue, 2002-04-23 at 01:00, Martin Dalecki wrote:
> >>
> >>>Miles Lane wrote:
> >>>
> >>>>I should probably add the /proc/ksyms snapshotting stuff to
> >>>>get the module information for you as well.  I hope this
> >>>>current batch of info helps, for starters.
> >>>>
> >>>>ksymoops 2.4.4 on i686 2.4.7-10.  Options used
> >>>>     -v /usr/src/linux/vmlinux (specified)
> >>>>     -K (specified)
> >>>>     -L (specified)
> >>>>     -o /lib/modules/2.5.9/ (specified)
> >>>>     -m /boot/System.map-2.5.9 (specified)
> >>>
> >>>
> >>>Looks like the oops came from module code.
> >>>Which modules did you use: ide-flappy and ide-scsi are still
> >>>in need of the same medication ide-cd got.
> >>
> >>CONFIG_BLK_DEV_IDESCSI=m
> >>CONFIG_SCSI=m
> >>CONFIG_BLK_DEV_SD=m
> >>CONFIG_BLK_DEV_SR=m
> >>CONFIG_CHR_DEV_SG=m
> >
> >
> > Hmm.  You probably need this, too.  Sorry for not sending this
> > in the first reply.
>
>
> OK I assume that the oops happens inside the ide-scsi module.
> This will be fixed in one of the forthcomming patch sets.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[Jens Axboe]

On Wed, Apr 24 2002, Martin Dalecki wrote:
> U?ytkownik Miles Lane napisa?:
> >On Tue, 2002-04-23 at 10:39, Miles Lane wrote:
> >
> >>On Tue, 2002-04-23 at 01:00, Martin Dalecki wrote:
> >>
> >>>Miles Lane wrote:
> >>>
> >>>>I should probably add the /proc/ksyms snapshotting stuff to 
> >>>>get the module information for you as well.  I hope this 
> >>>>current batch of info helps, for starters.
> >>>>
> >>>>ksymoops 2.4.4 on i686 2.4.7-10.  Options used
> >>>>    -v /usr/src/linux/vmlinux (specified)
> >>>>    -K (specified)
> >>>>    -L (specified)
> >>>>    -o /lib/modules/2.5.9/ (specified)
> >>>>    -m /boot/System.map-2.5.9 (specified)
> >>>
> >>>
> >>>Looks like the oops came from module code.
> >>>Which modules did you use: ide-flappy and ide-scsi are still
> >>>in need of the same medication ide-cd got.
> >>
> >>CONFIG_BLK_DEV_IDESCSI=m
> >>CONFIG_SCSI=m
> >>CONFIG_BLK_DEV_SD=m
> >>CONFIG_BLK_DEV_SR=m
> >>CONFIG_CHR_DEV_SG=m
> >
> >
> >Hmm.  You probably need this, too.  Sorry for not sending this
> >in the first reply.
> 
> 
> OK I assume that the oops happens inside the ide-scsi module.
> This will be fixed in one of the forthcomming patch sets.

Are you sure this isn't just due to ->special being set, and
ide_end_request() assuming it's an ar? From ide-cd, that is.

-- 
Jens Axboe

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[Martin Dalecki]

>>OK I assume that the oops happens inside the ide-scsi module.
>>This will be fixed in one of the forthcomming patch sets.
> 
> 
> Are you sure this isn't just due to ->special being set, and
> ide_end_request() assuming it's an ar? From ide-cd, that is.

Yes right. Thank you for reminding me. I will have to
redo the stuff from the "draft" patch I did send you once...

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[Martin Dalecki]

Użytkownik Miles Lane napisał:
> On Tue, 2002-04-23 at 10:39, Miles Lane wrote:
> 
>>On Tue, 2002-04-23 at 01:00, Martin Dalecki wrote:
>>
>>>Miles Lane wrote:
>>>
>>>>I should probably add the /proc/ksyms snapshotting stuff to 
>>>>get the module information for you as well.  I hope this 
>>>>current batch of info helps, for starters.
>>>>
>>>>ksymoops 2.4.4 on i686 2.4.7-10.  Options used
>>>>     -v /usr/src/linux/vmlinux (specified)
>>>>     -K (specified)
>>>>     -L (specified)
>>>>     -o /lib/modules/2.5.9/ (specified)
>>>>     -m /boot/System.map-2.5.9 (specified)
>>>
>>>
>>>Looks like the oops came from module code.
>>>Which modules did you use: ide-flappy and ide-scsi are still
>>>in need of the same medication ide-cd got.
>>
>>CONFIG_BLK_DEV_IDESCSI=m
>>CONFIG_SCSI=m
>>CONFIG_BLK_DEV_SD=m
>>CONFIG_BLK_DEV_SR=m
>>CONFIG_CHR_DEV_SG=m
> 
> 
> Hmm.  You probably need this, too.  Sorry for not sending this
> in the first reply.


OK I assume that the oops happens inside the ide-scsi module.
This will be fixed in one of the forthcomming patch sets.

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[Melchior FRANZ]

* Martin Dalecki -- Tuesday 23 April 2002 10:00:
> Looks like the oops came from module code.
> Which modules did you use: ide-flappy and ide-scsi are still
> in need of the same medication ide-cd got.

I've got the same oops, but I have ide-cd compiled into the kernel, and use
neither ide-scsi nor ide-floppy. It's obviously a ide-cd problem.
(Oops report on request.)

m.

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[Miles Lane]

On Tue, 2002-04-23 at 10:39, Miles Lane wrote:
> On Tue, 2002-04-23 at 01:00, Martin Dalecki wrote:
> > Miles Lane wrote:
> > > I should probably add the /proc/ksyms snapshotting stuff to 
> > > get the module information for you as well.  I hope this 
> > > current batch of info helps, for starters.
> > > 
> > > ksymoops 2.4.4 on i686 2.4.7-10.  Options used
> > >      -v /usr/src/linux/vmlinux (specified)
> > >      -K (specified)
> > >      -L (specified)
> > >      -o /lib/modules/2.5.9/ (specified)
> > >      -m /boot/System.map-2.5.9 (specified)
> > 
> > 
> > Looks like the oops came from module code.
> > Which modules did you use: ide-flappy and ide-scsi are still
> > in need of the same medication ide-cd got.
> 
> CONFIG_BLK_DEV_IDESCSI=m
> CONFIG_SCSI=m
> CONFIG_BLK_DEV_SD=m
> CONFIG_BLK_DEV_SR=m
> CONFIG_CHR_DEV_SG=m

Hmm.  You probably need this, too.  Sorry for not sending this
in the first reply.

CONFIG_IDE=y

#
# ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_BLK_DEV_CMD640=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_AMD74XX=y
CONFIG_IDEDMA_AUTO=y

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[Miles Lane]

On Tue, 2002-04-23 at 01:00, Martin Dalecki wrote:
> Miles Lane wrote:
> > I should probably add the /proc/ksyms snapshotting stuff to 
> > get the module information for you as well.  I hope this 
> > current batch of info helps, for starters.
> > 
> > ksymoops 2.4.4 on i686 2.4.7-10.  Options used
> >      -v /usr/src/linux/vmlinux (specified)
> >      -K (specified)
> >      -L (specified)
> >      -o /lib/modules/2.5.9/ (specified)
> >      -m /boot/System.map-2.5.9 (specified)
> 
> 
> Looks like the oops came from module code.
> Which modules did you use: ide-flappy and ide-scsi are still
> in need of the same medication ide-cd got.

CONFIG_BLK_DEV_IDESCSI=m
CONFIG_SCSI=m
CONFIG_BLK_DEV_SD=m
CONFIG_BLK_DEV_SR=m
CONFIG_CHR_DEV_SG=m

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[Jens Axboe]

On Tue, Apr 23 2002, Martin Dalecki wrote:
> >Martin,
> >
> >There are several 'issues' with the ide-cd changes, in fact I think they
> >are horrible. I'll take part of the blame for that, I'll explain.
> 
> Well... I refer you to my change long, where I indeed admitted directly
> that it's an ugly band aid ;-).

Didn't read that :)

> >The ata_ar_get() doesn't belong inside the do_request() strategies, the
> >reason I did that for ide-disk was to get going on the tcq stuff and not
> >spend too much time rewriting the ide request handling at that point. It
> 
> Right. it belongs one level up. The request handling should
> possible learn whatever it it's handling ATA or ATAPI devices.
> In esp. the ide_start_dma() changes where no pretty...

Why would you care what type of transport they use??

> >was _never_ meant to propagate into the other ide drivers, and in fact
> >the code in ide-disk has several tcq specific parts that really cannot
> >work in ide-cd. Such as (ide-cd.c:ide_cdrom_do_request()):
> >
> >	spin_lock...
> >
> >	ar = ata_ar_get()
> >	if (!ar) {
> >		spin_unlock;
> >		return ide_started;
> >	}
> >	...
> >
> >ide-disk guarentees that if ata_ar_get() fails, it's because we have
> >some pending commands on the drive. The ide_started is bogus too, in
> >this context it really should be ide_didnt_start_jack, but it works for
> >ide-disk because of the above assumptions.
> 
> Fortunately it can't happen becouse the other devices don't
> support TCQ.

Right, it should rather be a bug trigger in ide-cd... Doesn't matter, it
will be killed soon.

> >I'd suggest moving the ata_ar_get() at the ide_queue_commands() level,
> >and just pass { drive, ar } to the do_request() strategies. That's also
> >why ide-disk.c:idedisk_do_request() has this comment:
> 
> Yes this was my intention for the future. The only driver which will have
> problems with this is ide-scsi.c - it's not obvious (at least right now)
> to me how to change the do_request signature there.

How so? Even with pusing ar at the level discussed here, ide-xx.c does
really not need to care. Change the do_request() strategy to just take
the drive and ar, driver is free to just:

	/* something to this effect */
	struct request *rq = ar->ar_rq;
	sector_t block = ar->ar_block;

and the rest could remain unchanged. It's up to the driver how far it
wants to take this. The only "problem" is that rq->special will always
contain the pointer to the ar used, so none of them can touch it.

> >	/*
> >	 * get a new command (push ar further down to avoid grabbing
> >	 * lock here
> >	 */
> >	spin_lock_irqsave(DRIVE_LOCK(drive), flags);
> >
> >	ar = ata_ar_get(drive);
> >	...
> >
> >I've been meaning to do this once tcq settled down, just didn't get
> >around to it yet. But please don't start moving stuff like this into
> >ide-cd too.
> 
> You notice that I didn't even care to change the write request code-path?
> BTW.> It became obvious to me as well that even all the drivers out
> there not supporting TCQ will have to get the TCQ parts of struct ata_device
> initialized - with a trivial queue depth. drive->tcq should therefore be 
> really just a memmber of struct ata_device()..

I disagree, there's no need to have a ->tcq if you don't support
queueing. The "trivial queue depth" is already done, it's called
drive->queue_depth and is 1 for non-tcq (or tcq with depth 1 :-).

-- 
Jens Axboe

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[Jens Axboe]

On Tue, Apr 23 2002, Martin Dalecki wrote:
> Miles Lane wrote:
> >I should probably add the /proc/ksyms snapshotting stuff to 
> >get the module information for you as well.  I hope this 
> >current batch of info helps, for starters.
> >
> >ksymoops 2.4.4 on i686 2.4.7-10.  Options used
> >     -v /usr/src/linux/vmlinux (specified)
> >     -K (specified)
> >     -L (specified)
> >     -o /lib/modules/2.5.9/ (specified)
> >     -m /boot/System.map-2.5.9 (specified)
> 
> 
> Looks like the oops came from module code.
> Which modules did you use: ide-flappy and ide-scsi are still
> in need of the same medication ide-cd got.

Martin,

There are several 'issues' with the ide-cd changes, in fact I think they
are horrible. I'll take part of the blame for that, I'll explain.

The ata_ar_get() doesn't belong inside the do_request() strategies, the
reason I did that for ide-disk was to get going on the tcq stuff and not
spend too much time rewriting the ide request handling at that point. It
was _never_ meant to propagate into the other ide drivers, and in fact
the code in ide-disk has several tcq specific parts that really cannot
work in ide-cd. Such as (ide-cd.c:ide_cdrom_do_request()):

	spin_lock...

	ar = ata_ar_get()
	if (!ar) {
		spin_unlock;
		return ide_started;
	}
	...

ide-disk guarentees that if ata_ar_get() fails, it's because we have
some pending commands on the drive. The ide_started is bogus too, in
this context it really should be ide_didnt_start_jack, but it works for
ide-disk because of the above assumptions.

Don't tell me you can read ide_cdrom_do_request() right now without a
barf bag :-)

I'd suggest moving the ata_ar_get() at the ide_queue_commands() level,
and just pass { drive, ar } to the do_request() strategies. That's also
why ide-disk.c:idedisk_do_request() has this comment:

	/*
	 * get a new command (push ar further down to avoid grabbing
	 * lock here
	 */
	spin_lock_irqsave(DRIVE_LOCK(drive), flags);

	ar = ata_ar_get(drive);
	...

I've been meaning to do this once tcq settled down, just didn't get
around to it yet. But please don't start moving stuff like this into
ide-cd too.

-- 
Jens Axboe

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[Martin Dalecki]

> Martin,
> 
> There are several 'issues' with the ide-cd changes, in fact I think they
> are horrible. I'll take part of the blame for that, I'll explain.

Well... I refer you to my change long, where I indeed admitted directly
that it's an ugly band aid ;-).

> The ata_ar_get() doesn't belong inside the do_request() strategies, the
> reason I did that for ide-disk was to get going on the tcq stuff and not
> spend too much time rewriting the ide request handling at that point. It

Right. it belongs one level up. The request handling should
possible learn whatever it it's handling ATA or ATAPI devices.
In esp. the ide_start_dma() changes where no pretty...

> was _never_ meant to propagate into the other ide drivers, and in fact
> the code in ide-disk has several tcq specific parts that really cannot
> work in ide-cd. Such as (ide-cd.c:ide_cdrom_do_request()):
> 
> 	spin_lock...
> 
> 	ar = ata_ar_get()
> 	if (!ar) {
> 		spin_unlock;
> 		return ide_started;
> 	}
> 	...
> 
> ide-disk guarentees that if ata_ar_get() fails, it's because we have
> some pending commands on the drive. The ide_started is bogus too, in
> this context it really should be ide_didnt_start_jack, but it works for
> ide-disk because of the above assumptions.

Fortunately it can't happen becouse the other devices don't
support TCQ.

> Don't tell me you can read ide_cdrom_do_request() right now without a
> barf bag :-)

Ohhh. there are a lot of other things I'm unhappy about there as well.

> I'd suggest moving the ata_ar_get() at the ide_queue_commands() level,
> and just pass { drive, ar } to the do_request() strategies. That's also
> why ide-disk.c:idedisk_do_request() has this comment:

Yes this was my intention for the future. The only driver which will have
problems with this is ide-scsi.c - it's not obvious (at least right now)
to me how to change the do_request signature there.

> 	/*
> 	 * get a new command (push ar further down to avoid grabbing
> 	 * lock here
> 	 */
> 	spin_lock_irqsave(DRIVE_LOCK(drive), flags);
> 
> 	ar = ata_ar_get(drive);
> 	...
> 
> I've been meaning to do this once tcq settled down, just didn't get
> around to it yet. But please don't start moving stuff like this into
> ide-cd too.

You notice that I didn't even care to change the write request code-path?
BTW.> It became obvious to me as well that even all the drivers out
there not supporting TCQ will have to get the TCQ parts of struct ata_device
initialized - with a trivial queue depth. drive->tcq should therefore be really
just a memmber of struct ata_device()..

2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[Miles Lane]

I should probably add the /proc/ksyms snapshotting stuff to 
get the module information for you as well.  I hope this 
current batch of info helps, for starters.

ksymoops 2.4.4 on i686 2.4.7-10.  Options used
     -v /usr/src/linux/vmlinux (specified)
     -K (specified)
     -L (specified)
     -o /lib/modules/2.5.9/ (specified)
     -m /boot/System.map-2.5.9 (specified)

Unable to handle kernel NULL pointer dereference at virtual address 00000004
*pde = 00000000
Oops: 0002
CPU:    0
EIP:    0010:[<c01fb579>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010002
eax: 00000004   ebx: cf44be24   ecx: 00000000   edx: 00000000
esi: cf44bd90   edi: c03426bc   ebp: 00000296   esp: c02ddeac
ds: 0018   es: 0018   ss: 0018
Stack: 00000001 cf44bd90 cf44be24 c03426bc 00000001 c01ff62f c03426bc 00000001 
       00000000 d98f164d c03426bc 00000001 cf44bd50 00000000 cf44bd90 cf44be24 
       cff26500 d98f227b c02ddf0c c03426bc 00000000 c02ddf10 00000000 c01fce26 
Call Trace: [<c01ff62f>] [<d98f164d>] [<d98f227b>] [<c01fce26>] [<c01fd433>] 
   [<d98f2250>] [<c0108709>] [<c01088eb>] [<c0105310>] [<c010730e>] [<c0105310>] 
   [<c0105310>] [<c0105337>] [<c01053b6>] [<c0105000>] 
Code: c7 04 90 00 00 00 00 8b 53 0c 8b 87 20 02 00 00 0f b3 10 8b 

>>EIP; c01fb579 <__ide_end_request+109/190>   <=====
Trace; c01ff62f <ide_end_request+f/20>
Trace; d98f164d <END_OF_CODE+195a2039/????>
Trace; d98f227b <END_OF_CODE+195a2c67/????>
Trace; c01fce26 <ide_do_request+36/a0>
Trace; c01fd433 <ide_intr+103/1c0>
Trace; d98f2250 <END_OF_CODE+195a2c3c/????>
Trace; c0108709 <handle_IRQ_event+39/70>
Trace; c01088eb <do_IRQ+8b/110>
Trace; c0105310 <default_idle+0/30>
Trace; c010730e <common_interrupt+22/28>
Trace; c0105310 <default_idle+0/30>
Trace; c0105310 <default_idle+0/30>
Trace; c0105337 <default_idle+27/30>
Trace; c01053b6 <cpu_idle+36/40>
Trace; c0105000 <_stext+0/0>
Code;  c01fb579 <__ide_end_request+109/190>
00000000 <_EIP>:
Code;  c01fb579 <__ide_end_request+109/190>   <=====
   0:   c7 04 90 00 00 00 00      movl   $0x0,(%eax,%edx,4)   <=====
Code;  c01fb580 <__ide_end_request+110/190>
   7:   8b 53 0c                  mov    0xc(%ebx),%edx
Code;  c01fb583 <__ide_end_request+113/190>
   a:   8b 87 20 02 00 00         mov    0x220(%edi),%eax
Code;  c01fb589 <__ide_end_request+119/190>
  10:   0f b3 10                  btr    %edx,(%eax)
Code;  c01fb58c <__ide_end_request+11c/190>
  13:   8b 00                     mov    (%eax),%eax

 <0>Kernel panic: Aiee, killing interrupt handler!

1 warning and 1 error issued.  Results may not be reliable.


Linux version 2.5.9 (root@turbulence.megapathdsl.net) (gcc version 3.0.4 (Red Hat Linux 7.2 3.0.4-1)) #4 2BIOS-provided physical RAM map:                                   
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)          
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)        
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000ffe0000 (usable)
 BIOS-e820: 000000000ffe0000 - 000000000fff8000 (ACPI data)
 BIOS-e820: 000000000fff8000 - 0000000010000000 (ACPI NVS)
 BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
255MB LOWMEM available.
On node 0 totalpages: 65504
zone(0): 4096 pages.
zone(1): 61408 pages.
zone(2): 0 pages.
ACPI: RSDP (v000 AMI                        ) @ 0x000fae70
ACPI: RSDT (v001 GATEWA 8DT-084  00529.06553) @ 0x0fff0000
ACPI: FADT (v001 GATEWA 8DT-084  00529.06553) @ 0x0fff1000
Kernel command line: ro root=/dev/hda6 hdd=ide-scsi console=ttyS0,38400 video=riva:1600x1200-16@76
ide_setup: hdd=ide-scsi
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
Initializing CPU#0
Detected 848.364 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1690.82 BogoMIPS
Memory: 256916k/262016k available (1509k kernel code, 4712k reserved, 391k data, 232k init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU: AMD Athlon(tm) Processor stepping 01
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 848.3696 MHz.
..... host bus clock speed is 199.6163 MHz.
cpu: 0, clocks: 1996163, slice: 998081
CPU0<T0:1996160,T1:998064,D:15,S:998081,C:1996163>
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
ACPI: Bus Driver revision 20020404
ACPI: Core Subsystem revision 20020403
PCI: PCI BIOS revision 2.10 entry at 0xfdad1, last bus=1
PCI: Using configuration type 1
 tbxface-0101 [03] Acpi_load_tables      : ACPI Tables successfully loaded
Parsing Methods:...................................................................................
83 Control Methods found and parsed (271 nodes total)
ACPI Namespace successfully loaded at root c03276f8
evxfevnt-0080 [04] Acpi_enable           : Transition to ACPI mode successful
Executing all Device _STA and_INI methods:............... exfldio-0100 [21] Ex_setup_region       : Field) exfldio-0110 [21] Ex_setup_region       : Field [PS2E] Base+Offset+Width 0+0+4 is beyond end of region [)  uteval-0421 [07] Ut_execute_STA        : _STA on PS2M failed AE_AML_REGION_LIMIT
...........
26 Devices found containing: 25 _STA, 2 _INI methods
Completing Region/Field/Buffer/Package initialization:..........................................
 Initialized 12/15 Regions 1/1 Fields 21/21 Buffers 8/9 Packages (271 nodes)
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: System [ACPI] (supports S0 S1 S5)
ACPI: PCI Root Bridge [PCI0] (00:00:00.00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
      00:00:11[A] -> \_SB_.LNKA[0]
      00:00:11[B] -> \_SB_.LNKB[0]
      00:00:11[C] -> \_SB_.LNKC[0]
      00:00:11[D] -> \_SB_.LNKD[0]
      00:00:12[A] -> \_SB_.LNKB[0]
      00:00:12[B] -> \_SB_.LNKC[0]
      00:00:12[C] -> \_SB_.LNKD[0]
      00:00:12[D] -> \_SB_.LNKA[0]
      00:00:13[A] -> \_SB_.LNKC[0]
      00:00:13[B] -> \_SB_.LNKD[0]
      00:00:13[C] -> \_SB_.LNKA[0]
      00:00:13[D] -> \_SB_.LNKB[0]
      00:00:14[A] -> \_SB_.LNKB[0]
      00:00:14[B] -> \_SB_.LNKC[0]
      00:00:14[C] -> \_SB_.LNKD[0]
      00:00:14[D] -> \_SB_.LNKA[0]
      00:00:0F[A] -> \_SB_.LNKA[0]
      00:00:0F[B] -> \_SB_.LNKB[0]
      00:00:0F[C] -> \_SB_.LNKC[0]
      00:00:0F[D] -> \_SB_.LNKD[0]
      00:00:07[D] -> \_SB_.LNKD[0]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGPB._PRT]
      00:01:05[A] -> \_SB_.LNKA[0]
 exfldio-0100 [21] Ex_setup_region       : Field [PS2E] access width (4 bytes) too large for region [PSRG) exfldio-0110 [21] Ex_setup_region       : Field [PS2E] Base+Offset+Width 0+0+4 is beyond end of region [)acpi_pci_link-0164 [09] acpi_pci_link_get_poss: Resource is not an IRQ entry
acpi_pci_link-0164 [09] acpi_pci_link_get_poss: Resource is not an IRQ entry
acpi_pci_link-0164 [09] acpi_pci_link_get_poss: Resource is not an IRQ entry
acpi_pci_link-0164 [09] acpi_pci_link_get_poss: Resource is not an IRQ entry
PCI: Probing PCI hardware
PCI: Using ACPI for IRQ routing
acpi_pci_link-0330 [02] acpi_pci_link_get_irq : Invalid link context
pci_root-0160 [01] acpi_prt_get_irq      : Unable to reslove IRQ
PCI: No IRQ known for interrupt pin A of device 00:14.0
acpi_pci_link-0330 [02] acpi_pci_link_get_irq : Invalid link context
pci_root-0160 [01] acpi_prt_get_irq      : Unable to reslove IRQ
PCI: No IRQ known for interrupt pin B of device 00:14.1
Starting kswapd
BIO: pool of 256 setup, 14Kb (56 bytes/bio)
biovec: init pool 0, 1 entries, 12 bytes
biovec: init pool 1, 4 entries, 48 bytes
biovec: init pool 2, 16 entries, 192 bytes
biovec: init pool 3, 64 entries, 768 bytes
biovec: init pool 4, 128 entries, 1536 bytes
biovec: init pool 5, 256 entries, 3072 bytes
Journalled Block Device driver loaded
rivafb: RIVA MTRR set to ON
Console: switching to colour frame buffer device 200x75
rivafb: PCI nVidia NV16 framebuffer ver 0.9.2a (GeForce-DDR, 32MB @ 0xE8000000)
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS02 at 0x03e8 (irq = 0) is a 16550A
block: 256 slots per queue, batch=32
loop: loaded (max 8 devices)
acpi_pci_link-0330 [02] acpi_pci_link_get_irq : Invalid link context
pci_root-0160 [01] acpi_prt_get_irq      : Unable to reslove IRQ
PCI: No IRQ known for interrupt pin A of device 00:13.0
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
00:13.0: 3Com PCI 3c905C Tornado at 0xfc00. Vers LK1.1.17
phy=0, phyx=24, mii_status=0x782d
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 203M
agpgart: Detected AMD Irongate chipset
agpgart: AGP aperture is 64M @ 0xf8000000
ipddp.c:v0.01 8/28/97 Bradford W. Johnson <johns393@maroon.tc.umn.edu>
ipddp0: Appletalk-IP Encap. mode by Bradford W. Johnson <johns393@maroon.tc.umn.edu>
Uniform Multi-Platform E-IDE driver ver.:7.0.0
ide: system bus speed 33MHz
Advanced Micro Devices [AMD] AMD-756 [Viper] IDE: IDE controller on PCI slot 00:07.1
Advanced Micro Devices [AMD] AMD-756 [Viper] IDE: chipset revision 3
Advanced Micro Devices [AMD] AMD-756 [Viper] IDE: not 100% native mode: will probe irqs later
AMD_IDE: Advanced Micro Devices [AMD] AMD-756 [Viper] IDE (rev 03) UDMA66 controller on pci00:07.1
    ide0: BM-DMA at 0xcb00-0xcb07, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xcb08-0xcb0f, BIOS settings: hdc:DMA, hdd:DMA
hda: QUANTUM FIREBALLP LM30, ATA DISK drive
hdc: Pioneer DVD-ROM ATAPIModel DVD-114 0117, ATAPI CD/DVD-ROM drive
hdd: R/RW 4x4x24, ATAPI CD/DVD-ROM drive
ide2: ports already in use, skipping probe
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide: unexpected interrupt 0 14
hda: 58633344 sectors (30020 MB) w/1900KiB Cache, CHS=58168/16/63, UDMA(66)
Partition check:
 hda: [PTBL] [3649/255/63] hda1 hda2 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 hda12 hda13 >
mice: PS/2 mouse device common for all mice
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
 [events: 00000098]
 [events: 00000098]
md: autorun ...
md: considering hda12 ...
md:  adding hda12 ...
md:  adding hda11 ...
md: created md0
md: bind<hda11,1>
md0: WARNING: hda12 appears to be on the same physical disk as hda11. True
     protection against single-disk failure might be compromised.
md: bind<hda12,2>
md: running: <hda12><hda11>
md: hda12's event counter: 00000098
md: hda11's event counter: 00000098
md0: max total readahead window set to 512k
md0: 2 data-disks, max readahead per data-disk: 256k
raid0: looking at hda11
raid0:   comparing hda11(1028032) with hda11(1028032)
raid0:   END
raid0:   ==> UNIQUE
raid0: 1 zones
raid0: looking at hda12
raid0:   comparing hda12(1028032) with hda11(1028032)
raid0:   EQUAL
raid0: FINAL 1 zones
raid0: zone 0
raid0: checking hda11 ... contained as device 0
  (1028032) is smallest!.
raid0: checking hda12 ... contained as device 1
raid0: zone->nb_dev: 2, size: 2056064
raid0: current zone offset: 1028032
raid0: done.
raid0 : md_size is 2056064 blocks.
raid0 : conf->smallest->size is 2056064 blocks.
raid0 : nb_zone is 1.
raid0 : Allocating 8 bytes for hash.
md: updating md0 RAID superblock on device
md: hda12 [events: 00000099]<6>(write) hda12's sb offset: 1028032
md: hda11 [events: 00000099]<6>(write) hda11's sb offset: 1028032
md: ... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
IPv4 over IPv4 tunneling driver
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: AppleTalk 0.18a for Linux NET4.0
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 232k freed
INIT: version 2.78 booting
                        Welcome to Red Hat Linux
                Press 'I' to enter interactive startup.
Mounting proc filesystem:  [  OK  ]
Configuring kernel parameters:  [  OK  ]
Setting clock  (localtime): Mon Apr 22 22:15:59 PDT 2002 [  OK  ]
Activating swap partitions:  [  OK  ]
Setting hostname turbulence.megapathdsl.net:  [  OK  ]
Mounting USB filesystem:  [  OK  ]
Initializing USB controller (usb-ohci):  [  OK  ]
Initializing USB HID interface:  [  OK  ]
Initializing USB mouse:  modprobe: Can't locate module mousedev
[FAILED]
Checking root filesystem
/: clean, 313674/1921984 files, 2266435/3841535 blocks
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/hda6 
[  OK  ]
Remounting root filesystem in read-write mode:  [  OK  ]
Finding module dependencies:  [  OK  ]
Starting up RAID devices: md0 
Checking filesystems
/boot: clean, 77/84336 files, 53660/337333 blocks
/home: clean, 13228/257024 files, 173634/514016 blocks
Logical sector size is zero.dosfsck 2.7, 14 Feb 2001, FAT32, LFN

Logical sector size is zero.dosfsck 2.7, 14 Feb 2001, FAT32, LFN

Logical sector size is zero.dosfsck 2.7, 14 Feb 2001, FAT32, LFN
dosfsck 2.7, 14 Feb 2001, FAT32, LFN
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a /dev/hda5 
[/sbin/fsck.ext3 (1) -- /home] fsck.ext3 -a /dev/md0 
[/sbin/fsck.vfat (1) -- /mnt/test1] fsck.vfat -a /dev/hda7 
[/sbin/fsck.vfat (1) -- /mnt/test2] fsck.vfat -a /dev/hda8 
[/sbin/fsck.vfat (1) -- /mnt/test3] fsck.vfat -a /dev/hda9 
[/sbin/fsck.vfat (1) -- /mnt/test4] fsck.vfat -a /dev/hda10 

Logical sector size is zero.
[PASSED]
Mounting local filesystems:  mount: wrong fs type, bad option, bad superblock on /dev/hda7,
       or too many mounted file systems
mount: wrong fs type, bad option, bad superblock on /dev/hda8,
       or too many mounted file systems
mount: wrong fs type, bad option, bad superblock on /dev/hda9,
       or too many mounted file systems
mount: mount point /mnt/test4 does not exist
[FAILED]
Enabling local filesystem quotas:  [  OK  ]
Enabling swap space:  [  OK  ]
Unable to handle kernel NULL pointer dereference at virtual address 00000004
*pde = 00000000
Oops: 0002
CPU:    0
EIP:    0010:[<c01fb579>]    Not tainted
EFLAGS: 00010002
eax: 00000004   ebx: cf44be24   ecx: 00000000   edx: 00000000
esi: cf44bd90   edi: c03426bc   ebp: 00000296   esp: c02ddeac
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 0, threadinfo=c02dc000 task=c02bf3e0)
Stack: 00000001 cf44bd90 cf44be24 c03426bc 00000001 c01ff62f c03426bc 00000001 
       00000000 d98f164d c03426bc 00000001 cf44bd50 00000000 cf44bd90 cf44be24 
       cff26500 d98f227b c02ddf0c c03426bc 00000000 c02ddf10 00000000 c01fce26 
Call Trace: [<c01ff62f>] [<d98f164d>] [<d98f227b>] [<c01fce26>] [<c01fd433>] 
   [<d98f2250>] [<c0108709>] [<c01088eb>] [<c0105310>] [<c010730e>] [<c0105310>] 
   [<c0105310>] [<c0105337>] [<c01053b6>] [<c0105000>] 

Code: c7 04 90 00 00 00 00 8b 53 0c 8b 87 20 02 00 00 0f b3 10 8b 
 <0>Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing

Re: 2.5.9 -- OOPS in IDE code (symbolic dump and boot log included)

[Martin Dalecki]

Miles Lane wrote:
> I should probably add the /proc/ksyms snapshotting stuff to 
> get the module information for you as well.  I hope this 
> current batch of info helps, for starters.
> 
> ksymoops 2.4.4 on i686 2.4.7-10.  Options used
>      -v /usr/src/linux/vmlinux (specified)
>      -K (specified)
>      -L (specified)
>      -o /lib/modules/2.5.9/ (specified)
>      -m /boot/System.map-2.5.9 (specified)


Looks like the oops came from module code.
Which modules did you use: ide-flappy and ide-scsi are still
in need of the same medication ide-cd got.