From nobody@FreeBSD.org  Sat May 22 09:08:14 2004
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 7F85D16A4CE
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 22 May 2004 09:08:14 -0700 (PDT)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 4072643D45
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 22 May 2004 09:08:14 -0700 (PDT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.12.11/8.12.11) with ESMTP id i4MG7Vha051959
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 22 May 2004 09:07:31 -0700 (PDT)
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.12.11/8.12.11/Submit) id i4MG7VQe051958;
	Sat, 22 May 2004 09:07:31 -0700 (PDT)
	(envelope-from nobody)
Message-Id: <200405221607.i4MG7VQe051958@www.freebsd.org>
Date: Sat, 22 May 2004 09:07:31 -0700 (PDT)
From: Hiroyuki Aizu <eyes@navi.org>
To: freebsd-gnats-submit@FreeBSD.org
Subject: CardBus (PCI ?) resource allocation problem
X-Send-Pr-Version: www-2.3

>Number:         67050
>Category:       i386
>Synopsis:       CardBus (PCI ?) resource allocation problem (still on 5.3-BETA2)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    imp
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat May 22 09:10:24 PDT 2004
>Closed-Date:    Fri May 13 14:31:40 MDT 2011
>Last-Modified:  Fri May 13 14:31:40 MDT 2011
>Originator:     Hiroyuki Aizu
>Release:        FreeBSD 5.2-CURRENT
>Organization:
navi.org
>Environment:
FreeBSD ayers.navi.org 5.2-CURRENT FreeBSD 5.2-CURRENT #15: Sun May 16 17:23:16 JST 2004     aizu@ayers.navi.org:/usr/src/sys/i386/compile/ONE  i386
>Description:
      I have trouble with IEEE1394 CardBus card on 5-current. I think it is
CardBus(PCI ?) resource allocation problem. I'll figure out this.

The card cannot attached on 5-current as below message.

(with hw.cardbus.debug=1 and hw.cardbus.cis_debug=1)
-------------------------------------------------------------------------
cardbus1: Expecting link target, got 0x42
cardbus1: Resource not specified in CIS: id=10, size=800
cardbus1: Resource not specified in CIS: id=14, size=4000
cardbus1: Resource not specified in CIS: id=18, size=800
cardbus1: Non-prefetchable memory at 88008000-8800cfff
fwohci0: <Texas Instruments TSB43AB22/A> mem 0x8800c000-0x8800c7ff,0x88008000-0x8800bfff,0x8800c800-0x8800cfff irq 10 at device 0.0 on cardbus1
fwohci0: [GIANT-LOCKED]
fwohci0: OHCI version ff.ff (ROM=1)
fwohci0: invalid OHCI version
fwohci0: fwohci_init failed with err=6
device_probe_and_attach: fwohci0 attach returned 5
cbb1: CardBus card activation failed
-------------------------------------------------------------------------

Next, I was patched to /sys/dev/cardbus/cardbus_cis.c like below.
(Yes, this is very dirty hack. Just for trouble shooting.)
-------------------------------------------------------------------------
--- cardbus_cis.c.orig	Mon Apr 12 04:22:25 2004
+++ cardbus_cis.c	Sun May 16 17:23:03 2004
@@ -993,6 +993,9 @@ cardbus_add_map(device_t cbdev, device_t
 static void
 cardbus_pickup_maps(device_t cbdev, device_t child)
 {
+#if 1
+	cardbus_add_map(cbdev, child, PCIR_BAR(0));
+#else
 	struct cardbus_devinfo *dinfo = device_get_ivars(child);
 	int reg;
 
@@ -1003,6 +1006,7 @@ cardbus_pickup_maps(device_t cbdev, devi
 	 */
 	for (reg = 0; reg < dinfo->pci.cfg.nummaps; reg++)
 		cardbus_add_map(cbdev, child, PCIR_BAR(reg));
+#endif
 }
 
 int
-------------------------------------------------------------------------


The card works fine on patched kernel like below.
-------------------------------------------------------------------------
cardbus1: Expecting link target, got 0x42
cardbus1: Resource not specified in CIS: id=10, size=800
cardbus1: Non-prefetchable memory at 88001000-880017ff
fwohci0: <Texas Instruments TSB43AB22/A> mem 0x88001000-0x880017ff irq 10 at device 0.0 on cardbus1
fwohci0: [GIANT-LOCKED]
fwohci0: OHCI version 1.10 (ROM=1)
fwohci0: No. of Isochronous channel is 4.
fwohci0: EUI64 00:40:26:01:04:04:4e:ef
fwohci0: Phy 1394a available S400, 2 ports.
fwohci0: Link S400, max_rec 2048 bytes.
firewire0: <IEEE1394(FireWire) bus> on fwohci0
sbp0: <SBP-2/SCSI over FireWire> on firewire0
fwohci0: Initiate bus reset
fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode
firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me)
firewire0: bus manager 0 (me)
-------------------------------------------------------------------------

>How-To-Repeat:
      
>Fix:
      
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-i386->imp 
Responsible-Changed-By: arved 
Responsible-Changed-When: Mon Aug 23 21:03:38 GMT 2004 
Responsible-Changed-Why:  
Over to imp, the Cardbus expert. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=67050 

From: "M. Warner Losh" <imp@freebsd.org>
To: freebsd-gnats-submit@freebsd.org, eyes@navi.org
Cc:  
Subject: Re: i386/67050: CardBus (PCI ?) resource allocation problem
Date: Mon, 23 Aug 2004 15:14:30 -0600

 Maybe it isn't the fact that there are two different ranges assigned, 
 but rather some (all?) of the resources assigned are used by someone else.
 
 0x88001000-0x880017ff
 vs
 0x8800c000-0x8800c7ff,0x88008000-0x8800bfff,0x8800c800-0x8800cfff
 
 so I'm not sure what the real difference here is.
 

From: "Hiroyuki Aizu" <eyes@navi.org>
To: "M. Warner Losh" <imp@freebsd.org>,
	freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: i386/67050: CardBus (PCI ?) resource allocation problem
Date: Sun, 29 Aug 2004 18:05:07 +0900

 Hi
 Warner-san.
 
 I reconfirmed this problem on 5.3-BETA2, today.
 
 On Mon, 23 Aug 2004 15:14:30 -0600, M. Warner Losh <imp@freebsd.org> wro=
 te:
 
 > Maybe it isn't the fact that there are two different ranges assigned, =
  =
 
 > but rather some (all?) of the resources assigned are used by someone  =
 
 > else.
 >
 > 0x88001000-0x880017ff
 > vs
 > 0x8800c000-0x8800c7ff,0x88008000-0x8800bfff,0x8800c800-0x8800cfff
 >
 > so I'm not sure what the real difference here is.
 >
 
 So I checked the resources assignment with "devinfo -u".
 But there are only following difference.
 
 devinfo-nomal.log is logged on normal kernel.
 devinfo-ok.log is logged on patched kernel.
 
 --- devinfo-normal.logThu Aug 26 23:32:25 2004
 +++ devinfo-ok.logThu Aug 26 00:53:02 2004
 @@ -103,7 +103,9 @@
       0x80001000-0x80001fff (cbb1)
       0x80002000-0x87ffffff (root0)
       0x88000000-0x880003ff (pccard0)
 -    0x88000400-0xefffffff (root0)
 +    0x88000400-0x88000fff (root0)
 +    0x88001000-0x880017ff (fwohci0)
 +    0x88001800-0xefffffff (root0)
       0xf0000000-0xf7ffffff (drm0)
       0xf8000000-0xff9edfff (root0)
       0xff9ee000-0xff9eefff (ohci0)
 -----------------------------------------------------------
 
 And next, I try following patch.
 With this patched kernel works!
 It does just turn order of call cardbus_add_map() upside down.
 
 The assigned mem area is  =
 
 0x8800c000-0x8800c7ff,0x88008000-0x8800bfff,0x8800c800-0x8800cfff.
 That is same as problem kernel case.
 
 How do you think about this?
 I'll provide any other information if you want.
 
 Thank you.
 
 -----------------------------------------------------------
 --- cardbus_cis.c.origMon Apr 12 04:22:25 2004
 +++ cardbus_cis.cSun Aug 29 17:04:23 2004
 @@ -1001,8 +1001,13 @@
    * Maybe this isn't any longer necessary now that we have fixed
    * CIS parsing and we should filter things here?  XXX
    */
 +#if 1
 +	for (reg =3D dinfo->pci.cfg.nummaps-1; reg > -1; reg--)
 +	cardbus_add_map(cbdev, child, PCIR_BAR(reg));
 +#else
   	for (reg =3D 0; reg < dinfo->pci.cfg.nummaps; reg++)
   	cardbus_add_map(cbdev, child, PCIR_BAR(reg));
 +#endif
   }
 
   int
 -----------------------------------------------------------
 
 With above patched kernel output.
 -----------------------------------------------------------
 cardbus1: Expecting link target, got 0x42
 cardbus1: Resource not specified in CIS: id=3D18, size=3D800
 cardbus1: Resource not specified in CIS: id=3D14, size=3D4000
 cardbus1: Resource not specified in CIS: id=3D10, size=3D800
 fwohci0: <Texas Instruments TSB43AB22/A> mem  =
 
 0x8800c000-0x8800c7ff,0x88008000-0x8800bfff,0x8800c800-0x8800cfff irq 11=
   =
 
 at device 0.0 on cardbus1
 fwohci0: [GIANT-LOCKED]
 fwohci0: OHCI version 1.10 (ROM=3D1)
 fwohci0: No. of Isochronous channels is 4.
 fwohci0: EUI64 00:40:26:01:04:04:4e:f1
 fwohci0: Phy 1394a available S400, 2 ports.
 fwohci0: Link S400, max_rec 2048 bytes.
 firewire0: <IEEE1394(FireWire) bus> on fwohci0
 sbp0: <SBP-2/SCSI over FireWire> on firewire0
 fwohci0: Initiate bus reset
 fwohci0: node_id=3D0xc000ffc0, gen=3D1, CYCLEMASTER mode
 firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me)
 firewire0: bus manager 0 (me)
 -----------------------------------------------------------
 
 
 And I attach kernel message based 5.3-BETA2 for reconfirmation.
 
 The original 5.3-BETA2 output next messages.
 -----------------------------------------------------------
 cardbus1: Expecting link target, got 0x42
 cardbus1: Resource not specified in CIS: id=3D10, size=3D800
 cardbus1: Resource not specified in CIS: id=3D14, size=3D4000
 cardbus1: Resource not specified in CIS: id=3D18, size=3D800
 fwohci0: <Texas Instruments TSB43AB22/A> mem  =
 
 0x8800c000-0x8800c7ff,0x88008000-0x8800bfff,0x8800c800-0x8800cfff irq 11=
   =
 
 at device 0.0 on cardbus1
 fwohci0: [GIANT-LOCKED]
 fwohci0: OHCI version ff.ff (ROM=3D1)
 fwohci0: invalid OHCI version
 fwohci0: fwohci_init failed with err=3D6
 device_attach: fwohci0 attach returned 5
 cbb1: CardBus card activation failed
 -----------------------------------------------------------
 
 With my first patched kernel.
 -----------------------------------------------------------
 cardbus1: Expecting link target, got 0x42
 cardbus1: Resource not specified in CIS: id=3D10, size=3D800
 fwohci0: <Texas Instruments TSB43AB22/A> mem 0x88001000-0x880017ff irq 1=
 1  =
 
 at device 0.0 on cardbus1
 fwohci0: [GIANT-LOCKED]
 fwohci0: OHCI version 1.10 (ROM=3D1)
 fwohci0: No. of Isochronous channels is 4.
 fwohci0: EUI64 00:40:26:01:04:04:4e:f1
 fwohci0: Phy 1394a available S400, 2 ports.
 fwohci0: Link S400, max_rec 2048 bytes.
 firewire0: <IEEE1394(FireWire) bus> on fwohci0
 sbp0: <SBP-2/SCSI over FireWire> on firewire0
 fwohci0: Initiate bus reset
 fwohci0: node_id=3D0xc000ffc0, gen=3D1, CYCLEMASTER mode
 firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me)
 firewire0: bus manager 0 (me)
 -----------------------------------------------------------
 
 >>From difference between two debug messages, I think it is problem that
 kernel allocate non-requested resource from driver.
 It has side effects in this case.
 
 In the PCI firewire driver reqests I/O memory that specified with
 rid = 0x10 like this.
 
 (from /sys/dev/firewire/fwohci_pci.c)
     rid = PCI_CBMEM;   /* (= PCIR_BAR(0) = 0x10) */
     sc->bsr = bus_alloc_resource_any(self, SYS_RES_MEMORY, &rid, RF_ACTIVE);
 
 But 5-curret kernel allocates all memory resource (rid = 0x10, 0x14, 0x18).
 
     fwohci0: <Texas Instruments TSB43AB22/A> mem 0x8800c000-0x8800c7ff,0x88008000-0x8800bfff,0x8800c800-0x8800cfff irq 10 at device 0.0 on cardbus1
 
 With my patch, it prevent add surplus resource to resource list.
 (Yes I know, this is not real solution.)
 
 # And, I don't know why the IEEE1394 card does not works with all memory
 #  resouces allocated...

State-Changed-From-To: open->suspended 
State-Changed-By: linimon 
State-Changed-When: Sat Nov 20 06:39:56 GMT 2004 
State-Changed-Why:  
(with bugmeister hat on) 

Adding to audit trail from followup email from Warner: 

"works for me".  There's something odd going on with resources, but I 
can't for the life of me figure out it. 

(So let's mark this one Suspended for now, since Warner can't duplicate 
it readily -- mcl.) 

http://www.freebsd.org/cgi/query-pr.cgi?pr=67050 
State-Changed-From-To: suspended->open 
State-Changed-By: imp 
State-Changed-When: Fri Nov 19 23:51:40 MST 2004 
State-Changed-Why:  
Just because I can't recreate it doesn't mean I'm uninterested in 
finding the cause of the problem for the submitter.  I'm changing the 
status back to open because it is a real and recent problem. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=67050 
State-Changed-From-To: open->closed 
State-Changed-By: imp 
State-Changed-When: Fri May 13 14:30:14 MDT 2011 
State-Changed-Why:  
This bug is a duplicate.  73171 is better, so we'll leave that one 
open.  Baldwin's changes may fix that, but I'll wait until I can test 
it to close that. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=67050 
>Unformatted:
