FYI: FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw under qemu-system-aarch64 on odroid-c2 under UbuntuMate : No valid device tree blob found!
With: http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/1917/QEMU-AARCH64/RELEASE_CLANG35/QEMU_EFI.fd for QEMU_EFI.fd and with: http://ftp1.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/12.0-CURRENT/aarch64/20170420/FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw.xz for FreeBSD's .raw file (after unxz) I tried: qemu-system-aarch64 -m 1024M -enable-kvm -cpu host -M virt \ -bios QEMU_EFI.fd -nographic \ -drive format=raw,if=none,file=FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -device virtio-net-device,netdev=net0 \ -netdev user,id=net0 \ -smp cpus=4 on an odroid-c2 running UbuntuMate: # uname -a Linux odroidc2UbMate 3.14.79-110 #1 SMP PREEMPT Tue Apr 11 20:16:54 BRT 2017 aarch64 aarch64 aarch64 GNU/Linux The result was: . . . Booting [/boot/kernel/kernel]... No valid device tree blob found! WARNING! Trying to fire up the kernel, but no device tree blob found! . . . generic_timer0: irq 29,30,27 on acpi0 panic: Attempt to copy invalid resource id: 29 In full detail: >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Probing 5 block devices...* done ZFS found no pools UFS found 1 partition Consoles: EFI console Command line arguments: loader.efi Image base: 0x763b1000 EFI version: 2.60 EFI Firmware: EDK II (rev 1.00) FreeBSD/arm64 EFI loader, Revision 1.1 (Thu Apr 20 16:51:44 UTC 2017 r...@releng3.nyi.freebsd.org) EFI boot environment Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x7b6848 data=0xa0578+0x43b3be syms=[0x8+0x106938+0x8+0xfb67b] \ Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... No valid device tree blob found! WARNING! Trying to fire up the kernel, but no device tree blob found! KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #0 r317181: Thu Apr 20 16:54:23 UTC 2017 r...@releng3.nyi.freebsd.org:/usr/obj/arm64.aarch64/usr/src/sys/GENERIC arm64 FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs arc4random: no preloaded entropy cache random: entropy device external interface kbd0 at kbdmux0 acpi0: acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) psci0: on acpi0 generic_timer0: irq 29,30,27 on acpi0 panic: Attempt to copy invalid resource id: 29 cpuid = 0 time = 1 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc = 0x005db8a0 lr = 0x00088910 sp = 0x000102a0 fp = 0x000104b0 db_trace_self_wrapper() at vpanic+0x184 pc = 0x00088910 lr = 0x0030a774 sp = 0x000104c0 fp = 0x00010540 vpanic() at panic+0x48 pc = 0x0030a774 lr = 0x0030a800 sp = 0x00010550 fp = 0x000105d0 panic() at intr_map_copy_map_data+0x164 pc = 0x0030a800 lr = 0x00616600 sp = 0x000105e0 fp = 0x00010630 intr_map_copy_map_data() at intr_activate_irq+0xd8 pc = 0x00616600 lr = 0x00616280 sp = 0x00010640 fp = 0x00010690 intr_activate_irq() at nexus_activate_resource+0xb8 pc = 0x00616280 lr = 0x005e77b8 sp = 0x000106a0 fp = 0x000106d0 nexus_activate_resource() at nexus_alloc_resource+0x10c pc = 0x005e77b8 lr = 0x005e76cc sp = 0x000106e0 fp = 0x00010730 nexus_alloc_resource() at resource_list_alloc+0x1d4 pc = 0x005e76cc lr = 0x0033bf94 sp = 0x00010740 fp = 0x00010790 resource_list_alloc() at acpi_alloc_resource+0x17c pc = 0x0033bf94 lr = 0x000924fc sp = 0x000107a0 fp = 0x00010850 acpi_alloc_resource() at bus_alloc_resources+0xd8 pc = 0x000924fc lr = 0x0033dfa4 sp = 0x00010860 fp = 0x000108b0 bus_alloc_resources() at arm_tmr_attach+0xc8 pc = 0x0033dfa4 lr = 0x005ca394 sp = 0x000108c0 fp = 0x000108f0 arm_tmr_attach() at device_attach+0x404 pc = 0x005ca394 lr = 0x0033b60c sp = 0x00010900 fp = 0x00010950 device_attach() at bus_generic_attach+0x50 pc = 0x0033b60c lr
Re: Add support for ACPI Module Device ACPI0004?
On Sat, Apr 29, 2017 at 12:01 AM, John Baldwin wrote:
> On Friday, April 28, 2017 05:38:32 PM Sepherosa Ziehau wrote:
>> On Thu, Apr 27, 2017 at 12:14 AM, John Baldwin wrote:
>> > On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
>> >> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin wrote:
>> >> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
>> >> >> > From: John Baldwin [mailto:j...@freebsd.org]
>> >> >> > Sent: Thursday, April 20, 2017 02:34
>> >> >> > > Can we add the support of "ACPI0004" with the below one-line
>> >> >> > > change?
>> >> >> > >
>> >> >> > > acpi_sysres_probe(device_t dev)
>> >> >> > > {
>> >> >> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
>> >> >> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02",
>> >> >> > > "ACPI0004", NULL };
>> >> >> > >
>> >> >> > Hmm, so the role of C01 and C02 is to reserve system resources,
>> >> >> > though we
>> >> >> > in turn allow any child of acpi0 to suballocate those ranges (since
>> >> >> > historically
>> >> >> > c01 and c02 tend to allocate I/O ranges that are then used by things
>> >> >> > like the
>> >> >> > EC, PS/2 keyboard controller, etc.). From my reading of ACPI0004 in
>> >> >> > the ACPI
>> >> >> > 6.1 spec it's not quite clear that ACPI0004 is like that? In
>> >> >> > particular, it
>> >> >> > seems that 004 should only allow direct children to suballocate?
>> >> >> > This
>> >> >> > change might work, but it will allow more devices to allocate the
>> >> >> > ranges in
>> >> >> > _CRS than otherwise.
>> >> >> >
>> >> >> > Do you have an acpidump from a guest system that contains an ACPI0004
>> >> >> > node that you can share?
>> >> >> >
>> >> >> > John Baldwin
>> >> >>
>> >> >> Hi John,
>> >> >> Thanks for the help!
>> >> >>
>> >> >> Please see the attached file, which is got by
>> >> >> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
>> >> >>
>> >> >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
>> >> >> "VMBus" (VMBS).
>> >> >> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't
>> >> >> see the length of the MMIO range in the dumped asl code, it does have
>> >> >> a 512MB MMIO range [0xFE000, 0xF].
>> >> >>
>> >> >> It looks FreeBSD can't detect ACPI0004 automatically.
>> >> >> With the above one-line change, I can first find the child device
>> >> >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
>> >> >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
>> >> >>
>> >> >> If you think we shouldn't touch acpi_sysresource0 here, I guess
>> >> >> we can add a new small driver for ACPI0004, just like we added VMBus
>> >> >> driver as a child device of acpi0?
>> >> >
>> >> > Hmmm, so looking at this, the "right" thing is probably to have a device
>> >> > driver for the ACPI0004 device that parses its _CRS and then allows its
>> >> > child devices to sub-allocate resources from the ranges in _CRS.
>> >> > However,
>> >> > this would mean make VMBus be a child of the ACPI0004 device. Suppose
>> >> > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0'
>> >> > device
>> >> > would need to create a child device for all of its child devices. Right
>> >> > now acpi0 also creates devices for them which is somewhat messy (acpi0
>> >> > creates child devices anywhere in its namespace that have a valid _HID).
>> >> > You can find those duplicates and remove them during acpi_module0's
>> >> > attach
>> >> > routine before creating its own child device_t devices. (We associate
>> >> > a device_t with each Handle when creating device_t's for ACPI handles
>> >> > which is how you can find the old device that is a direct child of acpi0
>> >> > so that it can be removed).
>> >>
>> >> The remove/reassociate vmbus part seems kinda "messy" to me. I'd just
>> >> hook up a new acpi0004 driver, and let vmbus parse the _CRS like what
>> >> we did to the hyper-v's pcib0.
>> >
>> > The acpi_pci driver used to do the remove/reassociate part. What acpi0
>> > should probably be doing is only creating device_t nodes for immediate
>> > children. This would require an ACPI-aware isa0 for LPC devices below
>> > the ISA bus in the ACPI namespace. We haven't done that in part because
>> > BIOS vendors are not always consistent in placing LPC devices under an
>> > ISA bus. However, you otherwise have no good way to find your parent
>> > ACPI0004 device. You could perhaps find your ACPI handle, ask for its
>> > parent handle, then ask for the device_t of that handle to find the
>> > ACPI0004 device, but then you'd need to have all your bus_alloc_resource
>> > calls go to that device, not your "real" parent of acpi0, which means
>> > you can't use any of the standard bus_alloc_resource() methods like
>> > bus_alloc_resource_any() but would have to manually use BUS_ALLOC_RESOURCE
>> > with the ACPI0004 device as the explicit first argument. It is primarily
>> > the ability to let ACPI0004's drive
Re: DHCP/network issues
Am Sat, 29 Apr 2017 19:07:06 -0400 (EDT) AN schrieb: > Hi OH: > > On Sat, 18 Mar 2017, O. Hartmann wrote: > > > Date: Sat, 18 Mar 2017 19:11:42 +0100 > > From: O. Hartmann > > To: AN > > Cc: O. Hartmann > > Subject: Re: DHCP/network issues > > > > Am Sat, 18 Mar 2017 10:25:58 -0400 (EDT) > > AN schrieb: > > > >> Hi: > >> > >> On Sat, 18 Mar 2017, O. Hartmann wrote: > >> > >>> Date: Sat, 18 Mar 2017 15:20:13 +0100 > >>> From: O. Hartmann > >>> To: AN > >>> Cc: freebsd-current@freebsd.org > >>> Subject: Re: DHCP/network issues > >>> > >>> Am Sat, 18 Mar 2017 09:45:31 -0400 (EDT) > >>> AN schrieb: > >>> > Is anyone seeing network or DHCP issues with a recent update to > 12-current? > > On new hardware > Dual Core Celeron J1800 Bay Trail 2.4GHz, 2MB L2 Cache > 2 Gigabit Ethernet Intel NIC ports > > I'm seeing the following issues: > > - install latest 12-current snapshot > FreeBSD-12.0-CURRENT-amd64-20170316-r315413-memstick.img, try DHCP during > install and it fails. Setup networking manually and try to ping default > gateway > results in the response > ping: sendto: Host is down > >>> > >>> Yes. Since IFLIB has been introduced, Intel NICs seem to be suffering > >>> from not > >>> working properly anymore. i217-LM, i350 and sibblings are affected for > >>> which I can > >>> speak because we suffer the same problems here. Even if the NIC works, it > >>> dies > >>> after some time under heavy I/O. > >>> > >> > >> Thank you for the reply, I remember seeing your messages on the list about > >> this now. Is anyone trying to fix it, did you file a PR? > > > > I think, as you may already have read, some of the developers are aware of > > this > > problem. I haven't file a PR so far. > > > > Kind regards, > > > > oh > > > > > > > Do you know if the problem with Intel Nic in 12-current has been fixed? > > Thanks, > > AN Hello. The problem still persists!! I have a Fujitsu Celsius M740, which uses a i217 NIC. This NIC freezes up while under heavy I/O. In most cases, I can get it back online by bringing it first down and then up again with ifconfig em0 down/up. But sometimes I have to reboot. I get some strange errors on the console about "RX/TX no buffer left" - I'm sorry to be not more specific, I'm not in the lab at the moment where I have a more specific record of that problem. The i217 NIC suffers from this problem after IFLIB has been introduced and I can trigger the problem easily whily rsyncing poudriere repository packages with the NFSv4 connected package server. I haven't checked on igb NICs (we also use i350 based dual-port NICs as I do with some private servers). But last time I pushed them very hard with I/O, I was able to freeze them the same way. I do not know whether someone is working on this, I recall having filed a PR on this, but I was very unspecific, because I do not have further details and running CURRENT with no DEBUG features. As of your question: it hasn't been fixed so far. Kind regards, Oliver -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). pgpQRxAWGrWYD.pgp Description: OpenPGP digital signature
options FLOWTABLE: kernel panics
What is the status of options FLOWTABLE ? On recent CURRENT, enabling this feature results in sporadic reboots/panics. This is now for a while (months ...). Are there any plans ever to fix this? Kind regards and thanks in advance, O. Hartmann pgpDYnAc9WcBR.pgp Description: OpenPGP digital signature
Re: Panic String: solaris assert: (lsize != psize) implies ((flags & ZIO_FLAG_RAW) != 0), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line: 631
On 2017-04-28 17:42, Andriy Gapon wrote: On 28/04/2017 14:56, Michael Jung wrote: I have mad the requested change.. [root@bsd11 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs]# diff zio.c ~mikej/zio.c.orig 965c965 < size, NULL, NULL, ZIO_TYPE_FREE, ZIO_PRIORITY_NOW, --- BP_GET_PSIZE(bp), NULL, NULL, ZIO_TYPE_FREE, ZIO_PRIORITY_NOW, Yes, that's the change that I had in mind. I was a little bit confused by the order of the original and modified files, though :-) [root@bsd11 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs]# As to the pool size: [root@bsd11 /usr/home/mikej]# zpool list NAME SIZE ALLOC FREE EXPANDSZ FRAGCAP DEDUP HEALTH ALTROOT tank 199G 143G 55.9G -85%71% 1.00x ONLINE - [root@bsd11 /usr/home/mikej]# I should have also mentioned that besides poudriere running a build, it was removing old logs - There was some 43G of old logs files that were in the process of being removed. So, given that the panic was in the freeing path, you were probably low on the pool space back when those log files were created. I mean that the gang blocks are typically created when a pool is very fragmented. I will hammer the box with and report back first of the week whether the panic re-occurs or not. Please also try removing those old files again too. Running zpool scrub afterwards could be a good idea too. Thank you again! Andriy: I am happy to report that the system no longer panics. As requested I removed the remaining logs (34G worth) and punished the file system as hard as I could. A scrub of the pool completed without error Will the change be committed or do I need to open a PR? Please let me know if I can supply additional information or if there are any further tests you would like me to perform. Thanks again for you prompt reply and apparent solution. Regards, Michael Jung ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panics in network stack in 12-current
Hamza Sheikh wrote: I may have encountered something similar on an EdgeRouter Lite running r317256. It's serving as network gateway at home. After some time the WAN connection goes dead. It starts working with either (a) reconnecting the network cable or (b) pinging any IP on the internet from that box. On rare occasions I had to reboot to get it to work. it doesn't sound much like my problem. i had no network issues until the system would suddenly panic and reboot. removing FLOWTABLE from my kernel might have fixed it, but it is too early to tell as I have yet to discover a reproducible way to trigger the bug. I'm still new to FreeBSD and don't know how to collect relevant information or whether to even determine if my issue is related to Andrey's. Any help is really appreciated. My setup is documented in detail in a blog post[0] if it helps. You probably don't want to hear this, but if you are new to FreeBSD, maybe you shouldn't be running current. I probably shouldn't running current and I have 35 years of BSD experience. I do it as a way of contributing to the project by alpha-testing new code when I have time. Brendan Gregg has some very good material on his site that might help you learn to collect useful info about what is going on inside your systems. http://www.brendangregg.com/Perf/freebsd_observability_tools.png http://www.brendangregg.com/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RPi3 booting issues: vm_fault pager read error pid 1
Hello, I would like to ask for some help. I'm trying to build a freebsd image using crochet, however recent builds, since roughly march, are failing to boot on an RPi3. Currently once the kernel boots up and hands it over to init, the error message "vm_fault pager read error pid 1 (init)" is flooding the screen. Sadly, I don't really know how to debug and fix the cause of this, and I would like to ask some help on fixing this. The image I'm trying to boot (if boots, u/p aegir:aegir): http://czg.harmless.hu/aegir/FreeBSD-aarch64-12.0-AEGIR-317411.img.gz The kernel config: http://czg.harmless.hu/aegir/AEGIR And the crochet config I'm using: http://czg.harmless.hu/aegir/aegir.sh I would like to have a refreshed build, because the one I'm using currently does not have working i2c support, which should be the next thing on my project I'm using this for. Would be nice if someone could take a look into this. Best regards, Gergely ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: i915kms breakage
2017-04-29 0:52 GMT+02:00 Andrey Fesenko : > On Fri, Apr 28, 2017 at 10:10 PM, Maurizio Vairani > wrote: > > 2017-04-22 14:47 GMT+02:00 Domagoj Stolfa : > > > >> Hello, > >> > >> ever since I've merged yesterday, it would seem that the i915kms driver > >> panics every time it is loaded. Unfortunately, I am not able to provide > >> a dump of the panic, as I am unable to see what the panic is, or what is > >> even going on as a matter of fact due to my screen being overtaken by > >> a driver that has just panicked. call doadump() does not seem to work > >> either. > >> > >> Is anyone else having these problems, or know where the issue might be > >> occurring? > >> > >> The same happens with 12.0-CURRENT r317513 updated yesterday. The laptop > > is a Samsung NP270E5E with Intel Graphics 4000, > > http://www.samsung.com/us/computer/pcs/NP270E5E-K02US-specs > > -- > > i5 r317402 and r317437 run only single mode, after r317561 work Xorg again > :) > Thanks Andey, updated to r317579 and works for me too. -- Maurizio ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
regression suspend/resume on Lenovo T420
Hi, I'd been sucessfully running CURRENT on my Lenovo T420 with functional suspend/resume since some time. But after updating to CURRENT r317032 respectively r317559 suspend/resume does not work anymore. Putting it into suspend results only in a black screen, but no further action is possible (only pressing the powerbutton for some time to switch it off completely). The LEDs are not indicating any suspend mode. If i try to suspend it with X (intel-driver) stopped, the laptop does switch into suspend, but does not resume. It runs into some kind of resuming endless loop, where it tries to start the laptop again but at a certain point it restarts again. The screen stays dark all the time. I tried this with and without the following options but the same result. hw.acpi.reset_video=1 dev.acpi_ibm.0.handlerevents='0x04' Booting a Bootenvironment with an older CURRENT(r315141), all is working. Was there any change between these commits concerning suspend/resume? BR Manuel ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 2013 Macbook Pro, sound OK in headphones but no sound in internal speakers
I tried on this model and things basically worked out of the box once I changed the default output: root@sound:~ # uname -a FreeBSD sound 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r313561: Fri Feb 10 20:18:01 UTC 2017 r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 root@sound:~ # cat /dev/sndstat Installed devices: pcm0: (play) default pcm1: (play) pcm2: (play) pcm3: (play) pcm4: (play) pcm5: (play) No devices installed from userspace. root@sound:~ # sysctl hw.snd.default_unit=3 hw.snd.default_unit: 0 -> 3 root@sound:~ # pkg install curl xmp ... root@sound:~ # fetch https://blog.grem.de/spacedeb.mod.gz root@sound:~ # xmp spacedeb.mod.gz ... plays music ... Setting the default unit to 4 changes to headphones. You don't seem to have NVIDIA graphics, so for you changing to speakers probably is: sysctl hw.snd.default_unit=1 I didn't look closely in your first request, the word "default" next to the output device is key. To change settings to switch output automatically when plugging in/removing headphones I issued the following commands: sysctl dev.hdaa.1.nid9_config="as=1 seq=15" sysctl dev.hdaa.1.reconfig=1 Now devices show up as: cat /dev/sndstat Installed devices: pcm0: (play) default pcm1: (play) pcm2: (play) pcm3: (play) pcm4: (play) No devices installed from userspace. Changing the default device to pcm3: sysctl hw.snd.default_unit=3 cat /dev/sndstat Installed devices: pcm0: (play) pcm1: (play) pcm2: (play) pcm3: (play) default pcm4: (play) No devices installed from userspace. Unfortunately, even though this should work (and sysctl dev.hdac.1.pindump=1 shows the correct connection status for the headphones), this fails to mute the speakers, so it plays on headphones and speakers at the same time. It experimented quite a lot, so this might be a driver issue (googling shows others have similar problems), so not touching the config and switching manually by setting the output device explicitly might be the only option right now. See below for my unaltered hdaa settings after boot: root@sound:~ # sysctl -a dev.hdaa.1 dev.hdaa.1.reconfig: 0 dev.hdaa.1.gpo_config: dev.hdaa.1.gpo_state: dev.hdaa.1.gpio_config: 0=keep 1=set 2=keep 3=set dev.hdaa.1.gpio_state: 0=disabled 1=output(1) 2=disabled 3=output(1) dev.hdaa.1.gpi_state: dev.hdaa.1.config: forcestereo,ivref50,ivref80,ivref100,ivref,vref dev.hdaa.1.nid21_original: 0x40f0 as=15 seq=0 device=Line-out conn=None ctype=Unknown loc=0x00 color=Unknown misc=0 dev.hdaa.1.nid21_config: 0x40f0 as=15 seq=0 device=Line-out conn=None ctype=Unknown loc=0x00 color=Unknown misc=0 dev.hdaa.1.nid21: pin: Line-out (None) [DISABLED] Widget cap: 0x00410301 DIGITAL STEREO Pin cap: 0x0010 OUT Pin config: 0x40f0 as=15 seq=0 device=Line-out conn=None ctype=Unknown loc=0x00 color=Unknown misc=0 Pin control: 0x Connections: 1 + <- nid=20 [audio output] [DISABLED] dev.hdaa.1.nid20: audio output [DISABLED] Widget cap: 0x00040611 PWR DIGITAL STEREO Stream cap: 0x0007 AC3 FLOAT32 PCM PCM cap: 0x001e07f0 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz dev.hdaa.1.nid19: beep widget Widget cap: 0x0070 Association: -2 (0x) OSS: speaker (speaker) dev.hdaa.1.nid18_original: 0x40f0 as=15 seq=0 device=Line-out conn=None ctype=Unknown loc=0x00 color=Unknown misc=0 dev.hdaa.1.nid18_config: 0x40f0 as=15 seq=0 device=Line-out conn=None ctype=Unknown loc=0x00 color=Unknown misc=0 dev.hdaa.1.nid18: pin: Line-out (None) [DISABLED] Widget cap: 0x0041000b STEREO Pin cap: 0x0020 IN Pin config: 0x40f0 as=15 seq=0 device=Line-out conn=None ctype=Unknown loc=0x00 color=Unknown misc=0 Pin control: 0x Input amp: 0x00270200 mute=0 step=2 size=39 offset=0 (0/20dB) dev.hdaa.1.nid17: vendor widget [DISABLED] Widget cap: 0x00f00040 PROC dev.hdaa.1.nid16_original: 0x004be030 as=3 seq=0 device=SPDIF-out conn=Jack ctype=Combo loc=0x00 color=White misc=0 dev.hdaa.1.nid16_config: 0x004be030 as=3 seq=0 device=SPDIF-out conn=Jack ctype=Combo loc=0x00 color=White misc=0 dev.hdaa.1.nid16: pin: SPDIF-out (White Jack) Widget cap: 0x00410301 DIGITAL STEREO Association: 2 (0x0001) Pin cap: 0x0010 OUT Pin config: 0x004be030 as=3 seq=0 device=SPDIF-out conn=Jack ctype=Combo loc=0x00 color=White misc=0 Pin control: 0x0040 OUT Connections: 1 + <- nid=8 [audio output] dev.hdaa.1.nid15_original: 0x40f0 as=15 seq=0 device=Line-out conn=None ctype=Unknown loc=0x00 color=Unknown misc=0 dev.hdaa.1.nid15_config: 0x40f0 as=15 seq=0 device=Line-out conn=None ctype=Unknown loc=0x00 color=Unknown misc=0 dev.hdaa.1.nid15: pin: Line-out (None) [DISABLED] Widget cap: 0x00410681 PWR DIGITAL UNSOL STEREO Pin cap: 0x0024 PDC IN Pin config: 0x40f0 as=15 seq=0 device=Line-out conn=None ctype=Unknown loc=0x00 color=Unknown misc=0
