I've got an Adaptec 2940U (just Ultra, not Ultra/wide)
** Alan ** If you're reading this, here's some additional. I finally
found time to sit and investigate a little: It crashes out, just as Allen
says, right after the sda: without ever showing sda1, etc, with a
'General protection'. I tracked the EIP (0010:[<00187b91>]
back in the new System.map to the
following:
00185bf8 t ide_open
00185c98 t ide_release
00185d1c t revalidate_disk
00185e48 t write_fs_long
00185e78 t ide_ioctl
00186768 t ide_check_media_change
00186794 T ide_fixstring
00186808 t delay_50ms
0018681c t try_to_identify
00187018 t do_probe
0018721c t enable_nest
0018730c t probe_cmos_for_drives
00187388 t probe_hwif
00187620 t stridx
0018765c t match_parm
00187798 T ide_setup
00187b5c T ide_xlate_1024 <------------------***
00187db8 t save_match
00187e20 t init_irq
0018805c t ide_probe_pci
001880c4 t probe_for_hwifs
001881ac t hwif_init
00188318 T ide_init
Gary Anderson
ganderson@clark.net
> From: Allen Mcintosh <mcintosh@bellcore.com>
> Date: Fri, 22 Jan 1999 00:32:22 -0500
> Subject: 2.0.37pre4 oops
>
> The 2.0.37pre4 kernel that I built this evening crashes during the initial
> boot-up. It dies here:
>
> SCSI device sdd: hdwr sector= 512 bytes. Sectors= 4178874 [2040 MB] [2.0 GB]
> PPP: version 2.2.0 (dynamic channel allocation)
> TCP compression code copyright 1989 Regents of the University of California
> PPP Dynamic channel allocation code copyright 1995 Caldera, Inc.
> PPP line discipline registered.
> SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256).
> SLIP linefill/keepalive option.
> 3c59x.c:v0.99H 11/17/98 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html
> eth0: 3c509 at 0x250 tag 1, 10baseT port, address 00 c0 4f d9 79 7f, IRQ 10.
> 3c509.c:1.16 2/3/98 becker@cesdis.gsfc.nasa.gov
> Partition check:
> sda: sda1 sda2
>
> The " sda1 sda2" never prints.
>
> sda is on an Adaptec board, and my guess is that this is the first time that
> the Adaptec driver tries to read the disk. I knew that the driver changed
> between pre3 and pre4, so I grafted the pre4 changes back into pre3, and the
> resulting kernel worked (for the last 15 minutes, anyway).
>
> I'm willing to supply more info if anyone is interested, but since there
> is no logging active at this point, I will need either a pointer to info
> on how to get the traceback in machine readable form (this case is not
> covered in oops-tracing.txt) or some time and a pencil and paper...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/