Re: X freezes after a few seconds, default installation (amdgpu)
On Tue, 19 May 2020 23:44:18 - "Andrés V." wrote: > 6.6 works without issues. I made a clean 6.7 installation, selecting auto > loading > xenodm, finish, reboot, log in and after a trying to resize the default > xterm it > freezes. But: > -Mouse moves > -No cursor changes when moved over the 2 default windows > -No keyboard response > -I can ssh in without problems > -The only thing that jumped at me with top (via ssh) was that Xorg > process shows > 'fsleep' under the WAIT column (before freezing it shows just 'poll'). In top, if you do 'H' (to show threads) and 'g Xorg', you might see an Xorg thread stuck on a DMA fence; WAIT might be "dmafenc" or something else in the kernel's drm code. My amd64 desktop freezes in the same way, but not so quickly; I often use Xorg for hours without a freeze. I often run Xfce with emacs, firefox, sylpheed, and xfce4-terminal (as I am doing now). When the screen does freeze, I typically ssh in and reboot(8). My amd64 desktop has the same cpu as you (Ryzen 5 3400G), but I have 16G RAM (you have 48G), and I use the 3400G's integrated graphics (you seem to use discrete graphics). My screen is 1920x1080 (yours is 1920x1200). My board never ran 6.6, but started with 6.6-current; later snapshots fixed some amdgpu problems. I suspect a problem in the kernel, but have never found a cause. The symptom is a dma fence (in the kernel) that never gets signalled, so Xorg or an X client is stuck at the fence. Sometimes, the dmesg gets a message like, "ring gfx timeout". I have also seen graphical glitches, like windows blinking (I use xfwm4's compositor; they blink more often in bsd.sp than bsd.mp), and glitches in supertuxkart. Multiple people have reported X freezing on amdgpu or radeondrm to this bugs list in recent months. --George
Re: iwm: Intel wireless AC 7265 fails to connect to specific AP ("association failed (status 10)"; worked in 6.7-current #196)
On Tue, May 19, 2020 at 09:12:29PM -0400, Demi M. Obenour wrote: > On 2020-05-19 16:30, Theo Buehler wrote: > > Hi, > > > > Thanks for the detailed report. > > > >>iwm0: sending assoc_req to 18:e8:29:11:2b:2f on channel 6 mode 11g > >>iwm0: association failed (status 10) for 18:e8:29:11:2b:2f > >>iwm0: association timed out for 18:e8:29:11:2b:2f > > > > I saw the same problem on my access point. This is fixed in -current: > > https://cvsweb.openbsd.org/src/sys/net80211/ieee80211_output.c#rev1.131 > > > > > Would it be possible to get an errata patch for this, so that -stable > users can get it fixed? No, it's not possible since the breakage was 6.7-current only :) Look at the link and the commit message: you can see that it reverts a commit from ~10 hours earlier.
Re: iwm: Intel wireless AC 7265 fails to connect to specific AP ("association failed (status 10)"; worked in 6.7-current #196)
On 2020-05-19 21:15, Theo de Raadt wrote: > Demi M. Obenour wrote: >>> >> Would it be possible to get an errata patch for this, so that -stable >> users can get it fixed? > > If we decide. Once it settles in tree. > > For now, no. > > I'm think you don't get it. That change may break something else. That > is why it didn't make release. I hear "me me me". But if you really want > to support that, why not try snapshots? > > The errata process is FIRST AND FOREMOST FOR SECURITY. Sometimes we fix > operational issues. We cannot become servents to the process you suggest. > Understood, thanks! Sincerely, Demi signature.asc Description: OpenPGP digital signature
Re: iwm: Intel wireless AC 7265 fails to connect to specific AP ("association failed (status 10)"; worked in 6.7-current #196)
Demi M. Obenour wrote: > On 2020-05-19 16:30, Theo Buehler wrote: > > Hi, > > > > Thanks for the detailed report. > > > >>iwm0: sending assoc_req to 18:e8:29:11:2b:2f on channel 6 mode 11g > >>iwm0: association failed (status 10) for 18:e8:29:11:2b:2f > >>iwm0: association timed out for 18:e8:29:11:2b:2f > > > > I saw the same problem on my access point. This is fixed in -current: > > https://cvsweb.openbsd.org/src/sys/net80211/ieee80211_output.c#rev1.131 > > > > > Would it be possible to get an errata patch for this, so that -stable > users can get it fixed? If we decide. Once it settles in tree. For now, no. I'm think you don't get it. That change may break something else. That is why it didn't make release. I hear "me me me". But if you really want to support that, why not try snapshots? The errata process is FIRST AND FOREMOST FOR SECURITY. Sometimes we fix operational issues. We cannot become servents to the process you suggest.
Re: iwm: Intel wireless AC 7265 fails to connect to specific AP ("association failed (status 10)"; worked in 6.7-current #196)
On 2020-05-19 16:30, Theo Buehler wrote: > Hi, > > Thanks for the detailed report. > >> iwm0: sending assoc_req to 18:e8:29:11:2b:2f on channel 6 mode 11g >> iwm0: association failed (status 10) for 18:e8:29:11:2b:2f >> iwm0: association timed out for 18:e8:29:11:2b:2f > > I saw the same problem on my access point. This is fixed in -current: > https://cvsweb.openbsd.org/src/sys/net80211/ieee80211_output.c#rev1.131 > > Would it be possible to get an errata patch for this, so that -stable users can get it fixed? Sincerely, Demi signature.asc Description: OpenPGP digital signature
athn(4): AR9287 instability
>Synopsis: athn(4) AR9287 unstable and poor network quality >Category: system amd64 >Environment: System : OpenBSD 6.7 Details : OpenBSD 6.7 (GENERIC.MP) #1: Sat May 16 16:33:02 MDT 2020 r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/ GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: I've been testing a supposedly supported Atheros WiFi card to see if it would work better with 6.7 than it did with 6.6, but unfortunately not. It's an AR9287 chip on a PCI-express 1x card. I'll provide some details below, and I'd be happy to test any patches and suggestions. (PS. the WiFi card works great when I boot the PC into Linux) while transferring a 440 MiB file on 802.11g --- 192.168.1.1 ping statistics --- 641 packets transmitted, 640 packets received, 0.2% packet loss round-trip min/avg/max/std-dev = 12.367/1577.347/6751.938/1530.703 ms transfer speed swung between 200 and 1200 Kbit/s, averaging 700 Kbit/s 45 minutes of idle network on 802.11g = --- 192.168.1.1 ping statistics --- 2937 packets transmitted, 2924 packets received, 0.4% packet loss round-trip min/avg/max/std-dev = 11.577/47.667/310.944/34.576 ms trying to transfer the same 440 MiB file but on 802.11n === the machine's network freezes repeatedly, and ping(8) outputs lots of: ping: sendmsg: No buffer space available ping: wrote 192.168.1.1 64 chars, ret=-1 --- 192.168.1.1 ping statistics --- 348 packets transmitted, 227 packets received, 34.8% packet loss round-trip min/avg/max/std-dev = 29.615/2467.639/6041.608/1004.679 ms dmesg: OpenBSD 6.7 (GENERIC.MP) #1: Sat May 16 16:33:02 MDT 2020 r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/ GENERIC.MP real mem = 4268294144 (4070MB) avail mem = 4126326784 (3935MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf06b0 (57 entries) bios0: vendor American Megatrends Inc. version "0603" date 08/20/2010 bios0: ASUSTeK Computer INC. P5KPL-AM acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB HPET GSCI acpi0: wakeup devices P0P2(S4) P0P1(S4) PS2K(S4) MC97(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) USB0(S4) USB1(S4) USB2(S4) USB3(S4) EUSB(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 3010.46 MHz, 06-17-06 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF,MELTDOWN cpu0: 6MB 64b/line 16-way L2 cache mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 334MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 3010.04 MHz, 06-17-06 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF,MELTDOWN cpu1: 6MB 64b/line 16-way L2 cache cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 3010.06 MHz, 06-17-06 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF,MELTDOWN cpu2: 6MB 64b/line 16-way L2 cache cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 3010.04 MHz, 06-17-06 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF,MELTDOWN cpu3: 6MB 64b/line 16-way L2 cache ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 3 (P0P1) acpiprt2 at acpi0: bus 2 (P0P4) acpiprt3 at acpi0: bus 1 (P0P5) acpiprt4 at acpi0: bus -1 (P0P6) acpicpu0 at acpi0: C1(@1 halt!), PSS acpicpu1 at acpi0: C1(@1 halt!), PSS acpicpu2 at acpi0: C1(@1 halt!), PSS acpicpu3 at acpi0: C1(@1 halt!), PSS acpipci0 at acpi0 PCI0: _OSC failed acpicmos0 at acpi0 aibs0 at acpi0 RTMP RVLT RFAN GGRP GITM SITM acpibtn0 at acpi0: PWRB cpu0: Enhanced SpeedStep 3010 MHz: speeds: 2997, 1998 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x10 inteldrm0 at pci0 dev 2 function 0 "Intel 82G33 Video" rev 0x10 drm0 at inteldrm0 intagp0 at inteldrm0 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0: apic 4 int 16, G33, gen
Re: iwm: Intel wireless AC 7265 fails to connect to specific AP ("association failed (status 10)"; worked in 6.7-current #196)
Hi, Thanks for the detailed report. > iwm0: sending assoc_req to 18:e8:29:11:2b:2f on channel 6 mode 11g > iwm0: association failed (status 10) for 18:e8:29:11:2b:2f > iwm0: association timed out for 18:e8:29:11:2b:2f I saw the same problem on my access point. This is fixed in -current: https://cvsweb.openbsd.org/src/sys/net80211/ieee80211_output.c#rev1.131
pkg-config implementation error
Apologies for the duplicate email. I had some issues posting with protonmail. >Synopsis: pkg-config modversion edge case is not implemented >Category: system >Environment: System : OpenBSD 6.7 Details : OpenBSD 6.7-current (GENERIC.MP) #198: Mon May 18 20:33:28 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: From the man page of pkg-config, if the command "pkg-config --modversion" is executed with no package argument, then pkg-config returns its own version. On the latest snapshot (and previous snapshots) an empty output is produced. >How-To-Repeat: pkg-config --modversion >Fix: Check if no package argument is given and print the version string (producing the same output as pkg-config --version).
USB ure RTL8153 panics on release 6.7 + 001_wscons
>Synopsis: ure RTL8153 panics on 6.7 - was stable on 6.6
>Category:
>Environment:
System : OpenBSD 6.7
Details : OpenBSD 6.7 (GENERIC.MP) #1: Sat May 16 16:33:02 MDT 2020
r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Architecture: OpenBSD.amd64
Machine : amd64
>Description:
** PRELIMINARY BUG REPORT - INCOMPLETE INFO **
USB ure with RTL8153 on 6.7 panics. Same hardware stable on 6.6.
ure0 at uhub0 port 14 configuration 1 interface 0 "Realtek USB 10/100/1000 LAN"
rev 3.00/30.00 addr 5
ure0: RTL8153 (0x5c30), address a0:ce:c8:cd:ba:d1
rgephy0 at ure0 phy 0: RTL8251 PHY, rev. 0
Under load (estimated 50MB/s for approximate 5 minutes), kernel panics:
panic: assertwaitok: non-zero mutex count: 1
Stopped at db_enter+0xl0: popq %rbp
TID PID UID PRFLAGS PFLAGS CPU COMMAND
db_enter() at db_enter+0x10
panic(81c8al98) at panic+0x128
assertwaitok() at assertwaitok+0xc7
mi_switch at mi_switch+0x40
sleep_finish(800022e816b8,1) at sleep_finish+0x84
sleep_finish_all(800022e816b8,1) at sleep_finish_all+0x21
tsleepCfd84465a24b0,10,81c9c412,0) at tsleep+0xd6
usbd_transfer(fd84465a24b0) at usbd_transfer+0x204
usbd_do_request_flagsC8052e600,800022e81810,800022e8180c,0,0,1388)
at usbd_do_request_fLags+0x139
ure_reset(80538000) at ure_reset+0x5e
ure_stop(80538000) at ure_stop+0x21
ure_encap(80538000, fd809e390f00) at ure_encap+0xf2
ure_start(805380d0) at ure_start+0x8b
if_qstart_compat(80538348) at if_qstart_conpat+0x2e
end trace frame: 0x800022e819b0, count: 0
https://www.openbsd.org/ddb.htnl describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{0}>
Above panic OCR’d from a picture and may have errors. I hope to provide more
info / trace later.
Aside:
Same panic occurred with RTL8156 - first 6.7 panic. After that I reverted to
the RTL8153 above in case panic was limited to the newly-supported hardware.
ure0 at uhub0 port 14 configuration 1 interface 0 "Realtek USB 10/100/1G/2.5G
LAN" rev 3.20/30.00 addr 5
ure0: RTL8156 (0x7030), address 00:e0:4c:ab:64:5a
>How-To-Repeat:
Standard 6.7 amd64 install with 001_wscons syspatch and either RTL8153
or RTL8156.
Run under network load for a few minutes.
>Fix:
I removed the ure usb and reverted to an old axe device.
dmesg:
OpenBSD 6.7 (GENERIC.MP) #1: Sat May 16 16:33:02 MDT 2020
r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17076674560 (16285MB)
avail mem = 16546508800 (15779MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xb4eda000 (53 entries)
bios0: vendor Intel Corporation version "RYBDWi35.86A.0383.2019.1030.1528" date
10/30/2019
bios0: Intel Corporation NUC5i7RYB
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI LPIT SSDT ASF! SSDT
SSDT SSDT DMAR BGRT
acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4)
RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4)
RP05(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz, 3392.63 MHz, 06-3d-04
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz, 3392.17 MHz, 06-3d-04
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz, 3392.16 MHz, 06-3d-04
cpu2:
Crashes on 6.7-stable with PC Engines APU2D4
Hi all!
So this is a panic I noticed now with the fresh 6.7 release. I guess it's the
same as [1] with multi-threaded applications (in this case collectd) being the
culprit. It seems only bsd.mp is affected.
[1] - https://marc.info/?l=openbsd-bugs=157080005817280=2
Panic, trace, dmesg, etc. follows:
uvm_fault(0xfd81230a6990, 0x7f8499340440, 0, 2) -> e
kernel: page fault trap, code=0
Stopped at pmap_page_remove+0x210: xchgq %rax,0(%rcx,%rdx,1)
ddb{3}> show panic
kernel page fault
uvm_fault(0xfd81230a6990, 0x7f8499340440, 0, 2) -> e
pmap_page_remove(fd8008b84100) at pmap_page_remove+0x210
end trace frame: 0x800022892b40, count: 0
ddb{3}> machine ddbcpu 0
Stopped at x86_ipi_db+0x12:leave
ddb{0}> trace
x86_ipi_db(81f4aff0) at x86_ipi_db+0x12
x86_ipi_handler() at x86_ipi_handler+0x80
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23
_kernel_lock() at _kernel_lock+0xa2
Xsoftclock() at Xsoftclock+0x1f
_kernel_lock() at _kernel_lock+0xa2
Xsyscall() at Xsyscall+0x128
end of kernel
end trace frame: 0x9322fbcc2f0, count: -7
ddb{0}> machine ddbcpu 1
Stopped at x86_ipi_db+0x12:leave
ddb{1}> trace
x86_ipi_db(800022408ff0) at x86_ipi_db+0x12
x86_ipi_handler() at x86_ipi_handler+0x80
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23
_kernel_lock() at _kernel_lock+0xa2
Xsyscall() at Xsyscall+0x128
end of kernel
end trace frame: 0x93259c91380, count: -5
ddb{1}> machine ddbcpu 2
Stopped at x86_ipi_db+0x12:leave
ddb{2}> trace
x86_ipi_db(800022411ff0) at x86_ipi_db+0x12
x86_ipi_handler() at x86_ipi_handler+0x80
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23
_kernel_lock() at _kernel_lock+0xae
Xsyscall() at Xsyscall+0x128
end of kernel
end trace frame: 0x93222cb5140, count: -5
ddb{2}> machine ddbcpu 3
Stopped at pmap_page_remove+0x210: xchgq %rax,0(%rcx,%rdx,1)
ddb{3}> trace
pmap_page_remove(fd8008b84100) at pmap_page_remove+0x210
uvm_anfree_list(fd810c566010,800022892b58) at uvm_anfree_list+0x36
amap_wipeout(fd81283485f0) at amap_wipeout+0xa8
uvm_unmap_detach(800022892c08,0) at uvm_unmap_detach+0xef
sys_munmap(8000227e6628,800022892c70,800022892cd0) at sys_munmap+0x
11d
syscall(800022892d40) at syscall+0x389
Xsyscall() at Xsyscall+0x128
end of kernel
end trace frame: 0x9320131e330, count: -7
ddb{3}> show uvm
Current UVM status:
pagesize=4096 (0x1000), pagemask=0xfff, pageshift=12
1007490 VM pages: 52257 active, 329626 inactive, 0 wired, 428092 free (81268 z
ero)
min 10% (25) anon, 10% (25) vnode, 5% (12) vtext
freemin=33583, free-target=44777, inactive-target=0, wired-max=335830
faults=11214, traps=99051293, intrs=4058479, ctxswitch=26485051 fpuswitch
=0
softint=8588252, syscalls=227568304, kmapent=11
fault counts:
noram=0, noanon=0, noamap=0, pgwait=0, pgrele=0
ok relocks(total)=387034(388229), anget(retries)=62874158(0), amapcopy=4976
0394
neighbor anon/obj pg=2901229/42656439, gets(lock/unlock)=10685666/388229
cases: anon=56764208, anoncow=6109950, obj=9144502, prcopy=1539969, przero=
38641349
daemon and swap counts:
woke=0, revs=0, scans=0, obscans=0, anscans=0
busy=0, freed=0, reactivate=0, deactivate=0
pageouts=0, pending=0, nswget=0
nswapdev=1
swpages=1105553, swpginuse=0, swpgonly=0 paging=0
kernel pointers:
objs(kern)=0x81f7a0e0
ddb{3}> show bscstats
Current Buffer Cache status:
numbufs 40603 busymapped 0, delwri 1200
kvaslots 6553 avail kva slots 6553
bufpages 162378, dmapages 162378, dirtypages 4800
pendingreads 2, pendingwrites 0
highflips 0, highflops 0, dmaflips 0
ddb{3}> ps
PID TID PPIDUID S FLAGS WAIT COMMAND
73245 64899 67648652 30x100082 nanosleep sleep
50622 174638 8067 0 30x100082 nanosleep sleep
32231 359536 44450721 30x90 lockf perl
63686 250722 44450721 30x90 netconperl
5673 320647 44450721 30x90 lockf perl
87399 82310 44450721 30x90 lockf perl
65811 360549 44450721 30x90 lockf perl
67648 455897 42373652 30x10008a pause sh
42373 108123 1652 30x80 nanosleep collectd
42373 119486 1652 2 0x400collectd
42373 143614 1652 3 0x480 poll collectd
42373 428251 1652 2 0x400collectd
*42373 213696 1652 7 0x400collectd
42373 503627 1652 7 0x400collectd
42373 138307 1652 7 0x400collectd
42373 237827 1652 7 0x400collectd
42373 439432 1652 2 0x400collectd
42373 42664 1652 3 0x480 fsleepcollectd
42373 30222 1652 3 0x480 fsleepcollectd
42373 184825 1652 3 0x480
Re: acpipci kernel doesn't boot
ok, I need a little bit more info than that.
Can you build a -current kernel with the diff below and send me the
(complete) dmesg output it produces?
Index: arch/amd64/pci/acpipci.c
===
RCS file: /cvs/src/sys/arch/amd64/pci/acpipci.c,v
retrieving revision 1.4
diff -u -p -r1.4 acpipci.c
--- arch/amd64/pci/acpipci.c14 May 2020 13:07:11 - 1.4
+++ arch/amd64/pci/acpipci.c19 May 2020 15:07:25 -
@@ -153,15 +153,6 @@ acpipci_attach(struct device *parent, st
aml_parse_resource(, acpipci_parse_resources, sc);
- if (sc->sc_acpi->sc_major < 5) {
- extent_destroy(sc->sc_ioex);
- extent_destroy(sc->sc_memex);
-
- pci_init_extents();
- sc->sc_ioex = pciio_ex;
- sc->sc_memex = pcimem_ex;
- }
-
printf("\n");
#ifdef DIAGNOSTIC
@@ -169,6 +160,15 @@ acpipci_attach(struct device *parent, st
extent_print(sc->sc_ioex);
extent_print(sc->sc_memex);
#endif
+
+ if (sc->sc_acpi->sc_major < 7) {
+ extent_destroy(sc->sc_ioex);
+ extent_destroy(sc->sc_memex);
+
+ pci_init_extents();
+ sc->sc_ioex = pciio_ex;
+ sc->sc_memex = pcimem_ex;
+ }
}
void
Re: Mounting MFS filesystem does not preserve directory permissions of mount point
On Tue, May 19, 2020 at 01:28:24PM +0100, Stuart Henderson wrote: > On 2020/05/19 06:15, Todd C. Miller wrote: > > On Tue, 19 May 2020 14:04:37 +0200, Otto Moerbeek wrote: > > > > > In 18 years, yes. But the -O2 case should work whartever the default > > > is for mfs. > > > > I agree that -O2 should work for mfs, I'm just wasn't sure that > > should be the default for mfs. We don't actually have a way to > > specify the ffs version with mount_mfs as far as I can tell. > > > > - todd > > > > Easy to change that if wanted, OK with me. I also like you to commit the other diff to fix the -O2 case. -Otto > > Index: newfs.c > === > RCS file: /cvs/src/sbin/newfs/newfs.c,v > retrieving revision 1.113 > diff -u -p -r1.113 newfs.c > --- newfs.c 18 May 2020 06:20:44 - 1.113 > +++ newfs.c 19 May 2020 12:22:27 - > @@ -194,7 +194,7 @@ main(int argc, char *argv[]) > u_int64_t nsecs; > > if (strstr(__progname, "mfs")) > - mfs = Nflag = quiet = 1; > + mfs = Nflag = quiet = Oflag = 1; > > getphysmem(); > maxpartitions = getmaxpartitions(); > >
Re: Mounting MFS filesystem does not preserve directory permissions of mount point
On 2020/05/19 06:15, Todd C. Miller wrote: > On Tue, 19 May 2020 14:04:37 +0200, Otto Moerbeek wrote: > > > In 18 years, yes. But the -O2 case should work whartever the default > > is for mfs. > > I agree that -O2 should work for mfs, I'm just wasn't sure that > should be the default for mfs. We don't actually have a way to > specify the ffs version with mount_mfs as far as I can tell. > > - todd > Easy to change that if wanted, Index: newfs.c === RCS file: /cvs/src/sbin/newfs/newfs.c,v retrieving revision 1.113 diff -u -p -r1.113 newfs.c --- newfs.c 18 May 2020 06:20:44 - 1.113 +++ newfs.c 19 May 2020 12:22:27 - @@ -194,7 +194,7 @@ main(int argc, char *argv[]) u_int64_t nsecs; if (strstr(__progname, "mfs")) - mfs = Nflag = quiet = 1; + mfs = Nflag = quiet = Oflag = 1; getphysmem(); maxpartitions = getmaxpartitions();
Re: Mounting MFS filesystem does not preserve directory permissions of mount point
On Tue, May 19, 2020 at 06:15:15AM -0600, Todd C. Miller wrote: > On Tue, 19 May 2020 14:04:37 +0200, Otto Moerbeek wrote: > > > In 18 years, yes. But the -O2 case should work whartever the default > > is for mfs. > > I agree that -O2 should work for mfs, I'm just wasn't sure that > should be the default for mfs. We don't actually have a way to > specify the ffs version with mount_mfs as far as I can tell. > > - todd > Indeed. We could move mfs to ffs1 unconditionally like this. -Otto Index: newfs.c === RCS file: /cvs/src/sbin/newfs/newfs.c,v retrieving revision 1.113 diff -u -p -r1.113 newfs.c --- newfs.c 18 May 2020 06:20:44 - 1.113 +++ newfs.c 19 May 2020 12:25:41 - @@ -328,6 +328,7 @@ main(int argc, char *argv[]) rl.rlim_cur = rl.rlim_max; (void)setrlimit(RLIMIT_DATA, ); } + Oflag = 1; } special = argv[0];
Re: Mounting MFS filesystem does not preserve directory permissions of mount point
On Tue, 19 May 2020 14:04:37 +0200, Otto Moerbeek wrote: > In 18 years, yes. But the -O2 case should work whartever the default > is for mfs. I agree that -O2 should work for mfs, I'm just wasn't sure that should be the default for mfs. We don't actually have a way to specify the ffs version with mount_mfs as far as I can tell. - todd
Re: Mounting MFS filesystem does not preserve directory permissions of mount point
On Tue, May 19, 2020 at 06:06:36AM -0600, Theo de Raadt wrote: > Otto Moerbeek wrote: > > > On Tue, May 19, 2020 at 05:49:23AM -0600, Todd C. Miller wrote: > > > > > Is there any advantage to mfs defaulting to ffs2? > > > > > > - todd > > > > > > > In 18 years, yes. But the -O2 case should work whartever the default > > is for mfs. > > The stored timestamps are unsigned. Are you use it really breaks in > 18 years? all timestamps in dinode.h and fs.h are signed. I've run systems in 2039 and they show wrapped file times. -Otto
Re: Mounting MFS filesystem does not preserve directory permissions of mount point
Otto Moerbeek wrote: > On Tue, May 19, 2020 at 05:49:23AM -0600, Todd C. Miller wrote: > > > Is there any advantage to mfs defaulting to ffs2? > > > > - todd > > > > In 18 years, yes. But the -O2 case should work whartever the default > is for mfs. The stored timestamps are unsigned. Are you use it really breaks in 18 years?
Re: Mounting MFS filesystem does not preserve directory permissions of mount point
On Tue, May 19, 2020 at 05:49:23AM -0600, Todd C. Miller wrote: > Is there any advantage to mfs defaulting to ffs2? > > - todd > In 18 years, yes. But the -O2 case should work whartever the default is for mfs. -Otto
Re: Mounting MFS filesystem does not preserve directory permissions of mount point
Is there any advantage to mfs defaulting to ffs2? - todd
Re: Mounting MFS filesystem does not preserve directory permissions of mount point
On 2020/05/19 11:36, Andreas Kusalananda Kähäri wrote:
> >Synopsis:Mounting MFS filesystem does not preserve directory permissions
> >of mount point
> >Category:system
> >Environment:
> System : OpenBSD 6.7
> Details : OpenBSD 6.7-current (GENERIC.MP) #198: Mon May 18
> 20:33:28 MDT 2020
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
>
> I've notice that with the most recent snapshot, the permissions of my
> /tmp directory, mounted as a MFS filesystem, were wrong:
>
> $ ls -ld /tmp
> drwxr-xr-x 2 root wheel 512 May 19 11:23 /tmp
>
> This filesystem is mounted via fstab:
>
> swap/tmpmfs rw,nodev,nosuid,-s1G
>
> ... and the mount point has the correct permissions:
>
> $ doas umount /tmp
> $ ls -ld /tmp
> drwxrwxrwt 7 root wheel 512 May 19 11:23 /tmp
OK?
Index: mkfs.c
===
RCS file: /cvs/src/sbin/newfs/mkfs.c,v
retrieving revision 1.98
diff -u -p -r1.98 mkfs.c
--- mkfs.c 3 Jul 2019 03:24:02 - 1.98
+++ mkfs.c 19 May 2020 11:43:30 -
@@ -134,7 +134,7 @@ static int ilog2(int);
void initcg(int, time_t);
void wtfs(daddr_t, int, void *);
intfsinit1(time_t, mode_t, uid_t, gid_t);
-intfsinit2(time_t);
+intfsinit2(time_t, mode_t, uid_t, gid_t);
intmakedir(struct direct *, int);
void iput(union dinode *, ino_t);
void setblock(struct fs *, unsigned char *, int);
@@ -590,7 +590,7 @@ mkfs(struct partition *pp, char *fsys, i
sblock.fs_ffs1_cstotal.cs_nifree = sblock.fs_cstotal.cs_nifree;
sblock.fs_ffs1_cstotal.cs_nffree = sblock.fs_cstotal.cs_nffree;
} else {
- if (fsinit2(utime))
+ if (fsinit2(utime, mfsmode, mfsuid, mfsgid))
errx(32, "fsinit2 failed");
}
@@ -841,7 +841,7 @@ fsinit1(time_t utime, mode_t mfsmode, ui
}
int
-fsinit2(time_t utime)
+fsinit2(time_t utime, mode_t mfsmode, uid_t mfsuid, gid_t mfsgid)
{
union dinode node;
@@ -856,9 +856,15 @@ fsinit2(time_t utime)
/*
* Create the root directory.
*/
- node.dp2.di_mode = IFDIR | UMASK;
- node.dp2.di_uid = geteuid();
- node.dp2.di_gid = getegid();
+ if (mfs) {
+ node.dp2.di_mode = IFDIR | mfsmode;
+ node.dp2.di_uid = mfsuid;
+ node.dp2.di_gid = mfsgid;
+ } else {
+ node.dp2.di_mode = IFDIR | UMASK;
+ node.dp2.di_uid = geteuid();
+ node.dp2.di_gid = getegid();
+ }
node.dp2.di_nlink = PREDEFDIR;
node.dp2.di_size = makedir(root_dir, PREDEFDIR);
Mounting MFS filesystem does not preserve directory permissions of mount point
>Synopsis: Mounting MFS filesystem does not preserve directory permissions >of mount point >Category: system >Environment: System : OpenBSD 6.7 Details : OpenBSD 6.7-current (GENERIC.MP) #198: Mon May 18 20:33:28 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: I've notice that with the most recent snapshot, the permissions of my /tmp directory, mounted as a MFS filesystem, were wrong: $ ls -ld /tmp drwxr-xr-x 2 root wheel 512 May 19 11:23 /tmp This filesystem is mounted via fstab: swap/tmpmfs rw,nodev,nosuid,-s1G ... and the mount point has the correct permissions: $ doas umount /tmp $ ls -ld /tmp drwxrwxrwt 7 root wheel 512 May 19 11:23 /tmp >How-To-Repeat: Mount an MFS filesystem over /tmp and check permissions. $ ls -ld /tmp drwxrwxrwt 7 root wheel 512 May 19 11:30 /tmp $ doas mount_mfs -s 1G swap /tmp $ ls -ld /tmp drwxr-xr-x 2 root wheel 512 May 19 11:31 /tmp $ doas umount /tmp $ ls -ld /tmp drwxrwxrwt 7 root wheel 512 May 19 11:30 /tmp >Fix: Unknown. dmesg: OpenBSD 6.7-current (GENERIC.MP) #198: Mon May 18 20:33:28 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16872108032 (16090MB) avail mem = 16348139520 (15590MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (71 entries) bios0: vendor LENOVO version "G2ET33WW (1.13 )" date 07/24/2012 bios0: LENOVO 23252FG acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF! UEFI UEFI POAT SSDT SSDT DMAR UEFI acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.81 MHz, 06-3a-09 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.34 MHz, 06-3a-09 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.34 MHz, 06-3a-09 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.34 MHz, 06-3a-09 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus 4 (EXP3) acpicpu0 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1),
Re: acpipci kernel doesn't boot
On Mon, May 18, 2020 at 11:43:10PM +0200, Mark Kettenis wrote: > > Date: Mon, 18 May 2020 18:09:36 +0200 > > From: Moises Simon > > > > On Mon, May 18, 2020 at 04:59:22PM +0200, Mark Kettenis wrote: > > > > Date: Mon, 18 May 2020 16:39:06 +0200 > > > > From: Moises Simon > > > > > > > > On Mon, Feb 10, 2020 at 01:57:15PM +0100, Mark Kettenis wrote: > > > > > Macpipcioises Simon schreef op 2020-02-01 15:16: > > > > > > On Wed, Jan 29, 2020 at 10:48:10PM -0700, Nayden Markatchev wrote: > > > > > > > thank you for the bug report. > > > > > > > > > > > > > > there is a diff in snapshots that is likely to have caused this > > > > > > > regression. i've backed it out and ran a snapshot built. the new > > > > > > > snapshot should hit the mirrors in a couple of hours. please > > > > > > > update > > > > > > > and let us know if the issue persists. > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > working fine. > > > > > > > > > > However, that diff is going to return at some point. In order not to > > > > > break > > > > > your > > > > > machine again, I really need to see how it fails. > > > > > > > > > > > > > Hi Mark, > > > > > > > > I see that the ACPI diff was commited again. Same problem as the last > > > > time, > > > > what do you need from my machine to fix the issue? > > > > > > The diff has been committed with a change such that it should not > > > affect your machine. If it really doesn't work I need a proper > > > -current dmesg. > > > > > > > inline dmesg for ramdisk upgrade, -current from may 14 and -current from > > today > > with acpipci disabled > > Ah, you moved the goalposts on me by updating your BIOS ;). > > Previous one claimed to be ACPI 4.0, now it claims ACPI 6.0. > > I need pcidump -vxx and acpidump output. Easiest way to provide that > is to use sendbug. Either with the older kernel or with the new one > with acpipci disabled. > > Cheers, > > Mark > output of sendbug (minus dmesg). New one with acpipci disabled. usbdevs: Controller /dev/usb0: addr 01: 8086: Intel, EHCI root hub high speed, self powered, config 1, rev 1.00 driver: uhub0 addr 02: 8087:0024 Intel, Rate Matching Hub high speed, self powered, config 1, rev 0.00 driver: uhub3 addr 03: 0930:6545 Kingston, DataTraveler 2.0 high speed, power 300 mA, config 1, rev 1.10, iSerial 001BFC3653BCB131E904D64E driver: umass0 addr 04: 04f2:b221 Chicony Electronics Co., Ltd., Integrated Camera high speed, power 200 mA, config 1, rev 7.52 driver: uvideo0 Controller /dev/usb1: addr 01: 1912: Renesas, xHCI root hub super speed, self powered, config 1, rev 1.00 driver: uhub1 Controller /dev/usb2: addr 01: 8086: Intel, EHCI root hub high speed, self powered, config 1, rev 1.00 driver: uhub2 addr 02: 8087:0024 Intel, Rate Matching Hub high speed, self powered, config 1, rev 0.00 driver: uhub4 addr 03: 0bdb:1911 Lenovo, F5521gw high speed, self powered, config 1, rev 0.00, iSerial 678213BB930A51F0 driver: umodem0 driver: umodem1 driver: umodem2 driver: ugen0 addr 04: 17ef:1003 Lenovo, Integrated Smart Card Reader full speed, power 100 mA, config 1, rev 1.00 driver: ugen1 pcidump: Domain /dev/pci0: 0:0:0: Intel Core 2G Host 0x: Vendor ID: 8086, Product ID: 0104 0x0004: Command: 0006, Status: 2090 0x0008: Class: 06 Bridge, Subclass: 00 Host, Interface: 00, Revision: 09 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR empty () 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 17aa Product ID: 21ce 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00 0x00e0: Capability 0x09: Vendor Specific 0x: 01048086 2096 0609 0x0010: 0x0020: 21ce17aa 0x0030: 00e0 0x0040: fed19001 fed10001 0x0050: 0239 0091 0004 8001 0x0060: f005 fed18001 0x0070: fff0 007f 0400 0x0080: 3330 0033 001a 0x0090: 0001 0004 7151 0004 0x00a0: 0001 0004 7161 0004 0x00b0: 80a1 8081 8001 8ea1 0x00c0: 0x00d0: 0x00e0: 010c0009 e200619e 1490 0x00f0:
