On Fri, Jun 10, 2005 at 05:19:59PM +0100, Dieter wrote:
> [ ... ]
> satalink0: bus-master DMA support presentpciide_mapreg_dma: reg 0 addr 0x7ffffe42c010100
> pciide_mapreg_dma: reg 1 addr 0x7ffffe42c010101
> pciide_mapreg_dma: reg 2 addr 0x7ffffe42c010102
> pciide_mapreg_dma: reg 3 addr 0x7ffffe42c010103
> pciide_mapreg_dma: reg 4 addr 0x7ffffe42c010104
> pciide_mapreg_dma: reg 5 addr 0x7ffffe42c010105
> pciide_mapreg_dma: reg 6 addr 0x7ffffe42c010106
> pciide_mapreg_dma: reg 7 addr 0x7ffffe42c010107
> pciide_mapreg_dma: reg 0 addr 0x7ffffe42c010108
> pciide_mapreg_dma: reg 1 addr 0x7ffffe42c010109
> pciide_mapreg_dma: reg 2 addr 0x7ffffe42c01010a
> pciide_mapreg_dma: reg 3 addr 0x7ffffe42c01010b
> pciide_mapreg_dma: reg 4 addr 0x7ffffe42c01010c
> pciide_mapreg_dma: reg 5 addr 0x7ffffe42c01010d
> pciide_mapreg_dma: reg 6 addr 0x7ffffe42c01010e
> pciide_mapreg_dma: reg 7 addr 0x7ffffe42c01010f
> 
> satalink0: primary channel wired to native-PCI mode
> [ ... ]
> scsibus0 at isp0: 16 targets, 8 luns per target
> cmdide0 at pci0 dev 11 function 0
> cmdide0: CMD Technology PCI0646 (rev. 0x01)
> cmdide0: bus-master DMA support presentpciide_mapreg_dma: reg 0 addr 0x7ffffe42c012010
> pciide_mapreg_dma: reg 1 addr 0x7ffffe42c012011
> pciide_mapreg_dma: reg 2 addr 0x7ffffe42c012012
> pciide_mapreg_dma: reg 3 addr 0x7ffffe42c012013
> pciide_mapreg_dma: reg 4 addr 0x7ffffe42c012014
> pciide_mapreg_dma: reg 5 addr 0x7ffffe42c012015
> pciide_mapreg_dma: reg 6 addr 0x7ffffe42c012016
> pciide_mapreg_dma: reg 7 addr 0x7ffffe42c012017
> pciide_mapreg_dma: reg 0 addr 0x7ffffe42c012018
> pciide_mapreg_dma: reg 1 addr 0x7ffffe42c012019
> pciide_mapreg_dma: reg 2 addr 0x7ffffe42c01201a
> pciide_mapreg_dma: reg 3 addr 0x7ffffe42c01201b
> pciide_mapreg_dma: reg 4 addr 0x7ffffe42c01201c
> pciide_mapreg_dma: reg 5 addr 0x7ffffe42c01201d
> pciide_mapreg_dma: reg 6 addr 0x7ffffe42c01201e
> pciide_mapreg_dma: reg 7 addr 0x7ffffe42c01201f
> 
> cmdide0: primary channel wired to compatibility mode
> cmdide0: primary channel interrupting at isa irq 14
> atabus2 at cmdide0 channel 0
> cmdide0: secondary channel wired to compatibility mode
> cmdide0: secondary channel interrupting at isa irq 15
> atabus3 at cmdide0 channel 1
> isa0 at sio0
> [ ... ]
> wd0 at atabus1 drive 0scsibus0: waiting 2 seconds for devices to settle...
> pciide_irqack: reg 0x7ffffe42c01010a
> : <ST3250823AS>
> wd0: drive supports 16-sector PIO transfers, LBA48 addressing
> wd0: 232 GB, 484521 cyl, 16 head, 63 sec, 512 bytes/sect x 488397168 sectors
> pciide_irqack: reg 0x7ffffe42c012012

Well, I'm out of idea on this one. It seems to use the correct bus_space
handle, it even has the same aligneemnt as the one used for the satalink.

Does anyone more familiar with the alpha architecture have an idea what's
happening here ? What does the machine check below exactly mean ?

This cmdide controller is the one from the motherboard, right ?
If it's an add-on PCI card, it would be possible that not all PCI address
lines are wired up (this has been seen with some promise controllers), but
if it's the one from the motherboard I would expect it to be wired
properly.

> unexpected machine check:
> 
>     mces    = 0x1
>     vector  = 0x670
>     param   = 0xfffffc0000006068
>     pc      = 0xfffffc00004fddf4
>     ra      = 0xfffffc00004e98f4
>     code    = 0x98
>     curlwp = 0xfffffc0000ade780
>         pid = 9.1, comm = atabus2
> 
> panic: machine check
> Stopped in pid 9.1 (atabus2) at netbsd:cpu_Debugger+0x4:        ret     zero,(ra
> )
> db> bt
> cpu_Debugger() at netbsd:cpu_Debugger+0x4
> panic() at netbsd:panic+0x1e8
> machine_check() at netbsd:machine_check+0x234
> interrupt() at netbsd:interrupt+0x1e8
> XentInt() at netbsd:XentInt+0x1c
> --- interrupt (from ipl 4) ---
> cia_swiz_io_read_1() at netbsd:cia_swiz_io_read_1+0x14
> pciide_irqack() at netbsd:pciide_irqack+0x54
> cmd646_9_irqack() at netbsd:cmd646_9_irqack+0xb8
> wdcprobe1() at netbsd:wdcprobe1+0xc5c
> wdc_drvprobe() at netbsd:wdc_drvprobe+0x44
> atabusconfig() at netbsd:atabusconfig+0x78
> atabus_thread() at netbsd:atabus_thread+0x7c
> exception_return() at netbsd:exception_return
> --- root of call graph ---
> db> reboot
> syncing disks... pciide_irqack: reg 0x7ffffe42c01010a
> done
> rebooting...
> 
> ==================================
> 
> (gdb) list *(0xfffffc00004fddf4)
> 0xfffffc00004fddf4 is in cia_swiz_io_read_1 (pci_swiz_bus_io_chipdep.c:673).
> 668             tmpioh = ioh + off;
> 669             offset = tmpioh & 3;
> 670             port = (u_int32_t *)((tmpioh << CHIP_ADDR_SHIFT) |
> 671                 (0 << CHIP_SIZE_SHIFT));
> 672             val = *port;
> 673             rval = ((val) >> (8 * offset)) & 0xff;
> 674
> 675             return rval;
> 676     }
> 677
> (gdb) 
-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--