arm/150581: Unknown error generates IRQ address decoding error [patch]

Sat Sep 18 09:10:04 UTC 2010

The following reply was made to PR arm/150581; it has been noted by GNATS.

From: Johny Mattsson <johny.mattsson+fbsd at gmail.com>
To: Tyler Saylor <wthww at 680x0.com>
Cc: FreeBSD-gnats-submit at freebsd.org, freebsd-arm at freebsd.org, 
	Mark Tinguely <marktinguely at gmail.com>
Subject: Re: arm/150581: Unknown error generates IRQ address decoding error [patch]
Date: Sat, 18 Sep 2010 19:01:51 +1000

 --005045013dcc1b66c1049084eec3
 Content-Type: multipart/alternative; boundary=005045013dcc1b66bb049084eec1

 --005045013dcc1b66bb049084eec1
 Content-Type: text/plain; charset=UTF-8

 Hi Tyler (and list),

 It turned out this was the same issue I've been trying to hunt down the
 cause of for a couple of weeks. With a lot of help from Mark Tinguely I've
 finally nailed it.

 This problem is caused by a double-whammy of bugs.

 First of all, the USB bridge address decoding register definitions fail to
 account for the main offset from the base of the USB port range. This means
 that decode_win_usb_setup() in sys/arm/mv/common.c doesn't actually manage
 to set up the windows properly. Instead of poking the address decoding
 registers it writes to the ID and HWGENERAL registers, and possibly others
 depending on how much RAM is installed. As a result of not getting the
 windows set up properly, the USB controller ends up only being capable of
 decoding a limited range of addresses. The precise range might depend on how
 the boot loader initialized the controller, or it might use a default range.
 As I only have one type of hardware I can't readily verify which it is.

 With the incorrect windows established, under heavy USB I/O the controller
 typically ends up trying to decode an address which is outside its
 window(s), and raises an error interrupt for it. This in itself is not
 fatal.

 The actual hang is caused by a failure to sufficiently clear the error
 condition in the error interrupt handler (err_intr() in
 dev/usb/controllers/ehci_mv.c). For an address decode error, it is necessary
 to read out the error address from the bridge error address register.
 Failure to do so before returning from the interrupt handler causes the
 interrupt to be reissued.

 The attached patch addresses both issues. I have successfully tested it on
 my 88F6281 based Pogoplug, and I have verified the register addresses
 against the 88F5281 documentation.

 Unless someone can find fault with this patch, I'd love to see this
 committed.

 Regards,
 /Johny

 --005045013dcc1b66bb049084eec1
 Content-Type: text/html; charset=UTF-8
 Content-Transfer-Encoding: quoted-printable

Hi Tyler (and list), It turned out this was the same issue I&#39;ve =
 been trying to hunt down the cause of for a couple of weeks. With a lot of =
 help from Mark Tinguely I&#39;ve finally nailed it. This problem is =
 caused by a double-whammy of bugs. 
 First of all, the USB bridge address decoding register definitions fail=
 to account for the main offset from the base of the USB port range. This m=
 eans that decode_win_usb_setup() in sys/arm/mv/common.c doesn&#39;t actuall=
 y manage to set up the windows properly. Instead of poking the address deco=
 ding registers it writes to the ID and HWGENERAL registers, and possibly ot=
 hers depending on how much RAM is installed. As a result of not getting the=
 windows set up properly, the USB controller ends up only being capable of =
 decoding a limited range of addresses. The precise range might depend on ho=
 w the boot loader initialized the controller, or it might use a default ran=
 ge. As I only have one type of hardware I can&#39;t readily verify which it=
 is. 
 With the incorrect windows established, under heavy USB I/O the control=
 ler typically ends up trying to decode an address which is outside its wind=
 ow(s), and raises an error interrupt for it. This in itself is not fatal.<b=
 r>
 The actual hang is caused by a failure to sufficiently clear the error =
 condition in the error interrupt handler (err_intr() in dev/usb/controllers=
 /ehci_mv.c). For an address decode error, it is necessary to read out the e=
 rror address from the bridge error address register. Failure to do so befor=
 e returning from the interrupt handler causes the interrupt to be reissued.=
 
 The attached patch addresses both issues. I have successfully tested it=
 on my 88F6281 based Pogoplug, and I have verified the register addresses a=
 gainst the 88F5281 documentation. Unless someone can find fault with=
 this patch, I&#39;d love to see this committed. 
 Regards, /Johny

 --005045013dcc1b66bb049084eec1--
 --005045013dcc1b66c1049084eec3
 Content-Type: application/octet-stream; name="arm150581.patch"
 Content-Disposition: attachment; filename="arm150581.patch"
 Content-Transfer-Encoding: base64
 X-Attachment-Id: f_ge88ndz60

 LS0tIHN5cy9kZXYvdXNiL2NvbnRyb2xsZXIvZWhjaV9tdi5jLm9yaWcJMjAxMC0wOS0xNyAxODo1
 NjowMy4wMDAwMDAwMDAgKzEwMDAKKysrIHN5cy9kZXYvdXNiL2NvbnRyb2xsZXIvZWhjaV9tdi5j
 CTIwMTAtMDktMTggMTg6Mjc6MzYuMDAwMDAwMDAwICsxMDAwCkBAIC05Niw2ICs5Niw3IEBACiAK
 ICNkZWZpbmUJVVNCX0JSSURHRV9JTlRSX0NBVVNFICAweDIxMAogI2RlZmluZQlVU0JfQlJJREdF
 X0lOVFJfTUFTSyAgIDB4MjE0CisjZGVmaW5lCVVTQl9CUklER0VfRVJSX0FERFIgICAgMHgyMUMK
 IAogI2RlZmluZQlNVl9VU0JfQUREUl9ERUNPREVfRVJSICgxIDw8IDApCiAjZGVmaW5lCU1WX1VT
 Ql9IT1NUX1VOREVSRkxPVyAgKDEgPDwgMSkKQEAgLTM2MCw2ICszNjEsMjEgQEAKIAkJCXByaW50
 ZigiSVJRIEVSUjogVW5rbm93biBlcnJvclxuIik7CiAKIAkJRVdSSVRFNChzYywgVVNCX0JSSURH
 RV9JTlRSX0NBVVNFLCAwKTsKKworCQkvKgorCQkgKiBJbiBjYXNlIG9mIGFuIGFkZHJlc3MgZGVj
 b2RlIGVycm9yLCB3ZSBtdXN0IHJlYWQgZnJvbQorCQkgKiB0aGUgVVNCX0JSSURHRV9FUlJfQURE
 UiByZWdpc3RlciB0byBjbGVhciBpdCB0byBhbGxvdworCQkgKiB0aGUgY29udHJvbGxlciB0byBs
 YXRjaCBhIG5ldyBhZGRyZXNzIGluIG5leHQgdGltZSB0aGlzCisJCSAqIGVycm9yIG9jY3Vycy4g
 SWYgd2UgZG9uJ3QgcmVhZCBpdCwgd2UgZ2V0IHRoZSBpbnRlcnJ1cHQKKwkJICogcmVpc3N1ZWQg
 YWQgaW5maW5pdHVtLCBldmVuIHRob3VnaCB3ZSBoYXZlIGNsZWFyZWQgdGhlCisJCSAqIGludGVy
 cnVwdCBjYXVzZS4KKwkJICovCisJCWlmIChjYXVzZSAmIE1WX1VTQl9BRERSX0RFQ09ERV9FUlIp
 CisJCXsKKwkJCXVuc2lnbmVkIGVycmFkZHIgPSBFUkVBRDQoc2MsIFVTQl9CUklER0VfRVJSX0FE
 RFIpOworCQkJcHJpbnRmKCJJUlEgRVJSOiBVU0IgQnJpZGdlIEVycm9yIEFkZHJlc3M6IDB4JTA4
 eFxuIiwKKwkJCQllcnJhZGRyKTsKKwkJfQogCX0KIAlyZXR1cm4gKEZJTFRFUl9IQU5ETEVEKTsK
 IH0KLS0tIHN5cy9hcm0vbXYvbXZ3aW4uaC5vcmlnCTIwMTAtMDktMTggMTg6MTM6MDkuMDAwMDAw
 MDAwICsxMDAwCisrKyBzeXMvYXJtL212L212d2luLmgJMjAxMC0wOS0xOCAxODoxNzo0NC4wMDAw
 MDAwMDAgKzEwMDAKQEAgLTEzOCw4ICsxMzgsOCBAQAogI2RlZmluZSBNVl9XSU5fQ0VTQV9BVFRS
 CQkwCiAjZW5kaWYKIAotI2RlZmluZSBNVl9XSU5fVVNCX0NUUkwobikJCSgweDEwICogKG4pICsg
 MHgwKQotI2RlZmluZSBNVl9XSU5fVVNCX0JBU0UobikJCSgweDEwICogKG4pICsgMHg0KQorI2Rl
 ZmluZSBNVl9XSU5fVVNCX0NUUkwobikJCSgweDEwICogKG4pICsgMHgzMjApCisjZGVmaW5lIE1W
 X1dJTl9VU0JfQkFTRShuKQkJKDB4MTAgKiAobikgKyAweDMyNCkKICNkZWZpbmUgTVZfV0lOX1VT
 Ql9NQVgJCQk0CiAKICNkZWZpbmUgTVZfV0lOX0VUSF9CQVNFKG4pCQkoMHg4ICogKG4pICsgMHgy
 MDApCg==
 --005045013dcc1b66c1049084eec3--