Re: re(4) drivers not working
On Fri, Sep 16, 2022 at 09:39:56AM +0200, Stefan Sperling wrote: > On Fri, Sep 16, 2022 at 08:27:59AM +0200, Adam Szewczyk wrote: > > Checked on actual hardware it seems to work fine. So I report it also to > > Qubes and Xen Project, but marmarek (head of qubes development team) > > suggest that it can be a problem with driver itself: > > "I'm not sure if that's relevant, but a common cause is incorrect MSI / > > MSI-X detection/support by the driver. HVM in Qubes do not support MSI-X, > > but do support MSI. MSI-X, even if the device really supports it, is masked > > from PCI capabilities. Driver should fallback to MSI (or INTx) if MSI-X > > fails to setup (or isn't there at all), but many drivers have this path > > buggy, since it isn't exercised in most common (native) scenario." > > re(4) only uses MSI, it does not ever even try MSI-X. As can be seen here: > https://github.com/openbsd/src/blob/master/sys/dev/pci/if_re_pci.c#L161 But there has been at least one report of MSI, (not MSI-X), causing the error that the OP is seeing with an 're' device on bare hardware, (no hypervisor): https://marc.info/?l=openbsd-tech=165987603706259=2 So maybe test the patch in that mail to see if using a regular non-MSI interrupt mitigates the problem. Then look for the real bug if it does.
Re: re(4) drivers not working
On Fri, Sep 16, 2022 at 09:58:44AM +0200, Adam Szewczyk wrote: > My mistake in creating a bug for wireless it should be iwm (copied wrong > file name in a hurry). Is that are you wrote about iwx also true for iwm? At this low level the drivers are equivalent. > Sorry for the trouble. I just want to figured it out which project have, a > bug and create there a ticket. It was my first contact with BSD also so I > don't know nothing about the internals. It can be difficult when people send you around between each other's projects, I understand that. And one can never know for sure, there are so many layers involved that it is impossible to tell what's wrong without knowing details. PCI-passthrough is complicated. The best way to make progress is trying to eliminate possibile root causes for the issue. Have you tried PCI passthrough with KVM yet, just to see if a different hypervisor works fine? And have you tried on a different hardware configuration (different CPU/BIOS)? Are you sure you applied all the necessary BIOS tweaks for PCI passthrough to actually work? In any case, without solid evidence that something is wrong in the OpenBSD drivers, I don't expect anyone here will have motivation to hunt for a bug. Our developers don't always have time to help chase problems down from the very top (error message) to the very bottom (root cause). We need more information and clear evidence that other possible root causes have already been eliminated. Based on past experience with such bug reports, when it works just fine on bare metal then there is usually a hypervisor or BIOS problem.
Re: re(4) drivers not working
My mistake in creating a bug for wireless it should be iwm (copied wrong file name in a hurry). Is that are you wrote about iwx also true for iwm? Sorry for the trouble. I just want to figured it out which project have, a bug and create there a ticket. It was my first contact with BSD also so I don't know nothing about its internals. pt., 16 wrz 2022, 09:39 użytkownik Stefan Sperling napisał: > On Fri, Sep 16, 2022 at 08:27:59AM +0200, Adam Szewczyk wrote: > > Checked on actual hardware it seems to work fine. So I report it also to > > Qubes and Xen Project, but marmarek (head of qubes development team) > > suggest that it can be a problem with driver itself: > > "I'm not sure if that's relevant, but a common cause is incorrect MSI / > > MSI-X detection/support by the driver. HVM in Qubes do not support MSI-X, > > but do support MSI. MSI-X, even if the device really supports it, is > masked > > from PCI capabilities. Driver should fallback to MSI (or INTx) if MSI-X > > fails to setup (or isn't there at all), but many drivers have this path > > buggy, since it isn't exercised in most common (native) scenario." > > re(4) only uses MSI, it does not ever even try MSI-X. As can be seen here: > https://github.com/openbsd/src/blob/master/sys/dev/pci/if_re_pci.c#L161 > > iwx(4) first tries MSI-X, then falls back on MSI: > https://github.com/openbsd/src/blob/master/sys/dev/pci/if_iwx.c#L10573 > Your iwx firmare load failure looks like a DMA problem to me. > > I don't see any actionable information in your bug reports as far > as fixing our drivers goes. Sorry. >
Re: re(4) drivers not working
On Fri, Sep 16, 2022 at 08:27:59AM +0200, Adam Szewczyk wrote: > Checked on actual hardware it seems to work fine. So I report it also to > Qubes and Xen Project, but marmarek (head of qubes development team) > suggest that it can be a problem with driver itself: > "I'm not sure if that's relevant, but a common cause is incorrect MSI / > MSI-X detection/support by the driver. HVM in Qubes do not support MSI-X, > but do support MSI. MSI-X, even if the device really supports it, is masked > from PCI capabilities. Driver should fallback to MSI (or INTx) if MSI-X > fails to setup (or isn't there at all), but many drivers have this path > buggy, since it isn't exercised in most common (native) scenario." re(4) only uses MSI, it does not ever even try MSI-X. As can be seen here: https://github.com/openbsd/src/blob/master/sys/dev/pci/if_re_pci.c#L161 iwx(4) first tries MSI-X, then falls back on MSI: https://github.com/openbsd/src/blob/master/sys/dev/pci/if_iwx.c#L10573 Your iwx firmare load failure looks like a DMA problem to me. I don't see any actionable information in your bug reports as far as fixing our drivers goes. Sorry.
Re: re(4) drivers not working
Checked on actual hardware it seems to work fine. So I report it also to Qubes and Xen Project, but marmarek (head of qubes development team) suggest that it can be a problem with driver itself: "I'm not sure if that's relevant, but a common cause is incorrect MSI / MSI-X detection/support by the driver. HVM in Qubes do not support MSI-X, but do support MSI. MSI-X, even if the device really supports it, is masked from PCI capabilities. Driver should fallback to MSI (or INTx) if MSI-X fails to setup (or isn't there at all), but many drivers have this path buggy, since it isn't exercised in most common (native) scenario." czw., 15 wrz 2022 o 08:03 Adam Szewczyk napisał(a): > Ok, I will check if I have some time to perform installation on actual HW, > but the idea is to be able to run it on xen. There is growing interest in > using OpenBSD, as a sys-net for Qubes OS instead of the original one based > on Linux. So it is crucial for me to be able to use re(4) and iwm(4) with > my NICs on Xen. I understand that if the issue will be caused by having xen > in the middle I should report the issue to its maintainers. > > czw., 15 wrz 2022 o 02:03 Jonathan Gray napisał(a): > >> On Wed, Sep 14, 2022 at 10:23:32PM +0200, Adam Szewczyk wrote: >> > After installation of OpenBSD as HVM on Qubes OS with passed through >> > Realtek NIC driver starts to spamming with "re0: watchdog timeout" >> message >> > and not working. Attaching dmesg. >> >> Try without xen. It may be messing up interrupts. >> >> > >> > OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022 >> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/ >> GENERIC.MP >> > real mem = 1040183296 (991MB) >> > avail mem = 991436800 (945MB) >> > random: good seed from bootblocks >> > mpath0 at root >> > scsibus0 at mpath0: 256 targets >> > mainbus0 at root >> > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfc10 (12 entries) >> > bios0: vendor Xen version "4.14.5" date 08/24/2022 >> > bios0: Xen HVM domU >> > acpi0 at bios0: ACPI 4.0 >> > acpi0: sleep states S3 S4 S5 >> > acpi0: tables DSDT FACP APIC HPET WAET SSDT SSDT >> > acpi0: wakeup devices >> > acpitimer0 at acpi0: 3579545 Hz, 32 bits >> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat >> > ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 48 pins, remapped >> > cpu0 at mainbus0: apid 0 (boot processor) >> > cpu0: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz, 2593.27 MHz, 06-9e-0a >> > cpu0: >> > >> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN >> > cpu0: 256KB 64b/line 8-way L2 cache >> > cpu0: smt 0, core 0, package 0 >> > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges >> > cpu0: apic clock running at 100MHz >> > cpu1 at mainbus0: apid 2 (application processor) >> > cpu1: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz, 2592.03 MHz, 06-9e-0a >> > cpu1: >> > >> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN >> > cpu1: 256KB 64b/line 8-way L2 cache >> > cpu1: smt 0, core 1, package 0 >> > acpihpet0 at acpi0: 6250 Hz >> > acpiprt0 at acpi0: bus 0 (PCI0) >> > acpipci0 at acpi0 PCI0 >> > acpicmos0 at acpi0 >> > "ACPI0007" at acpi0 not configured >> > "ACPI0007" at acpi0 not configured >> > acpicpu0 at acpi0: C1(@1 halt!) >> > acpicpu1 at acpi0: C1(@1 halt!) >> > cpu0: using VERW MDS workaround (except on vmm entry) >> > pvbus0 at mainbus0: Xen 4.14 >> > xen0 at pvbus0: features 0x2705, 2048 grant table frames, event channel >> 1 >> > xbf0 at xen0 backend 0 channel 6: disk >> > scsibus1 at xbf0: 1 targets >> > sd0 at scsibus1 targ 0 lun 0: >> > sd0: 10240MB, 512 bytes/sector, 20971520 sectors >> > xbf1 at xen0 backend 0 channel 7: disk >> > scsibus2 at xbf1: 1 targets >> > sd1 at scsibus2 targ 0 lun 0: >> > sd1: 2048MB, 512 bytes/sector, 4194304 sectors >> > xbf2 at xen0 backend 0 channel 8: disk >> > scsibus3 at xbf2: 1 targets >> > sd2 at scsibus3 targ 0 lun 0: >> > sd2: 10240MB, 512 bytes/sector, 20971520 sectors >> > xnf0 at xen0 backend 113 channel 9: address 00:16:3e:5e:6c:00 >> > pci0 at mainbus0 bus 0 >> > pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 >> > pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00 >> > pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, >> channel >> > 0 wired to compatibility, channel 1
Re: re(4) drivers not working
Ok, I will check if I have some time to perform installation on actual HW, but the idea is to be able to run it on xen. There is growing interest in using OpenBSD, as a sys-net for Qubes OS instead of the original one based on Linux. So it is crucial for me to be able to use re(4) and iwm(4) with my NICs on Xen. I understand that if the issue will be caused by having xen in the middle I should report the issue to its maintainers. czw., 15 wrz 2022 o 02:03 Jonathan Gray napisał(a): > On Wed, Sep 14, 2022 at 10:23:32PM +0200, Adam Szewczyk wrote: > > After installation of OpenBSD as HVM on Qubes OS with passed through > > Realtek NIC driver starts to spamming with "re0: watchdog timeout" > message > > and not working. Attaching dmesg. > > Try without xen. It may be messing up interrupts. > > > > > OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > real mem = 1040183296 (991MB) > > avail mem = 991436800 (945MB) > > random: good seed from bootblocks > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfc10 (12 entries) > > bios0: vendor Xen version "4.14.5" date 08/24/2022 > > bios0: Xen HVM domU > > acpi0 at bios0: ACPI 4.0 > > acpi0: sleep states S3 S4 S5 > > acpi0: tables DSDT FACP APIC HPET WAET SSDT SSDT > > acpi0: wakeup devices > > acpitimer0 at acpi0: 3579545 Hz, 32 bits > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > > ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 48 pins, remapped > > cpu0 at mainbus0: apid 0 (boot processor) > > cpu0: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz, 2593.27 MHz, 06-9e-0a > > cpu0: > > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN > > cpu0: 256KB 64b/line 8-way L2 cache > > cpu0: smt 0, core 0, package 0 > > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > > cpu0: apic clock running at 100MHz > > cpu1 at mainbus0: apid 2 (application processor) > > cpu1: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz, 2592.03 MHz, 06-9e-0a > > cpu1: > > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN > > cpu1: 256KB 64b/line 8-way L2 cache > > cpu1: smt 0, core 1, package 0 > > acpihpet0 at acpi0: 6250 Hz > > acpiprt0 at acpi0: bus 0 (PCI0) > > acpipci0 at acpi0 PCI0 > > acpicmos0 at acpi0 > > "ACPI0007" at acpi0 not configured > > "ACPI0007" at acpi0 not configured > > acpicpu0 at acpi0: C1(@1 halt!) > > acpicpu1 at acpi0: C1(@1 halt!) > > cpu0: using VERW MDS workaround (except on vmm entry) > > pvbus0 at mainbus0: Xen 4.14 > > xen0 at pvbus0: features 0x2705, 2048 grant table frames, event channel 1 > > xbf0 at xen0 backend 0 channel 6: disk > > scsibus1 at xbf0: 1 targets > > sd0 at scsibus1 targ 0 lun 0: > > sd0: 10240MB, 512 bytes/sector, 20971520 sectors > > xbf1 at xen0 backend 0 channel 7: disk > > scsibus2 at xbf1: 1 targets > > sd1 at scsibus2 targ 0 lun 0: > > sd1: 2048MB, 512 bytes/sector, 4194304 sectors > > xbf2 at xen0 backend 0 channel 8: disk > > scsibus3 at xbf2: 1 targets > > sd2 at scsibus3 targ 0 lun 0: > > sd2: 10240MB, 512 bytes/sector, 20971520 sectors > > xnf0 at xen0 backend 113 channel 9: address 00:16:3e:5e:6c:00 > > pci0 at mainbus0 bus 0 > > pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 > > pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00 > > pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, > channel > > 0 wired to compatibility, channel 1 wired to compatibility > > pciide0: channel 0 disabled (no drives) > > pciide0: channel 1 disabled (no drives) > > piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: SMBus > > disabled > > xspd0 at pci0 dev 2 function 0 "XenSource Platform Device" rev 0x01 > > vga1 at pci0 dev 3 function 0 "Bochs VGA" rev 0x02 > > wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) > > wsdisplay0: screen 1-5 added (80x25, vt100 emulation) > > ehci0 at pci0 dev 4 function 0 "Intel 82801DB USB" rev 0x10: apic 1 int > 35 > > usb0 at ehci0: USB revision 2.0 > > uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev > > 2.00/1.00 addr 1 > > re0 at pci0 dev 6 function 0 "Realtek 8168" rev 0x15: RTL8168H/8111H > > (0x5400), msi, address 98:fa:9b:11:d0:cf > >
Re: re(4) drivers not working
On Wed, Sep 14, 2022 at 10:23:32PM +0200, Adam Szewczyk wrote: > After installation of OpenBSD as HVM on Qubes OS with passed through > Realtek NIC driver starts to spamming with "re0: watchdog timeout" message > and not working. Attaching dmesg. Try without xen. It may be messing up interrupts. > > OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 1040183296 (991MB) > avail mem = 991436800 (945MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfc10 (12 entries) > bios0: vendor Xen version "4.14.5" date 08/24/2022 > bios0: Xen HVM domU > acpi0 at bios0: ACPI 4.0 > acpi0: sleep states S3 S4 S5 > acpi0: tables DSDT FACP APIC HPET WAET SSDT SSDT > acpi0: wakeup devices > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 48 pins, remapped > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz, 2593.27 MHz, 06-9e-0a > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 100MHz > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz, 2592.03 MHz, 06-9e-0a > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > acpihpet0 at acpi0: 6250 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > acpipci0 at acpi0 PCI0 > acpicmos0 at acpi0 > "ACPI0007" at acpi0 not configured > "ACPI0007" at acpi0 not configured > acpicpu0 at acpi0: C1(@1 halt!) > acpicpu1 at acpi0: C1(@1 halt!) > cpu0: using VERW MDS workaround (except on vmm entry) > pvbus0 at mainbus0: Xen 4.14 > xen0 at pvbus0: features 0x2705, 2048 grant table frames, event channel 1 > xbf0 at xen0 backend 0 channel 6: disk > scsibus1 at xbf0: 1 targets > sd0 at scsibus1 targ 0 lun 0: > sd0: 10240MB, 512 bytes/sector, 20971520 sectors > xbf1 at xen0 backend 0 channel 7: disk > scsibus2 at xbf1: 1 targets > sd1 at scsibus2 targ 0 lun 0: > sd1: 2048MB, 512 bytes/sector, 4194304 sectors > xbf2 at xen0 backend 0 channel 8: disk > scsibus3 at xbf2: 1 targets > sd2 at scsibus3 targ 0 lun 0: > sd2: 10240MB, 512 bytes/sector, 20971520 sectors > xnf0 at xen0 backend 113 channel 9: address 00:16:3e:5e:6c:00 > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 > pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00 > pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel > 0 wired to compatibility, channel 1 wired to compatibility > pciide0: channel 0 disabled (no drives) > pciide0: channel 1 disabled (no drives) > piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: SMBus > disabled > xspd0 at pci0 dev 2 function 0 "XenSource Platform Device" rev 0x01 > vga1 at pci0 dev 3 function 0 "Bochs VGA" rev 0x02 > wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) > wsdisplay0: screen 1-5 added (80x25, vt100 emulation) > ehci0 at pci0 dev 4 function 0 "Intel 82801DB USB" rev 0x10: apic 1 int 35 > usb0 at ehci0: USB revision 2.0 > uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev > 2.00/1.00 addr 1 > re0 at pci0 dev 6 function 0 "Realtek 8168" rev 0x15: RTL8168H/8111H > (0x5400), msi, address 98:fa:9b:11:d0:cf > rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0 > isa0 at pcib0 > isadma0 at isa0 > fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 > pckbc0 at isa0 port 0x60/5 irq 1 irq 12 > pckbd0 at pckbc0 (kbd slot) > wskbd0 at pckbd0: console keyboard, using wsdisplay0 > pms0 at pckbc0 (aux slot) > wsmouse0 at pms0 mux 0 > pcppi0 at isa0 port 0x61 > spkr0 at pcppi0 > uhidev0 at uhub0 port 1 configuration 1 interface 0 "QEMU QEMU USB Tablet" > rev 2.00/0.00 addr 2 > uhidev0: iclass 3/0 > ums0 at uhidev0: 3 buttons, Z dir > wsmouse1 at ums0 mux 0 > vscsi0 at root > scsibus4 at vscsi0: 256 targets > softraid0 at root > scsibus5 at softraid0: 256 targets > root on sd0a
