Re: ld.so crash second attempt
On Tue, 03 Nov 2015 10:46:57 +0100,
Philip Guenther wrote:
>
> On Sun, 25 Oct 2015, Peter Hajdu wrote:
> > I try to give it one more attempt with a bit more description about the
> > bug.
> >
> > After calling dlclose in _dl_notify_unload_shlib_ group reference counts
> > are decreased by following the object's grpref-list. Unfortunately the
> > references are removed from the list during the graph traversal.
> >
> > dlclose will run all destructors of the unused objects and tries to
> > unload all objects reachable from the closed object's child and
> > grpref-list. Since the grpref-list references were removed, the unused
> > destructed object stays in memory as garbage. Next time when this
> > object is loaded it is found in the memory and crashes during load.
> >
> > This patch unloads all unused objects instead of following the closed
> > object's child and grpref list.
>
> Thank you for working on this. After a long rumination, I'd like to
> propose a different diff, seen below.
>
> Your diff changes dlclose() to switch from calling _dl_unload_shlib() to a
> new function _dl_unload_unused(). They both unload refcnt==0 objects:
> _dl_unload_shlib() finds them by walking the dependency tree from the
> selected object, while _dl_unload_unused() just scans the entire list.
>
> So why is the former not sufficient? As you describe, the problem occurs
> when a grpref is removed which is the last reference to an object. grprefs
> are used guarantee that entire load groups are unloaded all at once and
> not piecemeal. If later dlopen() adds a dependency to a child in this
> load group, the entire group will be kept even if that child is the last
> real link. When that dependency is added, the later object takes a grpref
> to the load_object, which is root of the load group.
>
> As you note _dl_run_all_dtors() releases that grpref, but we still know
> where it had pointed: to the load_object of some object being released!
> So we can retain the behavior of _dl_unload_shlib(), but we need to add a
> check for whether our load_object is now unreferenced. If so, it
> previously had a grpref which has been released, so we need to take down
> the entire load group.
>
> Thus the diff below. It works with your test setup (thanks for writing
> that!), passes regress/libexec/ld.so/, and chrome hasn't choked on it.
> Can someone who's familiar with the sdl problem case test it there?
>
>
> Does that make sense?
>
>
> Again, thank you for pushing on this. If what I show here works, it's
> because your description triggered an "ahhh, wait a moment..." thought.
>
>
> Philip
>
sdl2 (the old, marked-as-broken) port and sdl2 apps start and work
with this patch on amd64 -current.
Thx,
Alf
>
> Index: library.c
> ===
> RCS file: /data/src/openbsd/src/libexec/ld.so/library.c,v
> retrieving revision 1.71
> diff -u -p -r1.71 library.c
> --- library.c 16 Jan 2015 16:18:07 - 1.71
> +++ library.c 3 Nov 2015 09:09:15 -
> @@ -59,9 +59,27 @@ void
> _dl_unload_shlib(elf_object_t *object)
> {
> struct dep_node *n;
> + elf_object_t *load_object = object->load_object;
> +
> + /*
> + * If our load object has become unreferenced then we lost the
> + * last group reference to it, so the entire group should be taken
> + * down. The current object is somewhere below load_object in
> + * the child_list tree, so it'll get cleaned up by the recursion.
> + * That means we can just switch here to the load object.
> + */
> + if (load_object != object && OBJECT_REF_CNT(load_object) == 0 &&
> + (load_object->status & STAT_UNLOADED) == 0) {
> + DL_DEB(("unload_shlib switched from %s to %s\n",
> + object->load_name, load_object->load_name));
> + object = load_object;
> + goto unload;
> + }
> +
> DL_DEB(("unload_shlib called on %s\n", object->load_name));
> if (OBJECT_REF_CNT(object) == 0 &&
> (object->status & STAT_UNLOADED) == 0) {
> +unload:
> object->status |= STAT_UNLOADED;
> TAILQ_FOREACH(n, &object->child_list, next_sib)
> _dl_unload_shlib(n->data);
> Index: library_mquery.c
> ===
> RCS file: /data/src/openbsd/src/libexec/ld.so/library_mquery.c,v
> retrieving revision 1.49
> diff -u -p -r1.49 library_mquery.c
> --- library_mquery.c 22 Jan 2015 05:48:17 - 1.49
> +++ library_mquery.c 3 Nov 2015 09:10:39 -
> @@ -64,10 +64,27 @@ void
> _dl_unload_shlib(elf_object_t *object)
> {
> struct dep_node *n;
> + elf_object_t *load_object = object->load_object;
> +
> + /*
> + * If our load object has become unreferenced then we lost the
> + * last group reference to it, so the entire group should be taken
> + * down. The current object is
Re: ld.so crash second attempt
On Sun, 25 Oct 2015 11:01:27 +0100,
Peter Hajdu wrote:
>
> [1 ]
> Hi,
>
> I try to give it one more attempt with a bit more description about the
> bug.
>
> After calling dlclose in _dl_notify_unload_shlib_ group reference counts
> are decreased by following the object's grpref-list. Unfortunately the
> references are removed from the list during the graph traversal.
>
> dlclose will run all destructors of the unused objects and tries to
> unload all objects reachable from the closed object's child and
> grpref-list. Since the grpref-list references were removed, the unused
> destructed object stays in memory as garbage. Next time when this
> object is loaded it is found in the memory and crashes during load.
>
> This patch unloads all unused objects instead of following the closed
> object's child and grpref list.
>
> Best regards,
> Peter Hajdu
>
Hello,
I can confirm that this works with sdl2 on a maybe 4 week old snapshot
on amd64.
I used that old patch that was flying around to get sdl2 up and
running, now I replaced ld.so with a fresh checkout, applied the
patch and sdl2 still works fine, no other problems observed.
Thanks a lot,
Alf
> [2 ldso_fix.diff ]
> Index: dlfcn.c
> ===
> RCS file: /cvs/src/libexec/ld.so/dlfcn.c,v
> retrieving revision 1.91
> diff -u -p -r1.91 dlfcn.c
> --- dlfcn.c 19 Sep 2015 20:56:47 - 1.91
> +++ dlfcn.c 21 Oct 2015 13:52:46 -
> @@ -302,7 +302,7 @@ _dl_real_close(void *handle)
> object->opencount--;
> _dl_notify_unload_shlib(object);
> _dl_run_all_dtors();
> - _dl_unload_shlib(object);
> + _dl_unload_unused();
> _dl_cleanup_objects();
> return (0);
> }
> Index: library.c
> ===
> RCS file: /cvs/src/libexec/ld.so/library.c,v
> retrieving revision 1.71
> diff -u -p -r1.71 library.c
> --- library.c 16 Jan 2015 16:18:07 - 1.71
> +++ library.c 21 Oct 2015 13:52:46 -
> @@ -74,6 +74,22 @@ _dl_unload_shlib(elf_object_t *object)
> }
> }
>
> +void
> +_dl_unload_unused(void)
> +{
> + elf_object_t *obj, *next;
> +
> + for (obj = _dl_objects->next; obj != NULL; obj = next) {
> + next = obj->next;
> + if (OBJECT_REF_CNT(obj) != 0 || obj->status & STAT_UNLOADED)
> + continue;
> + obj->status |= STAT_UNLOADED;
> + _dl_load_list_free(obj->load_list);
> + _dl_munmap((void *)obj->load_base, obj->load_size);
> + _dl_remove_object(obj);
> + }
> +}
> +
> elf_object_t *
> _dl_tryload_shlib(const char *libname, int type, int flags)
> {
> Index: library_mquery.c
> ===
> RCS file: /cvs/src/libexec/ld.so/library_mquery.c,v
> retrieving revision 1.49
> diff -u -p -r1.49 library_mquery.c
> --- library_mquery.c 22 Jan 2015 05:48:17 - 1.49
> +++ library_mquery.c 21 Oct 2015 13:52:46 -
> @@ -79,6 +79,20 @@ _dl_unload_shlib(elf_object_t *object)
> }
> }
>
> +void
> +_dl_unload_unused(void)
> +{
> + elf_object_t *obj, *next;
> +
> + for (obj = _dl_objects->next; obj != NULL; obj = next) {
> + next = obj->next;
> + if (OBJECT_REF_CNT(obj) != 0 || obj->status & STAT_UNLOADED)
> + continue;
> + obj->status |= STAT_UNLOADED;
> + _dl_load_list_free(obj->load_list);
> + _dl_remove_object(obj);
> + }
> +}
>
> elf_object_t *
> _dl_tryload_shlib(const char *libname, int type, int flags)
> Index: resolve.h
> ===
> RCS file: /cvs/src/libexec/ld.so/resolve.h,v
> retrieving revision 1.73
> diff -u -p -r1.73 resolve.h
> --- resolve.h 19 Sep 2015 20:56:47 - 1.73
> +++ resolve.h 21 Oct 2015 13:52:46 -
> @@ -223,6 +223,7 @@ void _dl_unlink_dlopen(elf_object_t *dep
> void _dl_notify_unload_shlib(elf_object_t *object);
> void _dl_unload_shlib(elf_object_t *object);
> void _dl_unload_dlopen(void);
> +void _dl_unload_unused(void);
>
> void _dl_run_all_dtors(void);
>
Re: Stairstep mouse motion
On Sat, Oct 26, 2013 at 10:13:11PM +0600, Alexandr Shadchin wrote: > On Fri, Oct 25, 2013 at 11:41:25AM +0100, Edd Barrett wrote: > > On Thu, Oct 24, 2013 at 10:33:22PM +0300, Henri Kemppainen wrote: > > > What happens when priv->swap_axes is set, and the ax && ay branch is > > > taken along with the wsWheelEmuFilterMotion() branch. Following > > > continue another event is processed and now the axes are swapped again > > > (ax and ay were not reset after use) and then what? Not very likely > > > I know. > > > > Ah, yes, there is the possibility of posting an inconsistent pointer sample > > in this case. Perhaps we should only update the old_ax/old_ay if the > > wsWheelEmuFilterMotion branch is not taken? > > > > What do you think? And yes, this is a very very unlikely case. You could > > argue it wouldn't matter even if it did happen. > > > > -- > > Best Regards > > Edd Barrett > > > > http://www.theunixzoo.co.uk > > > > Alternative solution without extra magic (need rebuild kernel). > > Before (on example pms(4)): > * user move mouse > * pms(4) read state mouse and process it > * pms(4) send dx, dy and buttons in wscons > * wscons generate simple events > * ws(4) reads one event and process it immediately > > After applying diff: > * user move mouse > * pms(4) read state mouse and process it > * pms(4) send dx, dy and buttons in wscons > * wscons generate simple events and adds SYNC event > * ws(4) reads events until it receives SYNC, and only then begins processing > > Tested on mouse. > > Comments ? > > PS: > synaptics(4) is working on a similar basis > > -- > Alexandr Shadchin > I've tested this diff with some hours of QuakeWorld, an old and very fast/demanding FPS game. Works well. This staircase fix + KMS have improved these types of games on OpenBSD a lot. However, mouse input still isn't there yet, it still feels slightly delayed and not precise enough compared to running the same game and game client on Linux. This is only subtle and will most likely not be noticed without playing quite a lot though. Modern Quake engines rely on high sleep granuality so I always have to rip out any usleep from the clients since in OpenBSD atm you can't sleep below tic rate (roughly 1/100 sec on my machine) AFAIK. This may add to the aforementioned felt latency on input. Alf OpenBSD 5.4-current (GENERIC.MP) #0: Tue Oct 29 14:32:26 CET 2013 r...@obsd.rechners.lemarit.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8555986944 (8159MB) avail mem = 8320094208 (7934MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (37 entries) bios0: vendor Award Software International, Inc. version "F9" date 03/21/2012 bios0: Gigabyte Technology Co., Ltd. PH67A-UD3-B3 acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP MSDM HPET MCFG ASPT SSPT EUDS MATS TAMG APIC SSDT MATS acpi0: wakeup devices PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5) PEX6(S5) PEX7(S5) HUB0(S5) UAR1(S3) USBE(S3) USE2(S3) AZAL(S5) PCI0(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 addr 0xf400, bus 0-63 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz, 3396.09 MHz 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz, 3395.56 MHz 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz, 3395.56 MHz 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz, 3395.56 MHz 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,I
rksh annoyance
Hello, Here at work we have some special users that have a shell script as login shell so they can perform some tasks. Now, if this script is named /usr/local/bin/youcandothis.sh it will work, same script but named /usr/local/bin/youarenotallowed.sh does not because ksh determines if it is called as a restricted shell very loose, if not silly. Alf --- bin/ksh/main.c.orig Mon Aug 1 11:51:00 2011 +++ bin/ksh/main.c Mon Aug 1 12:04:03 2011 @@ -748,7 +748,14 @@ char *p; if ((p = strrchr(name, '/'))) - name = p; - /* accepts rsh, rksh, rpdksh, pdrksh, etc. */ - return (p = strchr(name, 'r')) && strstr(p, "sh"); + name = p + 1; + /* accepts rsh, rksh, rpdksh, pdrksh */ + if (strcmp(name, "rsh") && \ + strcmp(name, "rksh") && \ + strcmp(name, "rpdksh") && \ + strcmp(name, "pdrksh")) + return(0); + else + return(1); + }
Re: Looking for testers for a simple X test
On Tue, Aug 31, 2010 at 10:23:09PM +0100, Owain Ainsworth wrote: > On Tue, Aug 31, 2010 at 02:54:44PM +0200, Alf Schlichting wrote: > > On Tue, Aug 31, 2010 at 10:58:08AM +0300, Oleksii Zhmyrov wrote: > > > Hi, > > > > > > I use OpenBSD -current on my desktop with Xfce4. > > > With Option "UseSIGIO" "false" xserver refuses to start at all. > > > > > > > Same here, segmentation fault. I am on a radeon card too, x1950 with > > a ca. 1 week old x11. > > > > snipplet from Xorg.0.log: > > ... > > [3357823.938] (**) Keyboard0: CustomKeycodes disabled > > [3357823.938] (II) XINPUT: Adding extended input device "Keyboard0" (type: > > KEYBOARD) > > [3357823.938] Segmentation fault at address 0x9b641ce > > [3357823.938] > > Fatal server error: > > [3357823.938] Caught signal 11 (Segmentation fault). Server aborting > > [3357823.938] > > [3357823.938] > > ... > > > > I can attach the rest if it is needed. > > I just fixed this, please could you try again with current sources and > confirm that things are now ok? > Yep, fresh cvs checkout works ok, no more crashes. Alf
Re: Looking for testers for a simple X test
On Tue, Aug 31, 2010 at 10:58:08AM +0300, Oleksii Zhmyrov wrote:
> Hi,
>
> I use OpenBSD -current on my desktop with Xfce4.
> With Option "UseSIGIO" "false" xserver refuses to start at all.
>
Same here, segmentation fault. I am on a radeon card too, x1950 with
a ca. 1 week old x11.
snipplet from Xorg.0.log:
...
[3357823.938] (**) Keyboard0: CustomKeycodes disabled
[3357823.938] (II) XINPUT: Adding extended input device "Keyboard0" (type:
KEYBOARD)
[3357823.938] Segmentation fault at address 0x9b641ce
[3357823.938]
Fatal server error:
[3357823.938] Caught signal 11 (Segmentation fault). Server aborting
[3357823.938]
[3357823.938]
...
I can attach the rest if it is needed.
Alf
OpenBSD 4.8 (GENERIC.MP) #359: Mon Aug 16 09:16:26 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz ("GenuineIntel" 686-class)
3.01 GHz
cpu0:
FPU,V86,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,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1
real mem = 2145873920 (2046MB)
avail mem = 2100781056 (2003MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 12/11/07, BIOS32 rev. 0 @ 0xfb2e0, SMBIOS
rev. 2.4 @ 0xf0100 (38 entries)
bios0: vendor Award Software International, Inc. version "F1" date 12/11/2007
bios0: Gigabyte Technology Co., Ltd. EP35-DS3P
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP HPET MCFG APIC SSDT SSDT
acpi0: wakeup devices PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5)
HUB0(S5) UAR1(S1) USB0(S1) USB1(S1) USB2(S1) USB3(S1) US31(S1) USB4(S1)
USB5(S1) USBE(S1) USE2(S1) AZAL(S5) PCI0(S5)
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: apic clock running at 333MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz ("GenuineIntel" 686-class)
3.01 GHz
cpu1:
FPU,V86,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,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (PEX0)
acpiprt2 at acpi0: bus -1 (PEX1)
acpiprt3 at acpi0: bus -1 (PEX2)
acpiprt4 at acpi0: bus -1 (PEX3)
acpiprt5 at acpi0: bus 3 (PEX4)
acpiprt6 at acpi0: bus 4 (PEX5)
acpiprt7 at acpi0: bus 5 (HUB0)
acpicpu0 at acpi0: FVS, 3000, 2000 MHz
acpicpu1 at acpi0: FVS, 3000, 2000 MHz
acpibtn0 at acpi0: PWRB
bios0: ROM list: 0xc/0xf800
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x02
ppb0 at pci0 dev 1 function 0 "Intel 82G33 PCIE" rev 0x02: apic 2 int 16 (irq
10)
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Radeon X1950 Pro" rev 0x9a
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
radeondrm0 at vga1: apic 2 int 16 (irq 10)
drm0 at radeondrm0
"ATI Radeon X1950 Pro Sec" rev 0x9a at pci1 dev 0 function 1 not configured
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 2 int 16 (irq
10)
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 2 int 21 (irq
12)
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x02: apic 2 int 18 (irq
10)
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 2 int 18 (irq
10)
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 0x02: apic 2 int
22 (irq 9)
azalia0: codecs: Realtek ALC885
audio0 at azalia0
ppb1 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02: apic 2 int 16 (irq
10)
pci2 at ppb1 bus 2
ppb2 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02: apic 2 int 16 (irq
10)
pci3 at ppb2 bus 3
jmb0 at pci3 dev 0 function 0 "JMicron JMB363 IDE/SATA" rev 0x02
ahci0 at jmb0: apic 2 int 16 (irq 10), AHCI 1.0
scsibus0 at ahci0: 32 targets
pciide0 at jmb0: DMA, channel 0 wired to native-PCI, channel 1 wired to
native-PCI
pciide0: using apic 2 int 16 (irq 10) for native-PCI interrupt
atapiscsi0 at pciide0 channel 0 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: ATAPI 5/cdrom removable
cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
pciide0: channel 1 disabled (no drives)
ppb3 at pci0 dev 28 function 5 "Intel 82801I PCIE" rev 0x02: apic 2 int 17 (irq
12)
pci4 at ppb3 bus 4
re0 at pci4 dev 0 function 0 "Realtek 8168" rev 0x01: RTL8168 2 (0x3800), apic
2 int 17 (irq 12), address 00:1a:4d:5f:84:be
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2
uhci3 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x02: apic 2 int 23 (irq
11)
uhci4 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x02: apic 2 int 19
