From owner-freebsd-hardware@freebsd.org Sun Apr 16 09:03:25 2017 Return-Path: Delivered-To: freebsd-hardware@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E647D4047F for ; Sun, 16 Apr 2017 09:03:25 +0000 (UTC) (envelope-from freebsd-doc@fjl.co.uk) Received: from bs1.fjl.org.uk (bs1.fjl.org.uk [84.45.41.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "bs1.fjl.org.uk", Issuer "bs1.fjl.org.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C6A9C1177 for ; Sun, 16 Apr 2017 09:03:24 +0000 (UTC) (envelope-from freebsd-doc@fjl.co.uk) Received: from [192.168.1.35] (host31-53-31-182.range31-53.btcentralplus.com [31.53.31.182]) (authenticated bits=0) by bs1.fjl.org.uk (8.14.4/8.14.4) with ESMTP id v3G8n0I9095950 for ; Sun, 16 Apr 2017 09:49:00 +0100 (BST) (envelope-from freebsd-doc@fjl.co.uk) Subject: Re: SSD errors To: freebsd-hardware@freebsd.org References: <20170413205932.GJ2149@shrubbery.net> From: Frank Leonhardt Message-ID: <02898e76-9285-03e7-e76a-77a5290376b9@fjl.co.uk> Date: Sun, 16 Apr 2017 09:49:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170413205932.GJ2149@shrubbery.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Apr 2017 09:03:25 -0000 On 13/04/2017 21:59, heasley wrote: > > When I push a lot of data to them, such as an rsync, I receive errors like > the below. If I move drives between slots, it seems to follow the chassis > slots, those closest to the power supply, but I'm not positive about this. > > I suppose the questions for list are: > - have I missed any fbsd ssd-specific configuration? > > - all 4 have non-zero UDMA_CRC_Error_Count counters; not many, about the > same number, which I believe implies electrical interference - most > likely in the cable or chassis backplane. Should I buy some specific > model cable? other recommendations? I'm not aware of any SSD-specific stuff you've missed. The SSD option on the initialisation code in the BIOS is probably just there because there's no need to wait for spin-up time (as you probably thought too). So I don't have an answer, but here are a few thoughts: I think it's the CRC error (out of that lot) that you should be worried about. It means that the drive wrote data, but when it read it back it didn't match. With ST506 this could (and often was) a cable fault but not with IDE. This doesn't mean dodgy cables can't cause you problems with IDE; only that they'd manifest differently. If the drive wrote the data to the flash with a CRC and then the CRC didn't match later, it doesn't make any difference if the data was corrupted on it's way to the drive, or even if it was corrupted on its way back (ZFS would pick that up). So it must have been corrupted on-drive. Right? (I could be wrong about where your CRC errors are being tested/detected, so not necessarily right). So with this in mind, why should the drive's location on the shelf matter (if it does make a difference). I can think of two reasons - electromagnetic interference from adjacent circuits or PSU problems. So if it were me, I'd check the interference theory by using longer cables and spreading the drives out. Serial transfer on long cables isn't really a problem like it was with parallel. That's the easy check. Then it's on to PSU issues. Does an SSD use more or less power than spinning rust? Really? Most people assume they'll use less but it's not as much less as you think, and it varies in different ways. If the PSU can't cope with the peak (e.g. while it's writing). IT people will know all about watts. Add up the number of watts on all your drives and if it's <= the number of watts written on your PSU, cushty. Wrong! An engineer will tell you you can't add watts together and get anything meaningful. And believing the label on a PSU is a mug's game. So, if you've got a decent oscilloscope take a look at the supply rails where they enter the drives. Try writing, and if you get so much as a blip on the voltage then do something about it. If you haven't got a 'scope to hand, I'd try running (some) the drives of a different PSU and see that makes a difference. Although I haven't hit this problem myself, I'd be surprised if the same PSU design intended to power spinning rust at a relatively constant current could cope well with an SSD going from nothing much to lots to nothing much again over a very short space of time. If I was connecting a different PSU to the SSD I'd load it with some real drives just to stabilise the current output a bit (i.e. plug an old drive or two on to some of the other spare outlets). Then there's always the chance it's over-cooking, but I think you'd have mentioned if they were getting very hot. Regards, Frank. From owner-freebsd-hardware@freebsd.org Sun Apr 16 14:31:56 2017 Return-Path: Delivered-To: freebsd-hardware@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BF088D40770 for ; Sun, 16 Apr 2017 14:31:56 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 660C312D4 for ; Sun, 16 Apr 2017 14:31:56 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id BCFD0122557 for ; Sun, 16 Apr 2017 09:26:14 -0500 (CDT) Subject: Re: SSD errors To: freebsd-hardware@freebsd.org References: <20170413205932.GJ2149@shrubbery.net> <02898e76-9285-03e7-e76a-77a5290376b9@fjl.co.uk> From: Karl Denninger Message-ID: Date: Sun, 16 Apr 2017 09:26:10 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <02898e76-9285-03e7-e76a-77a5290376b9@fjl.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms040301070301060709040608" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Apr 2017 14:31:56 -0000 This is a cryptographically signed message in MIME format. --------------ms040301070301060709040608 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/16/2017 03:49, Frank Leonhardt wrote: > On 13/04/2017 21:59, heasley wrote: >> >> When I push a lot of data to them, such as an rsync, I receive errors >> like >> the below. If I move drives between slots, it seems to follow the >> chassis >> slots, those closest to the power supply, but I'm not positive about >> this. >> >> I suppose the questions for list are: >> - have I missed any fbsd ssd-specific configuration? >> >> - all 4 have non-zero UDMA_CRC_Error_Count counters; not many, about t= he >> same number, which I believe implies electrical interference - most= >> likely in the cable or chassis backplane. Should I buy some specif= ic >> model cable? other recommendations? > > > I'm not aware of any SSD-specific stuff you've missed. The SSD option > on the initialisation code in the BIOS is probably just there because > there's no need to wait for spin-up time (as you probably thought too).= > > So I don't have an answer, but here are a few thoughts: > > I think it's the CRC error (out of that lot) that you should be > worried about. It means that the drive wrote data, but when it read it > back it didn't match. With ST506 this could (and often was) a cable > fault but not with IDE. This doesn't mean dodgy cables can't cause you > problems with IDE; only that they'd manifest differently. If the drive > wrote the data to the flash with a CRC and then the CRC didn't match > later, it doesn't make any difference if the data was corrupted on > it's way to the drive, or even if it was corrupted on its way back > (ZFS would pick that up). So it must have been corrupted on-drive. > Right? (I could be wrong about where your CRC errors are being > tested/detected, so not necessarily right). > > So with this in mind, why should the drive's location on the shelf > matter (if it does make a difference). I can think of two reasons - > electromagnetic interference from adjacent circuits or PSU problems. > > So if it were me, I'd check the interference theory by using longer > cables and spreading the drives out. Serial transfer on long cables > isn't really a problem like it was with parallel. That's the easy check= =2E > > Then it's on to PSU issues. Does an SSD use more or less power than > spinning rust? Really? Most people assume they'll use less but it's > not as much less as you think, and it varies in different ways. If the > PSU can't cope with the peak (e.g. while it's writing). > > IT people will know all about watts. Add up the number of watts on all > your drives and if it's <=3D the number of watts written on your PSU, > cushty. > > Wrong! An engineer will tell you you can't add watts together and get > anything meaningful. And believing the label on a PSU is a mug's game. > So, if you've got a decent oscilloscope take a look at the supply > rails where they enter the drives. Try writing, and if you get so much > as a blip on the voltage then do something about it. > > If you haven't got a 'scope to hand, I'd try running (some) the drives > of a different PSU and see that makes a difference. > > Although I haven't hit this problem myself, I'd be surprised if the > same PSU design intended to power spinning rust at a relatively > constant current could cope well with an SSD going from nothing much > to lots to nothing much again over a very short space of time. If I > was connecting a different PSU to the SSD I'd load it with some real > drives just to stabilise the current output a bit (i.e. plug an old > drive or two on to some of the other spare outlets). > > Then there's always the chance it's over-cooking, but I think you'd > have mentioned if they were getting very hot. > > Regards, Frank. > > _______________________________________________ > freebsd-hardware@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hardware > To unsubscribe, send any mail to > "freebsd-hardware-unsubscribe@freebsd.org" Flaky power has been the cause of more intermittent and very odd problems, especially under load, than you can count. I always get suspicious of power issues when the system seems fine right up until you place it under heavy load, then bad things happen -- and I'm usually righ= t. I second Frank's suggestion. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms040301070301060709040608 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA0MTYxNDI2MTBaME8GCSqGSIb3DQEJBDFCBECqkVwu 6DsiqJp9nZVX3mGZBscCoxBAOLCckBrxZcJQjxvKwwxIMzylQSnQ7G39hYSaCCgQ7pwGVvN0 U/hlnCWGMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAbfgkLOzH+9tt bVmMc9xPweoMI1Rp+SckiDE366oG+28SOiMRAf78mBIZaR9FkEPOm2Ae9ewBhKyc0MJTnaya qjQn/hm6W44VxNgmVA3H9Qtc3TiF5ICCgzVu5kXjylo/2iC0UBERSw350gttAX/i0mj04Sja Fw6IHI45EiUQlOw/cA3Xi8DVne/UP+Pb0vNRjkNDrPsh9sms5egqC8jeIUQWvQj9pmancy0C 3Qa2va3o1qGYwJbF96ho/y0Qr0GrZcS5E7YKoopNqzqyITg2vP5KmQFlTcVfTTiwSXtMVs0R i/Q0ZH9eBHDpRCs6IIKjaw6Gsvpu70FhOFT0FwicZthnGaaXyK5dAq3O+sN6ffsLXRU7og5l g3z7J5Ek8hpwyzsb5opT4ul3PaBatabo9gvoVDieExPNlAXoSg9PBSWoxD6C1nFXl7I/X3Y7 T6QHIWyvsF53kLue4CIKWUri/pLDY1PsK61VUeu5I045qO5I0axrngx6lPCbTFUa3VCgyj0w YkZFxbHOayD/72VBgXti2hy+WLpiH0WMiS6BrFK4T/rqQzsCR+nMt7eAS4FY3gvYosG/aIy4 wKZcYInpBK/uE9M2YWmvPmkkU6MPVtbudQwUCz/7p2uOLQZULRnoZZr/mEDyO5rlv5x7KaKB r70RmZ1v+HaRABc45LjYKawAAAAAAAA= --------------ms040301070301060709040608-- From owner-freebsd-hardware@freebsd.org Wed Apr 19 12:23:11 2017 Return-Path: Delivered-To: freebsd-hardware@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3395DD45D85 for ; Wed, 19 Apr 2017 12:23:11 +0000 (UTC) (envelope-from nbe@renzel.net) Received: from nijmegen.renzel.net (mx1.renzel.net [195.243.213.130]) by mx1.freebsd.org (Postfix) with ESMTP id CF22B19E8 for ; Wed, 19 Apr 2017 12:23:10 +0000 (UTC) (envelope-from nbe@renzel.net) X-Virus-Scanned: GDATA Antivirus at gdata-milter.renzel.de.isb X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=-8.0 required=7.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 Received: from dublin.vkf.isb.de.renzel.net (unknown [10.0.0.80]) by nijmegen.renzel.net (smtpd) with ESMTP id 70D8A141482B for ; Wed, 19 Apr 2017 14:21:47 +0200 (CEST) Received: from asbach.renzel.net (unknown [172.18.96.1]) by dublin.vkf.isb.de.renzel.net (Postfix) with ESMTPA id 6A23882B88 for ; Wed, 19 Apr 2017 14:21:47 +0200 (CEST) To: freebsd-hardware@freebsd.org From: Nils Beyer Subject: ALC256: no sound from headphone jack - neither via discrete PCM device nor after re-patching NIDs... Organization: VKF Renzel GmbH Message-ID: <9d64835f-8c28-2f64-eada-673912d18d42@renzel.net> Date: Wed, 19 Apr 2017 14:21:47 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on nijmegen.renzel.net X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 12:23:11 -0000 Hi, hardware: Dell Vostro 15-3568, Skylake OS: FreeBSD 12.0-CURRENT #2 d74051004(drm-next)-dirty For some reason there's no sound from the headphones jack. I've tried it as a discrete PCM device (default setting) and as a re-patched NID. The re-patched NID variant should be fine because there's sound out off the internal speaker; and as soon as I plug in the headphone the internal speaker gets silent. Here's the dmesg output of the relevant section: --------------------------------------------------------------------------- hdacc0: at cad 0 on hdac0 ahcich0: SATA connect time=100us status=00000133 hdaa0: ahcich0: AHCI reset: device found at nid 1 on hdacc0 ahcich1: hdaa0: Subsystem ID: 0x10280793 AHCI reset... hdaa0: NumGPIO=3 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 ahcich1: SATA connect time=1800us status=00000113 hdaa0: ahcich1: AHCI reset: device found ahcich1: AHCI reset: device ready after 0ms GPIO0: disabled hdaa0: GPIO1: disabled hdaa0: GPIO2: disabled hdaa0: Original pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 18 90a60160 6 0 Mic Fixed Digital Internal Unknown 1 hdaa0: 19 40000000 0 0 Line-out None Unknown 0x00 Unknown 0 hdaa0: 20 90170120 2 0 Speaker Fixed Analog Internal Unknown 1 hdaa0: 24 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 26 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 27 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 29 40779a2d 2 13 Modem-handset None Analog 0x00 Pink 10 hdaa0: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 33 02211030 3 0 Headphones Jack 1/8 Front Black 0 hdaa0: Patching widget caps nid=29 0x00400400 -> 0x00700400 hdaa0: Patching pin config nid=33 0x02211030 -> 0x0221102f hdaa0: Patched pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 18 90a60160 6 0 Mic Fixed Digital Internal Unknown 1 hdaa0: 19 40000000 0 0 Line-out None Unknown 0x00 Unknown 0 DISA hdaa0: 20 90170120 2 0 Speaker Fixed Analog Internal Unknown 1 hdaa0: 24 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 26 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 27 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 33 0221102f 2 15 Headphones Jack 1/8 Front Black 0 hdaa0: 2 associations found: hdaa0: Association 0 (2) out: hdaa0: Pin nid=20 seq=0 hdaa0: Pin nid=33 seq=15 hdaa0: Association 1 (6) in: hdaa0: Pin nid=18 seq=0 hdaa0: Tracing association 0 (2) hdaa0: Pin 20 traced to DAC 2 hdaa0: Pin 33 traced to DAC 2 and hpredir 0 hdaa0: Association 0 (2) trace succeeded hdaa0: Tracing association 1 (6) hdaa0: Pin 18 traced to ADC 7 hdaa0: Association 1 (6) trace succeeded hdaa0: Looking for additional DAC for association 0 (2) hdaa0: Looking for additional ADC for association 1 (6) hdaa0: Tracing input monitor hdaa0: Tracing other input monitors hdaa0: Tracing nid 18 to out hdaa0: Tracing beeper hdaa0: Headphones redirection for association 0 nid=33 using unsolicited responses. hdaa0: Pin sense: nid=33 sense=0x80000000 (connected) hdaa0: Redirect output to: headphones hdaa0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm0: at nid 20,33 and 18 on hdaa0 pcm0: Playback: pcm0: Stream cap: 0x00000001 PCM pcm0: PCM cap: 0x000e0060 16 20 24 bits, 44 48 KHz pcm0: DAC: 2 pcm0: pcm0: nid=20 [pin: Speaker (Fixed)] pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: pcm0: nid=33 [pin: Headphones (Black Jack)] pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: pcm0: Record: pcm0: Stream cap: 0x00000001 PCM pcm0: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm0: ADC: 7 pcm0: pcm0: nid=7 [audio input] pcm0: + <- nid=36 [audio selector] [src: monitor] pcm0: + <- nid=18 [pin: Mic (Fixed)] [src: monitor] pcm0: pcm0: Master Volume (OSS: vol): -65/0dB pcm0: +- ctl 1 (nid 2 out): -65/0dB (88 steps) pcm0: +- ctl 8 (nid 20 in ): mute pcm0: +- ctl 14 (nid 33 in ): mute pcm0: pcm0: PCM Volume (OSS: pcm): -65/0dB pcm0: +- ctl 1 (nid 2 out): -65/0dB (88 steps) pcm0: +- ctl 8 (nid 20 in ): mute pcm0: +- ctl 14 (nid 33 in ): mute pcm0: pcm0: Microphone2 Volume (OSS: monitor): 0/30dB pcm0: +- ctl 3 (nid 7 in 0): -17/30dB (64 steps) + mute pcm0: +- ctl 6 (nid 18 out): 0/30dB (4 steps) pcm0: pcm0: Recording Level (OSS: rec): -17/30dB pcm0: +- ctl 3 (nid 7 in 0): -17/30dB (64 steps) + mute pcm0: +- ctl 6 (nid 18 out): 0/30dB (4 steps) pcm0: pcm0: Mixer "vol": pcm0: Mixer "bass": pcm0: Mixer "treble": pcm0: Mixer "pcm": pcm0: Mixer "rec": pcm0: Mixer "ogain": pcm0: Mixer "monitor": pcm0: EQ Treble/Bass ENABLED pcm0: Playback channel set is: Front Left, Front Right, pcm0: Playback channel matrix is: 2.0 (connected) pcm0: Automatically set rec source to: monitor pcm0: Recording channel set is: Front Left, Front Right, pcm0: Recording channel matrix is: 2.0 (unknown) --------------------------------------------------------------------------- Headphones jack is working - verified by trying Ubuntu. Any ideas what to try next? TIA and regards, Nils From owner-freebsd-hardware@freebsd.org Sat Apr 22 07:44:41 2017 Return-Path: Delivered-To: freebsd-hardware@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EAF37D4A939 for ; Sat, 22 Apr 2017 07:44:41 +0000 (UTC) (envelope-from orka.edison@ovh.fr) Received: from mo29.mail-out.ovh.net (mo29.mail-out.ovh.net [178.32.228.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B85FD69D for ; Sat, 22 Apr 2017 07:44:41 +0000 (UTC) (envelope-from orka.edison@ovh.fr) Received: from he8.mail.ovh.net (he8.mail.ovh.net [5.135.57.187]) by mo29.mail-out.ovh.net (Postfix) with ESMTP id B3F311FA2 for ; Sat, 22 Apr 2017 09:44:38 +0200 (CEST) Received: from DellPrecison (unknown [109.190.197.146]) by he8.mail.ovh.net (Postfix) with ESMTPSA id 74C02699E70 for ; Sat, 22 Apr 2017 09:44:38 +0200 (CEST) Message-ID: <1492847077.2963.12.camel@ovh.fr> Subject: Re: GSM card on Dell M4700 [wifi slot] From: Orka Edison To: freebsd-hardware@freebsd.org Date: Sat, 22 Apr 2017 09:44:37 +0200 In-Reply-To: <1492846128.2963.8.camel@ovh.fr> References: <1492846128.2963.8.camel@ovh.fr> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-0ubuntu0.1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 713257593870577703 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeliedrfeehgdduvdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenuc X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 07:44:42 -0000 Le samedi 22 avril 2017 à 09:28 +0200, Orka Edison a écrit : > hi, > > i search a french GSM card, 3G/4G pluggable on  > (pci-E slot - WiFi or WWan -) > > http://www.dell.com/support/manuals/fr/fr/frdhs1/precision-m4700/Dell > _P > recision_M4700_OM-v2/Technical-Specification?guid=GUID-493767EC-A736- > 4F36-9DEF-833E34C14E4B&lang=en-us > > capable on FreeBSD 11. > > Best Regard, > Orka Edison. http://tinyurl.com/mzt76qj sorry url so long _______________________________________________ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd. org"