NetBSD Problem Report #8460

Received: (qmail 29530 invoked from network); 21 Sep 1999 09:29:25 -0000
Message-Id: <199909210929.LAA05607@ymer.campus.luth.se>
Date: Tue, 21 Sep 1999 11:29:34 +0200 (CEST)
From: Andreas Johansson <ajo@ymer.campus.luth.se>
Reply-To: ajo@ymer.campus.luth.se
To: gnats-bugs@gnats.netbsd.org
Subject: PCI I/O address assigning problem on alpha
X-Send-Pr-Version: 3.95

>Number:         8460
>Category:       port-alpha
>Synopsis:       PCI I/O address assigning problem on alpha
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-alpha-maintainer
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Sep 21 02:35:00 +0000 1999
>Closed-Date:    
>Last-Modified:  Fri Jan 18 08:00:01 +0000 2002
>Originator:     Andreas Johansson
>Release:        current as of 1999-08-21
>Organization:
>Environment:
AlphaPC 164SX
Promise Ultra33 PCI IDE card

System: NetBSD ymer 1.4I NetBSD 1.4I (YMER) #16: Fri Aug 13 00:16:51 CEST 1999 ajo@ymer:/usr/src/sys/arch/alpha/compile/YMER alpha


>Description:
Some SRM's assign I/O addresses to PCI cards that are higher than 0xffff.
These addresses are supposed to be supported by NetBSD, but when the machine
boots it receives an undocumented machine check as soon as it tries to access
the I/O registers of the card. If I manually (in the promise driver) change
the I/O addresses to something below 0x10000, everything works fine.

This happens to my Promise Ultra33 card and the same scenario has been
reported by others.

I've tried to set the I/O addresses to the address & 0xffff, in case it's the
Promise chip that can only handle 16 bit I/O addresses, but this doesn't work.
Also, no matter what I/O address is mapped and read below 0x10000, it is
possible to read them even though no interresting data is found. For all
addresses above 0xffff, the machine check occurs. It seems that something is
not set up right.

>How-To-Repeat:
Put a Promise Ultra33 in a SX and boot a current kernel that has pciide
configured.
>Fix:
Either find out why the high I/O addresses doesn't work or make some machine
dependent moving around of PCI I/O.

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->analyzed 
State-Changed-By: thorpej 
State-Changed-When: Sat Apr 22 22:19:57 PDT 2000 
State-Changed-Why:  
The problem is actually with the device, not the Alpha itself.  The 
devices are supposed to respond to any address within the 32-bit I/O 
range. 

There needs to be some quirk to deal with this on a per-device basis. 

From: "Erik E. Fair" <fair@clock.org>
To: NetBSD GNATS Problem Report Tracking System <gnats-bugs@gnats.netbsd.org>
Cc:  
Subject: Re: port-alpha/8460
Date: Thu, 17 Jan 2002 23:56:13 -0800

 Did the PCI quirk table get implmented?

 	looking for PRs to close,

 	Erik <fair@netbsd.org>
>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.