From owner-freebsd-acpi@FreeBSD.ORG Sun Apr 14 00:39:25 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EDE98E18 for ; Sun, 14 Apr 2013 00:39:25 +0000 (UTC) (envelope-from mccuba48@gmail.com) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by mx1.freebsd.org (Postfix) with ESMTP id B35EA1A6E for ; Sun, 14 Apr 2013 00:39:25 +0000 (UTC) Received: by mail-ve0-f176.google.com with SMTP id ox1so3344160veb.35 for ; Sat, 13 Apr 2013 17:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:subject:message-id:x-mailer :mime-version:content-type:content-transfer-encoding; bh=BqBzU3jhbiBwSKdr9yhHdspnxgAYlp2xp9NC0dkafc0=; b=BcTzOFNxr38wHCkgMJaFn5rmVmGdvFyKm7mbaVGZM0DzuHCd5SV/TMhro15i+/oVPX YA3lCr1pC7Ot7g08Mz/+rUQqH2wKUiW1JCoQeHtJoLWd2q1Rl7l0XrJ1krTh0qjP1d1y qD2Q8j28TaJzLIgQ2Xb5toFyAypWtkjW2SbrWp+iBM/RPj5mKPIUcx87jyp91iso044e WxhZ3OcSQnQ7a4HFKPjNlpDGBiAixHcczTc7hAEANgcRMJy3GBvBDM1oAc9A6l/YdgHu JneU1ZeCDju6v6EuaqIxz9XX2uHy3/hb/ZpKeeJ+5j3ZtmYc33nJ87KSjoH/+8iPxvGL g+MQ== X-Received: by 10.221.1.144 with SMTP id nq16mr12394702vcb.57.1365899959454; Sat, 13 Apr 2013 17:39:19 -0700 (PDT) Received: from t61.mama.bogus (pool-72-68-7-73.nwrknj.east.verizon.net. [72.68.7.73]) by mx.google.com with ESMTPS id e8sm14157358vdt.7.2013.04.13.17.39.17 (version=SSLv3 cipher=RC4-SHA bits=128/128); Sat, 13 Apr 2013 17:39:19 -0700 (PDT) Sender: Manuel Chaviano Date: Sat, 13 Apr 2013 20:39:07 -0400 From: Manuel Chaviano To: freebsd-acpi@freebsd.org Subject: Asus EEEPC X101 - asus_acpi not working Message-ID: <20130413203907.44744ed7.manny@computer.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: base64 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 00:39:26 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpKdXN0IGlu c3RhbGxlZCBGcmVlQlNEIDkuMSBmcm9tIG1lbXN0aWNrIElTTy4NCmFjcGlfYXN1cyBzZWVtcyB0 byBsb2FkIGJ1dCBJIGNhbm5vdCBzZWUgYW55dGhpbmcgDQppbiBzeXNjdGw6DQoNCiQgY2F0IC9i b290L2xvYWRlci5jb25mDQpzbmRfaGRhX2xvYWQ9IllFUyINCmFjcGlfYXN1c19sb2FkPSJZRVMi DQprZXJuLmh6PTEwMA0KI2h3LnBjaS5kb19wb3dlcl9ub2RyaXZlcj0xDQpody5wc20uc3luYXB0 aWNzX3N1cHBvcnQ9MQ0KDQokIHN5c2N0bCAtYSB8IGdyZXAgYXN1cw0KJCANCg0Kcm9vdEB4MTAx Oi91c3IvaG9tZS9tYW5ueSAjIGtsZGxvYWQgYWNwaV9hc3VzDQprbGRsb2FkOiBjYW4ndCBsb2Fk IGFjcGlfYXN1czogRmlsZSBleGlzdHMNCnJvb3RAeDEwMTovdXNyL2hvbWUvbWFubnkgIyANCg0K V2hlbiB0cnlpbmcgdG8gYWRqdXN0IHRoZSBicmlnaHRuZXNzIEkgZ2V0IEFDUEkgRXhjZXB0aW9u IGVycm9yczoNCg0KQ29weXJpZ2h0IChjKSAxOTkyLTIwMTIgVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwg MTk5MiwgMTk5MywgMTk5NA0KICAgICAgICBUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBv ZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVkLg0KRnJlZUJTRCBpcyBhIHJlZ2lzdGVy ZWQgdHJhZGVtYXJrIG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24uDQpGcmVlQlNEIDkuMS1SRUxF QVNFICMwIHIyNDM4MjY6IFR1ZSBEZWMgIDQgMDY6NTU6MzkgVVRDIDIwMTINCiAgICByb290QG9i cmlhbi5jc2UuYnVmZmFsby5lZHU6L3Vzci9vYmovdXNyL3NyYy9zeXMvR0VORVJJQyBpMzg2DQpD UFU6IEludGVsKFIpIEF0b20oVE0pIENQVSBONDM1ICAgQCAxLjMzR0h6ICgxMzMzLjIxLU1IeiA2 ODYtY2xhc3MgQ1BVKQ0KICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweDEwNmNhICBG YW1pbHkgPSA2ICBNb2RlbCA9IDFjICBTdGVwcGluZyA9IDEwDQogIEZlYXR1cmVzPTB4YmZlOWZi ZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxN Q0EsQw0KTU9WLFBBVCxDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxU TSxQQkU+DQogIEZlYXR1cmVzMj0weDQwZTM5ZDxTU0UzLERURVM2NCxNT04sRFNfQ1BMLEVTVCxU TTIsU1NTRTMsQ1gxNix4VFBSLFBEQ00sTU9WQkU+DQogIEFNRCBGZWF0dXJlcz0weDIwMTAwMDAw PE5YLExNPg0KICBBTUQgRmVhdHVyZXMyPTB4MTxMQUhGPg0KICBUU0M6IFAtc3RhdGUgaW52YXJp YW50LCBwZXJmb3JtYW5jZSBzdGF0aXN0aWNzDQpyZWFsIG1lbW9yeSAgPSAxMDczNzQxODI0ICgx MDI0IE1CKQ0KYXZhaWwgbWVtb3J5ID0gMTAyMjAwNTI0OCAoOTc0IE1CKQ0KRXZlbnQgdGltZXIg IkxBUElDIiBxdWFsaXR5IDQwMA0KQUNQSSBBUElDIFRhYmxlOiA8QV9NX0lfIE9FTUFQSUMgPg0K RnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3RlZDogMiBDUFVzDQpGcmVl QlNEL1NNUDogMSBwYWNrYWdlKHMpIHggMSBjb3JlKHMpIHggMiBIVFQgdGhyZWFkcw0KIGNwdTAg KEJTUCk6IEFQSUMgSUQ6ICAwDQogY3B1MSAoQVAvSFQpOiBBUElDIElEOiAgMQ0KaW9hcGljMDog Q2hhbmdpbmcgQVBJQyBJRCB0byAyDQppb2FwaWMwIDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzIG9u IG1vdGhlcmJvYXJkDQprYmQxIGF0IGtiZG11eDANCmN0bDogQ0FNIFRhcmdldCBMYXllciBsb2Fk ZWQNCmFjcGkwOiA8QV9NX0lfIE9FTVhTRFQ+IG9uIG1vdGhlcmJvYXJkDQphY3BpX2VjMDogPEVt YmVkZGVkIENvbnRyb2xsZXI6IEdQRSAweDFjLCBFQ0RUPiBwb3J0IDB4NjIsMHg2NiBvbiBhY3Bp MA0KYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpDQphY3BpMDogcmVzZXJ2YXRpb24gb2YgZmZi MDAwMDAsIDEwMDAwMCAoMykgZmFpbGVkDQphY3BpMDogcmVzZXJ2YXRpb24gb2YgZmZmMDAwMDAs IDEwMDAwMCAoMykgZmFpbGVkDQphY3BpMDogcmVzZXJ2YXRpb24gb2YgZmVlMDAwMDAsIDEwMDAg KDMpIGZhaWxlZA0KYWNwaTA6IHJlc2VydmF0aW9uIG9mIDAsIGEwMDAwICgzKSBmYWlsZWQNCmFj cGkwOiByZXNlcnZhdGlvbiBvZiAxMDAwMDAsIDNmNjAwMDAwICgzKSBmYWlsZWQNCmNwdTA6IDxB Q1BJIENQVT4gb24gYWNwaTANCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTANCmF0dGltZXIwOiA8 QVQgdGltZXI+IHBvcnQgMHg0MC0weDQzIGlycSAwIG9uIGFjcGkwDQpUaW1lY291bnRlciAiaTgy NTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMA0KRXZlbnQgdGltZXIgImk4MjU0IiBm cmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDEwMA0KYXRydGMwOiA8QVQgcmVhbHRpbWUgY2xv Y2s+IHBvcnQgMHg3MC0weDcxIGlycSA4IG9uIGFjcGkwDQpFdmVudCB0aW1lciAiUlRDIiBmcmVx dWVuY3kgMzI3NjggSHogcXVhbGl0eSAwDQpocGV0MDogPEhpZ2ggUHJlY2lzaW9uIEV2ZW50IFRp bWVyPiBpb21lbSAweGZlZDAwMDAwLTB4ZmVkMDAzZmYgb24gYWNwaTANClRpbWVjb3VudGVyICJI UEVUIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA5NTANCkV2ZW50IHRpbWVyICJIUEVU IiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NTANCkV2ZW50IHRpbWVyICJIUEVUMSIg ZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgNDQwDQpFdmVudCB0aW1lciAiSFBFVDIiIGZy ZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDQ0MA0KVGltZWNvdW50ZXIgIkFDUEktZmFzdCIg ZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSA5MDANCmFjcGlfdGltZXIwOiA8MjQtYml0IHRp bWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4ODA4LTB4ODBiIG9uIGFjcGkwDQpwY2liMDogPEFD UEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwDQpwY2kwOiA8QUNQ SSBQQ0kgYnVzPiBvbiBwY2liMA0KdmdhcGNpMDogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IHBv cnQgMHhlYzAwLTB4ZWMwNyBtZW0gMHhmN2YwMDAwMC0weGY3ZjdmZmZmLDB4ZDAwMDAwMDAtMHhk ZmZmZmZmZiwweGY3ZTAwMDAwLTB4ZjdlZmZmZmYgaXJxIDE2IGF0IGRldmljZSAyLjAgb24gcGNp MA0KYWdwMDogPEludGVsIFBpbmV2aWV3IChNKSBTVkdBIGNvbnRyb2xsZXI+IG9uIHZnYXBjaTAN CmFncDA6IGFwZXJ0dXJlIHNpemUgaXMgMjU2TSwgZGV0ZWN0ZWQgODE4OGsgc3RvbGVuIG1lbW9y eQ0KdmdhcGNpMTogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IG1lbSAweGY3ZjgwMDAwLTB4Zjdm ZmZmZmYgYXQgZGV2aWNlIDIuMSBvbiBwY2kwDQpoZGFjMDogPEludGVsIDgyODAxRyBIREEgQ29u dHJvbGxlcj4gbWVtIDB4ZjdkZjgwMDAtMHhmN2RmYmZmZiBpcnEgMjIgYXQgZGV2aWNlIDI3LjAg b24gcGNpMA0KcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYgYXQgZGV2aWNlIDI4 LjAgb24gcGNpMA0KcGNpMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjENCnBjaWIyOiA8QUNQSSBQ Q0ktUENJIGJyaWRnZT4gaXJxIDE3IGF0IGRldmljZSAyOC4xIG9uIHBjaTANCnBjaTE6IDxBQ1BJ IFBDSSBidXM+IG9uIHBjaWIyDQphdGgwOiA8QXRoZXJvcyA5Mjg1PiBtZW0gMHhmYmZmMDAwMC0w eGZiZmZmZmZmIGlycSAxNyBhdCBkZXZpY2UgMC4wIG9uIHBjaTENClthdGhdIEFSOTI4NUVfMjAg ZGV0ZWN0ZWQ7IHVzaW5nIFhFIFRYIGdhaW4gdGFibGVzDQphdGgwOiBBUjkyODUgbWFjIDE5Mi4y IFJGNTEzMyBwaHkgMTQuMA0KdWhjaTA6IDxJbnRlbCA4MjgwMUcgKElDSDcpIFVTQiBjb250cm9s bGVyIFVTQi1BPiBwb3J0IDB4ZTQwMC0weGU0MWYgaXJxIDIzIGF0IGRldmljZSAyOS4wIG9uIHBj aTANCnVoY2kwOiBMZWdTdXAgPSAweDJmMDANCnVzYnVzMCBvbiB1aGNpMA0KdWhjaTE6IDxJbnRl bCA4MjgwMUcgKElDSDcpIFVTQiBjb250cm9sbGVyIFVTQi1CPiBwb3J0IDB4ZTQ4MC0weGU0OWYg aXJxIDE5IGF0IGRldmljZSAyOS4xIG9uIHBjaTANCnVoY2kxOiBMZWdTdXAgPSAweDJmMDANCnVz YnVzMSBvbiB1aGNpMQ0KdWhjaTI6IDxJbnRlbCA4MjgwMUcgKElDSDcpIFVTQiBjb250cm9sbGVy IFVTQi1DPiBwb3J0IDB4ZTgwMC0weGU4MWYgaXJxIDE4IGF0IGRldmljZSAyOS4yIG9uIHBjaTAN CnVoY2kyOiBMZWdTdXAgPSAweDJmMDANCnVzYnVzMiBvbiB1aGNpMg0KdWhjaTM6IDxJbnRlbCA4 MjgwMUcgKElDSDcpIFVTQiBjb250cm9sbGVyIFVTQi1EPiBwb3J0IDB4ZTg4MC0weGU4OWYgaXJx IDIwIGF0IGRldmljZSAyOS4zIG9uIHBjaTANCnVoY2kzOiBMZWdTdXAgPSAweDJmMDANCnVzYnVz MyBvbiB1aGNpMw0KZWhjaTA6IDxJbnRlbCA4MjgwMUdCL1IgKElDSDcpIFVTQiAyLjAgY29udHJv bGxlcj4gbWVtIDB4ZjdkZjdjMDAtMHhmN2RmN2ZmZiBpcnEgMjMgYXQgZGV2aWNlIDI5Ljcgb24g cGNpMA0KdXNidXM0OiBFSENJIHZlcnNpb24gMS4wDQp1c2J1czQgb24gZWhjaTANCnBjaWIzOiA8 QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMA0KcGNpNDogPEFDUEkg UENJIGJ1cz4gb24gcGNpYjMNCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4w IG9uIHBjaTANCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMA0KYXRhcGNpMDogPEludGVsIElDSDcg U0FUQTMwMCBjb250cm9sbGVyPiBwb3J0IDB4ZTA4MC0weGUwODcsMHhlMDAwLTB4ZTAwMywweGRj MDAtMHhkYzA3LDB4ZDg4MC0weGQ4ODMsMHhkODAwLTB4ZDgwZiBtZW0gMHhmN2RmNzgwMC0weGY3 ZGY3YmZmIGlycSAyMSBhdCBkZXZpY2UgMzEuMiBvbiBwY2kwDQphdGEyOiA8QVRBIGNoYW5uZWw+ IGF0IGNoYW5uZWwgMCBvbiBhdGFwY2kwDQphdGEzOiA8QVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwg MSBvbiBhdGFwY2kwDQpwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmljZSAzMS4zIChu byBkcml2ZXIgYXR0YWNoZWQpDQphY3BpX2xpZDA6IDxDb250cm9sIE1ldGhvZCBMaWQgU3dpdGNo PiBvbiBhY3BpMA0KYWNwaV9idXR0b24wOiA8U2xlZXAgQnV0dG9uPiBvbiBhY3BpMA0KYWNwaV9i dXR0b24xOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3BpMA0KYWNwaV90ejA6IDxUaGVybWFsIFpvbmU+ IG9uIGFjcGkwDQpiYXR0ZXJ5MDogPEFDUEkgQ29udHJvbCBNZXRob2QgQmF0dGVyeT4gb24gYWNw aTANCmFjcGlfYWNhZDA6IDxBQyBBZGFwdGVyPiBvbiBhY3BpMA0KYXRrYmRjMDogPEtleWJvYXJk IGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTANCmF0a2Jk MDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwDQprYmQwIGF0IGF0a2JkMA0KYXRrYmQw OiBbR0lBTlQtTE9DS0VEXQ0KcHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMwDQpw c20wOiBbR0lBTlQtTE9DS0VEXQ0KcHNtMDogbW9kZWwgU3luYXB0aWNzIFRvdWNocGFkLCBkZXZp Y2UgSUQgMA0KcG10aW1lcjAgb24gaXNhMA0Kc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdz IDB4MTAwIG9uIGlzYTANCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMw MD4NCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhh MDAwMC0weGJmZmZmIG9uIGlzYTANCmF0YTA6IDxBVEEgY2hhbm5lbD4gYXQgcG9ydCAweDFmMC0w eDFmNywweDNmNiBpcnEgMTQgb24gaXNhMA0KYXRhMTogPEFUQSBjaGFubmVsPiBhdCBwb3J0IDB4 MTcwLTB4MTc3LDB4Mzc2IGlycSAxNSBvbiBpc2EwDQpwcGMwOiBwYXJhbGxlbCBwb3J0IG5vdCBm b3VuZC4NCmVzdDA6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNw dTANCnA0dGNjMDogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUwDQplc3Qx OiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUxDQpwNHRjYzE6 IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MQ0KVGltZWNvdW50ZXJzIHRp Y2sgZXZlcnkgMTAuMDAwIG1zZWMNCmhkYWNjMDogPFJlYWx0ZWsgQUxDMjY5IEhEQSBDT0RFQz4g YXQgY2FkIDAgb24gaGRhYzANCmhkYWEwOiA8UmVhbHRlayBBTEMyNjkgQXVkaW8gRnVuY3Rpb24g R3JvdXA+IGF0IG5pZCAxIG9uIGhkYWNjMA0KcGNtMDogPFJlYWx0ZWsgQUxDMjY5IChBbmFsb2cg Mi4wK0hQLzIuMCk+IGF0IG5pZCAyMCwzMyBhbmQgMTggb24gaGRhYTANCnVzYnVzMDogMTJNYnBz IEZ1bGwgU3BlZWQgVVNCIHYxLjANCnVzYnVzMTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAN CnVzYnVzMjogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjANCnVzYnVzMzogMTJNYnBzIEZ1bGwg U3BlZWQgVVNCIHYxLjANCnVzYnVzNDogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wDQp1Z2Vu MC4xOiA8SW50ZWw+IGF0IHVzYnVzMA0KdWh1YjA6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFz cyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMwDQp1Z2VuMS4xOiA8SW50ZWw+ IGF0IHVzYnVzMQ0KdWh1YjE6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAx LjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMxDQp1Z2VuMi4xOiA8SW50ZWw+IGF0IHVzYnVzMg0K dWh1YjI6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFk ZHIgMT4gb24gdXNidXMyDQp1Z2VuMy4xOiA8SW50ZWw+IGF0IHVzYnVzMw0KdWh1YjM6IDxJbnRl bCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNi dXMzDQp1Z2VuNC4xOiA8SW50ZWw+IGF0IHVzYnVzNA0KdWh1YjQ6IDxJbnRlbCBFSENJIHJvb3Qg SFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM0DQp1aHViMDog MiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNCnVodWIxOiAyIHBvcnRzIHdp dGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZA0KdWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92 YWJsZSwgc2VsZiBwb3dlcmVkDQp1aHViMzogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxm IHBvd2VyZWQNCmFkYTAgYXQgYXRhMiBidXMgMCBzY2J1czAgdGFyZ2V0IDAgbHVuIDANCmFkYTA6 IDxKTWljcm9uIDEwMDQxNT4gQVRBLTcgU0FUQSAyLnggZGV2aWNlDQphZGEwOiAzMDAuMDAwTUIv cyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNSwgUElPIDUxMmJ5dGVzKQ0KYWRhMDogNzY4Nk1C ICgxNTc0MDkyOCA1MTIgYnl0ZSBzZWN0b3JzOiAxNkggNjNTL1QgMTU2MTZDKQ0KYWRhMDogUHJl dmlvdXNseSB3YXMga25vd24gYXMgYWQ0DQpTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCENClRpbWVj b3VudGVyICJUU0MtbG93IiBmcmVxdWVuY3kgMTA0MTU3MjQgSHogcXVhbGl0eSAxMDAwDQpSb290 IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czQNCnVodWI0OiA4IHBvcnRzIHdpdGggOCByZW1vdmFi bGUsIHNlbGYgcG93ZXJlZA0KUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM0DQp1Z2VuNC4y OiA8R2VuZXJpYz4gYXQgdXNidXM0DQp1bWFzczA6IDxHZW5lcmljIE1hc3MgU3RvcmFnZSBEZXZp Y2UsIGNsYXNzIDAvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAyPiBvbiB1c2J1czQNCnVtYXNzMDog IFNDU0kgb3ZlciBCdWxrLU9ubHk7IHF1aXJrcyA9IDB4NDAwMQ0KdW1hc3MwOjU6MDotMTogQXR0 YWNoZWQgdG8gc2NidXM1DQpkYTAgYXQgdW1hc3Mtc2ltMCBidXMgMCBzY2J1czUgdGFyZ2V0IDAg bHVuIDANCmRhMDogPE11bHRpcGxlIENhcmQgIFJlYWRlciAxLjAwPiBSZW1vdmFibGUgRGlyZWN0 IEFjY2VzcyBTQ1NJLTAgZGV2aWNlIA0KZGEwOiA0MC4wMDBNQi9zIHRyYW5zZmVycw0KZGEwOiAx NTE5M01CICgzMTExNjI4OCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDE5MzZDKQ0KdWdl bjQuMzogPEF6dXJld2F2ZT4gYXQgdXNidXM0DQpUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVm czovZGV2L2FkYTBwMiBbcncsbm9hdGltZV0uLi4NCndsYW4wOiBFdGhlcm5ldCBhZGRyZXNzOiA3 NDoyZjo2ODo4ZTo2OTpmMw0KLi4uDQpBQ1BJIEV4Y2VwdGlvbjogQUVfQU1MX1BBQ0tBR0VfTElN SVQsIEluZGV4ICgweDAwMDAwMDAwMDAwMDAwMEIpIGlzIGJleW9uZCBlbmQgb2Ygb2JqZWN0ICgy MDExMDUyNy9leG9wYXJnMi00NjApDQpBQ1BJIEVycm9yOiBNZXRob2QgcGFyc2UvZXhlY3V0aW9u IGZhaWxlZCBbXFxCTENTXSAoTm9kZSAweGM2MzllOGMwKSwgQUVfQU1MX1BBQ0tBR0VfTElNSVQg KDIwMTEwNTI3L3BzcGFyc2UtNTYwKQ0KQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlv biBmYWlsZWQgW1xcX1NCXy5QQ0kwLlNCUkcuRUMwXy5fUTBCXSAoTm9kZSAweGM2MzllNzIwKSwg QUVfQU1MX1BBQ0tBR0VfTElNSVQgKDIwMTEwNTI3L3BzcGFyc2UtNTYwKQ0KYWNwaV9lYzA6IGV2 YWx1YXRpb24gb2YgcXVlcnkgbWV0aG9kIF9RMEIgZmFpbGVkOiBBRV9BTUxfUEFDS0FHRV9MSU1J VA0KQUNQSSBFeGNlcHRpb246IEFFX0FNTF9QQUNLQUdFX0xJTUlULCBJbmRleCAoMHgwMDAwMDAw MDAwMDAwMDBCKSBpcyBiZXlvbmQgZW5kIG9mIG9iamVjdCAoMjAxMTA1MjcvZXhvcGFyZzItNDYw KQ0KQUNQSSBFcnJvcjogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1xcQkxDU10gKE5v ZGUgMHhjNjM5ZThjMCksIEFFX0FNTF9QQUNLQUdFX0xJTUlUICgyMDExMDUyNy9wc3BhcnNlLTU2 MCkNCkFDUEkgRXJyb3I6IE1ldGhvZCBwYXJzZS9leGVjdXRpb24gZmFpbGVkIFtcXF9TQl8uUENJ MC5TQlJHLkVDMF8uX1EwQl0gKE5vZGUgMHhjNjM5ZTcyMCksIEFFX0FNTF9QQUNLQUdFX0xJTUlU ICgyMDExMDUyNy9wc3BhcnNlLTU2MCkNCmFjcGlfZWMwOiBldmFsdWF0aW9uIG9mIHF1ZXJ5IG1l dGhvZCBfUTBCIGZhaWxlZDogQUVfQU1MX1BBQ0tBR0VfTElNSVQNCkFDUEkgRXhjZXB0aW9uOiBB RV9BTUxfUEFDS0FHRV9MSU1JVCwgSW5kZXggKDB4MDAwMDAwMDAwMDAwMDAwQikgaXMgYmV5b25k IGVuZCBvZiBvYmplY3QgKDIwMTEwNTI3L2V4b3BhcmcyLTQ2MCkNCkFDUEkgRXJyb3I6IE1ldGhv ZCBwYXJzZS9leGVjdXRpb24gZmFpbGVkIFtcXEJMQ1NdIChOb2RlIDB4YzYzOWU4YzApLCBBRV9B TUxfUEFDS0FHRV9MSU1JVCAoMjAxMTA1MjcvcHNwYXJzZS01NjApDQpBQ1BJIEVycm9yOiBNZXRo b2QgcGFyc2UvZXhlY3V0aW9uIGZhaWxlZCBbXFxfU0JfLlBDSTAuU0JSRy5FQzBfLl9RMERdIChO b2RlIDB4YzYzOWU3MDApLCBBRV9BTUxfUEFDS0FHRV9MSU1JVCAoMjAxMTA1MjcvcHNwYXJzZS01 NjApDQphY3BpX2VjMDogZXZhbHVhdGlvbiBvZiBxdWVyeSBtZXRob2QgX1EwRCBmYWlsZWQ6IEFF X0FNTF9QQUNLQUdFX0xJTUlUDQoNCg0Kcm9vdEB4MTAxOi91c3IvaG9tZS9tYW5ueSAjIHVuYW1l IC1hDQpGcmVlQlNEIHgxMDEgOS4xLVJFTEVBU0UgRnJlZUJTRCA5LjEtUkVMRUFTRSAjMCByMjQz ODI2OiBUdWUgRGVjICA0IDA2OjU1OjM5IFVUQyAyMDEyICAgICByb290QG9icmlhbi5jc2UuYnVm ZmFsby5lZHU6L3Vzci9vYmovdXNyL3NyYy9zeXMvR0VORVJJQyAgaTM4Ng0KDQotIC0tIA0KQnll IG5vdy4uLg0KDQpObyBtYW4gZXZlciBwcmF5ZWQgaGVhcnRpbHkgd2l0aG91dCBsZWFybmluZyBz b21ldGhpbmcuDQotIC0tIFJhbHBoIFdhbGRvIEVtZXJzb24NCiAgICAgICBfXw0KICAgICAgLy8v ICAgICAgTWFudWVsIENoYXZpYW5vDQogX18gIC8vLw0KIFxcXC8vLyANCiAgXFhYLyAgICAgICAg IEZyZWVCU0QgOS1TVEFCTEUNCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQpWZXJzaW9u OiBHbnVQRyB2Mi4wLjE5IChGcmVlQlNEKQ0KDQppRVlFQVJFQ0FBWUZBbEZwK3JFQUNna1EwTnJ2 OEUrQnkzM3pIUUNmUnV3WDUza2U2NG5SRW03OVFjRWJQeERlDQo3TVVBblJheStmSUZFL3BmZUtw aXhuazc0SjFKaHUvOA0KPVUxcisNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K From owner-freebsd-acpi@FreeBSD.ORG Sun Apr 14 18:32:38 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 04BC7BBC for ; Sun, 14 Apr 2013 18:32:38 +0000 (UTC) (envelope-from albert@acervin.com) Received: from mail-la0-x243.google.com (mail-la0-x243.google.com [IPv6:2a00:1450:4010:c03::243]) by mx1.freebsd.org (Postfix) with ESMTP id 85C6CCEF for ; Sun, 14 Apr 2013 18:32:37 +0000 (UTC) Received: by mail-la0-f67.google.com with SMTP id fq12so912450lab.2 for ; Sun, 14 Apr 2013 11:32:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=CrtD3C3Ex6qZG5Tn/aEZLjx3UKeo1OxTDAhL/052JtQ=; b=cfxZFZTQ8xn7fettHr7OtqJwsBonMhDYa5feRpID4NMq2M+IYFesRR0NGyI4/p5cTV 33kbrqEsVUkwb0vcl6QJgo1JxRGXiJcT82IDW+Dt0mEG1Py7WoQW8Jookjxep1uRK8B6 EZw4w93O7yecujFK5MMBSSB+Lz2imV/20DA6MkII5+FPqYwCZ5uyQ/BB9JIA/G8D0mvY XFc1NuYMBEtbiGGMeLtj2MF4Zvu6j3T/6nEWm1bQgeMm2vshwE2SVgoKHLQU3PVoh6qh ErxefAAJF3xMDOPq7udhnIM/+2oShps+oFFNVGJOaXip7rkggdfnfIX9HBazjx6cuOtp 4YTg== MIME-Version: 1.0 X-Received: by 10.112.23.232 with SMTP id p8mr9134468lbf.38.1365964356268; Sun, 14 Apr 2013 11:32:36 -0700 (PDT) Received: by 10.112.209.97 with HTTP; Sun, 14 Apr 2013 11:32:36 -0700 (PDT) X-Originating-IP: [92.244.21.21] Date: Sun, 14 Apr 2013 20:32:36 +0200 Message-ID: Subject: Dell Vostro 3300 backlight keys From: Albert Cervin To: freebsd-acpi@freebsd.org X-Gm-Message-State: ALoCoQnOXXM6QO7uGkD7vukDnYyamg0n3KjUSX0w61sYkb8g7rwtKmm4P0lA6vO33Lb0sQeRR9jy Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 18:32:38 -0000 Hi all! Thanks for a great operating system, coming from Linux certainly feels liberating :) I have some small problems though and one of them is that I cannot control backlight on my laptop, a Dell Vostro 3300. This worked under Linux when using acpi_video=legacy kernel parameter (if this helps). I have kldloaded acpi_video and I have hw.acpi.video.lcd0.brightness listed under sysctl but changing it has no effect at all. I would like some guidance where I can look to find a solution or help you guys identify the problem. I am also a developer myself so even though I am a FreeBSD newbie I can still understand technical details :) I know also that there might be other solutions to the problem (that only works under X) but I am interested in a more universal solution. Would appreciate any help! Thanks in advance! // Albert Cervin From owner-freebsd-acpi@FreeBSD.ORG Mon Apr 15 11:06:39 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A75D38BD for ; Mon, 15 Apr 2013 11:06:39 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 7FA29788 for ; Mon, 15 Apr 2013 11:06:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3FB6dlq014998 for ; Mon, 15 Apr 2013 11:06:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3FB6dBQ014996 for freebsd-acpi@FreeBSD.org; Mon, 15 Apr 2013 11:06:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 15 Apr 2013 11:06:39 GMT Message-Id: <201304151106.r3FB6dBQ014996@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 11:06:39 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [ACPI] Suspend/resume broken on Lenovo x220 o kern/171305 acpi [acpi] acpi_tz0: _CRT value is absurd, ignored (256.0C o kern/165381 acpi [cpufreq] powerd(8) eats CPUs for breakfast o kern/164329 acpi [acpi] hw.acpi.thermal.tz0.temperature shows strange v o kern/163268 acpi [acpi_hp] [patch] fix driver detach in absence of CMI o kern/162859 acpi [acpi] ACPI battery/acline monitoring partialy working o kern/161715 acpi [acpi] Dell E6520 doesn't resume after ACPI suspend o kern/161713 acpi [acpi] Suspend on Dell E6520 o kern/160838 acpi [acpi] ACPI Battery Monitor Non-Functional o kern/160419 acpi [acpi_thermal] acpi_thermal kernel thread high CPU usa o kern/158689 acpi [acpi] value of sysctl hw.acpi.thermal.polling_rate ne o kern/154955 acpi [acpi] Keyboard or ACPI doesn't work on Lenovo S10-3 o kern/152438 acpi [acpi]: patch to acpi_asus(4) to add extra sysctls for o kern/152098 acpi [acpi] Lenovo T61p does not resume o i386/146715 acpi [acpi] Suspend works, resume not on a HP Probook 4510s o kern/145306 acpi [acpi]: Can't change brightness on HP ProBook 4510s o i386/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot a i386/122887 acpi [panic] [atkbdc] 7.0-RELEASE on IBM HS20 panics immed s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/91594 acpi [acpi] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/ o kern/73823 acpi [request] acpi / power-on by timer support o kern/56024 acpi ACPI suspend drains battery while in S3 31 problems total. From owner-freebsd-acpi@FreeBSD.ORG Wed Apr 17 00:40:02 2013 Return-Path: Delivered-To: freebsd-acpi@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9A99CDDD for ; Wed, 17 Apr 2013 00:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8D65EA6 for ; Wed, 17 Apr 2013 00:40:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3H0e1GP098976 for ; Wed, 17 Apr 2013 00:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3H0e1BM098975; Wed, 17 Apr 2013 00:40:01 GMT (envelope-from gnats) Date: Wed, 17 Apr 2013 00:40:01 GMT Message-Id: <201304170040.r3H0e1BM098975@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org Cc: From: paranormal Subject: Re: kern/152098: [acpi] Lenovo T61p does not resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: paranormal List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 00:40:02 -0000 The following reply was made to PR kern/152098; it has been noted by GNATS. From: paranormal To: bug-followup@FreeBSD.org, rhyous@yahoo.com Cc: Subject: Re: kern/152098: [acpi] Lenovo T61p does not resume Date: Wed, 17 Apr 2013 03:36:48 +0300 --=-1cNDaFeeK/hPDf44alEq Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Unfortunately it doesn't work for me. With loaded nvidia.ko it didn't even wake up. My investigation continued from single mode without nvidia.ko. I tried with and without hw.acpi.reset_video=3D1, system always wakes up, but screen remains black. My system is stable, build 249161. --=-1cNDaFeeK/hPDf44alEq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAABCgAGBQJRbe6gAAoJEJv+PjkKQxN0sswP/RoycB+Da+z2WXHi6sFgjnBh a8F46HfAg7h1UUoPu2JLdaJfTvnErOa22Zv9yVztXU9vUOLIKurasZa1uvFSLaVp svzYpoc9BpOVX2dfM30hSEVhQwKbgQabLu+TfZd1x38lWEim2s2ZMW8hdW57VxpM NaHpHNtHTixAmWHC/skosI4RDZbNzKM2A3j+gQlmopPZRwDLUMXuhvykpJv9tWcZ rrl+4M8rPShq0Py8vPSVf9OfSZqILvIYk3iwN37s40W1D0wmOSPHPs67gaDIUhYO SB47MSnz+yZG4WGHFj5+0vtZTGcDZ8Up0qGE+tXRY11kHXZPdehKyQGKKW9S4Jwq qyXd5nFIG/YZy9OzxMO6JAhRDo2GJevPTT48VhYBbVy17ohnQ3BTiQfMCvj7s8MQ 6T175eckQiVk+GnQdR4KFlyiddki+OsLJuyjaCyQOs/35VWk16yL0t26ankDGZ+K xjFRR4WMepNj4Owv/GZG8UvbbkmpJqaqfWH/RZXvIaRiuBf0foX6y6XOOVyr+EX6 y1ThxQ5KlEHimRWhsAqyCjZCxyqdH1zlx/e9ri8a8hTHk69IpxSuxyK2PVsbq/eH +1Ho++bmql6F/Pa9DYl/KCYE8LiOrPAvl99Xh6k06OZy2FCPbU98jjb28mbDFJ+Y VHsXY2Hf3Z+xGB/+et4q =VsFd -----END PGP SIGNATURE----- --=-1cNDaFeeK/hPDf44alEq-- From owner-freebsd-acpi@FreeBSD.ORG Thu Apr 18 19:49:54 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9B57BB6 for ; Thu, 18 Apr 2013 19:49:54 +0000 (UTC) (envelope-from ben@b1c1l1.com) Received: from lancer.b1c1l1.com (lancer.b1c1l1.com [IPv6:2607:f358:1a:1a:1000::]) by mx1.freebsd.org (Postfix) with ESMTP id 8160A1894 for ; Thu, 18 Apr 2013 19:49:54 +0000 (UTC) Received: by lancer.b1c1l1.com (Postfix) with ESMTPSA id A1D3B5C39 for ; Thu, 18 Apr 2013 12:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=b1c1l1.com; s=default; t=1366314587; bh=JIMbWstSHfdQqZB0kpQ7SR80qEx68IgamaiGzarkLGM=; h=Date:From:To:Subject; b=H1fb/cFqpZ9Mge0Re/9bU6GX8xecYDZGZmiNdAaPbFSZb7JolK8Hh5gU/95U2WTnw kldKeKc/qLHWaqziwcU8Zj55mBcWXnbFa/I9oCCYXr2Lz9J3kDwMAKTZZp4+NRzJex QiT5lsr/7l7W8YGBbWrduG+fc6pJkPcjDcp0FGsQ= Date: Thu, 18 Apr 2013 12:49:40 -0700 From: Benjamin Lee To: freebsd-acpi@freebsd.org Subject: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Message-ID: <20130418124940.47e3618a@b1c1l1.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/qcl4.sH19ik2S.eb8KsU0z="; protocol="application/pgp-signature" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 19:49:54 -0000 --Sig_/qcl4.sH19ik2S.eb8KsU0z= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I have a system that panics on boot with 10-CURRENT and boots with many ACPI error messages and non-functional devices with 9.1-RELEASE. Motherboard is Foxconn C51XEM2AA (NVIDIA nForce 590) desktop board. Here is the panic on 10-CURRENT: pcib0: allocated type 3 (0xdffff000-0xdfffffff) for rid 10 of pci0:0:10:0 pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) pci_link26: Picked IRQ 20 with weight 0 panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ= resource type cpuid =3D 0 KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why db> bt Tracing pid 0 tid 100000 td 0xffffffff814f9810 kdb_enter() at kdb_enter+0x3e/frame 0xffffffff818344a0 vpanic() at vpanic+0x146/frame 0xffffffff818344e0 kassert_panic() at kassert_panic+0x136/frame 0xffffffff81834550 acpi_pci_link_route_irqs() at acpi_pci_link_route_irqs+0x2b6/frame 0xffff= ffff81834600 acpi_pci_link_route_interrupt() at acpi_pci_link_route_interrupt+0x422/fr= ame 0xffffffff818346a0 acpi_pcib_route_interrupt() at acpi_pcib_route_interrupt+0x4cd/frame 0xff= ffffff81834700 pci_assign_interrupt() at pci_assign_interrupt+0xef/frame 0xffffffff81834= 790 pci_add_resources() at pci_add_resources+0x653/frame 0xffffffff81834840 pci_add_children() at pci_add_children+0x18a/frame 0xffffffff818348a0 acpi_pci_attach() at acpi_pci_attach+0xd5/frame 0xffffffff818348f0 device_attach() at device_attach+0x396/frame 0xffffffff81834940 bus_generic_attach() at bus_generic_attach+0x4a/frame 0xffffffff81834960 acpi_pcib_attach() at acpi_pcib_attach+0x24d/frame 0xffffffff818349b0 acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x299/frame 0xffffffff81= 834a00 device_attach() at device_attach+0x396/frame 0xffffffff81834a50 bus_generic_attach() at bus_generic_attach+0x4a/frame 0xffffffff81834a70 acpi_attach() at acpi_attach+0xdd6/frame 0xffffffff81834b30 device_attach() at device_attach+0x396/frame 0xffffffff81834b80 bus_generic_attach() at bus_generic_attach+0x4a/frame 0xffffffff81834ba0 nexus_acpi_attach() at nexus_acpi_attach+0x76/frame 0xffffffff81834bd0 device_attach() at device_attach+0x396/frame 0xffffffff81834c20 bus_generic_new_pass() at bus_generic_new_pass+0x116/frame 0xffffffff8183= 4c50 bus_set_pass() at bus_set_pass+0x8f/frame 0xffffffff81834c80 configure() at configure+0xa/frame 0xffffffff81834c90 mi_startup() at mi_startup+0x118/frame 0xffffffff81834cb0 btext() at btext+0x2c And here is an example of the ACPI error messages on 9.1-RELEASE: pcib0: allocated type 3 (0xdffff000-0xdfffffff) for rid 10 of pci0:0:10:0 pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) pci_link26: Picked IRQ 20 with weight 0 ACPI Error: Field [INZ6] at 56 exceeds Buffer [NULL] size 48 (bits) (2011= 0527/ds opcode-254) ACPI Error: Method parse/execution failed [\_SB_.PCI0.SRSA] (Node 0xfffff= e0002d9 8b00), AE_AML_BUFFER_LIMIT (20110527/psparse-560) ACPI Error: Method parse/execution failed [\_SB_.PCI0.AUBA._SRS] (Node 0x= fffffe0 002d9d400), AE_AML_BUFFER_LIMIT (20110527/psparse-560) pci_link26: Unable to route IRQs: AE_AML_BUFFER_LIMIT Even though 9.1-RELEASE boots successfully, devices such as the ehci USB controller and SATA controller do not work. boot -v output for 10-CURRENT: http://www.b1c1l1.com/media/debug/20130418-1= 0-CURRENT-boot.txt.gz boot -v output for 9.1-RELEASE: http://www.b1c1l1.com/media/debug/20130418-= 9.1-RELEASE-boot.txt.gz acpidump -dt from 9.1-RELEASE: http://www.b1c1l1.com/media/debug/20130418-n= vidia.asl.gz --=20 Benjamin Lee http://www.b1c1l1.com/ --Sig_/qcl4.sH19ik2S.eb8KsU0z= Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRcE5aAAoJEHpz6H1iC6qDpdsP/ixENXgBj21VzhUJbqiMzIzX V8DqSiYhcLef3Jr1TligyuNIhbBhMHQLijnFqec8fKn3gOmOFzhRHSNBPE1GFGf8 hbQJgG0kfPZevhTPAEK0L2Z1hTFcsUQcxEG9vAXk1k91UoDxY/cW2JQ0eeaWhM7H vDxC9Y1WjcRgk1BmFbkVrUF9ctbzbVCWbTTXBorrRBKH2t9bg//XjuDJfYPISu6W ipRgmNge/taeO0vVnqWQ3FW9xfKSM7NYYge8kkH4/Ow4jY79aoAeQsqpRU81cGeO /1sk6f/zVvQsndU8hzZMEYh7BIfwtYU8H6y2LwD3W5JOwcGKLE4WU8LrOlPHXYfu j9rkLXXTWTXYwqpwAEOFeoe+GJ9VE2QCax/w+I4oWO4+zZESqqep032/8Hn/Xurn hZDKKKruImxu8bd5HccewtpdQ8TWUvgz3IwPmg1aXsq5xdCVkh7nOTilShX/l8k7 pnDPmo3lWpSAP4r0/iDhHSEP4BX27lewGQ++nBWiIYZBvmEdi/Ut+VZcQRyHgzvN Iz9I0Ol9+YhejvpQBkPCk+C6lsdj0SrpJXmzMN97/X0OgWZFrdaeMxecQ1SWYEm0 57K3WjqmgclVxdwTGNsdoNMfeo1lJ4DKhzKuBU+Js8znoMKU09aDy/vhnYreUL7A QTV5qOqXvJ52h+obmNxG =dvTp -----END PGP SIGNATURE----- --Sig_/qcl4.sH19ik2S.eb8KsU0z=-- From owner-freebsd-acpi@FreeBSD.ORG Fri Apr 19 17:48:47 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 28A09714 for ; Fri, 19 Apr 2013 17:48:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id C266E884 for ; Fri, 19 Apr 2013 17:48:46 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 244EEB917; Fri, 19 Apr 2013 12:29:04 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Date: Fri, 19 Apr 2013 11:31:49 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130418124940.47e3618a@b1c1l1.com> In-Reply-To: <20130418124940.47e3618a@b1c1l1.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201304191131.49433.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Apr 2013 12:29:04 -0400 (EDT) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 17:48:47 -0000 On Thursday, April 18, 2013 3:49:40 pm Benjamin Lee wrote: > I have a system that panics on boot with 10-CURRENT and boots with many > ACPI error messages and non-functional devices with 9.1-RELEASE. > > Motherboard is Foxconn C51XEM2AA (NVIDIA nForce 590) desktop board. > > Here is the panic on 10-CURRENT: > > pcib0: allocated type 3 (0xdffff000-0xdfffffff) for rid 10 of pci0:0:10:0 > pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > pci_link26: Picked IRQ 20 with weight 0 > panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type > cpuid = 0 > KDB: enter: panic > [ thread pid 0 tid 100000 ] > Stopped at kdb_enter+0x3e: movq $0,kdb_why > db> bt > Tracing pid 0 tid 100000 td 0xffffffff814f9810 > kdb_enter() at kdb_enter+0x3e/frame 0xffffffff818344a0 > vpanic() at vpanic+0x146/frame 0xffffffff818344e0 > kassert_panic() at kassert_panic+0x136/frame 0xffffffff81834550 > acpi_pci_link_route_irqs() at acpi_pci_link_route_irqs+0x2b6/frame 0xffffffff81834600 > acpi_pci_link_route_interrupt() at acpi_pci_link_route_interrupt+0x422/frame 0xffffffff818346a0 > acpi_pcib_route_interrupt() at acpi_pcib_route_interrupt+0x4cd/frame 0xffffffff81834700 > pci_assign_interrupt() at pci_assign_interrupt+0xef/frame 0xffffffff81834790 > pci_add_resources() at pci_add_resources+0x653/frame 0xffffffff81834840 > pci_add_children() at pci_add_children+0x18a/frame 0xffffffff818348a0 > acpi_pci_attach() at acpi_pci_attach+0xd5/frame 0xffffffff818348f0 > device_attach() at device_attach+0x396/frame 0xffffffff81834940 > bus_generic_attach() at bus_generic_attach+0x4a/frame 0xffffffff81834960 > acpi_pcib_attach() at acpi_pcib_attach+0x24d/frame 0xffffffff818349b0 > acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x299/frame 0xffffffff81834a00 > device_attach() at device_attach+0x396/frame 0xffffffff81834a50 > bus_generic_attach() at bus_generic_attach+0x4a/frame 0xffffffff81834a70 > acpi_attach() at acpi_attach+0xdd6/frame 0xffffffff81834b30 > device_attach() at device_attach+0x396/frame 0xffffffff81834b80 > bus_generic_attach() at bus_generic_attach+0x4a/frame 0xffffffff81834ba0 > nexus_acpi_attach() at nexus_acpi_attach+0x76/frame 0xffffffff81834bd0 > device_attach() at device_attach+0x396/frame 0xffffffff81834c20 > bus_generic_new_pass() at bus_generic_new_pass+0x116/frame 0xffffffff81834c50 > bus_set_pass() at bus_set_pass+0x8f/frame 0xffffffff81834c80 > configure() at configure+0xa/frame 0xffffffff81834c90 > mi_startup() at mi_startup+0x118/frame 0xffffffff81834cb0 > btext() at btext+0x2c > > And here is an example of the ACPI error messages on 9.1-RELEASE: > > pcib0: allocated type 3 (0xdffff000-0xdfffffff) for rid 10 of pci0:0:10:0 > pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > pci_link26: Picked IRQ 20 with weight 0 > ACPI Error: Field [INZ6] at 56 exceeds Buffer [NULL] size 48 (bits) (20110527/ds > opcode-254) > ACPI Error: Method parse/execution failed [\_SB_.PCI0.SRSA] (Node 0xfffffe0002d9 > 8b00), AE_AML_BUFFER_LIMIT (20110527/psparse-560) > ACPI Error: Method parse/execution failed [\_SB_.PCI0.AUBA._SRS] (Node 0xfffffe0 > 002d9d400), AE_AML_BUFFER_LIMIT (20110527/psparse-560) > pci_link26: Unable to route IRQs: AE_AML_BUFFER_LIMIT > > Even though 9.1-RELEASE boots successfully, devices such as the ehci USB > controller and SATA controller do not work. Ugh, your BIOS does unexpected things. It uses a _CRS for these pci link devices that uses a "short" IRQ resource, but uses an extended IRQ resource in _PRS (and expects an extended one in _SRS). We use _CRS as a template for the resource to build. Try this patch. It's a bit hackish, but it forces us to not use _CRS as a template if _CRS uses a "short" IRQ resource, but the link supports non-ISA IRQs. Index: /home/jhb/work/freebsd/svn/head/sys/dev/acpica/acpi_pci_link.c =================================================================== --- /home/jhb/work/freebsd/svn/head/sys/dev/acpica/acpi_pci_link.c (revision 249553) +++ /home/jhb/work/freebsd/svn/head/sys/dev/acpica/acpi_pci_link.c (working copy) @@ -99,6 +99,7 @@ uint8_t l_bios_irq; uint8_t l_irq; uint8_t l_initial_irq; + UINT32 l_crs_type; int l_res_index; int l_num_irqs; int *l_irqs; @@ -236,6 +237,7 @@ ("%s: array boundary violation", __func__)); link = &req->sc->pl_links[req->link_index]; link->l_res_index = req->res_index; + link->l_crs_type = res->Type; req->link_index++; req->res_index++; @@ -364,6 +366,14 @@ link->l_isa_irq = FALSE; } } + + /* + * If this is not an ISA IRQ but _CRS used a non-extended + * IRQ descriptor, don't use _CRS as a template for _SRS. + */ + if (!req->sc->pl_crs_bad && !link->l_isa_irq && + link->l_crs_type == ACPI_RESOURCE_TYPE_IRQ) + req->sc->pl_crs_bad = TRUE; break; default: if (req->in_dpf == DPF_IGNORE) -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri Apr 19 20:18:56 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8038A2A1; Fri, 19 Apr 2013 20:18:56 +0000 (UTC) (envelope-from ben@b1c1l1.com) Received: from lancer.b1c1l1.com (lancer.b1c1l1.com [IPv6:2607:f358:1a:1a:1000::]) by mx1.freebsd.org (Postfix) with ESMTP id 656371C8D; Fri, 19 Apr 2013 20:18:56 +0000 (UTC) Received: by lancer.b1c1l1.com (Postfix) with ESMTPSA id 104485C47; Fri, 19 Apr 2013 13:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=b1c1l1.com; s=default; t=1366402735; bh=/wa1pLwm49C0VhnW9/HauPUdiLHr13sc5BCbqt2UpnQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=wKX4IMqrrSUV00emrDxrk57Dtv/d0amBSscjZ6OOWycX827AQyfzwtCWtR4g76gfG 3iVhmID88kWOBcc3x8ViqQ1Z4SCQ10RbYwxYr6CYlfIsqraX6JKfDMdSLVDC68hcP/ lrKOW//rd4G1o6e8wQOUKxK81N67GcA2dBtnF+qQ= Date: Fri, 19 Apr 2013 13:18:49 -0700 From: Benjamin Lee To: John Baldwin Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Message-ID: <20130419131849.7357c8f6@b1c1l1.com> In-Reply-To: <201304191131.49433.jhb@freebsd.org> References: <20130418124940.47e3618a@b1c1l1.com> <201304191131.49433.jhb@freebsd.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/H2TZTOUAUQLx.N49+k18BPK"; protocol="application/pgp-signature" Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 20:18:56 -0000 --Sig_/H2TZTOUAUQLx.N49+k18BPK Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 19 Apr 2013 11:31:49 -0400, John Baldwin wrote: > On Thursday, April 18, 2013 3:49:40 pm Benjamin Lee wrote: > > I have a system that panics on boot with 10-CURRENT and boots with many > > ACPI error messages and non-functional devices with 9.1-RELEASE. > >=20 > > Motherboard is Foxconn C51XEM2AA (NVIDIA nForce 590) desktop board. [...] > > Even though 9.1-RELEASE boots successfully, devices such as the ehci USB > > controller and SATA controller do not work. >=20 > Ugh, your BIOS does unexpected things. It uses a _CRS for these pci link > devices that uses a "short" IRQ resource, but uses an extended IRQ resour= ce in > _PRS (and expects an extended one in _SRS). We use _CRS as a template fo= r the > resource to build. >=20 > Try this patch. It's a bit hackish, but it forces us to not use _CRS as a > template if _CRS uses a "short" IRQ resource, but the link supports non-I= SA > IRQs. [...] Thanks, that fixed the panic and the system boots. Now it is complaining about AE_AML_BAD_RESOURCE_LENGTH and still unable to route IRQs, but it definitely looks better than the ACPI parsing errors in 9: pcib0: allocated type 3 (0xdffff000-0xdfffffff) for rid 10 of pci0:0:10:0 pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) pci_link26: Picked IRQ 20 with weight 0 pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH Full boot -v output: http://www.b1c1l1.com/media/debug/20130419-10-patched-= boot.txt.gz --=20 Benjamin Lee http://www.b1c1l1.com/ --Sig_/H2TZTOUAUQLx.N49+k18BPK Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRcaauAAoJEHpz6H1iC6qDjhUP+wQMAzVGf23lBJ0U7vxmNZ+C R6chW0aG3ygUzVv9hHFeZiFgUbCt6SvnfCp8MLcWLZ/Vp3FBRSrp1p2FIHW/O9UM hzyp7OzOLzR4NikixwAIzj043PMAMVtDDATmW47qakghLBbdp99aa9+6htZLCReT SOWeQ/2bUxphfqJBxwD9CI+m+j2qApZAxRv++mTEpLD3mKLTzFmxmucwbsbYWF/I BrE6K2p5tcOk9q/kCXMgUVREkjJzqf0ULRTlLQx0ryXVpxbXin26/zeiC0qpDqhM /W6HI8ORbZdpPjNNX8rniz/n5SWQWs9p4QtAj1MoTfrMonUUSpeGlq+THWO6MCkN +WD9ASNwDv88u1kTWi+9VyKz4c4p+5ISYODZnE7hfmn/sLJvAKV7fRYBL+LIoxet nPEfNHmXyHXSDiqNMcyDKwnst1uW393aiS/e9Eg0uV6tgg489dnzH7WKckR0Mwo9 dyzMn/SwaiPbCCBraDWFnZkP5EGEbncdmucpoR6UZskOYQpLEvj1/vYIEF1X0EUZ NZ0ihApdfBCbkXW7N/I0wIIv6wVic5CF/eDPAsuBj0eb91sp/fqOed4QWz3zwF2x QVRuvGbZnoqjIby+cx+pQgf3xc6PmmbYGfWWVLM4xNn4iVZgHL8B+1uDS8gy7wNk MJ4kOTIZpbwANeoN+LMj =dfgn -----END PGP SIGNATURE----- --Sig_/H2TZTOUAUQLx.N49+k18BPK-- From owner-freebsd-acpi@FreeBSD.ORG Fri Apr 19 21:28:04 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 96A591E6 for ; Fri, 19 Apr 2013 21:28:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 74F9C1FAB for ; Fri, 19 Apr 2013 21:28:04 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C3BC8B97C; Fri, 19 Apr 2013 17:28:03 -0400 (EDT) From: John Baldwin To: Benjamin Lee Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Date: Fri, 19 Apr 2013 17:26:31 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130418124940.47e3618a@b1c1l1.com> <201304191131.49433.jhb@freebsd.org> <20130419131849.7357c8f6@b1c1l1.com> In-Reply-To: <20130419131849.7357c8f6@b1c1l1.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201304191726.31089.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Apr 2013 17:28:03 -0400 (EDT) Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 21:28:04 -0000 On Friday, April 19, 2013 4:18:49 pm Benjamin Lee wrote: > On Fri, 19 Apr 2013 11:31:49 -0400, John Baldwin wrote: > > On Thursday, April 18, 2013 3:49:40 pm Benjamin Lee wrote: > > > I have a system that panics on boot with 10-CURRENT and boots with many > > > ACPI error messages and non-functional devices with 9.1-RELEASE. > > > > > > Motherboard is Foxconn C51XEM2AA (NVIDIA nForce 590) desktop board. > [...] > > > Even though 9.1-RELEASE boots successfully, devices such as the ehci USB > > > controller and SATA controller do not work. > > > > Ugh, your BIOS does unexpected things. It uses a _CRS for these pci link > > devices that uses a "short" IRQ resource, but uses an extended IRQ resource in > > _PRS (and expects an extended one in _SRS). We use _CRS as a template for the > > resource to build. > > > > Try this patch. It's a bit hackish, but it forces us to not use _CRS as a > > template if _CRS uses a "short" IRQ resource, but the link supports non- ISA > > IRQs. > [...] > > Thanks, that fixed the panic and the system boots. Now it is > complaining about AE_AML_BAD_RESOURCE_LENGTH and still unable to route > IRQs, but it definitely looks better than the ACPI parsing errors in 9: > > pcib0: allocated type 3 (0xdffff000-0xdfffffff) for rid 10 of pci0:0:10:0 > pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > pci_link26: Picked IRQ 20 with weight 0 > pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH > > Full boot -v output: http://www.b1c1l1.com/media/debug/20130419-10-patched- boot.txt.gz Can you add some printfs to the places that return the AE_AML_BAD_RESOURCE_LENGTH to see which one is being triggered? (Just look for that constant in sys/contrib/dev/acpica to find the possible places.) -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri Apr 19 22:21:22 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 97D8BA3; Fri, 19 Apr 2013 22:21:22 +0000 (UTC) (envelope-from ben@b1c1l1.com) Received: from lancer.b1c1l1.com (lancer.b1c1l1.com [72.13.86.100]) by mx1.freebsd.org (Postfix) with ESMTP id 77BE4213; Fri, 19 Apr 2013 22:21:22 +0000 (UTC) Received: by lancer.b1c1l1.com (Postfix) with ESMTPSA id A4A6A5C21; Fri, 19 Apr 2013 15:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=b1c1l1.com; s=default; t=1366410076; bh=tjV4sG+UoeVuUuV2Az6eCQu+MkuNC1dQ8SGmyofzLPY=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=OFAJRfUGvG3Keeb0J5JqYjgsowwkaPgo45OJsxqAqeJQDGvTBJrYmq3Dr8S9Z1njy bbPfkF05hes4bDGyAhPRz4xkVxtOLbNYp3X/SakADvz0OmYqfoYSKa7/3SgqJdqisk ssMuEA+XvZMBQJSFy6JpU9GODckq8oLJb5qGc22M= Date: Fri, 19 Apr 2013 15:21:10 -0700 From: Benjamin Lee To: John Baldwin Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Message-ID: <20130419152110.213c7fbb@b1c1l1.com> In-Reply-To: <201304191726.31089.jhb@freebsd.org> References: <20130418124940.47e3618a@b1c1l1.com> <201304191131.49433.jhb@freebsd.org> <20130419131849.7357c8f6@b1c1l1.com> <201304191726.31089.jhb@freebsd.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/eEdCXbzuhjkEDZADVWrv2fN"; protocol="application/pgp-signature" Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 22:21:22 -0000 --Sig_/eEdCXbzuhjkEDZADVWrv2fN Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 19 Apr 2013 17:26:31 -0400, John Baldwin wrote: > On Friday, April 19, 2013 4:18:49 pm Benjamin Lee wrote: > > On Fri, 19 Apr 2013 11:31:49 -0400, John Baldwin wrot= e: > > > On Thursday, April 18, 2013 3:49:40 pm Benjamin Lee wrote: > > > > I have a system that panics on boot with 10-CURRENT and boots with = many > > > > ACPI error messages and non-functional devices with 9.1-RELEASE. > > > >=20 > > > > Motherboard is Foxconn C51XEM2AA (NVIDIA nForce 590) desktop board. > > [...] > > > > Even though 9.1-RELEASE boots successfully, devices such as the ehc= i USB > > > > controller and SATA controller do not work. > > >=20 > > > Ugh, your BIOS does unexpected things. It uses a _CRS for these pci = link > > > devices that uses a "short" IRQ resource, but uses an extended IRQ=20 > resource in > > > _PRS (and expects an extended one in _SRS). We use _CRS as a templat= e for=20 > the > > > resource to build. > > >=20 > > > Try this patch. It's a bit hackish, but it forces us to not use _CRS= as a > > > template if _CRS uses a "short" IRQ resource, but the link supports n= on- > ISA > > > IRQs. > > [...] > >=20 > > Thanks, that fixed the panic and the system boots. Now it is > > complaining about AE_AML_BAD_RESOURCE_LENGTH and still unable to route > > IRQs, but it definitely looks better than the ACPI parsing errors in 9: > >=20 > > pcib0: allocated type 3 (0xdffff000-0xdfffffff) for rid 10 of pci0:0:10= :0 > > pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > > pci_link26: Picked IRQ 20 with weight 0 > > pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH > >=20 > > Full boot -v output: http://www.b1c1l1.com/media/debug/20130419-10-patc= hed- > boot.txt.gz >=20 > Can you add some printfs to the places that return the=20 > AE_AML_BAD_RESOURCE_LENGTH to see which one is being triggered? (Just lo= ok=20 > for that constant in sys/contrib/dev/acpica to find the possible places.) Is there a macro for dumping information about Resource or Resource->Data? Here's what I have for now at sys/contrib/dev/acpica/resources/rscalc.c line 237: pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) pci_link26: Picked IRQ 20 with weight 0 rscalc.c:237 Resource->Type: 7 Resource->Length: 0 pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH All of the errors are from there and look identical (Type 7, Length 0). Type 7 appears to be ACPI_RESOURCE_TYPE_END_TAG. --=20 Benjamin Lee http://www.b1c1l1.com/ --Sig_/eEdCXbzuhjkEDZADVWrv2fN Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRccNaAAoJEHpz6H1iC6qDz9EP/iOQEILcs6gV/xV3BPROnHIX LwHyQPAr/IWsSRJ8UnatWaKbD76t0E9qyZysGDqJbM9ihYrNLMf+lVJGRWE890Mn UXkk4wmStKSdbBYNj78hPEWgK2wZ5BYOe46KrOtWCy5LCV8XVaztxBV9VIJrvX53 +XtdW241cruRFRCzfiEDiKLqOaGqF2PAcR4m4hkFODpp9nt945LKZj0ynfsrBNrd W7MF6kJ6N9UJeSLcnUWv2Ty78+YHdG2FT3z5oh8J33HXMBsxhW5vLpN2hvdfeh6p JP1TxRtPGT6Xl/H8F4ItVimy7XWf9/VxZNOXUpJFC1URzNc2XE7k6ZoA/7Jj+mNm 03bmygYWQK9YdEaLoaC2W5Ww7o5GqeI2agLcOBrWI2Y3FUXSA4dR1GUcRgamN1yZ j0ZxaRnAzok9Nvlpb2anxfG+S4tCVWBcYMYsNxhQL6pHeTLhTwmYivoAkEMD0ArZ ZpEAFNDuzVIIc7zwksapih+KXnMbc5hKAilZ35j1sPmvDCgRu0cUnmPIvKqsnAXK JZMm3vIwvX2TGPZRadfmFWF/8ZrzjO5+cd6MWuTzGXTvoaEA91EZu4G2FhTKMjLe ckyqhtAmMcbHU6zhyNI53bf+DwJCEKyUNWFGqPEJyd/hlMxs09txN1ss8N+iZEhL gl9MQwra/5GCQqLJaTaa =mPmB -----END PGP SIGNATURE----- --Sig_/eEdCXbzuhjkEDZADVWrv2fN-- From owner-freebsd-acpi@FreeBSD.ORG Fri Apr 19 22:51:27 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BC49788A; Fri, 19 Apr 2013 22:51:27 +0000 (UTC) (envelope-from ben@b1c1l1.com) Received: from lancer.b1c1l1.com (lancer.b1c1l1.com [IPv6:2607:f358:1a:1a:1000::]) by mx1.freebsd.org (Postfix) with ESMTP id 8F2C42FD; Fri, 19 Apr 2013 22:51:27 +0000 (UTC) Received: by lancer.b1c1l1.com (Postfix) with ESMTPSA id DBA055C21; Fri, 19 Apr 2013 15:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=b1c1l1.com; s=default; t=1366411887; bh=bA/LBsR34QA9b7/j/oX8gV3/kug3WTUVJjGb06Ik2es=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=5/2fzQMBBN22OWJZ00neAVt+7TNHNhAWF4cmxu9nqbgr4TQU27q9P63rTTFXMyoM+ OqZ481YRAnTj7RCs1SGwaXZ/wiVOfL8NxKDjUPiP0J1VHteNFBAw1Ds5yqFn17+c6S CSBbH+8lAdoNhs4+APWhQP5+tM1oY0GscyHbyoPI= Date: Fri, 19 Apr 2013 15:51:18 -0700 From: Benjamin Lee To: John Baldwin Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Message-ID: <20130419155118.7bafe9fc@b1c1l1.com> In-Reply-To: <20130419152110.213c7fbb@b1c1l1.com> References: <20130418124940.47e3618a@b1c1l1.com> <201304191131.49433.jhb@freebsd.org> <20130419131849.7357c8f6@b1c1l1.com> <201304191726.31089.jhb@freebsd.org> <20130419152110.213c7fbb@b1c1l1.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/rwA=b0KcrRKP8AQ8c.pb2pJ"; protocol="application/pgp-signature" Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 22:51:27 -0000 --Sig_/rwA=b0KcrRKP8AQ8c.pb2pJ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 19 Apr 2013 15:21:10 -0700, Benjamin Lee wrote: > On Fri, 19 Apr 2013 17:26:31 -0400, John Baldwin wrote: > > On Friday, April 19, 2013 4:18:49 pm Benjamin Lee wrote: > > > On Fri, 19 Apr 2013 11:31:49 -0400, John Baldwin wr= ote: > > > > On Thursday, April 18, 2013 3:49:40 pm Benjamin Lee wrote: > > > > > I have a system that panics on boot with 10-CURRENT and boots wit= h many > > > > > ACPI error messages and non-functional devices with 9.1-RELEASE. > > > > >=20 > > > > > Motherboard is Foxconn C51XEM2AA (NVIDIA nForce 590) desktop boar= d. > > > [...] > > > > > Even though 9.1-RELEASE boots successfully, devices such as the e= hci USB > > > > > controller and SATA controller do not work. > > > >=20 > > > > Ugh, your BIOS does unexpected things. It uses a _CRS for these pc= i link > > > > devices that uses a "short" IRQ resource, but uses an extended IRQ= =20 > > resource in > > > > _PRS (and expects an extended one in _SRS). We use _CRS as a templ= ate for=20 > > the > > > > resource to build. > > > >=20 > > > > Try this patch. It's a bit hackish, but it forces us to not use _C= RS as a > > > > template if _CRS uses a "short" IRQ resource, but the link supports= non- > > ISA > > > > IRQs. > > > [...] > > >=20 > > > Thanks, that fixed the panic and the system boots. Now it is > > > complaining about AE_AML_BAD_RESOURCE_LENGTH and still unable to route > > > IRQs, but it definitely looks better than the ACPI parsing errors in = 9: > > >=20 > > > pcib0: allocated type 3 (0xdffff000-0xdfffffff) for rid 10 of pci0:0:= 10:0 > > > pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > > > pci_link26: Picked IRQ 20 with weight 0 > > > pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH > > >=20 > > > Full boot -v output: http://www.b1c1l1.com/media/debug/20130419-10-pa= tched- > > boot.txt.gz > >=20 > > Can you add some printfs to the places that return the=20 > > AE_AML_BAD_RESOURCE_LENGTH to see which one is being triggered? (Just = look=20 > > for that constant in sys/contrib/dev/acpica to find the possible places= .) >=20 > Is there a macro for dumping information about Resource or > Resource->Data? Here's what I have for now at > sys/contrib/dev/acpica/resources/rscalc.c line 237: >=20 > pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > pci_link26: Picked IRQ 20 with weight 0 > rscalc.c:237 > Resource->Type: 7 > Resource->Length: 0 > pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH >=20 > All of the errors are from there and look identical (Type 7, Length 0). > Type 7 appears to be ACPI_RESOURCE_TYPE_END_TAG. This hack fixes everything (now the SATA controller works). It seems that the Resource->Length check might not be necessary for ACPI_RESOURCE_TYPE_END_TAG. blee@genesis /usr/src/sys/contrib/dev/acpica $ svn diff Index: components/resources/rscalc.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- components/resources/rscalc.c (revision 249624) +++ components/resources/rscalc.c (working copy) @@ -234,6 +234,15 @@ =20 if (!Resource->Length) { + if (Resource->Type =3D=3D ACPI_RESOURCE_TYPE_END_TAG) { + TotalSize =3D AcpiGbl_AmlResourceSizes [Resource->Type]; + printf("TotalSize: %u\n", TotalSize); + if (TotalSize !=3D 0) { + printf("ACPI_RESOURCE_TYPE_END_TAG hack\n"); + *SizeNeeded =3D AmlSizeNeeded + TotalSize; + return_ACPI_STATUS (AE_OK); + } + } return_ACPI_STATUS (AE_AML_BAD_RESOURCE_LENGTH); } =20 Index: components/resources/rslist.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- components/resources/rslist.c (revision 249624) +++ components/resources/rslist.c (working copy) @@ -203,6 +203,11 @@ =20 if (!Resource->Length) { + if (Resource->Type =3D=3D ACPI_RESOURCE_TYPE_END_TAG) { + printf("ACPI_RESOURCE_TYPE_END_TAG hack 2\n"); + return_ACPI_STATUS (AE_OK); + } + ACPI_ERROR ((AE_INFO, "Invalid zero length descriptor in resource list\n")); return_ACPI_STATUS (AE_AML_BAD_RESOURCE_LENGTH); --=20 Benjamin Lee http://www.b1c1l1.com/ --Sig_/rwA=b0KcrRKP8AQ8c.pb2pJ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRccptAAoJEHpz6H1iC6qDbf8P/imziMzhEbnH6yHQYHv1EAvY FX40jDjYFcF5uPFkzuqvzWxPg5xdEFNmrWgwYAhUMJQWRPrPHO71Mr4VCJMxJsSD LuMXxFzvVsbic2gDrKiqps+mvRpqWX0pBEPxA2+1aYD9NRruv5+HORmpwRhA3BrK 2RD43aKIcElf/IvOJ/cjARBXcET3IXg7Kls9IpqPjbMpdBMfTSQdOspoZm+BU4b6 YqOSx0JQrX4jGG3o2yPA9zq7dHiPaJk9MWofV0fXz+SRTrtBP8jQvoruCmJD6OL1 URMMKZdnnDQx/EQT7tKTgPDDcF99I+EHyllU3HkcYV6NLS9T7EcOJ8sjYiQUvBsN KSmn3rCmXq3Vg3v8uZD5pdZLvjPZtrQxHMqI2gLeOMq2+LEqHQoy9VIjc36wCCK3 rCw2oTQHIWpXahNf2VJHUxoDgEV22QBaqpl7WR6J+FN8ku8LXeOgjMKMC6MGAjNm X7DM1Wte4gJuf9PlAGvN7s8t2WSMcKwA+h2HNX/m8SejZnoInOsgjWnuauQA/Fzm V9cojomow32jzk8k5OBvq9/PDv19YwIdEtjZKemQxifvfOeT1Fw6lhjzp2xeXxuX fDeLv/Q3FI8rFWDEgDe+IwqmEKTm+uSlg/oZJxs20bygHJnN4bBupzhSmsYp6uvF 3CPktq11mzIDS42/IbHc =XzxK -----END PGP SIGNATURE----- --Sig_/rwA=b0KcrRKP8AQ8c.pb2pJ-- From owner-freebsd-acpi@FreeBSD.ORG Fri Apr 19 23:00:15 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D8DC990F; Fri, 19 Apr 2013 23:00:15 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mx1.freebsd.org (Postfix) with ESMTP id BE2A4331; Fri, 19 Apr 2013 23:00:15 +0000 (UTC) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 19 Apr 2013 16:00:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.87,512,1363158000"; d="scan'208";a="321958610" Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34]) by fmsmga001.fm.intel.com with ESMTP; 19 Apr 2013 16:00:08 -0700 Received: from fmsmsx153.amr.corp.intel.com ([169.254.9.79]) by FMSMSX103.amr.corp.intel.com ([169.254.3.111]) with mapi id 14.01.0355.002; Fri, 19 Apr 2013 16:00:08 -0700 From: "Moore, Robert" To: Benjamin Lee , John Baldwin Subject: RE: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Thread-Topic: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Thread-Index: AQHOPG391d2djyxEFEWgLAw8ZTDWIJjeIoGAgABQL4CAABLrgIAAD0UAgAAIawD//4zvYA== Date: Fri, 19 Apr 2013 23:00:07 +0000 Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42E28@FMSMSX153.amr.corp.intel.com> References: <20130418124940.47e3618a@b1c1l1.com> <201304191131.49433.jhb@freebsd.org> <20130419131849.7357c8f6@b1c1l1.com> <201304191726.31089.jhb@freebsd.org> <20130419152110.213c7fbb@b1c1l1.com> <20130419155118.7bafe9fc@b1c1l1.com> In-Reply-To: <20130419155118.7bafe9fc@b1c1l1.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 23:00:15 -0000 No, the length must be set in all descriptors, end tag included. > -----Original Message----- > From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- > acpi@freebsd.org] On Behalf Of Benjamin Lee > Sent: Friday, April 19, 2013 3:51 PM > To: John Baldwin > Cc: freebsd-acpi@freebsd.org > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 > in legacy IRQ resource type) >=20 > On Fri, 19 Apr 2013 15:21:10 -0700, Benjamin Lee wrote: > > On Fri, 19 Apr 2013 17:26:31 -0400, John Baldwin > wrote: > > > On Friday, April 19, 2013 4:18:49 pm Benjamin Lee wrote: > > > > On Fri, 19 Apr 2013 11:31:49 -0400, John Baldwin > wrote: > > > > > On Thursday, April 18, 2013 3:49:40 pm Benjamin Lee wrote: > > > > > > I have a system that panics on boot with 10-CURRENT and boots > > > > > > with many ACPI error messages and non-functional devices with > 9.1-RELEASE. > > > > > > > > > > > > Motherboard is Foxconn C51XEM2AA (NVIDIA nForce 590) desktop > board. > > > > [...] > > > > > > Even though 9.1-RELEASE boots successfully, devices such as > > > > > > the ehci USB controller and SATA controller do not work. > > > > > > > > > > Ugh, your BIOS does unexpected things. It uses a _CRS for these > > > > > pci link devices that uses a "short" IRQ resource, but uses an > > > > > extended IRQ > > > resource in > > > > > _PRS (and expects an extended one in _SRS). We use _CRS as a > > > > > template for > > > the > > > > > resource to build. > > > > > > > > > > Try this patch. It's a bit hackish, but it forces us to not use > > > > > _CRS as a template if _CRS uses a "short" IRQ resource, but the > > > > > link supports non- > > > ISA > > > > > IRQs. > > > > [...] > > > > > > > > Thanks, that fixed the panic and the system boots. Now it is > > > > complaining about AE_AML_BAD_RESOURCE_LENGTH and still unable to > > > > route IRQs, but it definitely looks better than the ACPI parsing > errors in 9: > > > > > > > > pcib0: allocated type 3 (0xdffff000-0xdfffffff) for rid 10 of > > > > pci0:0:10:0 > > > > pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > > > > pci_link26: Picked IRQ 20 with weight 0 > > > > pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH > > > > > > > > Full boot -v output: > > > > http://www.b1c1l1.com/media/debug/20130419-10-patched- > > > boot.txt.gz > > > > > > Can you add some printfs to the places that return the > > > AE_AML_BAD_RESOURCE_LENGTH to see which one is being triggered? > > > (Just look for that constant in sys/contrib/dev/acpica to find the > > > possible places.) > > > > Is there a macro for dumping information about Resource or > > Resource->Data? Here's what I have for now at > > sys/contrib/dev/acpica/resources/rscalc.c line 237: > > > > pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > > pci_link26: Picked IRQ 20 with weight 0 > > rscalc.c:237 > > Resource->Type: 7 > > Resource->Length: 0 > > pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH > > > > All of the errors are from there and look identical (Type 7, Length 0). > > Type 7 appears to be ACPI_RESOURCE_TYPE_END_TAG. >=20 > This hack fixes everything (now the SATA controller works). It seems tha= t > the Resource->Length check might not be necessary for > ACPI_RESOURCE_TYPE_END_TAG. >=20 > blee@genesis /usr/src/sys/contrib/dev/acpica $ svn diff > Index: components/resources/rscalc.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- components/resources/rscalc.c (revision 249624) > +++ components/resources/rscalc.c (working copy) > @@ -234,6 +234,15 @@ >=20 > if (!Resource->Length) > { > + if (Resource->Type =3D=3D ACPI_RESOURCE_TYPE_END_TAG) { > + TotalSize =3D AcpiGbl_AmlResourceSizes [Resource->Type]; > + printf("TotalSize: %u\n", TotalSize); > + if (TotalSize !=3D 0) { > + printf("ACPI_RESOURCE_TYPE_END_TAG hack\n"); > + *SizeNeeded =3D AmlSizeNeeded + TotalSize; > + return_ACPI_STATUS (AE_OK); > + } > + } > return_ACPI_STATUS (AE_AML_BAD_RESOURCE_LENGTH); > } >=20 > Index: components/resources/rslist.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- components/resources/rslist.c (revision 249624) > +++ components/resources/rslist.c (working copy) > @@ -203,6 +203,11 @@ >=20 > if (!Resource->Length) > { > + if (Resource->Type =3D=3D ACPI_RESOURCE_TYPE_END_TAG) { > + printf("ACPI_RESOURCE_TYPE_END_TAG hack 2\n"); > + return_ACPI_STATUS (AE_OK); > + } > + > ACPI_ERROR ((AE_INFO, > "Invalid zero length descriptor in resource list\n")); > return_ACPI_STATUS (AE_AML_BAD_RESOURCE_LENGTH); >=20 >=20 >=20 > -- > Benjamin Lee > http://www.b1c1l1.com/ From owner-freebsd-acpi@FreeBSD.ORG Fri Apr 19 23:35:35 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 33931C1A; Fri, 19 Apr 2013 23:35:35 +0000 (UTC) (envelope-from ben@b1c1l1.com) Received: from lancer.b1c1l1.com (lancer.b1c1l1.com [72.13.86.100]) by mx1.freebsd.org (Postfix) with ESMTP id 1B547623; Fri, 19 Apr 2013 23:35:34 +0000 (UTC) Received: by lancer.b1c1l1.com (Postfix) with ESMTPSA id F19C05C21; Fri, 19 Apr 2013 16:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=b1c1l1.com; s=default; t=1366414531; bh=cv8K8rl+U/f5/4dZeKIzu5+LaR1h3M7ezsVoHAT+f6o=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=K4wt5PjiN3LsgnDf6Cy+5EnT+4OCnUmy49JufJf8BwbbkzFNnCqvwjae8cNBTcM9M XOkhUe+kYjkttS3kSLBlMJmdQkAbtoqNO0GnbKBhsfdQdnGul5xKKW5EqLEISQa4E/ q1d+oEqeppPsU7pudcFOFyYDZhHSVZMc2upBDonA= Date: Fri, 19 Apr 2013 16:35:28 -0700 From: Benjamin Lee To: "Moore, Robert" Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Message-ID: <20130419163528.204bf3ff@b1c1l1.com> In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42E28@FMSMSX153.amr.corp.intel.com> References: <20130418124940.47e3618a@b1c1l1.com> <201304191131.49433.jhb@freebsd.org> <20130419131849.7357c8f6@b1c1l1.com> <201304191726.31089.jhb@freebsd.org> <20130419152110.213c7fbb@b1c1l1.com> <20130419155118.7bafe9fc@b1c1l1.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42E28@FMSMSX153.amr.corp.intel.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/ik6aAYfxTUf.F3Usy8mqh5y"; protocol="application/pgp-signature" Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 23:35:35 -0000 --Sig_/ik6aAYfxTUf.F3Usy8mqh5y Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 19 Apr 2013 23:00:07 +0000, "Moore, Robert" wrote: > No, the length must be set in all descriptors, end tag included. Do you have any pointers on how I can fix my ASL? Where do I find the end tags and what should I set the lengths to? Here is the output from acpidump -dt: http://www.b1c1l1.com/media/debug/201= 30418-nvidia.asl.gz >=20 > > -----Original Message----- > > From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- > > acpi@freebsd.org] On Behalf Of Benjamin Lee > > Sent: Friday, April 19, 2013 3:51 PM > > To: John Baldwin > > Cc: freebsd-acpi@freebsd.org > > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 > > in legacy IRQ resource type) > >=20 > > On Fri, 19 Apr 2013 15:21:10 -0700, Benjamin Lee wrote: > > > On Fri, 19 Apr 2013 17:26:31 -0400, John Baldwin > > wrote: > > > > On Friday, April 19, 2013 4:18:49 pm Benjamin Lee wrote: > > > > > On Fri, 19 Apr 2013 11:31:49 -0400, John Baldwin > > wrote: > > > > > > On Thursday, April 18, 2013 3:49:40 pm Benjamin Lee wrote: > > > > > > > I have a system that panics on boot with 10-CURRENT and boots > > > > > > > with many ACPI error messages and non-functional devices with > > 9.1-RELEASE. > > > > > > > > > > > > > > Motherboard is Foxconn C51XEM2AA (NVIDIA nForce 590) desktop > > board. > > > > > [...] > > > > > > > Even though 9.1-RELEASE boots successfully, devices such as > > > > > > > the ehci USB controller and SATA controller do not work. > > > > > > > > > > > > Ugh, your BIOS does unexpected things. It uses a _CRS for these > > > > > > pci link devices that uses a "short" IRQ resource, but uses an > > > > > > extended IRQ > > > > resource in > > > > > > _PRS (and expects an extended one in _SRS). We use _CRS as a > > > > > > template for > > > > the > > > > > > resource to build. > > > > > > > > > > > > Try this patch. It's a bit hackish, but it forces us to not use > > > > > > _CRS as a template if _CRS uses a "short" IRQ resource, but the > > > > > > link supports non- > > > > ISA > > > > > > IRQs. > > > > > [...] > > > > > > > > > > Thanks, that fixed the panic and the system boots. Now it is > > > > > complaining about AE_AML_BAD_RESOURCE_LENGTH and still unable to > > > > > route IRQs, but it definitely looks better than the ACPI parsing > > errors in 9: > > > > > > > > > > pcib0: allocated type 3 (0xdffff000-0xdfffffff) for rid 10 of > > > > > pci0:0:10:0 > > > > > pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > > > > > pci_link26: Picked IRQ 20 with weight 0 > > > > > pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH > > > > > > > > > > Full boot -v output: > > > > > http://www.b1c1l1.com/media/debug/20130419-10-patched- > > > > boot.txt.gz > > > > > > > > Can you add some printfs to the places that return the > > > > AE_AML_BAD_RESOURCE_LENGTH to see which one is being triggered? > > > > (Just look for that constant in sys/contrib/dev/acpica to find the > > > > possible places.) > > > > > > Is there a macro for dumping information about Resource or > > > Resource->Data? Here's what I have for now at > > > sys/contrib/dev/acpica/resources/rscalc.c line 237: > > > > > > pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > > > pci_link26: Picked IRQ 20 with weight 0 > > > rscalc.c:237 > > > Resource->Type: 7 > > > Resource->Length: 0 > > > pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH > > > > > > All of the errors are from there and look identical (Type 7, Length 0= ). > > > Type 7 appears to be ACPI_RESOURCE_TYPE_END_TAG. > >=20 > > This hack fixes everything (now the SATA controller works). It seems t= hat > > the Resource->Length check might not be necessary for > > ACPI_RESOURCE_TYPE_END_TAG. > >=20 > > blee@genesis /usr/src/sys/contrib/dev/acpica $ svn diff > > Index: components/resources/rscalc.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- components/resources/rscalc.c (revision 249624) > > +++ components/resources/rscalc.c (working copy) > > @@ -234,6 +234,15 @@ > >=20 > > if (!Resource->Length) > > { > > + if (Resource->Type =3D=3D ACPI_RESOURCE_TYPE_END_TAG) { > > + TotalSize =3D AcpiGbl_AmlResourceSizes [Resource->Type= ]; > > + printf("TotalSize: %u\n", TotalSize); > > + if (TotalSize !=3D 0) { > > + printf("ACPI_RESOURCE_TYPE_END_TAG hack\n"); > > + *SizeNeeded =3D AmlSizeNeeded + TotalSize; > > + return_ACPI_STATUS (AE_OK); > > + } > > + } > > return_ACPI_STATUS (AE_AML_BAD_RESOURCE_LENGTH); > > } > >=20 > > Index: components/resources/rslist.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- components/resources/rslist.c (revision 249624) > > +++ components/resources/rslist.c (working copy) > > @@ -203,6 +203,11 @@ > >=20 > > if (!Resource->Length) > > { > > + if (Resource->Type =3D=3D ACPI_RESOURCE_TYPE_END_TAG) { > > + printf("ACPI_RESOURCE_TYPE_END_TAG hack 2\n"); > > + return_ACPI_STATUS (AE_OK); > > + } > > + > > ACPI_ERROR ((AE_INFO, > > "Invalid zero length descriptor in resource list\n")); > > return_ACPI_STATUS (AE_AML_BAD_RESOURCE_LENGTH); > >=20 > >=20 > >=20 > > -- > > Benjamin Lee > > http://www.b1c1l1.com/ --=20 Benjamin Lee http://www.b1c1l1.com/ --Sig_/ik6aAYfxTUf.F3Usy8mqh5y Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRcdTAAAoJEHpz6H1iC6qDMEEP/3O7c8jqmiuwzJM6RIsoHg94 n+aAuf7fKFwMrx1Yclo16SjDLC2qi2at3n6BmEEvU7IgRA1REGJEv78spzFXt5CV kz+nUQvnhgTdXQYJiaZlyEta9/g4bI/7ETIzdJsqDrFKAh2ePLtp6tvxbkRiGpYf 1ZQV9eflTJQ0FmFiuA4AHxWhHy50WOEv7v/Ib+xkR7OANLZwkYonRQ0ju+HKblv5 JHWaVjiS9xJEn57pjYPYM1/pZvtB+AlYp4QR0VsHGeGx5ekq8eRVEqIBilv0wjF3 XaGJ2dOc74yyBp+AbS6zZEyYPVTPsgPyfFD7eReITXM0n+upI/pLk0a6clYp9c0P qR2kukuINs6gOwWQIsHxr6Ecr0cXBEO37aHTVKbYyuSaLpFjwMicFmOqRVSCKZQJ az/cYRbUdjvxsjcdl6p99TyuYRQFY3xTnHja/7I4F/s0Aceh21eI54bbSo7JLrXC e/wK6ANNyCQQu75aDT9w8gRs9kt+rx/5odCR8HEB/tOd77NGDSPxtuYHz/BZOnfK F7qyqGaGszLLX7CIfPNqeu2C1XnyCL0JsEJJUgFUjs98l3Ce5I5YoQjlzMQ8eFiT 9+3OYo1B7G+YZ9pW4k7jFdpcvsYHJDEJRFGvHW8DFF3J3iZhoAMiIVO+ohczwn2S w6u1NOWzYCp8IJgkdgkX =tN0D -----END PGP SIGNATURE----- --Sig_/ik6aAYfxTUf.F3Usy8mqh5y-- From owner-freebsd-acpi@FreeBSD.ORG Fri Apr 19 23:38:38 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 92365C56; Fri, 19 Apr 2013 23:38:38 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by mx1.freebsd.org (Postfix) with ESMTP id 60B13632; Fri, 19 Apr 2013 23:38:38 +0000 (UTC) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 19 Apr 2013 16:37:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.87,512,1363158000"; d="scan'208";a="288837985" Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37]) by azsmga001.ch.intel.com with ESMTP; 19 Apr 2013 16:37:29 -0700 Received: from fmsmsx112.amr.corp.intel.com (10.18.116.6) by FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 19 Apr 2013 16:37:29 -0700 Received: from fmsmsx153.amr.corp.intel.com ([169.254.9.79]) by FMSMSX112.amr.corp.intel.com ([169.254.3.140]) with mapi id 14.01.0355.002; Fri, 19 Apr 2013 16:37:29 -0700 From: "Moore, Robert" To: Benjamin Lee Subject: RE: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Thread-Topic: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Thread-Index: AQHOPG391d2djyxEFEWgLAw8ZTDWIJjeIoGAgABQL4CAABLrgIAAD0UAgAAIawD//4zvYIAAf2gA//+K6tA= Date: Fri, 19 Apr 2013 23:37:28 +0000 Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42E75@FMSMSX153.amr.corp.intel.com> References: <20130418124940.47e3618a@b1c1l1.com> <201304191131.49433.jhb@freebsd.org> <20130419131849.7357c8f6@b1c1l1.com> <201304191726.31089.jhb@freebsd.org> <20130419152110.213c7fbb@b1c1l1.com> <20130419155118.7bafe9fc@b1c1l1.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42E28@FMSMSX153.amr.corp.intel.com> <20130419163528.204bf3ff@b1c1l1.com> In-Reply-To: <20130419163528.204bf3ff@b1c1l1.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 23:38:38 -0000 I'll be glad to take a look at it next week. Can you tell me the exact sequence of events, and which _CRS/_SRC are you e= xecuting? thanks, Bob > -----Original Message----- > From: Benjamin Lee [mailto:ben@b1c1l1.com] > Sent: Friday, April 19, 2013 4:35 PM > To: Moore, Robert > Cc: John Baldwin; freebsd-acpi@freebsd.org > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 > in legacy IRQ resource type) >=20 > On Fri, 19 Apr 2013 23:00:07 +0000, "Moore, Robert" > wrote: > > No, the length must be set in all descriptors, end tag included. >=20 > Do you have any pointers on how I can fix my ASL? Where do I find the en= d > tags and what should I set the lengths to? >=20 > Here is the output from acpidump -dt: > http://www.b1c1l1.com/media/debug/20130418-nvidia.asl.gz >=20 > > > > > -----Original Message----- > > > From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- > > > acpi@freebsd.org] On Behalf Of Benjamin Lee > > > Sent: Friday, April 19, 2013 3:51 PM > > > To: John Baldwin > > > Cc: freebsd-acpi@freebsd.org > > > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA > > > IRQ 20 in legacy IRQ resource type) > > > > > > On Fri, 19 Apr 2013 15:21:10 -0700, Benjamin Lee > wrote: > > > > On Fri, 19 Apr 2013 17:26:31 -0400, John Baldwin > > > wrote: > > > > > On Friday, April 19, 2013 4:18:49 pm Benjamin Lee wrote: > > > > > > On Fri, 19 Apr 2013 11:31:49 -0400, John Baldwin > > > > > > > > > wrote: > > > > > > > On Thursday, April 18, 2013 3:49:40 pm Benjamin Lee wrote: > > > > > > > > I have a system that panics on boot with 10-CURRENT and > > > > > > > > boots with many ACPI error messages and non-functional > > > > > > > > devices with > > > 9.1-RELEASE. > > > > > > > > > > > > > > > > Motherboard is Foxconn C51XEM2AA (NVIDIA nForce 590) > > > > > > > > desktop > > > board. > > > > > > [...] > > > > > > > > Even though 9.1-RELEASE boots successfully, devices such > > > > > > > > as the ehci USB controller and SATA controller do not work. > > > > > > > > > > > > > > Ugh, your BIOS does unexpected things. It uses a _CRS for > > > > > > > these pci link devices that uses a "short" IRQ resource, but > > > > > > > uses an extended IRQ > > > > > resource in > > > > > > > _PRS (and expects an extended one in _SRS). We use _CRS as > > > > > > > a template for > > > > > the > > > > > > > resource to build. > > > > > > > > > > > > > > Try this patch. It's a bit hackish, but it forces us to not > > > > > > > use _CRS as a template if _CRS uses a "short" IRQ resource, > > > > > > > but the link supports non- > > > > > ISA > > > > > > > IRQs. > > > > > > [...] > > > > > > > > > > > > Thanks, that fixed the panic and the system boots. Now it is > > > > > > complaining about AE_AML_BAD_RESOURCE_LENGTH and still unable > > > > > > to route IRQs, but it definitely looks better than the ACPI > > > > > > parsing > > > errors in 9: > > > > > > > > > > > > pcib0: allocated type 3 (0xdffff000-0xdfffffff) for rid 10 of > > > > > > pci0:0:10:0 > > > > > > pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > > > > > > pci_link26: Picked IRQ 20 with weight 0 > > > > > > pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH > > > > > > > > > > > > Full boot -v output: > > > > > > http://www.b1c1l1.com/media/debug/20130419-10-patched- > > > > > boot.txt.gz > > > > > > > > > > Can you add some printfs to the places that return the > > > > > AE_AML_BAD_RESOURCE_LENGTH to see which one is being triggered? > > > > > (Just look for that constant in sys/contrib/dev/acpica to find > > > > > the possible places.) > > > > > > > > Is there a macro for dumping information about Resource or > > > > Resource->Data? Here's what I have for now at > > > > sys/contrib/dev/acpica/resources/rscalc.c line 237: > > > > > > > > pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > > > > pci_link26: Picked IRQ 20 with weight 0 > > > > rscalc.c:237 > > > > Resource->Type: 7 > > > > Resource->Length: 0 > > > > pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH > > > > > > > > All of the errors are from there and look identical (Type 7, Length > 0). > > > > Type 7 appears to be ACPI_RESOURCE_TYPE_END_TAG. > > > > > > This hack fixes everything (now the SATA controller works). It > > > seems that the Resource->Length check might not be necessary for > > > ACPI_RESOURCE_TYPE_END_TAG. > > > > > > blee@genesis /usr/src/sys/contrib/dev/acpica $ svn diff > > > Index: components/resources/rscalc.c > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > --- components/resources/rscalc.c (revision 249624) > > > +++ components/resources/rscalc.c (working copy) > > > @@ -234,6 +234,15 @@ > > > > > > if (!Resource->Length) > > > { > > > + if (Resource->Type =3D=3D ACPI_RESOURCE_TYPE_END_TAG) { > > > + TotalSize =3D AcpiGbl_AmlResourceSizes [Resource- > >Type]; > > > + printf("TotalSize: %u\n", TotalSize); > > > + if (TotalSize !=3D 0) { > > > + printf("ACPI_RESOURCE_TYPE_END_TAG hack\n"); > > > + *SizeNeeded =3D AmlSizeNeeded + TotalSize; > > > + return_ACPI_STATUS (AE_OK); > > > + } > > > + } > > > return_ACPI_STATUS (AE_AML_BAD_RESOURCE_LENGTH); > > > } > > > > > > Index: components/resources/rslist.c > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > --- components/resources/rslist.c (revision 249624) > > > +++ components/resources/rslist.c (working copy) > > > @@ -203,6 +203,11 @@ > > > > > > if (!Resource->Length) > > > { > > > + if (Resource->Type =3D=3D ACPI_RESOURCE_TYPE_END_TAG) { > > > + printf("ACPI_RESOURCE_TYPE_END_TAG hack 2\n"); > > > + return_ACPI_STATUS (AE_OK); > > > + } > > > + > > > ACPI_ERROR ((AE_INFO, > > > "Invalid zero length descriptor in resource > list\n")); > > > return_ACPI_STATUS (AE_AML_BAD_RESOURCE_LENGTH); > > > > > > > > > > > > -- > > > Benjamin Lee > > > http://www.b1c1l1.com/ >=20 >=20 >=20 > -- > Benjamin Lee > http://www.b1c1l1.com/ From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 20 00:10:17 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 75C3813E; Sat, 20 Apr 2013 00:10:17 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by mx1.freebsd.org (Postfix) with ESMTP id 44929752; Sat, 20 Apr 2013 00:10:17 +0000 (UTC) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 19 Apr 2013 17:10:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.87,512,1363158000"; d="scan'208";a="288845994" Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228]) by azsmga001.ch.intel.com with ESMTP; 19 Apr 2013 17:09:56 -0700 Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 19 Apr 2013 17:09:56 -0700 Received: from fmsmsx153.amr.corp.intel.com ([169.254.9.79]) by FMSMSX102.amr.corp.intel.com ([169.254.2.214]) with mapi id 14.01.0355.002; Fri, 19 Apr 2013 17:09:56 -0700 From: "Moore, Robert" To: Benjamin Lee Subject: RE: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Thread-Topic: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Thread-Index: AQHOPG391d2djyxEFEWgLAw8ZTDWIJjeIoGAgABQL4CAABLrgIAAD0UAgAAIawD//4zvYIAAf2gA//+UG8A= Date: Sat, 20 Apr 2013 00:09:55 +0000 Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42EA2@FMSMSX153.amr.corp.intel.com> References: <20130418124940.47e3618a@b1c1l1.com> <201304191131.49433.jhb@freebsd.org> <20130419131849.7357c8f6@b1c1l1.com> <201304191726.31089.jhb@freebsd.org> <20130419152110.213c7fbb@b1c1l1.com> <20130419155118.7bafe9fc@b1c1l1.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42E28@FMSMSX153.amr.corp.intel.com> <20130419163528.204bf3ff@b1c1l1.com> In-Reply-To: <20130419163528.204bf3ff@b1c1l1.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 00:10:17 -0000 Can you send the actual binary DSDT or the ASCII acpidump (not disassembled= ) > -----Original Message----- > From: Benjamin Lee [mailto:ben@b1c1l1.com] > Sent: Friday, April 19, 2013 4:35 PM > To: Moore, Robert > Cc: John Baldwin; freebsd-acpi@freebsd.org > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 > in legacy IRQ resource type) >=20 > On Fri, 19 Apr 2013 23:00:07 +0000, "Moore, Robert" > wrote: > > No, the length must be set in all descriptors, end tag included. >=20 > Do you have any pointers on how I can fix my ASL? Where do I find the en= d > tags and what should I set the lengths to? >=20 > Here is the output from acpidump -dt: > http://www.b1c1l1.com/media/debug/20130418-nvidia.asl.gz >=20 > > > > > -----Original Message----- > > > From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- > > > acpi@freebsd.org] On Behalf Of Benjamin Lee > > > Sent: Friday, April 19, 2013 3:51 PM > > > To: John Baldwin > > > Cc: freebsd-acpi@freebsd.org > > > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA > > > IRQ 20 in legacy IRQ resource type) > > > > > > On Fri, 19 Apr 2013 15:21:10 -0700, Benjamin Lee > wrote: > > > > On Fri, 19 Apr 2013 17:26:31 -0400, John Baldwin > > > wrote: > > > > > On Friday, April 19, 2013 4:18:49 pm Benjamin Lee wrote: > > > > > > On Fri, 19 Apr 2013 11:31:49 -0400, John Baldwin > > > > > > > > > wrote: > > > > > > > On Thursday, April 18, 2013 3:49:40 pm Benjamin Lee wrote: > > > > > > > > I have a system that panics on boot with 10-CURRENT and > > > > > > > > boots with many ACPI error messages and non-functional > > > > > > > > devices with > > > 9.1-RELEASE. > > > > > > > > > > > > > > > > Motherboard is Foxconn C51XEM2AA (NVIDIA nForce 590) > > > > > > > > desktop > > > board. > > > > > > [...] > > > > > > > > Even though 9.1-RELEASE boots successfully, devices such > > > > > > > > as the ehci USB controller and SATA controller do not work. > > > > > > > > > > > > > > Ugh, your BIOS does unexpected things. It uses a _CRS for > > > > > > > these pci link devices that uses a "short" IRQ resource, but > > > > > > > uses an extended IRQ > > > > > resource in > > > > > > > _PRS (and expects an extended one in _SRS). We use _CRS as > > > > > > > a template for > > > > > the > > > > > > > resource to build. > > > > > > > > > > > > > > Try this patch. It's a bit hackish, but it forces us to not > > > > > > > use _CRS as a template if _CRS uses a "short" IRQ resource, > > > > > > > but the link supports non- > > > > > ISA > > > > > > > IRQs. > > > > > > [...] > > > > > > > > > > > > Thanks, that fixed the panic and the system boots. Now it is > > > > > > complaining about AE_AML_BAD_RESOURCE_LENGTH and still unable > > > > > > to route IRQs, but it definitely looks better than the ACPI > > > > > > parsing > > > errors in 9: > > > > > > > > > > > > pcib0: allocated type 3 (0xdffff000-0xdfffffff) for rid 10 of > > > > > > pci0:0:10:0 > > > > > > pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > > > > > > pci_link26: Picked IRQ 20 with weight 0 > > > > > > pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH > > > > > > > > > > > > Full boot -v output: > > > > > > http://www.b1c1l1.com/media/debug/20130419-10-patched- > > > > > boot.txt.gz > > > > > > > > > > Can you add some printfs to the places that return the > > > > > AE_AML_BAD_RESOURCE_LENGTH to see which one is being triggered? > > > > > (Just look for that constant in sys/contrib/dev/acpica to find > > > > > the possible places.) > > > > > > > > Is there a macro for dumping information about Resource or > > > > Resource->Data? Here's what I have for now at > > > > sys/contrib/dev/acpica/resources/rscalc.c line 237: > > > > > > > > pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > > > > pci_link26: Picked IRQ 20 with weight 0 > > > > rscalc.c:237 > > > > Resource->Type: 7 > > > > Resource->Length: 0 > > > > pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH > > > > > > > > All of the errors are from there and look identical (Type 7, Length > 0). > > > > Type 7 appears to be ACPI_RESOURCE_TYPE_END_TAG. > > > > > > This hack fixes everything (now the SATA controller works). It > > > seems that the Resource->Length check might not be necessary for > > > ACPI_RESOURCE_TYPE_END_TAG. > > > > > > blee@genesis /usr/src/sys/contrib/dev/acpica $ svn diff > > > Index: components/resources/rscalc.c > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > --- components/resources/rscalc.c (revision 249624) > > > +++ components/resources/rscalc.c (working copy) > > > @@ -234,6 +234,15 @@ > > > > > > if (!Resource->Length) > > > { > > > + if (Resource->Type =3D=3D ACPI_RESOURCE_TYPE_END_TAG) { > > > + TotalSize =3D AcpiGbl_AmlResourceSizes [Resource- > >Type]; > > > + printf("TotalSize: %u\n", TotalSize); > > > + if (TotalSize !=3D 0) { > > > + printf("ACPI_RESOURCE_TYPE_END_TAG hack\n"); > > > + *SizeNeeded =3D AmlSizeNeeded + TotalSize; > > > + return_ACPI_STATUS (AE_OK); > > > + } > > > + } > > > return_ACPI_STATUS (AE_AML_BAD_RESOURCE_LENGTH); > > > } > > > > > > Index: components/resources/rslist.c > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > --- components/resources/rslist.c (revision 249624) > > > +++ components/resources/rslist.c (working copy) > > > @@ -203,6 +203,11 @@ > > > > > > if (!Resource->Length) > > > { > > > + if (Resource->Type =3D=3D ACPI_RESOURCE_TYPE_END_TAG) { > > > + printf("ACPI_RESOURCE_TYPE_END_TAG hack 2\n"); > > > + return_ACPI_STATUS (AE_OK); > > > + } > > > + > > > ACPI_ERROR ((AE_INFO, > > > "Invalid zero length descriptor in resource > list\n")); > > > return_ACPI_STATUS (AE_AML_BAD_RESOURCE_LENGTH); > > > > > > > > > > > > -- > > > Benjamin Lee > > > http://www.b1c1l1.com/ >=20 >=20 >=20 > -- > Benjamin Lee > http://www.b1c1l1.com/ From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 20 00:22:02 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 647CF396; Sat, 20 Apr 2013 00:22:02 +0000 (UTC) (envelope-from ben@b1c1l1.com) Received: from lancer.b1c1l1.com (lancer.b1c1l1.com [72.13.86.100]) by mx1.freebsd.org (Postfix) with ESMTP id 45AE8791; Sat, 20 Apr 2013 00:22:02 +0000 (UTC) Received: by lancer.b1c1l1.com (Postfix) with ESMTPSA id D239C5C21; Fri, 19 Apr 2013 17:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=b1c1l1.com; s=default; t=1366417322; bh=qMbzwM3fNqWRaDw35oBW+Kd3323He6Ki1Q6oedgs3zo=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Vaxqd9a+tGtMEcBHQ2NGP0e2lzzhROvTWY+AL0XksCK9pAfLuWRs1nbtiqo7Q4vaI fhosLWabckjcSOgEx/fkAyptffplHBT58MZjlkmmjGYwhap1pfb7QuXi/VirbPKUF2 STb2x+jW5dz+kj+n5P0jD6bZigTpXYqZwm4NLKMM= Date: Fri, 19 Apr 2013 17:22:00 -0700 From: Benjamin Lee To: "Moore, Robert" Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Message-ID: <20130419172200.45d8601b@b1c1l1.com> In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42EA2@FMSMSX153.amr.corp.intel.com> References: <20130418124940.47e3618a@b1c1l1.com> <201304191131.49433.jhb@freebsd.org> <20130419131849.7357c8f6@b1c1l1.com> <201304191726.31089.jhb@freebsd.org> <20130419152110.213c7fbb@b1c1l1.com> <20130419155118.7bafe9fc@b1c1l1.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42E28@FMSMSX153.amr.corp.intel.com> <20130419163528.204bf3ff@b1c1l1.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42EA2@FMSMSX153.amr.corp.intel.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/4TzAPDF91p9L6qOcITCuvo3"; protocol="application/pgp-signature" Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 00:22:02 -0000 --Sig_/4TzAPDF91p9L6qOcITCuvo3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 20 Apr 2013 00:09:55 +0000, "Moore, Robert" wrote: > Can you send the actual binary DSDT or the ASCII acpidump (not disassembl= ed) I missed this earlier, but I just noticed _OS and _OSI checks for Windows. I'll need to do some testing with hw.acpi.osname. Here is the binary DSDT: http://www.b1c1l1.com/media/debug/20130419-nvidia.dsdt >=20 >=20 > > -----Original Message----- > > From: Benjamin Lee [mailto:ben@b1c1l1.com] > > Sent: Friday, April 19, 2013 4:35 PM > > To: Moore, Robert > > Cc: John Baldwin; freebsd-acpi@freebsd.org > > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 > > in legacy IRQ resource type) > >=20 > > On Fri, 19 Apr 2013 23:00:07 +0000, "Moore, Robert" > > wrote: > > > No, the length must be set in all descriptors, end tag included. > >=20 > > Do you have any pointers on how I can fix my ASL? Where do I find the = end > > tags and what should I set the lengths to? > >=20 > > Here is the output from acpidump -dt: > > http://www.b1c1l1.com/media/debug/20130418-nvidia.asl.gz > >=20 > > > > > > > -----Original Message----- > > > > From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- > > > > acpi@freebsd.org] On Behalf Of Benjamin Lee > > > > Sent: Friday, April 19, 2013 3:51 PM > > > > To: John Baldwin > > > > Cc: freebsd-acpi@freebsd.org > > > > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA > > > > IRQ 20 in legacy IRQ resource type) > > > > > > > > On Fri, 19 Apr 2013 15:21:10 -0700, Benjamin Lee > > wrote: > > > > > On Fri, 19 Apr 2013 17:26:31 -0400, John Baldwin > > > > wrote: > > > > > > On Friday, April 19, 2013 4:18:49 pm Benjamin Lee wrote: > > > > > > > On Fri, 19 Apr 2013 11:31:49 -0400, John Baldwin > > > > > > > > > > > wrote: > > > > > > > > On Thursday, April 18, 2013 3:49:40 pm Benjamin Lee wrote: > > > > > > > > > I have a system that panics on boot with 10-CURRENT and > > > > > > > > > boots with many ACPI error messages and non-functional > > > > > > > > > devices with > > > > 9.1-RELEASE. > > > > > > > > > > > > > > > > > > Motherboard is Foxconn C51XEM2AA (NVIDIA nForce 590) > > > > > > > > > desktop > > > > board. > > > > > > > [...] > > > > > > > > > Even though 9.1-RELEASE boots successfully, devices such > > > > > > > > > as the ehci USB controller and SATA controller do not wor= k. > > > > > > > > > > > > > > > > Ugh, your BIOS does unexpected things. It uses a _CRS for > > > > > > > > these pci link devices that uses a "short" IRQ resource, but > > > > > > > > uses an extended IRQ > > > > > > resource in > > > > > > > > _PRS (and expects an extended one in _SRS). We use _CRS as > > > > > > > > a template for > > > > > > the > > > > > > > > resource to build. > > > > > > > > > > > > > > > > Try this patch. It's a bit hackish, but it forces us to not > > > > > > > > use _CRS as a template if _CRS uses a "short" IRQ resource, > > > > > > > > but the link supports non- > > > > > > ISA > > > > > > > > IRQs. > > > > > > > [...] > > > > > > > > > > > > > > Thanks, that fixed the panic and the system boots. Now it is > > > > > > > complaining about AE_AML_BAD_RESOURCE_LENGTH and still unable > > > > > > > to route IRQs, but it definitely looks better than the ACPI > > > > > > > parsing > > > > errors in 9: > > > > > > > > > > > > > > pcib0: allocated type 3 (0xdffff000-0xdfffffff) for rid 10 of > > > > > > > pci0:0:10:0 > > > > > > > pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > > > > > > > pci_link26: Picked IRQ 20 with weight 0 > > > > > > > pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH > > > > > > > > > > > > > > Full boot -v output: > > > > > > > http://www.b1c1l1.com/media/debug/20130419-10-patched- > > > > > > boot.txt.gz > > > > > > > > > > > > Can you add some printfs to the places that return the > > > > > > AE_AML_BAD_RESOURCE_LENGTH to see which one is being triggered? > > > > > > (Just look for that constant in sys/contrib/dev/acpica to find > > > > > > the possible places.) > > > > > > > > > > Is there a macro for dumping information about Resource or > > > > > Resource->Data? Here's what I have for now at > > > > > sys/contrib/dev/acpica/resources/rscalc.c line 237: > > > > > > > > > > pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > > > > > pci_link26: Picked IRQ 20 with weight 0 > > > > > rscalc.c:237 > > > > > Resource->Type: 7 > > > > > Resource->Length: 0 > > > > > pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH > > > > > > > > > > All of the errors are from there and look identical (Type 7, Leng= th > > 0). > > > > > Type 7 appears to be ACPI_RESOURCE_TYPE_END_TAG. > > > > > > > > This hack fixes everything (now the SATA controller works). It > > > > seems that the Resource->Length check might not be necessary for > > > > ACPI_RESOURCE_TYPE_END_TAG. > > > > > > > > blee@genesis /usr/src/sys/contrib/dev/acpica $ svn diff > > > > Index: components/resources/rscalc.c > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > --- components/resources/rscalc.c (revision 249624) > > > > +++ components/resources/rscalc.c (working copy) > > > > @@ -234,6 +234,15 @@ > > > > > > > > if (!Resource->Length) > > > > { > > > > + if (Resource->Type =3D=3D ACPI_RESOURCE_TYPE_END_TAG) { > > > > + TotalSize =3D AcpiGbl_AmlResourceSizes [Resource- > > >Type]; > > > > + printf("TotalSize: %u\n", TotalSize); > > > > + if (TotalSize !=3D 0) { > > > > + printf("ACPI_RESOURCE_TYPE_END_TAG hack\n"); > > > > + *SizeNeeded =3D AmlSizeNeeded + TotalSize; > > > > + return_ACPI_STATUS (AE_OK); > > > > + } > > > > + } > > > > return_ACPI_STATUS (AE_AML_BAD_RESOURCE_LENGTH); > > > > } > > > > > > > > Index: components/resources/rslist.c > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > --- components/resources/rslist.c (revision 249624) > > > > +++ components/resources/rslist.c (working copy) > > > > @@ -203,6 +203,11 @@ > > > > > > > > if (!Resource->Length) > > > > { > > > > + if (Resource->Type =3D=3D ACPI_RESOURCE_TYPE_END_TAG) { > > > > + printf("ACPI_RESOURCE_TYPE_END_TAG hack 2\n"); > > > > + return_ACPI_STATUS (AE_OK); > > > > + } > > > > + > > > > ACPI_ERROR ((AE_INFO, > > > > "Invalid zero length descriptor in resource > > list\n")); > > > > return_ACPI_STATUS (AE_AML_BAD_RESOURCE_LENGTH); > > > > > > > > > > > > > > > > -- > > > > Benjamin Lee > > > > http://www.b1c1l1.com/ > >=20 > >=20 > >=20 > > -- > > Benjamin Lee > > http://www.b1c1l1.com/ --=20 Benjamin Lee http://www.b1c1l1.com/ --Sig_/4TzAPDF91p9L6qOcITCuvo3 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRcd+oAAoJEHpz6H1iC6qDxxoP/RWfeua86RWFOe7SBC4+pOlF J2Juyg5/duAq3xGjFThL0AK2wXS8sDzF1Tp+lhHJAIHq4XwxgWyEdLDZDPBaV3hf jLXsVl/Fsr3yDYHZtmPu+yhACDA6medayfqbJfFcBJ6vKkLtm51Phf/tsCgwmrfF 3sS8hysSDqLRPtwYeMgUoMzCYTt8AsvJY8gXIu8aSQfUYmGjpNNFFNUCcuGWKwRw u1CZa1QCT0rqCOGyz77XwIEYsBAEESduCuNUuQK58CkERcGi+h+qIrm6LrS06/w5 vANFBXk/OTrJCnXfTGn7dF1zOyTOsyb8xHRkI5YXocM0wB6k9qBI3xaDwXhT53IX 1VI5XBFXv9YHrX6IHspXnsFlkwcj5Ftwuc97rliS+n80Aaorm3nhcaD1qvVxPrNi ClpnlSKYdlEzXMuCuCsJfAMzjvdoxg+DmhDEVatnUQs5aXh2u/VLNQRESOXEAEVw q2VkK+/86IFf8vH81TYbtrBjlOiZ7uYlHHRDEgMzTH7A0kxZ8ED5ckPSq7D6/YrV Z6VMok3lKP8bLJFvzRhE3IDIAv+RHQZWyBrCCodZ0Cpoj37MuGXtmpKGkXpAAbEa xt70Xf2qg87sOrj0Rn0Lw9ou75eHsBsVCnMKz7TboTr8zGphVG16aEYjX09ctI6c sVXXTEsACedJXEwwnRhQ =f4mP -----END PGP SIGNATURE----- --Sig_/4TzAPDF91p9L6qOcITCuvo3-- From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 20 00:52:00 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C923C76A; Sat, 20 Apr 2013 00:52:00 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mx1.freebsd.org (Postfix) with ESMTP id 80117829; Sat, 20 Apr 2013 00:52:00 +0000 (UTC) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 19 Apr 2013 17:50:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.87,513,1363158000"; d="scan'208";a="297805043" Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34]) by orsmga001.jf.intel.com with ESMTP; 19 Apr 2013 17:51:43 -0700 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 19 Apr 2013 17:51:42 -0700 Received: from fmsmsx153.amr.corp.intel.com ([169.254.9.79]) by FMSMSX109.amr.corp.intel.com ([169.254.5.234]) with mapi id 14.01.0355.002; Fri, 19 Apr 2013 17:51:42 -0700 From: "Moore, Robert" To: Benjamin Lee Subject: RE: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Thread-Topic: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Thread-Index: AQHOPG391d2djyxEFEWgLAw8ZTDWIJjeIoGAgABQL4CAABLrgIAAD0UAgAAIawD//4zvYIAAf2gA//+UG8CAAHjlAP//kbwQ Date: Sat, 20 Apr 2013 00:51:42 +0000 Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42EE3@FMSMSX153.amr.corp.intel.com> References: <20130418124940.47e3618a@b1c1l1.com> <201304191131.49433.jhb@freebsd.org> <20130419131849.7357c8f6@b1c1l1.com> <201304191726.31089.jhb@freebsd.org> <20130419152110.213c7fbb@b1c1l1.com> <20130419155118.7bafe9fc@b1c1l1.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42E28@FMSMSX153.amr.corp.intel.com> <20130419163528.204bf3ff@b1c1l1.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42EA2@FMSMSX153.amr.corp.intel.com> <20130419172200.45d8601b@b1c1l1.com> In-Reply-To: <20130419172200.45d8601b@b1c1l1.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-acpi@freebsd.org" , "Guan, Chao" , "Zheng, Lv" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 00:52:00 -0000 I was able to quickly reproduce the _CRS/_SRS problem with the AUBA device.= I would imagine that this would fail on Windows also, as the basic model o= f read(_CRS)/modify/write(_SRS) is fairly standard. Unless something else i= s going on, of course. Our debugger has a command to do this: - resource \_SB_.PCI0.AUBA Device: \_SB_.PCI0.AUBA Evaluating _CRS rscalc-0663 [04] RsGetListLength : Type 20, AmlLength 04 InternalLe= ngth 10 rslist-0217 [05] RsConvertAmlToResource: Type 20, AmlLength 04 InternalLe= ngth 10 rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02 InternalLe= ngth 0C rscalc-0663 [04] RsGetListLength : Type 20, AmlLength 04 InternalLe= ngth 10 rslist-0217 [05] RsConvertAmlToResource: Type 20, AmlLength 04 InternalLe= ngth 10 rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02 InternalLe= ngth 0C [00] IRQ Resource Descriptor Length : 03 Triggering : Level Polarity : ActiveLow Sharing : Shared Interrupt Count : 00 Interrupt List : [01] EndTag Resource Resource Conversion Comparison: rscalc-0663 [04] RsGetListLength : Type 20, AmlLength 04 InternalLe= ngth 10 rslist-0217 [05] RsConvertAmlToResource: Type 20, AmlLength 04 InternalLe= ngth 10 rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02 InternalLe= ngth 0C Evaluating _SRS ACPI Error: Field [INZ6] at 56 exceeds Buffer [NULL] size 48 (bits) (201304= 18/dsopcode-326) [AcpiExec] Exception AE_AML_BUFFER_LIMIT during execution of method [SRSA] = Opcode [CreateWordField] @4 **** Exception AE_AML_BUFFER_LIMIT during execution of method [\_SB_.PCI0.S= RSA] (Node 004B7B50) Method Execution Stack: Method [SRSA] executing: [SRSA] @00000 #008B: CreateWordField (Arg0, 0= x05, INZ6) Method [_SRS] executing: Call to method [\_SB_.PCI0.SRSA] (Node 004B7B5= 0) Local Variables for method [SRSA]: Local0: 00000000 Local1: 00000000 Local2: 00000000 Local3: 00000000 Local4: 00000000 Local5: 00000000 Local6: 00000000 Local7: 00000000 Arguments for Method [SRSA]: (1 arguments defined, max concurrency =3D 0) Arg0: 004F4840 Buffer(6) 23 00 00 18 79 00 Arg1: 00000000 Arg2: 00000000 Arg3: 00000000 Arg4: 00000000 Arg5: 00000000 Arg6: 00000000 ACPI Error: Method parse/execution failed [\_SB_.PCI0.SRSA] (Node 004B7B50)= , AE_AML_BUFFER_LIMIT (20130418/psparse-632) ACPI Error: Method parse/execution failed [\_SB_.PCI0.AUBA._SRS] (Node 004B= EB50), AE_AML_BUFFER_LIMIT (20130418/psparse-632) AcpiSetCurrentResources failed: AE_AML_BUFFER_LIMIT Evaluating _PRS rscalc-0663 [04] RsGetListLength : Type 89, AmlLength 15 InternalLe= ngth 28 rslist-0217 [05] RsConvertAmlToResource: Type 89, AmlLength 15 InternalLe= ngth 28 rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02 InternalLe= ngth 0C [00] Extended IRQ Resource Type : ResourceConsumer Triggering : Level Polarity : ActiveLow Sharing : Shared Resource Source Index : 00 Resource Source : [Not Specified] Interrupt Count : 04 Dword00 : 00000014 Dword01 : 00000015 Dword02 : 00000016 Dword03 : 00000017 [01] EndTag Resource - > -----Original Message----- > From: Benjamin Lee [mailto:ben@b1c1l1.com] > Sent: Friday, April 19, 2013 5:22 PM > To: Moore, Robert > Cc: John Baldwin; freebsd-acpi@freebsd.org > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 > in legacy IRQ resource type) >=20 > On Sat, 20 Apr 2013 00:09:55 +0000, "Moore, Robert" > wrote: > > Can you send the actual binary DSDT or the ASCII acpidump (not > > disassembled) >=20 > I missed this earlier, but I just noticed _OS and _OSI checks for Windows= . > I'll need to do some testing with hw.acpi.osname. >=20 > Here is the binary DSDT: >=20 > http://www.b1c1l1.com/media/debug/20130419-nvidia.dsdt >=20 > > > > > > > -----Original Message----- > > > From: Benjamin Lee [mailto:ben@b1c1l1.com] > > > Sent: Friday, April 19, 2013 4:35 PM > > > To: Moore, Robert > > > Cc: John Baldwin; freebsd-acpi@freebsd.org > > > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA > > > IRQ 20 in legacy IRQ resource type) > > > > > > On Fri, 19 Apr 2013 23:00:07 +0000, "Moore, Robert" > > > wrote: > > > > No, the length must be set in all descriptors, end tag included. > > > > > > Do you have any pointers on how I can fix my ASL? Where do I find > > > the end tags and what should I set the lengths to? > > > > > > Here is the output from acpidump -dt: > > > http://www.b1c1l1.com/media/debug/20130418-nvidia.asl.gz > > > > > > > > > > > > -----Original Message----- > > > > > From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- > > > > > acpi@freebsd.org] On Behalf Of Benjamin Lee > > > > > Sent: Friday, April 19, 2013 3:51 PM > > > > > To: John Baldwin > > > > > Cc: freebsd-acpi@freebsd.org > > > > > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put > > > > > non-ISA IRQ 20 in legacy IRQ resource type) > > > > > > > > > > On Fri, 19 Apr 2013 15:21:10 -0700, Benjamin Lee > > > > > > > > wrote: > > > > > > On Fri, 19 Apr 2013 17:26:31 -0400, John Baldwin > > > > > > > > > > > wrote: > > > > > > > On Friday, April 19, 2013 4:18:49 pm Benjamin Lee wrote: > > > > > > > > On Fri, 19 Apr 2013 11:31:49 -0400, John Baldwin > > > > > > > > > > > > > wrote: > > > > > > > > > On Thursday, April 18, 2013 3:49:40 pm Benjamin Lee wrote= : > > > > > > > > > > I have a system that panics on boot with 10-CURRENT > > > > > > > > > > and boots with many ACPI error messages and > > > > > > > > > > non-functional devices with > > > > > 9.1-RELEASE. > > > > > > > > > > > > > > > > > > > > Motherboard is Foxconn C51XEM2AA (NVIDIA nForce 590) > > > > > > > > > > desktop > > > > > board. > > > > > > > > [...] > > > > > > > > > > Even though 9.1-RELEASE boots successfully, devices > > > > > > > > > > such as the ehci USB controller and SATA controller do > not work. > > > > > > > > > > > > > > > > > > Ugh, your BIOS does unexpected things. It uses a _CRS > > > > > > > > > for these pci link devices that uses a "short" IRQ > > > > > > > > > resource, but uses an extended IRQ > > > > > > > resource in > > > > > > > > > _PRS (and expects an extended one in _SRS). We use _CRS > > > > > > > > > as a template for > > > > > > > the > > > > > > > > > resource to build. > > > > > > > > > > > > > > > > > > Try this patch. It's a bit hackish, but it forces us to > > > > > > > > > not use _CRS as a template if _CRS uses a "short" IRQ > > > > > > > > > resource, but the link supports non- > > > > > > > ISA > > > > > > > > > IRQs. > > > > > > > > [...] > > > > > > > > > > > > > > > > Thanks, that fixed the panic and the system boots. Now it > > > > > > > > is complaining about AE_AML_BAD_RESOURCE_LENGTH and still > > > > > > > > unable to route IRQs, but it definitely looks better than > > > > > > > > the ACPI parsing > > > > > errors in 9: > > > > > > > > > > > > > > > > pcib0: allocated type 3 (0xdffff000-0xdfffffff) for rid 10 > > > > > > > > of > > > > > > > > pci0:0:10:0 > > > > > > > > pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > > > > > > > > pci_link26: Picked IRQ 20 with weight 0 > > > > > > > > pci_link26: Unable to route IRQs: > > > > > > > > AE_AML_BAD_RESOURCE_LENGTH > > > > > > > > > > > > > > > > Full boot -v output: > > > > > > > > http://www.b1c1l1.com/media/debug/20130419-10-patched- > > > > > > > boot.txt.gz > > > > > > > > > > > > > > Can you add some printfs to the places that return the > > > > > > > AE_AML_BAD_RESOURCE_LENGTH to see which one is being > triggered? > > > > > > > (Just look for that constant in sys/contrib/dev/acpica to > > > > > > > find the possible places.) > > > > > > > > > > > > Is there a macro for dumping information about Resource or > > > > > > Resource->Data? Here's what I have for now at > > > > > > sys/contrib/dev/acpica/resources/rscalc.c line 237: > > > > > > > > > > > > pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > > > > > > pci_link26: Picked IRQ 20 with weight 0 > > > > > > rscalc.c:237 > > > > > > Resource->Type: 7 > > > > > > Resource->Length: 0 > > > > > > pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH > > > > > > > > > > > > All of the errors are from there and look identical (Type 7, > > > > > > Length > > > 0). > > > > > > Type 7 appears to be ACPI_RESOURCE_TYPE_END_TAG. > > > > > > > > > > This hack fixes everything (now the SATA controller works). It > > > > > seems that the Resource->Length check might not be necessary for > > > > > ACPI_RESOURCE_TYPE_END_TAG. > > > > > > > > > > blee@genesis /usr/src/sys/contrib/dev/acpica $ svn diff > > > > > Index: components/resources/rscalc.c > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > --- components/resources/rscalc.c (revision 249624) > > > > > +++ components/resources/rscalc.c (working copy) > > > > > @@ -234,6 +234,15 @@ > > > > > > > > > > if (!Resource->Length) > > > > > { > > > > > + if (Resource->Type =3D=3D ACPI_RESOURCE_TYPE_END_TAG= ) { > > > > > + TotalSize =3D AcpiGbl_AmlResourceSizes [Resource= - > > > >Type]; > > > > > + printf("TotalSize: %u\n", TotalSize); > > > > > + if (TotalSize !=3D 0) { > > > > > + printf("ACPI_RESOURCE_TYPE_END_TAG hack\n"); > > > > > + *SizeNeeded =3D AmlSizeNeeded + TotalSize; > > > > > + return_ACPI_STATUS (AE_OK); > > > > > + } > > > > > + } > > > > > return_ACPI_STATUS (AE_AML_BAD_RESOURCE_LENGTH); > > > > > } > > > > > > > > > > Index: components/resources/rslist.c > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > --- components/resources/rslist.c (revision 249624) > > > > > +++ components/resources/rslist.c (working copy) > > > > > @@ -203,6 +203,11 @@ > > > > > > > > > > if (!Resource->Length) > > > > > { > > > > > + if (Resource->Type =3D=3D ACPI_RESOURCE_TYPE_END_TAG= ) { > > > > > + printf("ACPI_RESOURCE_TYPE_END_TAG hack 2\n"); > > > > > + return_ACPI_STATUS (AE_OK); > > > > > + } > > > > > + > > > > > ACPI_ERROR ((AE_INFO, > > > > > "Invalid zero length descriptor in resource > > > list\n")); > > > > > return_ACPI_STATUS (AE_AML_BAD_RESOURCE_LENGTH); > > > > > > > > > > > > > > > > > > > > -- > > > > > Benjamin Lee > > > > > http://www.b1c1l1.com/ > > > > > > > > > > > > -- > > > Benjamin Lee > > > http://www.b1c1l1.com/ >=20 >=20 >=20 > -- > Benjamin Lee > http://www.b1c1l1.com/ From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 20 01:44:51 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A46E9C3D; Sat, 20 Apr 2013 01:44:51 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mx1.freebsd.org (Postfix) with ESMTP id 50E7E922; Sat, 20 Apr 2013 01:44:50 +0000 (UTC) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 19 Apr 2013 18:44:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.87,513,1363158000"; d="scan'208";a="325236284" Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34]) by fmsmga002.fm.intel.com with ESMTP; 19 Apr 2013 18:44:42 -0700 Received: from fmsmsx153.amr.corp.intel.com ([169.254.9.79]) by FMSMSX103.amr.corp.intel.com ([169.254.3.111]) with mapi id 14.01.0355.002; Fri, 19 Apr 2013 18:44:42 -0700 From: "Moore, Robert" To: Benjamin Lee Subject: RE: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Thread-Topic: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Thread-Index: AQHOPG391d2djyxEFEWgLAw8ZTDWIJjeIoGAgABQL4CAABLrgIAAD0UAgAAIawD//4zvYIAAf2gA//+UG8CAAHjlAP//kbwQAAFR74A= Date: Sat, 20 Apr 2013 01:44:42 +0000 Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42EFF@FMSMSX153.amr.corp.intel.com> References: <20130418124940.47e3618a@b1c1l1.com> <201304191131.49433.jhb@freebsd.org> <20130419131849.7357c8f6@b1c1l1.com> <201304191726.31089.jhb@freebsd.org> <20130419152110.213c7fbb@b1c1l1.com> <20130419155118.7bafe9fc@b1c1l1.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42E28@FMSMSX153.amr.corp.intel.com> <20130419163528.204bf3ff@b1c1l1.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42EA2@FMSMSX153.amr.corp.intel.com> <20130419172200.45d8601b@b1c1l1.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-acpi@freebsd.org" , "Guan, Chao" , "Zheng, Lv" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 01:44:51 -0000 Disassembling the DSDT, we have this code in the _SRS execution path: Method (SRSA, 1, Serialized) { CreateWordField (Arg0, 0x05, INZ6) This code causes the main exception that was first reported: ACPI Error: Field [INZ6] at 56 exceeds Buffer [NULL] size 48 (bits) (201304= 18/dsopcode-326) [AcpiExec] Exception AE_AML_BUFFER_LIMIT during execution of method [SRSA] = Opcode [CreateWordField] @4 This code should not be a WORD field, it needs to be a BYTE field. This is = because the incoming buffer (Arg0) is exactly 6 bytes long -- so a WORD fie= ld at offset 5 will overrun the buffer. It looks like the code is attempting to access the last byte of the resourc= e descriptor, which is the second byte of the EndTag. Here is the fixed code: Method (SRSA, 1, Serialized) { CreateByteField (Arg0, 0x05, INZ6) Recompiling the DSDT and executing resource command, there are no errors: - resource \_SB_.PCI0.AUBA Device: \_SB_.PCI0.AUBA Evaluating _CRS rscalc-0663 [04] RsGetListLength : Type 20, AmlLength 04 InternalLe= ngth 10 rslist-0217 [05] RsConvertAmlToResource: Type 20, AmlLength 04 InternalLe= ngth 10 rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02 InternalLe= ngth 0C rscalc-0663 [04] RsGetListLength : Type 20, AmlLength 04 InternalLe= ngth 10 rslist-0217 [05] RsConvertAmlToResource: Type 20, AmlLength 04 InternalLe= ngth 10 rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02 InternalLe= ngth 0C [00] IRQ Resource Descriptor Length : 03 Triggering : Level Polarity : ActiveLow Sharing : Shared Interrupt Count : 00 Interrupt List : [01] EndTag Resource Resource Conversion Comparison: rscalc-0663 [04] RsGetListLength : Type 20, AmlLength 04 InternalLe= ngth 10 rslist-0217 [05] RsConvertAmlToResource: Type 20, AmlLength 04 InternalLe= ngth 10 rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02 InternalLe= ngth 0C Evaluating _SRS Evaluating _PRS rscalc-0663 [04] RsGetListLength : Type 89, AmlLength 15 InternalLe= ngth 28 rslist-0217 [05] RsConvertAmlToResource: Type 89, AmlLength 15 InternalLe= ngth 28 rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02 InternalLe= ngth 0C [00] Extended IRQ Resource Type : ResourceConsumer Triggering : Level Polarity : ActiveLow Sharing : Shared Resource Source Index : 00 Resource Source : [Not Specified] Interrupt Count : 04 Dword00 : 00000014 Dword01 : 00000015 Dword02 : 00000016 Dword03 : 00000017 [01] EndTag Resource So, this is obviously a rather serious bug in the DSDT that will need to be= addressed by the vendor. Chances are, there are a few more issues like thi= s in the code. As far as workarounds -- I'm sorry, but we can't allow a buffer overrun, an= d we can't "guess" what the code is really attempting to do. The correct ex= ecution is an abort with the exception AE_AML_BUFFER_LIMIT. I don't see any issues with the resource lengths, but I will double-check. Bob > -----Original Message----- > From: Moore, Robert > Sent: Friday, April 19, 2013 5:52 PM > To: 'Benjamin Lee' > Cc: John Baldwin; freebsd-acpi@freebsd.org; Zheng, Lv; Guan, Chao > Subject: RE: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 > in legacy IRQ resource type) >=20 > I was able to quickly reproduce the _CRS/_SRS problem with the AUBA > device. I would imagine that this would fail on Windows also, as the basi= c > model of read(_CRS)/modify/write(_SRS) is fairly standard. Unless > something else is going on, of course. >=20 > Our debugger has a command to do this: >=20 >=20 > - resource \_SB_.PCI0.AUBA >=20 > Device: \_SB_.PCI0.AUBA > Evaluating _CRS > rscalc-0663 [04] RsGetListLength : Type 20, AmlLength 04 > InternalLength 10 > rslist-0217 [05] RsConvertAmlToResource: Type 20, AmlLength 04 > InternalLength 10 > rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02 > InternalLength 0C > rscalc-0663 [04] RsGetListLength : Type 20, AmlLength 04 > InternalLength 10 > rslist-0217 [05] RsConvertAmlToResource: Type 20, AmlLength 04 > InternalLength 10 > rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02 > InternalLength 0C >=20 > [00] IRQ Resource > Descriptor Length : 03 > Triggering : Level > Polarity : ActiveLow > Sharing : Shared > Interrupt Count : 00 > Interrupt List : >=20 > [01] EndTag Resource > Resource Conversion Comparison: > rscalc-0663 [04] RsGetListLength : Type 20, AmlLength 04 > InternalLength 10 > rslist-0217 [05] RsConvertAmlToResource: Type 20, AmlLength 04 > InternalLength 10 > rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02 > InternalLength 0C Evaluating _SRS ACPI Error: Field [INZ6] at 56 exceeds > Buffer [NULL] size 48 (bits) (20130418/dsopcode-326) [AcpiExec] Exception > AE_AML_BUFFER_LIMIT during execution of method [SRSA] Opcode > [CreateWordField] @4 >=20 > **** Exception AE_AML_BUFFER_LIMIT during execution of method > [\_SB_.PCI0.SRSA] (Node 004B7B50) >=20 > Method Execution Stack: > Method [SRSA] executing: [SRSA] @00000 #008B: CreateWordField (Arg0, > 0x05, INZ6) > Method [_SRS] executing: Call to method [\_SB_.PCI0.SRSA] (Node > 004B7B50) >=20 > Local Variables for method [SRSA]: > Local0: 00000000 > Local1: 00000000 > Local2: 00000000 > Local3: 00000000 > Local4: 00000000 > Local5: 00000000 > Local6: 00000000 > Local7: 00000000 >=20 > Arguments for Method [SRSA]: (1 arguments defined, max concurrency =3D 0= ) > Arg0: 004F4840 Buffer(6) 23 00 00 18 79 00 > Arg1: 00000000 > Arg2: 00000000 > Arg3: 00000000 > Arg4: 00000000 > Arg5: 00000000 > Arg6: 00000000 >=20 > ACPI Error: Method parse/execution failed [\_SB_.PCI0.SRSA] (Node > 004B7B50), AE_AML_BUFFER_LIMIT (20130418/psparse-632) ACPI Error: Method > parse/execution failed [\_SB_.PCI0.AUBA._SRS] (Node 004BEB50), > AE_AML_BUFFER_LIMIT (20130418/psparse-632) AcpiSetCurrentResources failed= : > AE_AML_BUFFER_LIMIT Evaluating _PRS > rscalc-0663 [04] RsGetListLength : Type 89, AmlLength 15 > InternalLength 28 > rslist-0217 [05] RsConvertAmlToResource: Type 89, AmlLength 15 > InternalLength 28 > rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02 > InternalLength 0C >=20 > [00] Extended IRQ Resource > Type : ResourceConsumer > Triggering : Level > Polarity : ActiveLow > Sharing : Shared > Resource Source Index : 00 > Resource Source : [Not Specified] > Interrupt Count : 04 > Dword00 : 00000014 > Dword01 : 00000015 > Dword02 : 00000016 > Dword03 : 00000017 >=20 > [01] EndTag Resource > - >=20 >=20 >=20 > > -----Original Message----- > > From: Benjamin Lee [mailto:ben@b1c1l1.com] > > Sent: Friday, April 19, 2013 5:22 PM > > To: Moore, Robert > > Cc: John Baldwin; freebsd-acpi@freebsd.org > > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ > > 20 in legacy IRQ resource type) > > > > On Sat, 20 Apr 2013 00:09:55 +0000, "Moore, Robert" > > wrote: > > > Can you send the actual binary DSDT or the ASCII acpidump (not > > > disassembled) > > > > I missed this earlier, but I just noticed _OS and _OSI checks for > Windows. > > I'll need to do some testing with hw.acpi.osname. > > > > Here is the binary DSDT: > > > > http://www.b1c1l1.com/media/debug/20130419-nvidia.dsdt > > > > > > > > > > > > -----Original Message----- > > > > From: Benjamin Lee [mailto:ben@b1c1l1.com] > > > > Sent: Friday, April 19, 2013 4:35 PM > > > > To: Moore, Robert > > > > Cc: John Baldwin; freebsd-acpi@freebsd.org > > > > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA > > > > IRQ 20 in legacy IRQ resource type) > > > > > > > > On Fri, 19 Apr 2013 23:00:07 +0000, "Moore, Robert" > > > > wrote: > > > > > No, the length must be set in all descriptors, end tag included. > > > > > > > > Do you have any pointers on how I can fix my ASL? Where do I find > > > > the end tags and what should I set the lengths to? > > > > > > > > Here is the output from acpidump -dt: > > > > http://www.b1c1l1.com/media/debug/20130418-nvidia.asl.gz > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- > > > > > > acpi@freebsd.org] On Behalf Of Benjamin Lee > > > > > > Sent: Friday, April 19, 2013 3:51 PM > > > > > > To: John Baldwin > > > > > > Cc: freebsd-acpi@freebsd.org > > > > > > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put > > > > > > non-ISA IRQ 20 in legacy IRQ resource type) > > > > > > > > > > > > On Fri, 19 Apr 2013 15:21:10 -0700, Benjamin Lee > > > > > > > > > > wrote: > > > > > > > On Fri, 19 Apr 2013 17:26:31 -0400, John Baldwin > > > > > > > > > > > > > wrote: > > > > > > > > On Friday, April 19, 2013 4:18:49 pm Benjamin Lee wrote: > > > > > > > > > On Fri, 19 Apr 2013 11:31:49 -0400, John Baldwin > > > > > > > > > > > > > > > wrote: > > > > > > > > > > On Thursday, April 18, 2013 3:49:40 pm Benjamin Lee > wrote: > > > > > > > > > > > I have a system that panics on boot with 10-CURRENT > > > > > > > > > > > and boots with many ACPI error messages and > > > > > > > > > > > non-functional devices with > > > > > > 9.1-RELEASE. > > > > > > > > > > > > > > > > > > > > > > Motherboard is Foxconn C51XEM2AA (NVIDIA nForce 590) > > > > > > > > > > > desktop > > > > > > board. > > > > > > > > > [...] > > > > > > > > > > > Even though 9.1-RELEASE boots successfully, devices > > > > > > > > > > > such as the ehci USB controller and SATA controller > > > > > > > > > > > do > > not work. > > > > > > > > > > > > > > > > > > > > Ugh, your BIOS does unexpected things. It uses a _CRS > > > > > > > > > > for these pci link devices that uses a "short" IRQ > > > > > > > > > > resource, but uses an extended IRQ > > > > > > > > resource in > > > > > > > > > > _PRS (and expects an extended one in _SRS). We use > > > > > > > > > > _CRS as a template for > > > > > > > > the > > > > > > > > > > resource to build. > > > > > > > > > > > > > > > > > > > > Try this patch. It's a bit hackish, but it forces us > > > > > > > > > > to not use _CRS as a template if _CRS uses a "short" > > > > > > > > > > IRQ resource, but the link supports non- > > > > > > > > ISA > > > > > > > > > > IRQs. > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > Thanks, that fixed the panic and the system boots. Now > > > > > > > > > it is complaining about AE_AML_BAD_RESOURCE_LENGTH and > > > > > > > > > still unable to route IRQs, but it definitely looks > > > > > > > > > better than the ACPI parsing > > > > > > errors in 9: > > > > > > > > > > > > > > > > > > pcib0: allocated type 3 (0xdffff000-0xdfffffff) for rid > > > > > > > > > 10 of > > > > > > > > > pci0:0:10:0 > > > > > > > > > pcib0: matched entry for 0.10.INTA (src > > > > > > > > > \_SB_.PCI0.AUBA:0) > > > > > > > > > pci_link26: Picked IRQ 20 with weight 0 > > > > > > > > > pci_link26: Unable to route IRQs: > > > > > > > > > AE_AML_BAD_RESOURCE_LENGTH > > > > > > > > > > > > > > > > > > Full boot -v output: > > > > > > > > > http://www.b1c1l1.com/media/debug/20130419-10-patched- > > > > > > > > boot.txt.gz > > > > > > > > > > > > > > > > Can you add some printfs to the places that return the > > > > > > > > AE_AML_BAD_RESOURCE_LENGTH to see which one is being > > triggered? > > > > > > > > (Just look for that constant in sys/contrib/dev/acpica to > > > > > > > > find the possible places.) > > > > > > > > > > > > > > Is there a macro for dumping information about Resource or > > > > > > > Resource->Data? Here's what I have for now at > > > > > > > sys/contrib/dev/acpica/resources/rscalc.c line 237: > > > > > > > > > > > > > > pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > > > > > > > pci_link26: Picked IRQ 20 with weight 0 > > > > > > > rscalc.c:237 > > > > > > > Resource->Type: 7 > > > > > > > Resource->Length: 0 > > > > > > > pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH > > > > > > > > > > > > > > All of the errors are from there and look identical (Type 7, > > > > > > > Length > > > > 0). > > > > > > > Type 7 appears to be ACPI_RESOURCE_TYPE_END_TAG. > > > > > > > > > > > > This hack fixes everything (now the SATA controller works). > > > > > > It seems that the Resource->Length check might not be > > > > > > necessary for ACPI_RESOURCE_TYPE_END_TAG. > > > > > > > > > > > > blee@genesis /usr/src/sys/contrib/dev/acpica $ svn diff > > > > > > Index: components/resources/rscalc.c > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > --- components/resources/rscalc.c (revision 249624) > > > > > > +++ components/resources/rscalc.c (working copy) > > > > > > @@ -234,6 +234,15 @@ > > > > > > > > > > > > if (!Resource->Length) > > > > > > { > > > > > > + if (Resource->Type =3D=3D ACPI_RESOURCE_TYPE_END_T= AG) { > > > > > > + TotalSize =3D AcpiGbl_AmlResourceSizes > > > > > > + [Resource- > > > > >Type]; > > > > > > + printf("TotalSize: %u\n", TotalSize); > > > > > > + if (TotalSize !=3D 0) { > > > > > > + printf("ACPI_RESOURCE_TYPE_END_TAG > hack\n"); > > > > > > + *SizeNeeded =3D AmlSizeNeeded + TotalSize; > > > > > > + return_ACPI_STATUS (AE_OK); > > > > > > + } > > > > > > + } > > > > > > return_ACPI_STATUS (AE_AML_BAD_RESOURCE_LENGTH); > > > > > > } > > > > > > > > > > > > Index: components/resources/rslist.c > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > --- components/resources/rslist.c (revision 249624) > > > > > > +++ components/resources/rslist.c (working copy) > > > > > > @@ -203,6 +203,11 @@ > > > > > > > > > > > > if (!Resource->Length) > > > > > > { > > > > > > + if (Resource->Type =3D=3D ACPI_RESOURCE_TYPE_END_T= AG) { > > > > > > + printf("ACPI_RESOURCE_TYPE_END_TAG hack 2\n"); > > > > > > + return_ACPI_STATUS (AE_OK); > > > > > > + } > > > > > > + > > > > > > ACPI_ERROR ((AE_INFO, > > > > > > "Invalid zero length descriptor in resource > > > > list\n")); > > > > > > return_ACPI_STATUS (AE_AML_BAD_RESOURCE_LENGTH); > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Benjamin Lee > > > > > > http://www.b1c1l1.com/ > > > > > > > > > > > > > > > > -- > > > > Benjamin Lee > > > > http://www.b1c1l1.com/ > > > > > > > > -- > > Benjamin Lee > > http://www.b1c1l1.com/ From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 20 03:25:27 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 63340370; Sat, 20 Apr 2013 03:25:27 +0000 (UTC) (envelope-from ben@b1c1l1.com) Received: from lancer.b1c1l1.com (lancer.b1c1l1.com [IPv6:2607:f358:1a:1a:1000::]) by mx1.freebsd.org (Postfix) with ESMTP id 2F4DBC1B; Sat, 20 Apr 2013 03:25:27 +0000 (UTC) Received: by lancer.b1c1l1.com (Postfix) with ESMTPSA id 808F05C21; Fri, 19 Apr 2013 20:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=b1c1l1.com; s=default; t=1366428323; bh=seq7h06kaMrLBpvw0pWNBolBVciO7UFyy5kqtB84uoQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=xUl4IZU3t9IESCTTiwyynsEWpjYLmD9hoiwjrEN4Sy5dzRiwYOPr8cw38LI6veqK/ kijmhZ8kJZVD6ZssuhqvnKHx6YcxBfOrZk6p6/DDsrAsJQp7JUb9ZgTTeIHg1w/rqk EoK5SyangC4mZNc0wRIpGgnRWtjl9y0qgEn48pJw= Date: Fri, 19 Apr 2013 20:25:09 -0700 From: Benjamin Lee To: "Moore, Robert" Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Message-ID: <20130419202509.6a56d1d4@b1c1l1.com> In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42EFF@FMSMSX153.amr.corp.intel.com> References: <20130418124940.47e3618a@b1c1l1.com> <201304191131.49433.jhb@freebsd.org> <20130419131849.7357c8f6@b1c1l1.com> <201304191726.31089.jhb@freebsd.org> <20130419152110.213c7fbb@b1c1l1.com> <20130419155118.7bafe9fc@b1c1l1.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42E28@FMSMSX153.amr.corp.intel.com> <20130419163528.204bf3ff@b1c1l1.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42EA2@FMSMSX153.amr.corp.intel.com> <20130419172200.45d8601b@b1c1l1.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42EFF@FMSMSX153.amr.corp.intel.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/9_q.rxLcL.B0hrNKkw+kcXx"; protocol="application/pgp-signature" Cc: "freebsd-acpi@freebsd.org" , "Guan, Chao" , "Zheng, Lv" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 03:25:27 -0000 --Sig_/9_q.rxLcL.B0hrNKkw+kcXx Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 20 Apr 2013 01:44:42 +0000, "Moore, Robert" wrote: > Disassembling the DSDT, we have this code in the _SRS execution path: >=20 >=20 > Method (SRSA, 1, Serialized) > { > CreateWordField (Arg0, 0x05, INZ6) >=20 >=20 > This code causes the main exception that was first reported: >=20 > ACPI Error: Field [INZ6] at 56 exceeds Buffer [NULL] size 48 (bits) (2013= 0418/dsopcode-326) > [AcpiExec] Exception AE_AML_BUFFER_LIMIT during execution of method [SRSA= ] Opcode [CreateWordField] @4 >=20 >=20 > This code should not be a WORD field, it needs to be a BYTE field. This i= s because the incoming buffer (Arg0) is exactly 6 bytes long -- so a WORD f= ield at offset 5 will overrun the buffer. >=20 > It looks like the code is attempting to access the last byte of the resou= rce descriptor, which is the second byte of the EndTag. >=20 >=20 >=20 >=20 > Here is the fixed code: >=20 > Method (SRSA, 1, Serialized) > { > CreateByteField (Arg0, 0x05, INZ6) >=20 >=20 >=20 >=20 > Recompiling the DSDT and executing resource command, there are no errors: [...] > So, this is obviously a rather serious bug in the DSDT that will need to = be addressed by the vendor. Chances are, there are a few more issues like t= his in the code. >=20 > As far as workarounds -- I'm sorry, but we can't allow a buffer overrun, = and we can't "guess" what the code is really attempting to do. The correct = execution is an abort with the exception AE_AML_BUFFER_LIMIT. >=20 > I don't see any issues with the resource lengths, but I will double-check. Thank you! I have modified my ASL to use CreateByteField in the SRSA method. Unfortunately, I'm now seeing the following: With 9.1-RELEASE, all ACPI errors are gone but devices still do not work (even though they appear to be getting the proper PCI IRQs now instead of ISA IRQs). Nothing is complaining about AE_AML_BAD_RESOURCE_LENGTH, which confirms your observation that resource lengths in the ASL seem to be OK. 10-CURRENT is still triggering my ACPI_RESOURCE_TYPE_END_TAG hack (and devices are functioning), which might indicate a regression related to resource lengths. 9.1-RELEASE (fixed ASL) boot -v: http://www.b1c1l1.com/media/debug/20130419= -fixedasl-9-boot.txt.gz 10-CURRENT (fixed ASL) boot -v: http://www.b1c1l1.com/media/debug/20130419-= fixedasl-10-patched-boot.txt.gz In comparing the outputs, I see that 9.1-RELEASE prints 3 INTR messages: INTR: Adding local APIC 0 as a target INTR: Adding local APIC 0 as a target INTR: Adding local APIC 1 as a target while in 10-CURRENT I only see 1 INTR message: INTR: Adding local APIC 1 as a target which might be related to devices not working since they are being routed to lapic 0. > Bob >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Moore, Robert > > Sent: Friday, April 19, 2013 5:52 PM > > To: 'Benjamin Lee' > > Cc: John Baldwin; freebsd-acpi@freebsd.org; Zheng, Lv; Guan, Chao > > Subject: RE: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 > > in legacy IRQ resource type) > >=20 > > I was able to quickly reproduce the _CRS/_SRS problem with the AUBA > > device. I would imagine that this would fail on Windows also, as the ba= sic > > model of read(_CRS)/modify/write(_SRS) is fairly standard. Unless > > something else is going on, of course. > >=20 > > Our debugger has a command to do this: > >=20 > >=20 > > - resource \_SB_.PCI0.AUBA > >=20 > > Device: \_SB_.PCI0.AUBA > > Evaluating _CRS > > rscalc-0663 [04] RsGetListLength : Type 20, AmlLength 04 > > InternalLength 10 > > rslist-0217 [05] RsConvertAmlToResource: Type 20, AmlLength 04 > > InternalLength 10 > > rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02 > > InternalLength 0C > > rscalc-0663 [04] RsGetListLength : Type 20, AmlLength 04 > > InternalLength 10 > > rslist-0217 [05] RsConvertAmlToResource: Type 20, AmlLength 04 > > InternalLength 10 > > rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02 > > InternalLength 0C > >=20 > > [00] IRQ Resource > > Descriptor Length : 03 > > Triggering : Level > > Polarity : ActiveLow > > Sharing : Shared > > Interrupt Count : 00 > > Interrupt List : > >=20 > > [01] EndTag Resource > > Resource Conversion Comparison: > > rscalc-0663 [04] RsGetListLength : Type 20, AmlLength 04 > > InternalLength 10 > > rslist-0217 [05] RsConvertAmlToResource: Type 20, AmlLength 04 > > InternalLength 10 > > rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02 > > InternalLength 0C Evaluating _SRS ACPI Error: Field [INZ6] at 56 exceeds > > Buffer [NULL] size 48 (bits) (20130418/dsopcode-326) [AcpiExec] Excepti= on > > AE_AML_BUFFER_LIMIT during execution of method [SRSA] Opcode > > [CreateWordField] @4 > >=20 > > **** Exception AE_AML_BUFFER_LIMIT during execution of method > > [\_SB_.PCI0.SRSA] (Node 004B7B50) > >=20 > > Method Execution Stack: > > Method [SRSA] executing: [SRSA] @00000 #008B: CreateWordField (Arg= 0, > > 0x05, INZ6) > > Method [_SRS] executing: Call to method [\_SB_.PCI0.SRSA] (Node > > 004B7B50) > >=20 > > Local Variables for method [SRSA]: > > Local0: 00000000 > > Local1: 00000000 > > Local2: 00000000 > > Local3: 00000000 > > Local4: 00000000 > > Local5: 00000000 > > Local6: 00000000 > > Local7: 00000000 > >=20 > > Arguments for Method [SRSA]: (1 arguments defined, max concurrency =3D= 0) > > Arg0: 004F4840 Buffer(6) 23 00 00 18 79 00 > > Arg1: 00000000 > > Arg2: 00000000 > > Arg3: 00000000 > > Arg4: 00000000 > > Arg5: 00000000 > > Arg6: 00000000 > >=20 > > ACPI Error: Method parse/execution failed [\_SB_.PCI0.SRSA] (Node > > 004B7B50), AE_AML_BUFFER_LIMIT (20130418/psparse-632) ACPI Error: Method > > parse/execution failed [\_SB_.PCI0.AUBA._SRS] (Node 004BEB50), > > AE_AML_BUFFER_LIMIT (20130418/psparse-632) AcpiSetCurrentResources fail= ed: > > AE_AML_BUFFER_LIMIT Evaluating _PRS > > rscalc-0663 [04] RsGetListLength : Type 89, AmlLength 15 > > InternalLength 28 > > rslist-0217 [05] RsConvertAmlToResource: Type 89, AmlLength 15 > > InternalLength 28 > > rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02 > > InternalLength 0C > >=20 > > [00] Extended IRQ Resource > > Type : ResourceConsumer > > Triggering : Level > > Polarity : ActiveLow > > Sharing : Shared > > Resource Source Index : 00 > > Resource Source : [Not Specified] > > Interrupt Count : 04 > > Dword00 : 00000014 > > Dword01 : 00000015 > > Dword02 : 00000016 > > Dword03 : 00000017 > >=20 > > [01] EndTag Resource > > - > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Benjamin Lee [mailto:ben@b1c1l1.com] > > > Sent: Friday, April 19, 2013 5:22 PM > > > To: Moore, Robert > > > Cc: John Baldwin; freebsd-acpi@freebsd.org > > > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ > > > 20 in legacy IRQ resource type) > > > > > > On Sat, 20 Apr 2013 00:09:55 +0000, "Moore, Robert" > > > wrote: > > > > Can you send the actual binary DSDT or the ASCII acpidump (not > > > > disassembled) > > > > > > I missed this earlier, but I just noticed _OS and _OSI checks for > > Windows. > > > I'll need to do some testing with hw.acpi.osname. > > > > > > Here is the binary DSDT: > > > > > > http://www.b1c1l1.com/media/debug/20130419-nvidia.dsdt > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Benjamin Lee [mailto:ben@b1c1l1.com] > > > > > Sent: Friday, April 19, 2013 4:35 PM > > > > > To: Moore, Robert > > > > > Cc: John Baldwin; freebsd-acpi@freebsd.org > > > > > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA > > > > > IRQ 20 in legacy IRQ resource type) > > > > > > > > > > On Fri, 19 Apr 2013 23:00:07 +0000, "Moore, Robert" > > > > > wrote: > > > > > > No, the length must be set in all descriptors, end tag included. > > > > > > > > > > Do you have any pointers on how I can fix my ASL? Where do I find > > > > > the end tags and what should I set the lengths to? > > > > > > > > > > Here is the output from acpidump -dt: > > > > > http://www.b1c1l1.com/media/debug/20130418-nvidia.asl.gz > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- > > > > > > > acpi@freebsd.org] On Behalf Of Benjamin Lee > > > > > > > Sent: Friday, April 19, 2013 3:51 PM > > > > > > > To: John Baldwin > > > > > > > Cc: freebsd-acpi@freebsd.org > > > > > > > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put > > > > > > > non-ISA IRQ 20 in legacy IRQ resource type) > > > > > > > > > > > > > > On Fri, 19 Apr 2013 15:21:10 -0700, Benjamin Lee > > > > > > > > > > > > wrote: > > > > > > > > On Fri, 19 Apr 2013 17:26:31 -0400, John Baldwin > > > > > > > > > > > > > > > wrote: > > > > > > > > > On Friday, April 19, 2013 4:18:49 pm Benjamin Lee wrote: > > > > > > > > > > On Fri, 19 Apr 2013 11:31:49 -0400, John Baldwin > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > On Thursday, April 18, 2013 3:49:40 pm Benjamin Lee > > wrote: > > > > > > > > > > > > I have a system that panics on boot with 10-CURRENT > > > > > > > > > > > > and boots with many ACPI error messages and > > > > > > > > > > > > non-functional devices with > > > > > > > 9.1-RELEASE. > > > > > > > > > > > > > > > > > > > > > > > > Motherboard is Foxconn C51XEM2AA (NVIDIA nForce 590) > > > > > > > > > > > > desktop > > > > > > > board. > > > > > > > > > > [...] > > > > > > > > > > > > Even though 9.1-RELEASE boots successfully, devices > > > > > > > > > > > > such as the ehci USB controller and SATA controller > > > > > > > > > > > > do > > > not work. > > > > > > > > > > > > > > > > > > > > > > Ugh, your BIOS does unexpected things. It uses a _CRS > > > > > > > > > > > for these pci link devices that uses a "short" IRQ > > > > > > > > > > > resource, but uses an extended IRQ > > > > > > > > > resource in > > > > > > > > > > > _PRS (and expects an extended one in _SRS). We use > > > > > > > > > > > _CRS as a template for > > > > > > > > > the > > > > > > > > > > > resource to build. > > > > > > > > > > > > > > > > > > > > > > Try this patch. It's a bit hackish, but it forces us > > > > > > > > > > > to not use _CRS as a template if _CRS uses a "short" > > > > > > > > > > > IRQ resource, but the link supports non- > > > > > > > > > ISA > > > > > > > > > > > IRQs. > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > > Thanks, that fixed the panic and the system boots. Now > > > > > > > > > > it is complaining about AE_AML_BAD_RESOURCE_LENGTH and > > > > > > > > > > still unable to route IRQs, but it definitely looks > > > > > > > > > > better than the ACPI parsing > > > > > > > errors in 9: > > > > > > > > > > > > > > > > > > > > pcib0: allocated type 3 (0xdffff000-0xdfffffff) for rid > > > > > > > > > > 10 of > > > > > > > > > > pci0:0:10:0 > > > > > > > > > > pcib0: matched entry for 0.10.INTA (src > > > > > > > > > > \_SB_.PCI0.AUBA:0) > > > > > > > > > > pci_link26: Picked IRQ 20 with weight 0 > > > > > > > > > > pci_link26: Unable to route IRQs: > > > > > > > > > > AE_AML_BAD_RESOURCE_LENGTH > > > > > > > > > > > > > > > > > > > > Full boot -v output: > > > > > > > > > > http://www.b1c1l1.com/media/debug/20130419-10-patched- > > > > > > > > > boot.txt.gz > > > > > > > > > > > > > > > > > > Can you add some printfs to the places that return the > > > > > > > > > AE_AML_BAD_RESOURCE_LENGTH to see which one is being > > > triggered? > > > > > > > > > (Just look for that constant in sys/contrib/dev/acpica to > > > > > > > > > find the possible places.) > > > > > > > > > > > > > > > > Is there a macro for dumping information about Resource or > > > > > > > > Resource->Data? Here's what I have for now at > > > > > > > > sys/contrib/dev/acpica/resources/rscalc.c line 237: > > > > > > > > > > > > > > > > pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > > > > > > > > pci_link26: Picked IRQ 20 with weight 0 > > > > > > > > rscalc.c:237 > > > > > > > > Resource->Type: 7 > > > > > > > > Resource->Length: 0 > > > > > > > > pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH > > > > > > > > > > > > > > > > All of the errors are from there and look identical (Type 7, > > > > > > > > Length > > > > > 0). > > > > > > > > Type 7 appears to be ACPI_RESOURCE_TYPE_END_TAG. > > > > > > > > > > > > > > This hack fixes everything (now the SATA controller works). > > > > > > > It seems that the Resource->Length check might not be > > > > > > > necessary for ACPI_RESOURCE_TYPE_END_TAG. > > > > > > > > > > > > > > blee@genesis /usr/src/sys/contrib/dev/acpica $ svn diff > > > > > > > Index: components/resources/rscalc.c > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > --- components/resources/rscalc.c (revision 249624) > > > > > > > +++ components/resources/rscalc.c (working copy) > > > > > > > @@ -234,6 +234,15 @@ > > > > > > > > > > > > > > if (!Resource->Length) > > > > > > > { > > > > > > > + if (Resource->Type =3D=3D ACPI_RESOURCE_TYPE_END= _TAG) { > > > > > > > + TotalSize =3D AcpiGbl_AmlResourceSizes > > > > > > > + [Resource- > > > > > >Type]; > > > > > > > + printf("TotalSize: %u\n", TotalSize); > > > > > > > + if (TotalSize !=3D 0) { > > > > > > > + printf("ACPI_RESOURCE_TYPE_END_TAG > > hack\n"); > > > > > > > + *SizeNeeded =3D AmlSizeNeeded + TotalSiz= e; > > > > > > > + return_ACPI_STATUS (AE_OK); > > > > > > > + } > > > > > > > + } > > > > > > > return_ACPI_STATUS (AE_AML_BAD_RESOURCE_LENGTH); > > > > > > > } > > > > > > > > > > > > > > Index: components/resources/rslist.c > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > --- components/resources/rslist.c (revision 249624) > > > > > > > +++ components/resources/rslist.c (working copy) > > > > > > > @@ -203,6 +203,11 @@ > > > > > > > > > > > > > > if (!Resource->Length) > > > > > > > { > > > > > > > + if (Resource->Type =3D=3D ACPI_RESOURCE_TYPE_END= _TAG) { > > > > > > > + printf("ACPI_RESOURCE_TYPE_END_TAG hack 2\n"= ); > > > > > > > + return_ACPI_STATUS (AE_OK); > > > > > > > + } > > > > > > > + > > > > > > > ACPI_ERROR ((AE_INFO, > > > > > > > "Invalid zero length descriptor in resource > > > > > list\n")); > > > > > > > return_ACPI_STATUS (AE_AML_BAD_RESOURCE_LENGTH); --=20 Benjamin Lee http://www.b1c1l1.com/ --Sig_/9_q.rxLcL.B0hrNKkw+kcXx Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRcgqhAAoJEHpz6H1iC6qDGcsP/2IhjQRic4t+hZ1FiFUWckQS 4Gcv18cOmSbr1W0hmSublcJ4deGgUkCpT6jH7hDmw+E0cpeACguQ//a7w4jepbDt 808/gPeeDRfiHY+Iu1+4NXKudS7ad3F05pS+OvKzTnfE2Aya5wP7pwuOsmp6hiZ2 PSY9W1AOb4P/rbJJFuwsuAnZSL2vxgXicm8+eC2tPlotkuw6xAsFZ953F+QVwPMJ 0c236jx43dR+v5u0qKh011K0iCz3RR9aPQUitUol38sd/QroSCIcP/JRQzTQLMgg hlXFLgbxqyGnqey2mz6HvcJUcQ/Pj5N6o3jjXCPqEEdN2O51XOE4ponjoM9zGe1u zw5fQ2Qf1WHn79qQbizTp9eKO/tpr9XWO+ec+X2WvLBGZ4rYCOupaEiSJZAjY/GK lyAqqNaMPpv3amPMnA8vGIG+IuzCm8esI1OJc8oJUuaJ7J1pwpvXEWV2JjNntB/W xR/NIY4wn3aLv3tf9CmMsvUDRPae1LJr6253nSUkfFHFT8DddmjthxtE8+be0CkN rRRY+5M+g+bNmQdMpRTnHIscJynclpkPuZH+m/jsfScO5X2wo7KVRj7/0Yza9qwm qcNLdVk5JZSEvocOB+SI8BIydISDZn+Ba82MJJEgF81m/mW1hCJ9qO4Q4wLIX1O6 tLDCyhgvTORugXQtc3ye =lf6i -----END PGP SIGNATURE----- --Sig_/9_q.rxLcL.B0hrNKkw+kcXx-- From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 20 04:14:17 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6E39058D; Sat, 20 Apr 2013 04:14:17 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by mx1.freebsd.org (Postfix) with ESMTP id E2891D86; Sat, 20 Apr 2013 04:14:16 +0000 (UTC) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 19 Apr 2013 21:13:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.87,513,1363158000"; d="scan'208";a="288901777" Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37]) by azsmga001.ch.intel.com with ESMTP; 19 Apr 2013 21:13:08 -0700 Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 19 Apr 2013 21:13:07 -0700 Received: from fmsmsx153.amr.corp.intel.com ([169.254.9.79]) by fmsmsx111.amr.corp.intel.com ([169.254.2.230]) with mapi id 14.01.0355.002; Fri, 19 Apr 2013 21:13:07 -0700 From: "Moore, Robert" To: Benjamin Lee Subject: RE: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Thread-Topic: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Thread-Index: AQHOPG391d2djyxEFEWgLAw8ZTDWIJjeIoGAgABQL4CAABLrgIAAD0UAgAAIawD//4zvYIAAf2gA//+UG8CAAHjlAP//kbwQAAFR74AAEtwlgAANAthg Date: Sat, 20 Apr 2013 04:13:06 +0000 Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42F37@FMSMSX153.amr.corp.intel.com> References: <20130418124940.47e3618a@b1c1l1.com> <201304191131.49433.jhb@freebsd.org> <20130419131849.7357c8f6@b1c1l1.com> <201304191726.31089.jhb@freebsd.org> <20130419152110.213c7fbb@b1c1l1.com> <20130419155118.7bafe9fc@b1c1l1.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42E28@FMSMSX153.amr.corp.intel.com> <20130419163528.204bf3ff@b1c1l1.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42EA2@FMSMSX153.amr.corp.intel.com> <20130419172200.45d8601b@b1c1l1.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42EFF@FMSMSX153.amr.corp.intel.com> <20130419202509.6a56d1d4@b1c1l1.com> In-Reply-To: <20130419202509.6a56d1d4@b1c1l1.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-acpi@freebsd.org" , "Guan, Chao" , "Zheng, Lv" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 04:14:17 -0000 That's about as far as I can help. Bob > -----Original Message----- > From: Benjamin Lee [mailto:ben@b1c1l1.com] > Sent: Friday, April 19, 2013 8:25 PM > To: Moore, Robert > Cc: John Baldwin; freebsd-acpi@freebsd.org; Zheng, Lv; Guan, Chao > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 > in legacy IRQ resource type) >=20 > On Sat, 20 Apr 2013 01:44:42 +0000, "Moore, Robert" > wrote: > > Disassembling the DSDT, we have this code in the _SRS execution path: > > > > > > Method (SRSA, 1, Serialized) > > { > > CreateWordField (Arg0, 0x05, INZ6) > > > > > > This code causes the main exception that was first reported: > > > > ACPI Error: Field [INZ6] at 56 exceeds Buffer [NULL] size 48 (bits) > > (20130418/dsopcode-326) [AcpiExec] Exception AE_AML_BUFFER_LIMIT > > during execution of method [SRSA] Opcode [CreateWordField] @4 > > > > > > This code should not be a WORD field, it needs to be a BYTE field. This > is because the incoming buffer (Arg0) is exactly 6 bytes long -- so a WOR= D > field at offset 5 will overrun the buffer. > > > > It looks like the code is attempting to access the last byte of the > resource descriptor, which is the second byte of the EndTag. > > > > > > > > > > Here is the fixed code: > > > > Method (SRSA, 1, Serialized) > > { > > CreateByteField (Arg0, 0x05, INZ6) > > > > > > > > > > Recompiling the DSDT and executing resource command, there are no > errors: > [...] > > So, this is obviously a rather serious bug in the DSDT that will need t= o > be addressed by the vendor. Chances are, there are a few more issues like > this in the code. > > > > As far as workarounds -- I'm sorry, but we can't allow a buffer overrun= , > and we can't "guess" what the code is really attempting to do. The correc= t > execution is an abort with the exception AE_AML_BUFFER_LIMIT. > > > > I don't see any issues with the resource lengths, but I will double- > check. >=20 > Thank you! I have modified my ASL to use CreateByteField in the SRSA > method. >=20 > Unfortunately, I'm now seeing the following: >=20 > With 9.1-RELEASE, all ACPI errors are gone but devices still do not work > (even though they appear to be getting the proper PCI IRQs now instead of > ISA IRQs). Nothing is complaining about AE_AML_BAD_RESOURCE_LENGTH, whic= h > confirms your observation that resource lengths in the ASL seem to be OK. >=20 > 10-CURRENT is still triggering my ACPI_RESOURCE_TYPE_END_TAG hack (and > devices are functioning), which might indicate a regression related to > resource lengths. >=20 > 9.1-RELEASE (fixed ASL) boot -v: > http://www.b1c1l1.com/media/debug/20130419-fixedasl-9-boot.txt.gz > 10-CURRENT (fixed ASL) boot -v: > http://www.b1c1l1.com/media/debug/20130419-fixedasl-10-patched-boot.txt.g= z >=20 > In comparing the outputs, I see that 9.1-RELEASE prints 3 INTR messages: >=20 > INTR: Adding local APIC 0 as a target > INTR: Adding local APIC 0 as a target > INTR: Adding local APIC 1 as a target >=20 > while in 10-CURRENT I only see 1 INTR message: >=20 > INTR: Adding local APIC 1 as a target >=20 > which might be related to devices not working since they are being routed > to lapic 0. >=20 > > Bob > > > > > > > > > > > > > -----Original Message----- > > > From: Moore, Robert > > > Sent: Friday, April 19, 2013 5:52 PM > > > To: 'Benjamin Lee' > > > Cc: John Baldwin; freebsd-acpi@freebsd.org; Zheng, Lv; Guan, Chao > > > Subject: RE: panic: acpi_pci_link_srs_from_crs: can't put non-ISA > > > IRQ 20 in legacy IRQ resource type) > > > > > > I was able to quickly reproduce the _CRS/_SRS problem with the AUBA > > > device. I would imagine that this would fail on Windows also, as the > > > basic model of read(_CRS)/modify/write(_SRS) is fairly standard. > > > Unless something else is going on, of course. > > > > > > Our debugger has a command to do this: > > > > > > > > > - resource \_SB_.PCI0.AUBA > > > > > > Device: \_SB_.PCI0.AUBA > > > Evaluating _CRS > > > rscalc-0663 [04] RsGetListLength : Type 20, AmlLength 04 > > > InternalLength 10 > > > rslist-0217 [05] RsConvertAmlToResource: Type 20, AmlLength 04 > > > InternalLength 10 > > > rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02 > > > InternalLength 0C > > > rscalc-0663 [04] RsGetListLength : Type 20, AmlLength 04 > > > InternalLength 10 > > > rslist-0217 [05] RsConvertAmlToResource: Type 20, AmlLength 04 > > > InternalLength 10 > > > rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02 > > > InternalLength 0C > > > > > > [00] IRQ Resource > > > Descriptor Length : 03 > > > Triggering : Level > > > Polarity : ActiveLow > > > Sharing : Shared > > > Interrupt Count : 00 > > > Interrupt List : > > > > > > [01] EndTag Resource > > > Resource Conversion Comparison: > > > rscalc-0663 [04] RsGetListLength : Type 20, AmlLength 04 > > > InternalLength 10 > > > rslist-0217 [05] RsConvertAmlToResource: Type 20, AmlLength 04 > > > InternalLength 10 > > > rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02 > > > InternalLength 0C Evaluating _SRS ACPI Error: Field [INZ6] at 56 > > > exceeds Buffer [NULL] size 48 (bits) (20130418/dsopcode-326) > > > [AcpiExec] Exception AE_AML_BUFFER_LIMIT during execution of method > > > [SRSA] Opcode [CreateWordField] @4 > > > > > > **** Exception AE_AML_BUFFER_LIMIT during execution of method > > > [\_SB_.PCI0.SRSA] (Node 004B7B50) > > > > > > Method Execution Stack: > > > Method [SRSA] executing: [SRSA] @00000 #008B: CreateWordField > > > (Arg0, 0x05, INZ6) > > > Method [_SRS] executing: Call to method [\_SB_.PCI0.SRSA] (Node > > > 004B7B50) > > > > > > Local Variables for method [SRSA]: > > > Local0: 00000000 > > > Local1: 00000000 > > > Local2: 00000000 > > > Local3: 00000000 > > > Local4: 00000000 > > > Local5: 00000000 > > > Local6: 00000000 > > > Local7: 00000000 > > > > > > Arguments for Method [SRSA]: (1 arguments defined, max concurrency = =3D > 0) > > > Arg0: 004F4840 Buffer(6) 23 00 00 18 79 00 > > > Arg1: 00000000 > > > Arg2: 00000000 > > > Arg3: 00000000 > > > Arg4: 00000000 > > > Arg5: 00000000 > > > Arg6: 00000000 > > > > > > ACPI Error: Method parse/execution failed [\_SB_.PCI0.SRSA] (Node > > > 004B7B50), AE_AML_BUFFER_LIMIT (20130418/psparse-632) ACPI Error: > > > Method parse/execution failed [\_SB_.PCI0.AUBA._SRS] (Node > > > 004BEB50), AE_AML_BUFFER_LIMIT (20130418/psparse-632) > AcpiSetCurrentResources failed: > > > AE_AML_BUFFER_LIMIT Evaluating _PRS > > > rscalc-0663 [04] RsGetListLength : Type 89, AmlLength 15 > > > InternalLength 28 > > > rslist-0217 [05] RsConvertAmlToResource: Type 89, AmlLength 15 > > > InternalLength 28 > > > rslist-0217 [05] RsConvertAmlToResource: Type 78, AmlLength 02 > > > InternalLength 0C > > > > > > [00] Extended IRQ Resource > > > Type : ResourceConsumer > > > Triggering : Level > > > Polarity : ActiveLow > > > Sharing : Shared > > > Resource Source Index : 00 > > > Resource Source : [Not Specified] > > > Interrupt Count : 04 > > > Dword00 : 00000014 > > > Dword01 : 00000015 > > > Dword02 : 00000016 > > > Dword03 : 00000017 > > > > > > [01] EndTag Resource > > > - > > > > > > > > > > > > > -----Original Message----- > > > > From: Benjamin Lee [mailto:ben@b1c1l1.com] > > > > Sent: Friday, April 19, 2013 5:22 PM > > > > To: Moore, Robert > > > > Cc: John Baldwin; freebsd-acpi@freebsd.org > > > > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA > > > > IRQ > > > > 20 in legacy IRQ resource type) > > > > > > > > On Sat, 20 Apr 2013 00:09:55 +0000, "Moore, Robert" > > > > wrote: > > > > > Can you send the actual binary DSDT or the ASCII acpidump (not > > > > > disassembled) > > > > > > > > I missed this earlier, but I just noticed _OS and _OSI checks for > > > Windows. > > > > I'll need to do some testing with hw.acpi.osname. > > > > > > > > Here is the binary DSDT: > > > > > > > > http://www.b1c1l1.com/media/debug/20130419-nvidia.dsdt > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Benjamin Lee [mailto:ben@b1c1l1.com] > > > > > > Sent: Friday, April 19, 2013 4:35 PM > > > > > > To: Moore, Robert > > > > > > Cc: John Baldwin; freebsd-acpi@freebsd.org > > > > > > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put > > > > > > non-ISA IRQ 20 in legacy IRQ resource type) > > > > > > > > > > > > On Fri, 19 Apr 2013 23:00:07 +0000, "Moore, Robert" > > > > > > wrote: > > > > > > > No, the length must be set in all descriptors, end tag > included. > > > > > > > > > > > > Do you have any pointers on how I can fix my ASL? Where do I > > > > > > find the end tags and what should I set the lengths to? > > > > > > > > > > > > Here is the output from acpidump -dt: > > > > > > http://www.b1c1l1.com/media/debug/20130418-nvidia.asl.gz > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: owner-freebsd-acpi@freebsd.org > > > > > > > > [mailto:owner-freebsd- acpi@freebsd.org] On Behalf Of > > > > > > > > Benjamin Lee > > > > > > > > Sent: Friday, April 19, 2013 3:51 PM > > > > > > > > To: John Baldwin > > > > > > > > Cc: freebsd-acpi@freebsd.org > > > > > > > > Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put > > > > > > > > non-ISA IRQ 20 in legacy IRQ resource type) > > > > > > > > > > > > > > > > On Fri, 19 Apr 2013 15:21:10 -0700, Benjamin Lee > > > > > > > > > > > > > > wrote: > > > > > > > > > On Fri, 19 Apr 2013 17:26:31 -0400, John Baldwin > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > On Friday, April 19, 2013 4:18:49 pm Benjamin Lee wrote= : > > > > > > > > > > > On Fri, 19 Apr 2013 11:31:49 -0400, John Baldwin > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > On Thursday, April 18, 2013 3:49:40 pm Benjamin > > > > > > > > > > > > Lee > > > wrote: > > > > > > > > > > > > > I have a system that panics on boot with > > > > > > > > > > > > > 10-CURRENT and boots with many ACPI error > > > > > > > > > > > > > messages and non-functional devices with > > > > > > > > 9.1-RELEASE. > > > > > > > > > > > > > > > > > > > > > > > > > > Motherboard is Foxconn C51XEM2AA (NVIDIA nForce > > > > > > > > > > > > > 590) desktop > > > > > > > > board. > > > > > > > > > > > [...] > > > > > > > > > > > > > Even though 9.1-RELEASE boots successfully, > > > > > > > > > > > > > devices such as the ehci USB controller and SATA > > > > > > > > > > > > > controller do > > > > not work. > > > > > > > > > > > > > > > > > > > > > > > > Ugh, your BIOS does unexpected things. It uses a > > > > > > > > > > > > _CRS for these pci link devices that uses a > > > > > > > > > > > > "short" IRQ resource, but uses an extended IRQ > > > > > > > > > > resource in > > > > > > > > > > > > _PRS (and expects an extended one in _SRS). We > > > > > > > > > > > > use _CRS as a template for > > > > > > > > > > the > > > > > > > > > > > > resource to build. > > > > > > > > > > > > > > > > > > > > > > > > Try this patch. It's a bit hackish, but it forces > > > > > > > > > > > > us to not use _CRS as a template if _CRS uses a > "short" > > > > > > > > > > > > IRQ resource, but the link supports non- > > > > > > > > > > ISA > > > > > > > > > > > > IRQs. > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > > > > Thanks, that fixed the panic and the system boots. > > > > > > > > > > > Now it is complaining about > > > > > > > > > > > AE_AML_BAD_RESOURCE_LENGTH and still unable to route > > > > > > > > > > > IRQs, but it definitely looks better than the ACPI > > > > > > > > > > > parsing > > > > > > > > errors in 9: > > > > > > > > > > > > > > > > > > > > > > pcib0: allocated type 3 (0xdffff000-0xdfffffff) for > > > > > > > > > > > rid > > > > > > > > > > > 10 of > > > > > > > > > > > pci0:0:10:0 > > > > > > > > > > > pcib0: matched entry for 0.10.INTA (src > > > > > > > > > > > \_SB_.PCI0.AUBA:0) > > > > > > > > > > > pci_link26: Picked IRQ 20 with weight 0 > > > > > > > > > > > pci_link26: Unable to route IRQs: > > > > > > > > > > > AE_AML_BAD_RESOURCE_LENGTH > > > > > > > > > > > > > > > > > > > > > > Full boot -v output: > > > > > > > > > > > http://www.b1c1l1.com/media/debug/20130419-10-patche > > > > > > > > > > > d- > > > > > > > > > > boot.txt.gz > > > > > > > > > > > > > > > > > > > > Can you add some printfs to the places that return the > > > > > > > > > > AE_AML_BAD_RESOURCE_LENGTH to see which one is being > > > > triggered? > > > > > > > > > > (Just look for that constant in sys/contrib/dev/acpica > > > > > > > > > > to find the possible places.) > > > > > > > > > > > > > > > > > > Is there a macro for dumping information about Resource > > > > > > > > > or > > > > > > > > > Resource->Data? Here's what I have for now at > > > > > > > > > sys/contrib/dev/acpica/resources/rscalc.c line 237: > > > > > > > > > > > > > > > > > > pcib0: matched entry for 0.10.INTA (src > > > > > > > > > \_SB_.PCI0.AUBA:0) > > > > > > > > > pci_link26: Picked IRQ 20 with weight 0 > > > > > > > > > rscalc.c:237 > > > > > > > > > Resource->Type: 7 > > > > > > > > > Resource->Length: 0 > > > > > > > > > pci_link26: Unable to route IRQs: > > > > > > > > > AE_AML_BAD_RESOURCE_LENGTH > > > > > > > > > > > > > > > > > > All of the errors are from there and look identical > > > > > > > > > (Type 7, Length > > > > > > 0). > > > > > > > > > Type 7 appears to be ACPI_RESOURCE_TYPE_END_TAG. > > > > > > > > > > > > > > > > This hack fixes everything (now the SATA controller works). > > > > > > > > It seems that the Resource->Length check might not be > > > > > > > > necessary for ACPI_RESOURCE_TYPE_END_TAG. > > > > > > > > > > > > > > > > blee@genesis /usr/src/sys/contrib/dev/acpica $ svn diff > > > > > > > > Index: components/resources/rscalc.c > > > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > =3D > > > > > > > > --- components/resources/rscalc.c (revision 249624) > > > > > > > > +++ components/resources/rscalc.c (working copy) > > > > > > > > @@ -234,6 +234,15 @@ > > > > > > > > > > > > > > > > if (!Resource->Length) > > > > > > > > { > > > > > > > > + if (Resource->Type =3D=3D > ACPI_RESOURCE_TYPE_END_TAG) { > > > > > > > > + TotalSize =3D AcpiGbl_AmlResourceSizes > > > > > > > > + [Resource- > > > > > > >Type]; > > > > > > > > + printf("TotalSize: %u\n", TotalSize); > > > > > > > > + if (TotalSize !=3D 0) { > > > > > > > > + printf("ACPI_RESOURCE_TYPE_END_TAG > > > hack\n"); > > > > > > > > + *SizeNeeded =3D AmlSizeNeeded + > TotalSize; > > > > > > > > + return_ACPI_STATUS (AE_OK); > > > > > > > > + } > > > > > > > > + } > > > > > > > > return_ACPI_STATUS > (AE_AML_BAD_RESOURCE_LENGTH); > > > > > > > > } > > > > > > > > > > > > > > > > Index: components/resources/rslist.c > > > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > =3D > > > > > > > > --- components/resources/rslist.c (revision 249624) > > > > > > > > +++ components/resources/rslist.c (working copy) > > > > > > > > @@ -203,6 +203,11 @@ > > > > > > > > > > > > > > > > if (!Resource->Length) > > > > > > > > { > > > > > > > > + if (Resource->Type =3D=3D > ACPI_RESOURCE_TYPE_END_TAG) { > > > > > > > > + printf("ACPI_RESOURCE_TYPE_END_TAG hack > 2\n"); > > > > > > > > + return_ACPI_STATUS (AE_OK); > > > > > > > > + } > > > > > > > > + > > > > > > > > ACPI_ERROR ((AE_INFO, > > > > > > > > "Invalid zero length descriptor in > > > > > > > > resource > > > > > > list\n")); > > > > > > > > return_ACPI_STATUS > > > > > > > > (AE_AML_BAD_RESOURCE_LENGTH); >=20 >=20 > -- > Benjamin Lee > http://www.b1c1l1.com/ From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 20 09:13:12 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A619F56F; Sat, 20 Apr 2013 09:13:12 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 1974013D6; Sat, 20 Apr 2013 09:13:11 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id c10so1927958wiw.6 for ; Sat, 20 Apr 2013 02:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=T27N221VBQcgew8IAzQ1DghAk2SCGeiszqjN+mxAzj4=; b=bm30PzLAa7a2465hiBdDzqJ/VLbVLhB2aHk4EVyjulc9dd8L+lsccizn9KLmCmwos3 fZtNHstwwLL/fD3BliFmUJryhdh8nHnWmdRjvBIA42rIKnStZsBlnUul041ZQDyXTDFs 7fLfZJd0gR5MBjwuZo0cpo2q7uXNVtEc9/LoPL4UadbGmCSog7hS8fsR6Kmtf3ca5o5S wsYOXs2rdApMYSlWYEbtEjV/xOLpf1FWmONYNT+ojComTBiB5RK0H1zzrevNPZKB8AqP NDXhlMG138Mfs9VoDwGFM2NOGM2qa6SgwZlJ0XnRlsOP3Y+1UUoGniKI3wQTs9tfAfNY /7PA== X-Received: by 10.180.92.229 with SMTP id cp5mr10453485wib.20.1366449190103; Sat, 20 Apr 2013 02:13:10 -0700 (PDT) Received: from melon.localnet (11.33.91.91.rev.sfr.net. [91.91.33.11]) by mx.google.com with ESMTPS id o3sm8551185wia.2.2013.04.20.02.13.07 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 20 Apr 2013 02:13:08 -0700 (PDT) From: David Demelier To: Andriy Gapon Subject: Re: panics due to buggy ACPI in Dell Latitude E6530? Date: Sat, 20 Apr 2013 02:13:08 -0700 (PDT) Message-ID: <2514081.nyTdW5Saad@melon> User-Agent: KMail/4.10.1 (FreeBSD/9.1-RELEASE-p1; KDE/4.10.1; amd64; ; ) In-Reply-To: <515DA036.5070206@FreeBSD.org> References: <512E24CD.9090404@gmail.com> <51582122.3050703@gmail.com> <515DA036.5070206@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Cc: freebsd-acpi@freebsd.org, kron X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 09:13:12 -0000 Le jeudi 4 avril 2013 18:45:58 Andriy Gapon a =E9crit : > on 31/03/2013 14:42 kron said the following: > > I'm sorry I forgot to update the thread - good you're reminding. > > Andriy did a brilliant job at debugging the issue and I owe him > > to say in public: Thank you, Andriy! >=20 > I also apologize for not sharing the information promptly. >=20 > So here is a summary. >=20 > The problem turned out to be with the reference count in ACPICA. It = doesn't > have any internal locking and so it relied on locks obtained by the > callers. But not all of the callers obtained the relevant locks > (namespace, interpreter) and they not really needed them (except for = the > reference counting). Also, our acpi_battery driver uses ACPICA inter= faces > that were problematic. Additionally the driver allows parallel queri= es, > not sure if that is an intentional choice. >=20 > So now the ACPICA developers have fixed the reference counting code a= nd no > changes in FreeBSD code should be required. We are just waiting for = the > next ACPICA release. That's for head. Not sure which approach we wil= l take > for stable branches, because we haven't been doing any MFCs of ACPICA= > imports. So there are tow choices: - use the below patch to prevent > parallel execution in the batter driver - manually apply the specific= > reference count change to ACPICA code in the branches >=20 > Finally many thanks to Olli/kron for doing a lot of testing and debug= ging. > And many thanks to Tom Lislegaard who did a lot of testing and debugg= ing too > - in our debugging session I reached all the same conclusions and cam= e up > with a (different) patch, but then got distracted and completely forg= ot > about the issue until it resurfaced again. >=20 Thanks a lot for the very detailed explanation. For now I'll use the pa= tch=20 until the acpica release is merge into the next FreeBSD release :-). Regards, > > The results are: > > - hw.acpi.osname=3D"Linux" is not relevant > > - there's some ACPICA issue Andriy took to discuss with other > > =20 > > hackers (and much above my competence to comment) > > =20 > > - a temporary workaround: > > --- sys/dev/acpica/acpi_battery.c (revision 248682) > > +++ sys/dev/acpica/acpi_battery.c (working copy) > > @@ -360,6 +360,8 @@ > >=20 > > int error, unit; > > device_t dev; > >=20 > > + mtx_lock(&Giant); > > + > >=20 > > /* For commands that use the ioctl_arg struct, validate it fir= st. */ > > error =3D ENXIO; > > unit =3D 0; > >=20 > > @@ -417,6 +419,7 @@ > >=20 > > error =3D EINVAL; > > =20 > > } > >=20 > > + mtx_unlock(&Giant); > >=20 > > return (error); > > =20 > > } > >=20 > > The patch works for me without any problem. I guess it won't hurt > > your system ;-) but I actually don't know if/how it relates to your= > > PR. --=20 David Demelier From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 20 12:27:05 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1669774B; Sat, 20 Apr 2013 12:27:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id E74001B41; Sat, 20 Apr 2013 12:27:04 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8FD4CB988; Sat, 20 Apr 2013 08:27:02 -0400 (EDT) From: John Baldwin To: "Moore, Robert" Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Date: Sat, 20 Apr 2013 08:19:57 -0400 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <20130418124940.47e3618a@b1c1l1.com> <20130419202509.6a56d1d4@b1c1l1.com> <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42F37@FMSMSX153.amr.corp.intel.com> In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E36FE42F37@FMSMSX153.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304200819.57868.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sat, 20 Apr 2013 08:27:02 -0400 (EDT) Cc: "freebsd-acpi@freebsd.org" , "Zheng, Lv" , "Guan, Chao" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 12:27:05 -0000 On Saturday, April 20, 2013 12:13:06 AM Moore, Robert wrote: > That's about as far as I can help. > Bob In this case I think you want to patch the _CRS method to use an ExtendedIRQ resource rather than patching _SRS. _PRS is returning IRQs > 15 which won't fit into the IRQ resource used by _CRS, and _SRS is expecting that layout. I think the other patch I posted to this thread should fix the end tag and allow my earlier patch to work as a workaround for this system. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 20 12:27:05 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5A51E74F for ; Sat, 20 Apr 2013 12:27:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 32C581B43 for ; Sat, 20 Apr 2013 12:27:05 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2BC93B94F; Sat, 20 Apr 2013 08:27:02 -0400 (EDT) From: John Baldwin To: Benjamin Lee Subject: Re: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type) Date: Sat, 20 Apr 2013 08:17:15 -0400 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <20130418124940.47e3618a@b1c1l1.com> <201304191726.31089.jhb@freebsd.org> <20130419152110.213c7fbb@b1c1l1.com> In-Reply-To: <20130419152110.213c7fbb@b1c1l1.com> MIME-Version: 1.0 Message-Id: <201304200817.15189.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sat, 20 Apr 2013 08:27:02 -0400 (EDT) Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 12:27:05 -0000 On Friday, April 19, 2013 06:21:10 PM Benjamin Lee wrote: > On Fri, 19 Apr 2013 17:26:31 -0400, John Baldwin wrote: > > On Friday, April 19, 2013 4:18:49 pm Benjamin Lee wrote: > > > On Fri, 19 Apr 2013 11:31:49 -0400, John Baldwin wrote: > > > > On Thursday, April 18, 2013 3:49:40 pm Benjamin Lee wrote: > > > > > I have a system that panics on boot with 10-CURRENT and boots with > > > > > many ACPI error messages and non-functional devices with > > > > > 9.1-RELEASE. > > > > > > > > > > Motherboard is Foxconn C51XEM2AA (NVIDIA nForce 590) desktop board. > > > > > > [...] > > > > > > > > Even though 9.1-RELEASE boots successfully, devices such as the > > > > > ehci USB controller and SATA controller do not work. > > > > > > > > Ugh, your BIOS does unexpected things. It uses a _CRS for these pci > > > > link devices that uses a "short" IRQ resource, but uses an extended > > > > IRQ > > > > resource in > > > > > > _PRS (and expects an extended one in _SRS). We use _CRS as a > > > > template for > > > > the > > > > > > resource to build. > > > > > > > > Try this patch. It's a bit hackish, but it forces us to not use _CRS > > > > as a template if _CRS uses a "short" IRQ resource, but the link > > > > supports non- > > > > ISA > > > > > > IRQs. > > > > > > [...] > > > > > > Thanks, that fixed the panic and the system boots. Now it is > > > complaining about AE_AML_BAD_RESOURCE_LENGTH and still unable to route > > > IRQs, but it definitely looks better than the ACPI parsing errors in 9: > > > > > > pcib0: allocated type 3 (0xdffff000-0xdfffffff) for rid 10 of > > > pci0:0:10:0 pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > > > pci_link26: Picked IRQ 20 with weight 0 > > > pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH > > > > > > Full boot -v output: > > > http://www.b1c1l1.com/media/debug/20130419-10-patched- > > > > boot.txt.gz > > > > Can you add some printfs to the places that return the > > AE_AML_BAD_RESOURCE_LENGTH to see which one is being triggered? (Just > > look for that constant in sys/contrib/dev/acpica to find the possible > > places.) > > Is there a macro for dumping information about Resource or > Resource->Data? Here's what I have for now at > sys/contrib/dev/acpica/resources/rscalc.c line 237: > > pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) > pci_link26: Picked IRQ 20 with weight 0 > rscalc.c:237 > Resource->Type: 7 > Resource->Length: 0 > pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH > > All of the errors are from there and look identical (Type 7, Length 0). > Type 7 appears to be ACPI_RESOURCE_TYPE_END_TAG. Ah, this is easy to fix then. It seems in sys/dev/acpica/acpi.c in acpi_AppendBufferResource() we didn't create the end tag correctly. Can you try this in addition to the patch to acpi_pci_link.c: Index: sys/dev/acpica/acpi.c =================================================================== --- acpi.c (revision 249195) +++ acpi.c (working copy) @@ -2384,7 +2384,7 @@ /* And add the terminator. */ rp = ACPI_NEXT_RESOURCE(rp); rp->Type = ACPI_RESOURCE_TYPE_END_TAG; - rp->Length = 0; + rp->Length = ACPI_RS_SIZE_MIN; return (AE_OK); } -- John Baldwin