Date: Sat, 18 Sep 2010 09:10:04 GMT From: Johny Mattsson <johny.mattsson+fbsd@gmail.com> To: freebsd-arm@FreeBSD.org Subject: Re: arm/150581: Unknown error generates IRQ address decoding error [patch] Message-ID: <201009180910.o8I9A4pF043433@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR arm/150581; it has been noted by GNATS. From: Johny Mattsson <johny.mattsson+fbsd@gmail.com> To: Tyler Saylor <wthww@680x0.com> Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-arm@freebsd.org, Mark Tinguely <marktinguely@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),<br><br>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.<br><br>This problem is = caused by a double-whammy of bugs.<br> <br>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'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't readily verify which it= is.<br> <br>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> <br>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.= <br> <br>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.<br><br>Unless someone can find fault with= this patch, I'd love to see this committed.<br> <br>Regards,<br>/Johny<br> --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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201009180910.o8I9A4pF043433>