Re: 64-bit PCI bridge support: testers needed

2014-11-29 Thread Jiri Navratil 
Can this be realted to load, which is very high?

Jiri

28. 11. 2014 v 16:12, sven falempin sven.falem...@gmail.com:

 There is no direct relation with the commit, but i will anyway report
 the test result on my problematic hardware.
 The behavior is mostly the same, but now rl0: watchdog timeout is
 spammed by the kernel.
 
 As you can see the system work for more than 40 hours.
 
 I really wonder what could be the cause of this, after rebooting the
 machine reproduce the bug quickly,
 maybe there is some kind of electric problem.
 
 Aug 22 18:00:07 unicorn /bsd: rl0: watchdog timeout
 # uptime
 7:58PM  up 1 day, 23:17, 1 user, load averages: 5.23, 5.50, 5.30
 # date
 Fri Aug 22 19:58:38 EDT 2014
 # rl0: watchdog timeout
 rl0: watchdog timeout
 
 
 On Wed, Nov 26, 2014 at 10:10 AM, sven falempin sven.falem...@gmail.com 
 wrote:
 HEllo,
 
 So i reported a bug with a pci bridge a while ago. On an Apu with a
 pci to pci bridge over pci express.
 Dmesg below
 
 I use a recent snapshot
 OpenBSD 5.6-current (GENERIC.MP) #610: Tue Nov 25 06:00:07 MST 2014
 
 and assume the commit was in
 
 The situation improved, as i can have the card running with bsd.mp for
 more than a second. But on the second boot.
 During the first boot i add the vr3: restarting kernel message when
 asking for a lease on vr3. At this moment my not reliable serial usb
 decide to do the classic freez. This time i was not able to get access
 to the machine.
 
 I am currently sending icmp trhough rl and vr and waiting for a problem.
 
 bug mail objet was : pci disconnection creates interfaces instabilities
 
 dmesg:
 
 
 OpenBSD 5.6-current (GENERIC.MP) #610: Tue Nov 25 06:00:07 MST 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 2098520064 (2001MB)
 avail mem = 2038870016 (1944MB)
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7e16d820 (7 entries)
 bios0: vendor coreboot version 4.0 date 09/08/2014
 bios0: PC Engines APU
 acpi0 at bios0: rev 0
 acpi0: sleep states S0 S1 S3 S4 S5
 acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
 acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4)
 PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3)
 UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) [...]
 acpitimer0 at acpi0: 3579545 Hz, 32 bits
 acpihpet0 at acpi0: 14318180 Hz
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: AMD G-T40E Processor, 1000.14 MHz
 cpu0: 
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
 cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
 64b/line 16-way L2 cache
 cpu0: 8 4MB entries fully associative
 cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
 cpu0: smt 0, core 0, package 0
 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
 cpu0: apic clock running at 200MHz
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: AMD G-T40E Processor, 1000.00 MHz
 cpu1: 
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
 cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
 64b/line 16-way L2 cache
 cpu1: 8 4MB entries fully associative
 cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
 cpu1: smt 0, core 1, package 0
 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
 acpiprt0 at acpi0: bus -1 (AGPB)
 acpiprt1 at acpi0: bus -1 (HDMI)
 acpiprt2 at acpi0: bus 1 (PBR4)
 acpiprt3 at acpi0: bus 2 (PBR5)
 acpiprt4 at acpi0: bus 3 (PBR6)
 acpiprt5 at acpi0: bus -1 (PBR7)
 acpiprt6 at acpi0: bus 5 (PE20)
 acpiprt7 at acpi0: bus -1 (PE21)
 acpiprt8 at acpi0: bus -1 (PE22)
 acpiprt9 at acpi0: bus -1 (PE23)
 acpiprt10 at acpi0: bus 0 (PCI0)
 acpiprt11 at acpi0: bus 4 (PIBR)
 acpicpu0 at acpi0: C2, PSS
 acpicpu1 at acpi0: C2, PSS
 acpibtn0 at acpi0: PWRB
 cpu0: 1000 MHz: speeds: 1000 800 MHz
 pci0 at mainbus0 bus 0
 pchb0 at pci0 dev 0 function 0 AMD AMD64 14h Host rev 0x00
 ppb0 at pci0 dev 4 function 0 AMD AMD64 14h PCIE rev 0x00: msi
 pci1 at ppb0 bus 1
 re0 at pci1 dev 0 function 0 Realtek 8168 rev 0x06: RTL8168E/8111E
 (0x2c00), msi, address 00:0d:b9:33:85:d8
 rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 4
 ppb1 at pci0 dev 5 function 0 AMD AMD64 14h PCIE rev 0x00: msi
 pci2 at ppb1 bus 2
 re1 at pci2 dev 0 function 0 Realtek 8168 rev 0x06: RTL8168E/8111E
 (0x2c00), msi, address 00:0d:b9:33:85:d9
 rgephy1 at re1 phy 7: RTL8169S/8110S PHY, rev. 4
 ppb2 at pci0 dev 6 function 0 AMD AMD64 14h PCIE rev 0x00: msi
 pci3 at ppb2 bus 3
 re2 at pci3 dev 0 function 0 Realtek 8168 rev 0x06: RTL8168E/8111E
 (0x2c00),

Re: 64-bit PCI bridge support: testers needed

2014-11-26 Thread sven falempin 
HEllo,

So i reported a bug with a pci bridge a while ago. On an Apu with a
pci to pci bridge over pci express.
Dmesg below

I use a recent snapshot
OpenBSD 5.6-current (GENERIC.MP) #610: Tue Nov 25 06:00:07 MST 2014

and assume the commit was in

The situation improved, as i can have the card running with bsd.mp for
more than a second. But on the second boot.
During the first boot i add the vr3: restarting kernel message when
asking for a lease on vr3. At this moment my not reliable serial usb
decide to do the classic freez. This time i was not able to get access
to the machine.

I am currently sending icmp trhough rl and vr and waiting for a problem.

bug mail objet was : pci disconnection creates interfaces instabilities

dmesg:


OpenBSD 5.6-current (GENERIC.MP) #610: Tue Nov 25 06:00:07 MST 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2098520064 (2001MB)
avail mem = 2038870016 (1944MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7e16d820 (7 entries)
bios0: vendor coreboot version 4.0 date 09/08/2014
bios0: PC Engines APU
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4)
PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3)
UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD G-T40E Processor, 1000.14 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD G-T40E Processor, 1000.00 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 16-way L2 cache
cpu1: 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
acpiprt0 at acpi0: bus -1 (AGPB)
acpiprt1 at acpi0: bus -1 (HDMI)
acpiprt2 at acpi0: bus 1 (PBR4)
acpiprt3 at acpi0: bus 2 (PBR5)
acpiprt4 at acpi0: bus 3 (PBR6)
acpiprt5 at acpi0: bus -1 (PBR7)
acpiprt6 at acpi0: bus 5 (PE20)
acpiprt7 at acpi0: bus -1 (PE21)
acpiprt8 at acpi0: bus -1 (PE22)
acpiprt9 at acpi0: bus -1 (PE23)
acpiprt10 at acpi0: bus 0 (PCI0)
acpiprt11 at acpi0: bus 4 (PIBR)
acpicpu0 at acpi0: C2, PSS
acpicpu1 at acpi0: C2, PSS
acpibtn0 at acpi0: PWRB
cpu0: 1000 MHz: speeds: 1000 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 AMD AMD64 14h Host rev 0x00
ppb0 at pci0 dev 4 function 0 AMD AMD64 14h PCIE rev 0x00: msi
pci1 at ppb0 bus 1
re0 at pci1 dev 0 function 0 Realtek 8168 rev 0x06: RTL8168E/8111E
(0x2c00), msi, address 00:0d:b9:33:85:d8
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 4
ppb1 at pci0 dev 5 function 0 AMD AMD64 14h PCIE rev 0x00: msi
pci2 at ppb1 bus 2
re1 at pci2 dev 0 function 0 Realtek 8168 rev 0x06: RTL8168E/8111E
(0x2c00), msi, address 00:0d:b9:33:85:d9
rgephy1 at re1 phy 7: RTL8169S/8110S PHY, rev. 4
ppb2 at pci0 dev 6 function 0 AMD AMD64 14h PCIE rev 0x00: msi
pci3 at ppb2 bus 3
re2 at pci3 dev 0 function 0 Realtek 8168 rev 0x06: RTL8168E/8111E
(0x2c00), msi, address 00:0d:b9:33:85:da
rgephy2 at re2 phy 7: RTL8169S/8110S PHY, rev. 4
ahci0 at pci0 dev 17 function 0 ATI SBx00 SATA rev 0x40: apic 2 int
19, AHCI 1.2
scsibus1 at ahci0: 32 targets
ohci0 at pci0 dev 18 function 0 ATI SB700 USB rev 0x00: apic 2 int
18, version 1.0, legacy support
ehci0 at pci0 dev 18 function 2 ATI SB700 USB2 rev 0x00: apic 2 int 17
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 ATI EHCI root hub rev 2.00/1.00 addr 1
ohci1 at pci0 dev 19 function 0 ATI SB700 USB rev 0x00: apic 2 int
18, version 1.0, legacy support
ehci1 at pci0 dev 19 function 2 ATI SB700 USB2 rev 0x00: apic 2 int 17
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 ATI EHCI root hub rev 2.00/1.00 addr 1
piixpm0 at pci0 dev 20 function 0 ATI SBx00 SMBus rev 0x42: polling
iic0 at piixpm0
pcib0 at pci0 dev 20 function 3 ATI SB700 ISA rev 0x40
ppb3 at pci0 dev 20 function 4 ATI SB600 PCI rev 0x40
pci4 at ppb3 bus 4
ohci2 at pci0 dev 20

Re: 64-bit PCI bridge support: testers needed

2014-11-26 Thread Mark Kettenis 
 From: sven falempin sven.falem...@gmail.com
 Date: Wed, 26 Nov 2014 10:10:51 -0500
 
 HEllo,
 
 So i reported a bug with a pci bridge a while ago. On an Apu with a
 pci to pci bridge over pci express.
 Dmesg below
 
 I use a recent snapshot
 OpenBSD 5.6-current (GENERIC.MP) #610: Tue Nov 25 06:00:07 MST 2014
 
 and assume the commit was in
 
 The situation improved, as i can have the card running with bsd.mp for
 more than a second. But on the second boot.
 During the first boot i add the vr3: restarting kernel message when
 asking for a lease on vr3. At this moment my not reliable serial usb
 decide to do the classic freez. This time i was not able to get access
 to the machine.

I don't expect this diff to make any difference on your machine.

64-bit PCI bridge support: testers needed

2014-11-20 Thread Mark Kettenis 
Hi All,

dlg@ managed to get access to a machine that actually uses 64-bit PCI
addresses behind a bridge.  This triggered some bugs in the so far
untested code.  Quelle suprprise!

I'd appreciate it if some people can verify that this doesn't break
other systems.  In particular I'm looking for testers on server-type
machines, both i386 and amd64.

Thanks,

Mark


Index: pci.c
===
RCS file: /cvs/src/sys/dev/pci/pci.c,v
retrieving revision 1.106
diff -u -p -r1.106 pci.c
--- pci.c   26 Oct 2014 16:18:42 -  1.106
+++ pci.c   20 Nov 2014 09:04:51 -
@@ -936,6 +936,12 @@ pci_reserve_resources(struct pci_attach_
blr = pci_conf_read(pc, tag, PPB_REG_PREFMEM);
base = (blr  0xfff0)  16;
limit = (blr  0xfff0) | 0x000f;
+#ifdef __LP64__
+   blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFBASE_HI32);
+   base |= ((uint64_t)blr)  32;
+   blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFLIM_HI32);
+   limit |= ((uint64_t)blr)  32;
+#endif
if (limit  base)
size = (limit - base + 1);
else
Index: ppb.c
===
RCS file: /cvs/src/sys/dev/pci/ppb.c,v
retrieving revision 1.59
diff -u -p -r1.59 ppb.c
--- ppb.c   15 Sep 2014 14:22:07 -  1.59
+++ ppb.c   20 Nov 2014 09:04:51 -
@@ -261,7 +261,7 @@ ppbattach(struct device *parent, struct 
name = malloc(32, M_DEVBUF, M_NOWAIT);
if (name) {
snprintf(name, 32, %s pcimem, sc-sc_dev.dv_xname);
-   sc-sc_memex = extent_create(name, 0, 0x,
+   sc-sc_memex = extent_create(name, 0, (u_long)-1L,
M_DEVBUF, NULL, 0, EX_NOWAIT | EX_FILLED);
extent_free(sc-sc_memex, sc-sc_membase,
sc-sc_memlimit - sc-sc_membase + 1,
@@ -273,7 +273,7 @@ ppbattach(struct device *parent, struct 
blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFMEM);
sc-sc_pmembase = (blr  0xfff0)  16;
sc-sc_pmemlimit = (blr  0xfff0) | 0x000f;
-#ifdef __LP64__/* XXX because extents use long... */
+#ifdef __LP64__
blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFBASE_HI32);
sc-sc_pmembase |= ((uint64_t)blr)  32;
blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFLIM_HI32);

Re: 64-bit PCI bridge support: testers needed

2014-11-20 Thread David Gwynne 
working on a 2950. will put try it on a r710 soon.

dlg

 On 20 Nov 2014, at 19:10, Mark Kettenis mark.kette...@xs4all.nl wrote:
 
 Hi All,
 
 dlg@ managed to get access to a machine that actually uses 64-bit PCI
 addresses behind a bridge.  This triggered some bugs in the so far
 untested code.  Quelle suprprise!
 
 I'd appreciate it if some people can verify that this doesn't break
 other systems.  In particular I'm looking for testers on server-type
 machines, both i386 and amd64.
 
 Thanks,
 
 Mark
 
 
 Index: pci.c
 ===
 RCS file: /cvs/src/sys/dev/pci/pci.c,v
 retrieving revision 1.106
 diff -u -p -r1.106 pci.c
 --- pci.c 26 Oct 2014 16:18:42 -  1.106
 +++ pci.c 20 Nov 2014 09:04:51 -
 @@ -936,6 +936,12 @@ pci_reserve_resources(struct pci_attach_
   blr = pci_conf_read(pc, tag, PPB_REG_PREFMEM);
   base = (blr  0xfff0)  16;
   limit = (blr  0xfff0) | 0x000f;
 +#ifdef __LP64__
 + blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFBASE_HI32);
 + base |= ((uint64_t)blr)  32;
 + blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFLIM_HI32);
 + limit |= ((uint64_t)blr)  32;
 +#endif
   if (limit  base)
   size = (limit - base + 1);
   else
 Index: ppb.c
 ===
 RCS file: /cvs/src/sys/dev/pci/ppb.c,v
 retrieving revision 1.59
 diff -u -p -r1.59 ppb.c
 --- ppb.c 15 Sep 2014 14:22:07 -  1.59
 +++ ppb.c 20 Nov 2014 09:04:51 -
 @@ -261,7 +261,7 @@ ppbattach(struct device *parent, struct 
   name = malloc(32, M_DEVBUF, M_NOWAIT);
   if (name) {
   snprintf(name, 32, %s pcimem, sc-sc_dev.dv_xname);
 - sc-sc_memex = extent_create(name, 0, 0x,
 + sc-sc_memex = extent_create(name, 0, (u_long)-1L,
   M_DEVBUF, NULL, 0, EX_NOWAIT | EX_FILLED);
   extent_free(sc-sc_memex, sc-sc_membase,
   sc-sc_memlimit - sc-sc_membase + 1,
 @@ -273,7 +273,7 @@ ppbattach(struct device *parent, struct 
   blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFMEM);
   sc-sc_pmembase = (blr  0xfff0)  16;
   sc-sc_pmemlimit = (blr  0xfff0) | 0x000f;
 -#ifdef __LP64__  /* XXX because extents use long... */
 +#ifdef __LP64__
   blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFBASE_HI32);
   sc-sc_pmembase |= ((uint64_t)blr)  32;
   blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFLIM_HI32);

Re: 64-bit PCI bridge support: testers needed

2014-11-20 Thread David Gwynne 
works on an alpha es45 as well. theo made me do it.

 On 21 Nov 2014, at 13:49, David Gwynne da...@gwynne.id.au wrote:
 
 working on a 2950. will put try it on a r710 soon.
 
 dlg
 
 On 20 Nov 2014, at 19:10, Mark Kettenis mark.kette...@xs4all.nl wrote:
 
 Hi All,
 
 dlg@ managed to get access to a machine that actually uses 64-bit PCI
 addresses behind a bridge.  This triggered some bugs in the so far
 untested code.  Quelle suprprise!
 
 I'd appreciate it if some people can verify that this doesn't break
 other systems.  In particular I'm looking for testers on server-type
 machines, both i386 and amd64.
 
 Thanks,
 
 Mark
 
 
 Index: pci.c
 ===
 RCS file: /cvs/src/sys/dev/pci/pci.c,v
 retrieving revision 1.106
 diff -u -p -r1.106 pci.c
 --- pci.c26 Oct 2014 16:18:42 -  1.106
 +++ pci.c20 Nov 2014 09:04:51 -
 @@ -936,6 +936,12 @@ pci_reserve_resources(struct pci_attach_
  blr = pci_conf_read(pc, tag, PPB_REG_PREFMEM);
  base = (blr  0xfff0)  16;
  limit = (blr  0xfff0) | 0x000f;
 +#ifdef __LP64__
 +blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFBASE_HI32);
 +base |= ((uint64_t)blr)  32;
 +blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFLIM_HI32);
 +limit |= ((uint64_t)blr)  32;
 +#endif
  if (limit  base)
  size = (limit - base + 1);
  else
 Index: ppb.c
 ===
 RCS file: /cvs/src/sys/dev/pci/ppb.c,v
 retrieving revision 1.59
 diff -u -p -r1.59 ppb.c
 --- ppb.c15 Sep 2014 14:22:07 -  1.59
 +++ ppb.c20 Nov 2014 09:04:51 -
 @@ -261,7 +261,7 @@ ppbattach(struct device *parent, struct 
  name = malloc(32, M_DEVBUF, M_NOWAIT);
  if (name) {
  snprintf(name, 32, %s pcimem, sc-sc_dev.dv_xname);
 -sc-sc_memex = extent_create(name, 0, 0x,
 +sc-sc_memex = extent_create(name, 0, (u_long)-1L,
  M_DEVBUF, NULL, 0, EX_NOWAIT | EX_FILLED);
  extent_free(sc-sc_memex, sc-sc_membase,
  sc-sc_memlimit - sc-sc_membase + 1,
 @@ -273,7 +273,7 @@ ppbattach(struct device *parent, struct 
  blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFMEM);
  sc-sc_pmembase = (blr  0xfff0)  16;
  sc-sc_pmemlimit = (blr  0xfff0) | 0x000f;
 -#ifdef __LP64__ /* XXX because extents use long... */
 +#ifdef __LP64__
  blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFBASE_HI32);
  sc-sc_pmembase |= ((uint64_t)blr)  32;
  blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFLIM_HI32);