Manuel Bouyer wrote:
> 
> On Fri, Apr 27, 2001 at 03:47:40PM +0000, Andrea wrote:
> > Hi All!
> >
> > I got a A7v133 motherboard.
> >
> > This mother board is provided with 2 IDE controller, the first based on
> > VIA chipset and the other is a Promise ATA100 (with raid support).
> >
> > [...]
> > pciide1:1: bogus intr <---------------------------------???????
> 
> This is not something to worry about for now, it's mostly cosmetic.
> If you start getting these under normal operation (during network I/O for
> example, as network and pciide1 shares the interrupt) then please report
> 
> > boot device: wd0dump device:
> > file system (default generic): nfd\^H \^Hs
> > root on rtk0
> > nfs_boot: trying DHCP/BOOTP
> > nfs_boot: BOOTP server: 151.36.176.69
> > nfs_boot: my_addr=151.36.176.68
> > nfs_boot: my_mask=255.255.0.0
> > root on moondust.practive.org:/usr/home/andrea/netbsd
> >
> > /---- I got these when i mount the filesystems --/
> > pciide0:0:0: lost interrupt
> >         type: ata tc_bcount: 2048 tc_skip: 0
> > pciide0:0:0: bus-master DMA error: missing interrupt, status=0x60
> > wd0: transfer error, downgrading to Ultra-DMA mode 1
> > wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 1 (using DMA data
> > transfers)
> > wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2 (Ultra/33) (using
> > DMA data transfers)
> > wd0a: DMA error writing fsbn 16 of 16-19 (wd0 bn 79; cn 0 tn 1 sn 16),
> > retrying
> > wd0: soft error (corrected)
> > pciide0:0:1: lost interrupt
> >         type: ata tc_bcount: 2048 tc_skip: 0
> > pciide0:0:1: bus-master DMA error: missing interrupt, status=0x60
> > wd1: transfer error, downgrading to Ultra-DMA mode 1
> > wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 1 (using DMA data
> > transfers)
> > wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 1 (using DMA data
> > transfers)
> > wd1a: aborted command, interface CRC error writing fsbn 16 of 16-19 (wd1
> > bn 79; cn 0 tn 1 sn 16), retrying
> > wd1: soft error (corrected)
> >
> >
> > After that the filesystem came up correctly (or so seems) but i got
> > system panic when i try to configure raidframe.
> 
> What kind of panic ?
> You may also want to put each drive on it own channel (as you don't have
> anything on pciide0:1) it will work better
> 
> > The promise controller ,instead, works without errors.
> 
> I know the VIA support isn't in a good shape these days. This comes partly
> from VIA's stupidity which doesn't change product or revision ID for their
> controllers, when a lot of things change (Ultra33->Ultra/66->Ultra/100 for
> example). This needs a workaround, to detect the chip type by some other
> way ...
> 
It's possible to force statically the correct controllers ID in kernel
config file or even
in device driver source code? and how?

> --
> Manuel Bouyer <bouyer@antioche.eu.org>
> --

Thanks!