Re: pmspcv panic on boot on this box
On Aug 4, 2015, at 6:13 PM, Glen Barber g...@freebsd.org wrote: On Mon, Aug 03, 2015 at 12:10:57PM -0500, Larry Rosenman wrote: Just to close this out, current -HEAD is fine on this box with pmspcv in GENERIC, and using that as my base. No nasty pmspcv messages. Sorry for the delayed reply. Again, Larry, thank you for your help with this - you very likely helped avoid a huge problem in 10.2-RELEASE. Warner, again, thank you for the quick fix. Sure thing. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: pmspcv panic on boot on this box
On 2015-08-04 19:13, Glen Barber wrote: On Mon, Aug 03, 2015 at 12:10:57PM -0500, Larry Rosenman wrote: Just to close this out, current -HEAD is fine on this box with pmspcv in GENERIC, and using that as my base. No nasty pmspcv messages. Sorry for the delayed reply. Again, Larry, thank you for your help with this - you very likely helped avoid a huge problem in 10.2-RELEASE. Warner, again, thank you for the quick fix. Glen My absolute pleasure. I enjoy helping :) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pmspcv panic on boot on this box
On Mon, Aug 03, 2015 at 12:10:57PM -0500, Larry Rosenman wrote: Just to close this out, current -HEAD is fine on this box with pmspcv in GENERIC, and using that as my base. No nasty pmspcv messages. Sorry for the delayed reply. Again, Larry, thank you for your help with this - you very likely helped avoid a huge problem in 10.2-RELEASE. Warner, again, thank you for the quick fix. Glen pgpFVSBZk9sf8.pgp Description: PGP signature
Re: pmspcv panic on boot on this box
Just to close this out, current -HEAD is fine on this box with pmspcv in GENERIC, and using that as my base. No nasty pmspcv messages. Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #17 r286232: Mon Aug 3 11:41:33 CDT 2015 r...@oldtbh.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 FreeBSD clang version 3.6.1 (tags/RELEASE_361/final 237755) 20150525 VT: running with driver vga. CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.57-MHz K8-class CPU) Origin=GenuineIntel Id=0xf43 Family=0xf Model=0x4 Stepping=3 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x641dSSE3,DTES64,MON,DS_CPL,CNXT-ID,CX16,xTPR AMD Features=0x20100800SYSCALL,NX,LM TSC: P-state invariant real memory = 9395240960 (8960 MB) avail memory = 8257851392 (7875 MB) Event timer LAPIC quality 400 ACPI APIC Table: PTLTD APIC FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP/HT): APIC ID: 7 random: unblocking device. ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard random: entropy device external interface kbd1 at kbdmux0 netmap: loaded module module_register_init: MOD_LOAD (vesa, 0x80fe15a0, 0) error 19 vtvga0: VT VGA driver on motherboard cryptosoft0: software crypto on motherboard acpi0: PTLTD RSDT on motherboard acpi0: Power Button (fixed) cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff irq 0,8 on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 Event timer HPET frequency 14318180 Hz quality 450 Event timer HPET1 frequency 14318180 Hz quality 440 Event timer HPET2 frequency 14318180 Hz quality 440 atrtc0: AT realtime clock port 0x70-0x77 on acpi0 Event timer RTC frequency 32768 Hz quality 0 attimer0: AT timer port 0x40-0x43 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: unknown at device 0.1 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1 pci2: ACPI PCI bus on pcib2 ahd0: Adaptec AIC7902 Ultra320 SCSI adapter port 0x2400-0x24ff,0x2000-0x20ff mem 0xdd20-0xdd201fff irq 32 at device 2.0 on pci2 aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133MHz, 512 SCBs ahd1: Adaptec AIC7902 Ultra320 SCSI adapter port 0x2c00-0x2cff,0x2800-0x28ff mem 0xdd202000-0xdd203fff irq 33 at device 2.1 on pci2 aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133MHz, 512 SCBs pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1 pci3: ACPI PCI bus on pcib3 em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.6 port 0x3000-0x303f mem 0xdd30-0xdd31 irq 54 at device 2.0 on pci3 em0: Ethernet address: 00:30:48:2e:99:ba em0: netmap queues/slots: TX 1/256, RX 1/256 em1: Intel(R) PRO/1000 Legacy Network Connection 1.0.6 port 0x3040-0x307f mem 0xdd32-0xdd33 irq 55 at device 2.1 on pci3 em1: Ethernet address: 00:30:48:2e:99:bb em1: netmap queues/slots: TX 1/256, RX 1/256 pcib4: ACPI PCI-PCI bridge irq 16 at device 4.0 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge irq 16 at device 6.0 on pci0 pci5: ACPI PCI bus on pcib5 uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0x1400-0x141f irq 16 at device 29.0 on pci0 usbus0 on uhci0 uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0x1420-0x143f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0x1440-0x145f irq 18 at device 29.2 on pci0 usbus2 on uhci2 uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0x1460-0x147f irq 16 at device 29.3 on pci0 usbus3 on uhci3 ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xdd001000-0xdd0013ff irq 23 at device 29.7 on pci0 usbus4: EHCI version 1.0 usbus4 on ehci0 pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0 pci6: ACPI PCI bus on pcib6 vgapci0: VGA-compatible display port 0x4000-0x40ff mem 0xde00-0xdeff,0xdd40-0xdd400fff irq 17 at device 1.0 on pci6 vgapci0: Boot video device isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH5 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x14a0-0x14af at device 31.1 on pci0 ata0: ATA channel at channel 0
Re: pmspcv panic on boot on this box
On 31/07/15 4:52 pm, Glen Barber wrote: On Fri, Jul 31, 2015 at 04:48:18AM +, mailingli...@debank.tv wrote: July 31 2015 4:21 PM, Glen Barber g...@freebsd.org wrote: On Fri, Jul 31, 2015 at 04:18:15AM +, Glen Barber wrote: On Thu, Jul 30, 2015 at 06:57:05PM -0500, Larry Rosenman wrote: On 2015-07-30 17:17, Glen Barber wrote: On Thu, Jul 30, 2015 at 03:20:46PM -0500, Larry Rosenman wrote: Kernel compiling -- give mr a bit and I'll boot it and make sure it comes up. Larry, have you had any luck with this patch applied? If it resolves your issue, I want to make sure it is included in the 10.2-RC2 build. Thanks. [...] There are 3 pictures from the CURRENT panic. it STILL fails. :( Larry, I am sorry this is causing headaches for you, and I certainly appreciate the prompt (and detailed) report, and assistance debugging this. Would you be able to try one more test case? I'm interested in the behavior without the 'nodevice pmsdrv' addition to your kernel configuration (effectively, removing the device from the GENERIC kernel), and *without* the patch provided from Benno? To be more specific on what I'm interested in, 'nodevice pmsdrv' and 'device pmsdrv' should *both* be removed from the kernel configuration, and the pms(4) should only be available as a .ko module. In particular, I'm interested in if ahd(4) attaches or if loader(8) auto-loads pms(4) after the PCI IDs are detected. As this issue also affects the upcoming 10.2-RELEASE, your willingness to help debug this is greatly appreciated, as you've tripped over something that would have caused a great deal of pain after 10.2 was release. I owe you several beers. Hi All, I've experienced the same bug although with a mvs(4) device on 10.2-PRERELEASE, once the pms driver is removed from the kernel config the problem disappears, I haven't had time to try the suggested patch as I only found this thread after removing the pms driver from the kernel. Thank you for the information (stripped from my reply). So, to be clear, you have 'device pmsdrv' removed from the kernel config, but the /boot/kernel/pmspcv.ko is still available to the system? Glen Glen, I removed the module from /boot/kernel to be sure it wasn't loaded. Rob Evers ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pmspcv panic on boot on this box
On 1/08/15 4:26 pm, Glen Barber wrote: On Sat, Aug 01, 2015 at 04:24:26PM +1200, mailinglists wrote: On 31/07/15 4:52 pm, Glen Barber wrote: So, to be clear, you have 'device pmsdrv' removed from the kernel config, but the /boot/kernel/pmspcv.ko is still available to the system? I removed the module from /boot/kernel to be sure it wasn't loaded. This does not help with debugging the *real* problem. Glen Glen, What would be most helpful to try? 1. rebuild kernel with 'pmsdrv' removed from kernel, install and reboot with the module present 2. patch the src tree (with the patches in the e-mail thread) and rebuild/install kernel (GENERIC) and reboot 3. anything else I will have an hour or two of free time later on so I could try and help out. Rob Evers ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pmspcv panic on boot on this box
On Sat, Aug 01, 2015 at 04:34:14PM +1200, mailinglists wrote: On 1/08/15 4:26 pm, Glen Barber wrote: On Sat, Aug 01, 2015 at 04:24:26PM +1200, mailinglists wrote: On 31/07/15 4:52 pm, Glen Barber wrote: So, to be clear, you have 'device pmsdrv' removed from the kernel config, but the /boot/kernel/pmspcv.ko is still available to the system? I removed the module from /boot/kernel to be sure it wasn't loaded. This does not help with debugging the *real* problem. Glen Glen, What would be most helpful to try? 1. rebuild kernel with 'pmsdrv' removed from kernel, install and reboot with the module present 2. patch the src tree (with the patches in the e-mail thread) and rebuild/install kernel (GENERIC) and reboot 3. anything else I will have an hour or two of free time later on so I could try and help out. There was an updated patch posted (in reply to this thread) that would be helpful if you could test. It's not the final version, but it is helpful to know (since you have a different storage controller driver affected) if it prevents the panic for you. Glen pgppjixXARRkm.pgp Description: PGP signature
Re: pmspcv panic on boot on this box
On Sat, Aug 01, 2015 at 04:24:26PM +1200, mailinglists wrote: On 31/07/15 4:52 pm, Glen Barber wrote: So, to be clear, you have 'device pmsdrv' removed from the kernel config, but the /boot/kernel/pmspcv.ko is still available to the system? I removed the module from /boot/kernel to be sure it wasn't loaded. This does not help with debugging the *real* problem. Glen pgpyjoKIpFOJO.pgp Description: PGP signature
Re: pmspcv panic on boot on this box
On Fri, Jul 31, 2015 at 05:27:22AM -0500, Larry Rosenman wrote: Ok, I made a GENERIC-NOPMS, without the device pmspcv, and adjusted my custom to include GENERIC-NOPMS. And we boot (I'm typing this from a ssh session to the box). Larry, thank you very much for testing this. Benno, for 10.2-RELEASE, I think we're going to pull pmspcv from GENERIC and issue an EN for the driver update when this is fixed. I think this should be pulled from GENERIC in head and stable/10 in the meantime, as well. Glen pgpTjLW2NaCTM.pgp Description: PGP signature
Re: pmspcv panic on boot on this box
Please do pull it from GENERIC until this is fixed in HEAD and RELENG/10. On July 31, 2015 8:32:17 AM Glen Barber g...@freebsd.org wrote: On Fri, Jul 31, 2015 at 05:27:22AM -0500, Larry Rosenman wrote: Ok, I made a GENERIC-NOPMS, without the device pmspcv, and adjusted my custom to include GENERIC-NOPMS. And we boot (I'm typing this from a ssh session to the box). Larry, thank you very much for testing this. Benno, for 10.2-RELEASE, I think we're going to pull pmspcv from GENERIC and issue an EN for the driver update when this is fixed. I think this should be pulled from GENERIC in head and stable/10 in the meantime, as well. Glen ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pmspcv panic on boot on this box
I'm getting ready to commit to head and stable/10 now, and will also update releng/10.2 and restart the -RC2 builds with the change. Glen On Fri, Jul 31, 2015 at 09:41:39AM -0500, Larry Rosenman wrote: Please do pull it from GENERIC until this is fixed in HEAD and RELENG/10. On July 31, 2015 8:32:17 AM Glen Barber g...@freebsd.org wrote: On Fri, Jul 31, 2015 at 05:27:22AM -0500, Larry Rosenman wrote: Ok, I made a GENERIC-NOPMS, without the device pmspcv, and adjusted my custom to include GENERIC-NOPMS. And we boot (I'm typing this from a ssh session to the box). Larry, thank you very much for testing this. Benno, for 10.2-RELEASE, I think we're going to pull pmspcv from GENERIC and issue an EN for the driver update when this is fixed. I think this should be pulled from GENERIC in head and stable/10 in the meantime, as well. Glen pgpJQTK3sQqPp.pgp Description: PGP signature
Re: pmspcv panic on boot on this box
Try the following patch. There’s a fundamental misunderstanding of newbus
that’s screwing things up…
Also available at http://people.freebsd.org/~imp/patch-queue/pms
The problem is that the first time through for ahd0 we’re setting cardMap[0] to
5. The second time through it is already 5, so we say ‘oh, this has been
probed before’ and return 2. This causes antiapi_probe() to return 0, because
the card has already been probed before. This is wrong on so many levels, but
I’ll suppress channelling my inner bde and stop here.
Warner
diff -r 1805eb187340 sys/dev/pms/freebsd/driver/common/lxutil.c
--- a/sys/dev/pms/freebsd/driver/common/lxutil.c
+++ b/sys/dev/pms/freebsd/driver/common/lxutil.c
@@ -757,18 +757,25 @@ STATIC int agtiapi_ProbeCard( device_t d
{
int idx;
static U32 cardMap[4] = { 0, 0, 0, 0 };
+ u_int16_t agtiapi_vendor; // PCI vendor ID
u_int16_t agtiapi_dev; // PCI device ID
AGTIAPI_PRINTK(agtiapi_ProbeCard: start\n);
+#if 0
if ( ! atomic_cmpset_32( cardMap[thisCard], 0, 5 ) ) { // card already ran
AGTIAPI_PRINTK( We'll only ID this card once -- %d\n, thisCard );
return 2; // error return value; card already ran this function
}
else {
+#else
+ {
+#endif
+agtiapi_vendor = pci_get_vendor( dev ); // get PCI vendor ID
agtiapi_dev = pci_get_device( dev ); // get PCI device ID
for( idx = 0; idx COUNT(ag_card_type); idx++ )
{
- if( ag_card_type[idx].deviceId == agtiapi_dev )
+ if( ag_card_type[idx].deviceId == agtiapi_dev
+ ag_card_type[idx].vendorId == agtiapi_vendor)
{ // device ID match
memset( (void *)agCardInfoList[ thisCard ], 0,
sizeof(ag_card_info_t) );
On Jul 31, 2015, at 8:41 AM, Larry Rosenman l...@lerctr.org wrote:
Please do pull it from GENERIC until this is fixed in HEAD and RELENG/10.
On July 31, 2015 8:32:17 AM Glen Barber g...@freebsd.org wrote:
On Fri, Jul 31, 2015 at 05:27:22AM -0500, Larry Rosenman wrote:
Ok, I made a GENERIC-NOPMS, without the device pmspcv, and adjusted my
custom
to include GENERIC-NOPMS. And we boot (I'm typing this from a ssh session
to the box).
Larry, thank you very much for testing this.
Benno, for 10.2-RELEASE, I think we're going to pull pmspcv from GENERIC
and issue an EN for the driver update when this is fixed.
I think this should be pulled from GENERIC in head and stable/10 in the
meantime, as well.
Glen
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: pmspcv panic on boot on this box
Is this with or without Benno's patch?
On July 31, 2015 12:24:11 PM Warner Losh i...@bsdimp.com wrote:
Try the following patch. There’s a fundamental misunderstanding of newbus
that’s screwing things up…
Also available at http://people.freebsd.org/~imp/patch-queue/pms
The problem is that the first time through for ahd0 we’re setting
cardMap[0] to 5. The second time through it is already 5, so we say ‘oh,
this has been probed before’ and return 2. This causes antiapi_probe() to
return 0, because the card has already been probed before. This is wrong on
so many levels, but I’ll suppress channelling my inner bde and stop here.
Warner
diff -r 1805eb187340 sys/dev/pms/freebsd/driver/common/lxutil.c
--- a/sys/dev/pms/freebsd/driver/common/lxutil.c
+++ b/sys/dev/pms/freebsd/driver/common/lxutil.c
@@ -757,18 +757,25 @@ STATIC int agtiapi_ProbeCard( device_t d
{
int idx;
static U32 cardMap[4] = { 0, 0, 0, 0 };
+ u_int16_t agtiapi_vendor; // PCI vendor ID
u_int16_t agtiapi_dev; // PCI device ID
AGTIAPI_PRINTK(agtiapi_ProbeCard: start\n);
+#if 0
if ( ! atomic_cmpset_32( cardMap[thisCard], 0, 5 ) ) { // card already ran
AGTIAPI_PRINTK( We'll only ID this card once -- %d\n, thisCard );
return 2; // error return value; card already ran this function
}
else {
+#else
+ {
+#endif
+agtiapi_vendor = pci_get_vendor( dev ); // get PCI vendor ID
agtiapi_dev = pci_get_device( dev ); // get PCI device ID
for( idx = 0; idx COUNT(ag_card_type); idx++ )
{
- if( ag_card_type[idx].deviceId == agtiapi_dev )
+ if( ag_card_type[idx].deviceId == agtiapi_dev
+ ag_card_type[idx].vendorId == agtiapi_vendor)
{ // device ID match
memset( (void *)agCardInfoList[ thisCard ], 0,
sizeof(ag_card_info_t) );
On Jul 31, 2015, at 8:41 AM, Larry Rosenman l...@lerctr.org wrote:
Please do pull it from GENERIC until this is fixed in HEAD and RELENG/10.
On July 31, 2015 8:32:17 AM Glen Barber g...@freebsd.org wrote:
On Fri, Jul 31, 2015 at 05:27:22AM -0500, Larry Rosenman wrote:
Ok, I made a GENERIC-NOPMS, without the device pmspcv, and adjusted my
custom
to include GENERIC-NOPMS. And we boot (I'm typing this from a ssh
session
to the box).
Larry, thank you very much for testing this.
Benno, for 10.2-RELEASE, I think we're going to pull pmspcv from GENERIC
and issue an EN for the driver update when this is fixed.
I think this should be pulled from GENERIC in head and stable/10 in the
meantime, as well.
Glen
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pmspcv panic on boot on this box
It replaces it.
Or you could just add the #if 0 bits to remove the atomic_cmpset_32 from the
picture entirely.
All this state saving should be done in attach anyway, so it is mis-located
here… But the current
patch will tell me if my theory of the crime is correct and offer a path
forward...
Warner
On Jul 31, 2015, at 11:52 AM, Larry Rosenman l...@lerctr.org wrote:
Is this with or without Benno's patch?
On July 31, 2015 12:24:11 PM Warner Losh i...@bsdimp.com wrote:
Try the following patch. There’s a fundamental misunderstanding of newbus
that’s screwing things up…
Also available at http://people.freebsd.org/~imp/patch-queue/pms
The problem is that the first time through for ahd0 we’re setting cardMap[0]
to 5. The second time through it is already 5, so we say ‘oh, this has been
probed before’ and return 2. This causes antiapi_probe() to return 0,
because the card has already been probed before. This is wrong on so many
levels, but I’ll suppress channelling my inner bde and stop here.
Warner
diff -r 1805eb187340 sys/dev/pms/freebsd/driver/common/lxutil.c
--- a/sys/dev/pms/freebsd/driver/common/lxutil.c
+++ b/sys/dev/pms/freebsd/driver/common/lxutil.c
@@ -757,18 +757,25 @@ STATIC int agtiapi_ProbeCard( device_t d
{
int idx;
static U32 cardMap[4] = { 0, 0, 0, 0 };
+ u_int16_t agtiapi_vendor; // PCI vendor ID
u_int16_t agtiapi_dev; // PCI device ID
AGTIAPI_PRINTK(agtiapi_ProbeCard: start\n);
+#if 0
if ( ! atomic_cmpset_32( cardMap[thisCard], 0, 5 ) ) { // card already ran
AGTIAPI_PRINTK( We'll only ID this card once -- %d\n, thisCard );
return 2; // error return value; card already ran this function
}
else {
+#else
+ {
+#endif
+agtiapi_vendor = pci_get_vendor( dev ); // get PCI vendor ID
agtiapi_dev = pci_get_device( dev ); // get PCI device ID
for( idx = 0; idx COUNT(ag_card_type); idx++ )
{
- if( ag_card_type[idx].deviceId == agtiapi_dev )
+ if( ag_card_type[idx].deviceId == agtiapi_dev
+ ag_card_type[idx].vendorId == agtiapi_vendor)
{ // device ID match
memset( (void *)agCardInfoList[ thisCard ], 0,
sizeof(ag_card_info_t) );
On Jul 31, 2015, at 8:41 AM, Larry Rosenman l...@lerctr.org wrote:
Please do pull it from GENERIC until this is fixed in HEAD and RELENG/10.
On July 31, 2015 8:32:17 AM Glen Barber g...@freebsd.org wrote:
On Fri, Jul 31, 2015 at 05:27:22AM -0500, Larry Rosenman wrote:
Ok, I made a GENERIC-NOPMS, without the device pmspcv, and adjusted my
custom
to include GENERIC-NOPMS. And we boot (I'm typing this from a ssh
session
to the box).
Larry, thank you very much for testing this.
Benno, for 10.2-RELEASE, I think we're going to pull pmspcv from GENERIC
and issue an EN for the driver update when this is fixed.
I think this should be pulled from GENERIC in head and stable/10 in the
meantime, as well.
Glen
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: pmspcv panic on boot on this box
On 2015-07-31 15:44, Glen Barber wrote: On Fri, Jul 31, 2015 at 03:41:37PM -0500, Larry Rosenman wrote: We have a winner -- rebuilt with just this patch, and GENERIC with pmspcv, and we boot. Larry, thank you so much for your willingness to test this. It is greatly appreciated. Glen Absolutely my pleasure. I appreciate ALL that the re@ and developers folks do for FreeBSD. Best OS ever :) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pmspcv panic on boot on this box
On Fri, Jul 31, 2015 at 03:41:37PM -0500, Larry Rosenman wrote: We have a winner -- rebuilt with just this patch, and GENERIC with pmspcv, and we boot. Larry, thank you so much for your willingness to test this. It is greatly appreciated. Glen pgpxqgmxk674m.pgp Description: PGP signature
Re: pmspcv panic on boot on this box
We have a winner -- rebuilt with just this patch, and GENERIC with pmspcv,
and we boot.
On Fri, Jul 31, 2015 at 12:03:27PM -0600, Warner Losh wrote:
It replaces it.
Or you could just add the #if 0 bits to remove the atomic_cmpset_32 from the
picture entirely.
All this state saving should be done in attach anyway, so it is mis-located
here? But the current
patch will tell me if my theory of the crime is correct and offer a path
forward...
Warner
On Jul 31, 2015, at 11:52 AM, Larry Rosenman l...@lerctr.org wrote:
Is this with or without Benno's patch?
On July 31, 2015 12:24:11 PM Warner Losh i...@bsdimp.com wrote:
Try the following patch. There?s a fundamental misunderstanding of newbus
that?s screwing things up?
Also available at http://people.freebsd.org/~imp/patch-queue/pms
The problem is that the first time through for ahd0 we?re setting
cardMap[0] to 5. The second time through it is already 5, so we say ?oh,
this has been probed before? and return 2. This causes antiapi_probe() to
return 0, because the card has already been probed before. This is wrong
on so many levels, but I?ll suppress channelling my inner bde and stop
here.
Warner
diff -r 1805eb187340 sys/dev/pms/freebsd/driver/common/lxutil.c
--- a/sys/dev/pms/freebsd/driver/common/lxutil.c
+++ b/sys/dev/pms/freebsd/driver/common/lxutil.c
@@ -757,18 +757,25 @@ STATIC int agtiapi_ProbeCard( device_t d
{
int idx;
static U32 cardMap[4] = { 0, 0, 0, 0 };
+ u_int16_t agtiapi_vendor; // PCI vendor ID
u_int16_t agtiapi_dev; // PCI device ID
AGTIAPI_PRINTK(agtiapi_ProbeCard: start\n);
+#if 0
if ( ! atomic_cmpset_32( cardMap[thisCard], 0, 5 ) ) { // card already
ran
AGTIAPI_PRINTK( We'll only ID this card once -- %d\n, thisCard );
return 2; // error return value; card already ran this function
}
else {
+#else
+ {
+#endif
+agtiapi_vendor = pci_get_vendor( dev ); // get PCI vendor ID
agtiapi_dev = pci_get_device( dev ); // get PCI device ID
for( idx = 0; idx COUNT(ag_card_type); idx++ )
{
- if( ag_card_type[idx].deviceId == agtiapi_dev )
+ if( ag_card_type[idx].deviceId == agtiapi_dev
+ag_card_type[idx].vendorId == agtiapi_vendor)
{ // device ID match
memset( (void *)agCardInfoList[ thisCard ], 0,
sizeof(ag_card_info_t) );
On Jul 31, 2015, at 8:41 AM, Larry Rosenman l...@lerctr.org wrote:
Please do pull it from GENERIC until this is fixed in HEAD and
RELENG/10.
On July 31, 2015 8:32:17 AM Glen Barber g...@freebsd.org wrote:
On Fri, Jul 31, 2015 at 05:27:22AM -0500, Larry Rosenman wrote:
Ok, I made a GENERIC-NOPMS, without the device pmspcv, and adjusted
my custom
to include GENERIC-NOPMS. And we boot (I'm typing this from a ssh
session
to the box).
Larry, thank you very much for testing this.
Benno, for 10.2-RELEASE, I think we're going to pull pmspcv from GENERIC
and issue an EN for the driver update when this is fixed.
I think this should be pulled from GENERIC in head and stable/10 in the
meantime, as well.
Glen
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
Copyright (c) 1992-2015 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #16 r285990M: Fri Jul 31 15:31:38 CDT 2015
r...@oldtbh.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64
FreeBSD clang version 3.6.1 (tags/RELEASE_361/final 237755) 20150525
VT: running with driver vga.
CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.56-MHz K8-class CPU)
Origin=GenuineIntel Id=0xf43 Family=0xf Model=0x4 Stepping=3
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Features2=0x641dSSE3,DTES64,MON,DS_CPL,CNXT-ID,CX16,xTPR
AMD Features=0x20100800SYSCALL,NX,LM
TSC: P-state invariant
real memory = 9395240960 (8960 MB)
avail memory = 8257855488 (7875 MB)
Event timer LAPIC quality 400
ACPI APIC Table: PTLTD APIC
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s) x 2 HTT threads
cpu0 (BSP): APIC ID: 0
cpu1 (AP/HT): APIC ID: 1
cpu2 (AP): APIC ID: 6
cpu3 (AP/HT): APIC ID: 7
random: unblocking device.
ioapic0 Version 2.0 irqs 0-23 on motherboard
ioapic1 Version 2.0 irqs 24-47 on motherboard
ioapic2 Version 2.0 irqs 48-71 on motherboard
random: entropy device external interface
kbd1 at kbdmux0
netmap: loaded module
module_register_init: MOD_LOAD
Re: pmspcv panic on boot on this box
On Jul 31, 2015, at 3:32 PM, Glen Barber g...@freebsd.org wrote: On Fri, Jul 31, 2015 at 03:11:15PM -0600, Warner Losh wrote: On Jul 31, 2015, at 2:46 PM, Larry Rosenman l...@lerctr.org wrote: On 2015-07-31 15:44, Glen Barber wrote: On Fri, Jul 31, 2015 at 03:41:37PM -0500, Larry Rosenman wrote: We have a winner -- rebuilt with just this patch, and GENERIC with pmspcv, and we boot. Larry, thank you so much for your willingness to test this. It is greatly appreciated. Glen Absolutely my pleasure. I appreciate ALL that the re@ and developers folks do for FreeBSD. Best OS ever :) Thanks Larry. I’ll cleanup the patch (I’d never knowing commit #if 0 w/o a good reason) and get it reviewed. The good news is that we can make a fairly low-risk patch for 10.2R I think, subject to the blessings of our benevolent re@ overlords... My gut instinct is to leave the driver in 10.2 as-is for now, as I'd like to make sure this driver does not present more pain (and certainly before being re-enabled in GENERIC on stable/10), since this situation could have been much more of a disaster. Personally, I'd like to keep it out of GENERIC on stable/10 for at least a month, while things get shaken out in head. That said, once the issues are flushed out, re@ will be happy to issue an EN for 10.2 to resolve the existing (and any new) issues with this. You’re the boss. I can understand the skepticism given how badly the current code misunderstands newbus. This instance is quite easy to fix (I should have something in -current in a day or two). Fortunately, the series of errors would only cause a problem if you had two Adaptec devices in your system (and not just one). Since it is available as a module, perhaps a note explaining there was a problem with the auto-probing code so it was omitted from GENERIC, but if you have one of these devices put pms_load=YES in your loader.conf file. But only if you don’t have any other devices with the Adaptec vendor ID (since if you want to load pms, it is because you presumably have one of these cards). The path to doom is the second trip into probe after the first trip into probe failed. I’d be inclined to take a middle ground and fix the driver (and therefore the module) in 10.2R, but not put it in GENERIC until 10.3, but hey that’s just me. Interested parties should check out https://reviews.freebsd.org/D3263 for correctness or for testing. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: pmspcv panic on boot on this box
I'll try it when I get back to Austin tomorrow.
On July 31, 2015 1:03:43 PM Warner Losh i...@bsdimp.com wrote:
It replaces it.
Or you could just add the #if 0 bits to remove the atomic_cmpset_32 from
the picture entirely.
All this state saving should be done in attach anyway, so it is mis-located
here… But the current
patch will tell me if my theory of the crime is correct and offer a path
forward...
Warner
On Jul 31, 2015, at 11:52 AM, Larry Rosenman l...@lerctr.org wrote:
Is this with or without Benno's patch?
On July 31, 2015 12:24:11 PM Warner Losh i...@bsdimp.com wrote:
Try the following patch. There’s a fundamental misunderstanding of
newbus that’s screwing things up…
Also available at http://people.freebsd.org/~imp/patch-queue/pms
The problem is that the first time through for ahd0 we’re setting
cardMap[0] to 5. The second time through it is already 5, so we say ‘oh,
this has been probed before’ and return 2. This causes antiapi_probe() to
return 0, because the card has already been probed before. This is wrong on
so many levels, but I’ll suppress channelling my inner bde and stop here.
Warner
diff -r 1805eb187340 sys/dev/pms/freebsd/driver/common/lxutil.c
--- a/sys/dev/pms/freebsd/driver/common/lxutil.c
+++ b/sys/dev/pms/freebsd/driver/common/lxutil.c
@@ -757,18 +757,25 @@ STATIC int agtiapi_ProbeCard( device_t d
{
int idx;
static U32 cardMap[4] = { 0, 0, 0, 0 };
+ u_int16_t agtiapi_vendor; // PCI vendor ID
u_int16_t agtiapi_dev; // PCI device ID
AGTIAPI_PRINTK(agtiapi_ProbeCard: start\n);
+#if 0
if ( ! atomic_cmpset_32( cardMap[thisCard], 0, 5 ) ) { // card
already ran
AGTIAPI_PRINTK( We'll only ID this card once -- %d\n, thisCard );
return 2; // error return value; card already ran this function
}
else {
+#else
+ {
+#endif
+agtiapi_vendor = pci_get_vendor( dev ); // get PCI vendor ID
agtiapi_dev = pci_get_device( dev ); // get PCI device ID
for( idx = 0; idx COUNT(ag_card_type); idx++ )
{
- if( ag_card_type[idx].deviceId == agtiapi_dev )
+ if( ag_card_type[idx].deviceId == agtiapi_dev
+ag_card_type[idx].vendorId == agtiapi_vendor)
{ // device ID match
memset( (void *)agCardInfoList[ thisCard ], 0,
sizeof(ag_card_info_t) );
On Jul 31, 2015, at 8:41 AM, Larry Rosenman l...@lerctr.org wrote:
Please do pull it from GENERIC until this is fixed in HEAD and RELENG/10.
On July 31, 2015 8:32:17 AM Glen Barber g...@freebsd.org wrote:
On Fri, Jul 31, 2015 at 05:27:22AM -0500, Larry Rosenman wrote:
Ok, I made a GENERIC-NOPMS, without the device pmspcv, and adjusted
my custom
to include GENERIC-NOPMS. And we boot (I'm typing this from a ssh
session
to the box).
Larry, thank you very much for testing this.
Benno, for 10.2-RELEASE, I think we're going to pull pmspcv from GENERIC
and issue an EN for the driver update when this is fixed.
I think this should be pulled from GENERIC in head and stable/10 in the
meantime, as well.
Glen
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pmspcv panic on boot on this box
On Jul 31, 2015, at 2:46 PM, Larry Rosenman l...@lerctr.org wrote: On 2015-07-31 15:44, Glen Barber wrote: On Fri, Jul 31, 2015 at 03:41:37PM -0500, Larry Rosenman wrote: We have a winner -- rebuilt with just this patch, and GENERIC with pmspcv, and we boot. Larry, thank you so much for your willingness to test this. It is greatly appreciated. Glen Absolutely my pleasure. I appreciate ALL that the re@ and developers folks do for FreeBSD. Best OS ever :) Thanks Larry. I’ll cleanup the patch (I’d never knowing commit #if 0 w/o a good reason) and get it reviewed. The good news is that we can make a fairly low-risk patch for 10.2R I think, subject to the blessings of our benevolent re@ overlords... Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: pmspcv panic on boot on this box
On Fri, Jul 31, 2015 at 03:11:15PM -0600, Warner Losh wrote: On Jul 31, 2015, at 2:46 PM, Larry Rosenman l...@lerctr.org wrote: On 2015-07-31 15:44, Glen Barber wrote: On Fri, Jul 31, 2015 at 03:41:37PM -0500, Larry Rosenman wrote: We have a winner -- rebuilt with just this patch, and GENERIC with pmspcv, and we boot. Larry, thank you so much for your willingness to test this. It is greatly appreciated. Glen Absolutely my pleasure. I appreciate ALL that the re@ and developers folks do for FreeBSD. Best OS ever :) Thanks Larry. I’ll cleanup the patch (I’d never knowing commit #if 0 w/o a good reason) and get it reviewed. The good news is that we can make a fairly low-risk patch for 10.2R I think, subject to the blessings of our benevolent re@ overlords... My gut instinct is to leave the driver in 10.2 as-is for now, as I'd like to make sure this driver does not present more pain (and certainly before being re-enabled in GENERIC on stable/10), since this situation could have been much more of a disaster. Personally, I'd like to keep it out of GENERIC on stable/10 for at least a month, while things get shaken out in head. That said, once the issues are flushed out, re@ will be happy to issue an EN for 10.2 to resolve the existing (and any new) issues with this. Glen pgpvmQsbE3FZV.pgp Description: PGP signature
Re: pmspcv panic on boot on this box
On Fri, Jul 31, 2015 at 01:33:32AM -0500, Larry Rosenman wrote: On 2015-07-30 23:21, Glen Barber wrote: On Fri, Jul 31, 2015 at 04:18:15AM +, Glen Barber wrote: On Thu, Jul 30, 2015 at 06:57:05PM -0500, Larry Rosenman wrote: On 2015-07-30 17:17, Glen Barber wrote: On Thu, Jul 30, 2015 at 03:20:46PM -0500, Larry Rosenman wrote: Kernel compiling -- give mr a bit and I'll boot it and make sure it comes up. Larry, have you had any luck with this patch applied? If it resolves your issue, I want to make sure it is included in the 10.2-RC2 build. Thanks. [...] There are 3 pictures from the CURRENT panic. it STILL fails. :( Larry, I am sorry this is causing headaches for you, and I certainly appreciate the prompt (and detailed) report, and assistance debugging this. Would you be able to try one more test case? I'm interested in the behavior without the 'nodevice pmsdrv' addition to your kernel configuration (effectively, removing the device from the GENERIC kernel), and *without* the patch provided from Benno? To be more specific on what I'm interested in, 'nodevice pmsdrv' and 'device pmsdrv' should *both* be removed from the kernel configuration, and the pms(4) should only be available as a .ko module. In particular, I'm interested in if ahd(4) attaches or if loader(8) auto-loads pms(4) after the PCI IDs are detected. As this issue also affects the upcoming 10.2-RELEASE, your willingness to help debug this is greatly appreciated, as you've tripped over something that would have caused a great deal of pain after 10.2 was release. I owe you several beers. Glen My kernel is based on GENERIC (I.E. include GENERIC). With the nodedevice pmspcv, after boot, if I kldload pmspcv, NO PANIC. Okay. I'm interested in the behavior if the pmspcv is removed entirely (no 'nodevice' or 'device' entry). Unfortunately, I've got a funeral to go to in Dallas (~150Mi away from home) today, Friday, and will not be back until late Saturday (US/CDT, GMT-5). My condolences. :( I'm going to be occupied testing the 10.2-RC2 (while taking into account the pms(4) issue), so no worries regarding getting back to me. There was another report as well, so I'll parallelize as needed. I can probably help someone with this on Sunday, but would appreciate a real-tome conversation, as the box in question is at a COLO facility, and does NOT have IPMI, so I need to be physically there. Where in the world are you located, Glen? I'm in Pennsylvania. I'll email you my phone number off-list when you return if that is helpful for debugging, and we can try to streamline this. Deal with the non-computer stuff first though, please. Glen pgpZWbFACqc7S.pgp Description: PGP signature
Re: pmspcv panic on boot on this box
On 2015-07-30 23:21, Glen Barber wrote: On Fri, Jul 31, 2015 at 04:18:15AM +, Glen Barber wrote: On Thu, Jul 30, 2015 at 06:57:05PM -0500, Larry Rosenman wrote: On 2015-07-30 17:17, Glen Barber wrote: On Thu, Jul 30, 2015 at 03:20:46PM -0500, Larry Rosenman wrote: Kernel compiling -- give mr a bit and I'll boot it and make sure it comes up. Larry, have you had any luck with this patch applied? If it resolves your issue, I want to make sure it is included in the 10.2-RC2 build. Thanks. [...] There are 3 pictures from the CURRENT panic. it STILL fails. :( Larry, I am sorry this is causing headaches for you, and I certainly appreciate the prompt (and detailed) report, and assistance debugging this. Would you be able to try one more test case? I'm interested in the behavior without the 'nodevice pmsdrv' addition to your kernel configuration (effectively, removing the device from the GENERIC kernel), and *without* the patch provided from Benno? To be more specific on what I'm interested in, 'nodevice pmsdrv' and 'device pmsdrv' should *both* be removed from the kernel configuration, and the pms(4) should only be available as a .ko module. In particular, I'm interested in if ahd(4) attaches or if loader(8) auto-loads pms(4) after the PCI IDs are detected. As this issue also affects the upcoming 10.2-RELEASE, your willingness to help debug this is greatly appreciated, as you've tripped over something that would have caused a great deal of pain after 10.2 was release. I owe you several beers. Glen My kernel is based on GENERIC (I.E. include GENERIC). With the nodedevice pmspcv, after boot, if I kldload pmspcv, NO PANIC. Unfortunately, I've got a funeral to go to in Dallas (~150Mi away from home) today, Friday, and will not be back until late Saturday (US/CDT, GMT-5). I can probably help someone with this on Sunday, but would appreciate a real-tome conversation, as the box in question is at a COLO facility, and does NOT have IPMI, so I need to be physically there. Where in the world are you located, Glen? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pmspcv panic on boot on this box
On Fri, Jul 31, 2015 at 06:50:16AM +, Glen Barber wrote: On Fri, Jul 31, 2015 at 01:33:32AM -0500, Larry Rosenman wrote: On 2015-07-30 23:21, Glen Barber wrote: On Fri, Jul 31, 2015 at 04:18:15AM +, Glen Barber wrote: On Thu, Jul 30, 2015 at 06:57:05PM -0500, Larry Rosenman wrote: On 2015-07-30 17:17, Glen Barber wrote: On Thu, Jul 30, 2015 at 03:20:46PM -0500, Larry Rosenman wrote: Kernel compiling -- give mr a bit and I'll boot it and make sure it comes up. Larry, have you had any luck with this patch applied? If it resolves your issue, I want to make sure it is included in the 10.2-RC2 build. Thanks. [...] There are 3 pictures from the CURRENT panic. it STILL fails. :( Larry, I am sorry this is causing headaches for you, and I certainly appreciate the prompt (and detailed) report, and assistance debugging this. Would you be able to try one more test case? I'm interested in the behavior without the 'nodevice pmsdrv' addition to your kernel configuration (effectively, removing the device from the GENERIC kernel), and *without* the patch provided from Benno? To be more specific on what I'm interested in, 'nodevice pmsdrv' and 'device pmsdrv' should *both* be removed from the kernel configuration, and the pms(4) should only be available as a .ko module. In particular, I'm interested in if ahd(4) attaches or if loader(8) auto-loads pms(4) after the PCI IDs are detected. As this issue also affects the upcoming 10.2-RELEASE, your willingness to help debug this is greatly appreciated, as you've tripped over something that would have caused a great deal of pain after 10.2 was release. I owe you several beers. Glen My kernel is based on GENERIC (I.E. include GENERIC). With the nodedevice pmspcv, after boot, if I kldload pmspcv, NO PANIC. Okay. I'm interested in the behavior if the pmspcv is removed entirely (no 'nodevice' or 'device' entry). Unfortunately, I've got a funeral to go to in Dallas (~150Mi away from home) today, Friday, and will not be back until late Saturday (US/CDT, GMT-5). My condolences. :( I'm going to be occupied testing the 10.2-RC2 (while taking into account the pms(4) issue), so no worries regarding getting back to me. There was another report as well, so I'll parallelize as needed. I can probably help someone with this on Sunday, but would appreciate a real-tome conversation, as the box in question is at a COLO facility, and does NOT have IPMI, so I need to be physically there. Where in the world are you located, Glen? I'm in Pennsylvania. I'll email you my phone number off-list when you return if that is helpful for debugging, and we can try to streamline this. Deal with the non-computer stuff first though, please. Glen Ok, I made a GENERIC-NOPMS, without the device pmspcv, and adjusted my custom to include GENERIC-NOPMS. And we boot (I'm typing this from a ssh session to the box). Included: the GENERIC-NOPMS, my custom VT-LER, dmesg.boot. pciconf -lv: hostb0@pci0:0:0:0: class=0x06 card=0x658015d9 chip=0x35908086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'E7520 Memory Controller Hub' class = bridge subclass = HOST-PCI none0@pci0:0:0:1: class=0xff card=0x658015d9 chip=0x35918086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'E7525/E7520 Error Reporting Registers' none1@pci0:0:1:0: class=0x088000 card=0x658015d9 chip=0x35948086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'E7520 DMA Controller' class = base peripheral pcib1@pci0:0:2:0: class=0x060400 card=0x chip=0x35958086 rev=0x0c hdr=0x01 vendor = 'Intel Corporation' device = 'E7525/E7520/E7320 PCI Express Port A' class = bridge subclass = PCI-PCI pcib4@pci0:0:4:0: class=0x060400 card=0x chip=0x35978086 rev=0x0c hdr=0x01 vendor = 'Intel Corporation' device = 'E7525/E7520 PCI Express Port B' class = bridge subclass = PCI-PCI pcib5@pci0:0:6:0: class=0x060400 card=0x chip=0x35998086 rev=0x0c hdr=0x01 vendor = 'Intel Corporation' device = 'E7520 PCI Express Port C' class = bridge subclass = PCI-PCI uhci0@pci0:0:29:0: class=0x0c0300 card=0x658015d9 chip=0x24d28086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) USB UHCI Controller' class = serial bus subclass = USB uhci1@pci0:0:29:1: class=0x0c0300 card=0x658015d9 chip=0x24d48086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) USB UHCI Controller' class = serial bus subclass = USB uhci2@pci0:0:29:2: class=0x0c0300 card=0x658015d9 chip=0x24d78086 rev=0x02 hdr=0x00 vendor
Re: pmspcv panic on boot on this box
On Thu, Jul 30, 2015 at 03:09:30PM -0500, Larry Rosenman wrote:
$ sudo -s
Password:
# cd /usr/src
# patch -p0 ~ler/pmspcv.diff
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|Index: sys/dev/pms/freebsd/driver/common/lxutil.c
|===
|--- sys/dev/pms/freebsd/driver/common/lxutil.c (revision 286083)
|+++ sys/dev/pms/freebsd/driver/common/lxutil.c (working copy)
--
Patching file sys/dev/pms/freebsd/driver/common/lxutil.c using Plan A...
Hunk #1 failed at 758.
Hunk #2 failed at 767.
2 out of 2 hunks failed--saving rejects to
sys/dev/pms/freebsd/driver/common/lxutil.c.rej
done
# vi sys/dev/pms/freebsd/driver/common/lxutil.c.rej
@@ -758,6 +758,7 @@
int idx;^M
static U32 cardMap[4] = { 0, 0, 0, 0 };^M
Hmm. Somehow you ended up with MS DOS EOL...
I'm able to apply the patch without issues. Try this:
vi pmspcv.diff
:%s:[ctrl-m]::g
It should apply afterward.
Glen
pgpNAsx5wWYdP.pgp
Description: PGP signature
Re: pmspcv panic on boot on this box
On Thu, Jul 30, 2015 at 08:13:51PM +, Glen Barber wrote:
On Thu, Jul 30, 2015 at 03:09:30PM -0500, Larry Rosenman wrote:
$ sudo -s
Password:
# cd /usr/src
# patch -p0 ~ler/pmspcv.diff
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|Index: sys/dev/pms/freebsd/driver/common/lxutil.c
|===
|--- sys/dev/pms/freebsd/driver/common/lxutil.c (revision 286083)
|+++ sys/dev/pms/freebsd/driver/common/lxutil.c (working copy)
--
Patching file sys/dev/pms/freebsd/driver/common/lxutil.c using Plan A...
Hunk #1 failed at 758.
Hunk #2 failed at 767.
2 out of 2 hunks failed--saving rejects to
sys/dev/pms/freebsd/driver/common/lxutil.c.rej
done
# vi sys/dev/pms/freebsd/driver/common/lxutil.c.rej
@@ -758,6 +758,7 @@
int idx;^M
static U32 cardMap[4] = { 0, 0, 0, 0 };^M
Hmm. Somehow you ended up with MS DOS EOL...
I'm able to apply the patch without issues. Try this:
vi pmspcv.diff
:%s:[ctrl-m]::g
It should apply afterward.
Or, fetch the patch from here:
https://people.freebsd.org/~gjb/pmspcv.diff.txt
Glen
pgpw87P9B5UV2.pgp
Description: PGP signature
Re: pmspcv panic on boot on this box
Can you try the attached patch and let me know if it fixes the issue? Many thanks, Benno. pmspcv.diff Description: Binary data On Jul 30, 2015, at 11:55 AM, Benno Rice be...@freebsd.org wrote: Hi Larry, I’ve brought this to the attention of PMC Sierra and we’re pretty sure we’ve worked out what the problem is. I’m just waiting on their review of the fix I’ve suggested. Sorry this has caused you problems. Many apologies, Benno. On Jul 28, 2015, at 2:01 PM, Larry Rosenman l...@lerctr.org wrote: When I upgraded an approximately 3 month old -CURRENT system to yesterday, I got page not present panics, after a message about pmspcv not supporting my ahd(4) deviceid. I did NOT capture the panic, but adding nodevice pmspcv Allowed me to boot. Dmesg.boot from the WORKING system attached. I *CAN* work with someone if they want. dmesg.boot___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pmspcv panic on boot on this box
$ sudo -s
Password:
# cd /usr/src
# patch -p0 ~ler/pmspcv.diff
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|Index: sys/dev/pms/freebsd/driver/common/lxutil.c
|===
|--- sys/dev/pms/freebsd/driver/common/lxutil.c (revision 286083)
|+++ sys/dev/pms/freebsd/driver/common/lxutil.c (working copy)
--
Patching file sys/dev/pms/freebsd/driver/common/lxutil.c using Plan A...
Hunk #1 failed at 758.
Hunk #2 failed at 767.
2 out of 2 hunks failed--saving rejects to
sys/dev/pms/freebsd/driver/common/lxutil.c.rej
done
# vi sys/dev/pms/freebsd/driver/common/lxutil.c.rej
@@ -758,6 +758,7 @@
int idx;^M
static U32 cardMap[4] = { 0, 0, 0, 0 };^M
u_int16_t agtiapi_dev; // PCI device ID^M
+ u_int16_t agtiapi_vendor; // PCI vendor ID^M
AGTIAPI_PRINTK(agtiapi_ProbeCard: start\n);^M
^M
if ( ! atomic_cmpset_32( cardMap[thisCard], 0, 5 ) ) { // card
already ran^M
@@ -766,10 +767,12 @@
}^M
else {^M
agtiapi_dev = pci_get_device( dev ); // get PCI device ID^M
+agtiapi_vendor = pci_get_vendor( dev ); // get PCI vendor ID^M
for( idx = 0; idx COUNT(ag_card_type); idx++ ) ^M
{^M
- if( ag_card_type[idx].deviceId == agtiapi_dev ) ^M
- { // device ID match^M
+ if( ag_card_type[idx].deviceId == agtiapi_dev ^M
+ ag_card_type[idx].vendorId == agtiapi_vendor ) ^M
+ { // device and vendor IDs match^M
memset( (void *)agCardInfoList[ thisCard ], 0,^M
sizeof(ag_card_info_t) );^M
thisCardInst-cardIdIndex = idx;^M
~
:q
#
Not good :(
On 2015-07-30 15:05, Benno Rice wrote:
Can you try the attached patch and let me know if it fixes the issue?
Many thanks,
Benno.
On Jul 30, 2015, at 11:55 AM, Benno Rice be...@freebsd.org wrote:
Hi Larry,
I’ve brought this to the attention of PMC Sierra and we’re pretty sure
we’ve worked out what the problem is. I’m just waiting on their review
of the fix I’ve suggested.
Sorry this has caused you problems.
Many apologies,
Benno.
On Jul 28, 2015, at 2:01 PM, Larry Rosenman l...@lerctr.org wrote:
When I upgraded an approximately 3 month old -CURRENT system to
yesterday, I
got page not present panics, after a message about pmspcv not
supporting
my ahd(4) deviceid.
I did NOT capture the panic, but adding
nodevicepmspcv
Allowed me to boot.
Dmesg.boot from the WORKING system attached.
I *CAN* work with someone if they want.
dmesg.boot___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pmspcv panic on boot on this box
On 2015-07-30 15:15, Glen Barber wrote:
On Thu, Jul 30, 2015 at 08:13:51PM +, Glen Barber wrote:
On Thu, Jul 30, 2015 at 03:09:30PM -0500, Larry Rosenman wrote:
$ sudo -s
Password:
# cd /usr/src
# patch -p0 ~ler/pmspcv.diff
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|Index: sys/dev/pms/freebsd/driver/common/lxutil.c
|===
|--- sys/dev/pms/freebsd/driver/common/lxutil.c(revision 286083)
|+++ sys/dev/pms/freebsd/driver/common/lxutil.c(working copy)
--
Patching file sys/dev/pms/freebsd/driver/common/lxutil.c using Plan A...
Hunk #1 failed at 758.
Hunk #2 failed at 767.
2 out of 2 hunks failed--saving rejects to
sys/dev/pms/freebsd/driver/common/lxutil.c.rej
done
# vi sys/dev/pms/freebsd/driver/common/lxutil.c.rej
@@ -758,6 +758,7 @@
int idx;^M
static U32 cardMap[4] = { 0, 0, 0, 0 };^M
Hmm. Somehow you ended up with MS DOS EOL...
I'm able to apply the patch without issues. Try this:
vi pmspcv.diff
:%s:[ctrl-m]::g
It should apply afterward.
Or, fetch the patch from here:
https://people.freebsd.org/~gjb/pmspcv.diff.txt
Glen
Kernel compiling -- give mr a bit and I'll boot it and make sure it
comes up.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pmspcv panic on boot on this box
On Thu, Jul 30, 2015 at 03:20:46PM -0500, Larry Rosenman wrote: Kernel compiling -- give mr a bit and I'll boot it and make sure it comes up. Larry, have you had any luck with this patch applied? If it resolves your issue, I want to make sure it is included in the 10.2-RC2 build. Thanks. Glen pgpBxa8F2_IXJ.pgp Description: PGP signature
Re: pmspcv panic on boot on this box
On Fri, Jul 31, 2015 at 04:18:15AM +, Glen Barber wrote: On Thu, Jul 30, 2015 at 06:57:05PM -0500, Larry Rosenman wrote: On 2015-07-30 17:17, Glen Barber wrote: On Thu, Jul 30, 2015 at 03:20:46PM -0500, Larry Rosenman wrote: Kernel compiling -- give mr a bit and I'll boot it and make sure it comes up. Larry, have you had any luck with this patch applied? If it resolves your issue, I want to make sure it is included in the 10.2-RC2 build. Thanks. [...] There are 3 pictures from the CURRENT panic. it STILL fails. :( Larry, I am sorry this is causing headaches for you, and I certainly appreciate the prompt (and detailed) report, and assistance debugging this. Would you be able to try one more test case? I'm interested in the behavior without the 'nodevice pmsdrv' addition to your kernel configuration (effectively, removing the device from the GENERIC kernel), and *without* the patch provided from Benno? To be more specific on what I'm interested in, 'nodevice pmsdrv' and 'device pmsdrv' should *both* be removed from the kernel configuration, and the pms(4) should only be available as a .ko module. In particular, I'm interested in if ahd(4) attaches or if loader(8) auto-loads pms(4) after the PCI IDs are detected. As this issue also affects the upcoming 10.2-RELEASE, your willingness to help debug this is greatly appreciated, as you've tripped over something that would have caused a great deal of pain after 10.2 was release. I owe you several beers. Glen pgp2B9PyLFDIx.pgp Description: PGP signature
Re: pmspcv panic on boot on this box
On Fri, Jul 31, 2015 at 04:48:18AM +, mailingli...@debank.tv wrote: July 31 2015 4:21 PM, Glen Barber g...@freebsd.org wrote: On Fri, Jul 31, 2015 at 04:18:15AM +, Glen Barber wrote: On Thu, Jul 30, 2015 at 06:57:05PM -0500, Larry Rosenman wrote: On 2015-07-30 17:17, Glen Barber wrote: On Thu, Jul 30, 2015 at 03:20:46PM -0500, Larry Rosenman wrote: Kernel compiling -- give mr a bit and I'll boot it and make sure it comes up. Larry, have you had any luck with this patch applied? If it resolves your issue, I want to make sure it is included in the 10.2-RC2 build. Thanks. [...] There are 3 pictures from the CURRENT panic. it STILL fails. :( Larry, I am sorry this is causing headaches for you, and I certainly appreciate the prompt (and detailed) report, and assistance debugging this. Would you be able to try one more test case? I'm interested in the behavior without the 'nodevice pmsdrv' addition to your kernel configuration (effectively, removing the device from the GENERIC kernel), and *without* the patch provided from Benno? To be more specific on what I'm interested in, 'nodevice pmsdrv' and 'device pmsdrv' should *both* be removed from the kernel configuration, and the pms(4) should only be available as a .ko module. In particular, I'm interested in if ahd(4) attaches or if loader(8) auto-loads pms(4) after the PCI IDs are detected. As this issue also affects the upcoming 10.2-RELEASE, your willingness to help debug this is greatly appreciated, as you've tripped over something that would have caused a great deal of pain after 10.2 was release. I owe you several beers. Hi All, I've experienced the same bug although with a mvs(4) device on 10.2-PRERELEASE, once the pms driver is removed from the kernel config the problem disappears, I haven't had time to try the suggested patch as I only found this thread after removing the pms driver from the kernel. Thank you for the information (stripped from my reply). So, to be clear, you have 'device pmsdrv' removed from the kernel config, but the /boot/kernel/pmspcv.ko is still available to the system? Glen pgpgXu5q7OFHI.pgp Description: PGP signature
Re: pmspcv panic on boot on this box
On Thu, Jul 30, 2015 at 06:57:05PM -0500, Larry Rosenman wrote: On 2015-07-30 17:17, Glen Barber wrote: On Thu, Jul 30, 2015 at 03:20:46PM -0500, Larry Rosenman wrote: Kernel compiling -- give mr a bit and I'll boot it and make sure it comes up. Larry, have you had any luck with this patch applied? If it resolves your issue, I want to make sure it is included in the 10.2-RC2 build. Thanks. [...] There are 3 pictures from the CURRENT panic. it STILL fails. :( Larry, I am sorry this is causing headaches for you, and I certainly appreciate the prompt (and detailed) report, and assistance debugging this. Would you be able to try one more test case? I'm interested in the behavior without the 'nodevice pmsdrv' addition to your kernel configuration (effectively, removing the device from the GENERIC kernel), and *without* the patch provided from Benno? In particular, I'm interested in if ahd(4) attaches or if loader(8) auto-loads pms(4) after the PCI IDs are detected. As this issue also affects the upcoming 10.2-RELEASE, your willingness to help debug this is greatly appreciated, as you've tripped over something that would have caused a great deal of pain after 10.2 was release. I owe you several beers. Glen pgpxK8fd3erJc.pgp Description: PGP signature
Re: pmspcv panic on boot on this box
July 31 2015 4:21 PM, Glen Barber g...@freebsd.org wrote: On Fri, Jul 31, 2015 at 04:18:15AM +, Glen Barber wrote: On Thu, Jul 30, 2015 at 06:57:05PM -0500, Larry Rosenman wrote: On 2015-07-30 17:17, Glen Barber wrote: On Thu, Jul 30, 2015 at 03:20:46PM -0500, Larry Rosenman wrote: Kernel compiling -- give mr a bit and I'll boot it and make sure it comes up. Larry, have you had any luck with this patch applied? If it resolves your issue, I want to make sure it is included in the 10.2-RC2 build. Thanks. [...] There are 3 pictures from the CURRENT panic. it STILL fails. :( Larry, I am sorry this is causing headaches for you, and I certainly appreciate the prompt (and detailed) report, and assistance debugging this. Would you be able to try one more test case? I'm interested in the behavior without the 'nodevice pmsdrv' addition to your kernel configuration (effectively, removing the device from the GENERIC kernel), and *without* the patch provided from Benno? To be more specific on what I'm interested in, 'nodevice pmsdrv' and 'device pmsdrv' should *both* be removed from the kernel configuration, and the pms(4) should only be available as a .ko module. In particular, I'm interested in if ahd(4) attaches or if loader(8) auto-loads pms(4) after the PCI IDs are detected. As this issue also affects the upcoming 10.2-RELEASE, your willingness to help debug this is greatly appreciated, as you've tripped over something that would have caused a great deal of pain after 10.2 was release. I owe you several beers. Glen Hi All, I've experienced the same bug although with a mvs(4) device on 10.2-PRERELEASE, once the pms driver is removed from the kernel config the problem disappears, I haven't had time to try the suggested patch as I only found this thread after removing the pms driver from the kernel. Rob Evers P.S. some info from the machine working system: # pciconf -l | grep mvs1 mvs1@pci0:5:0:0:class=0x010400 card=0x02439005 chip=0x02439005 rev=0x02 hdr=0x00 Failed boot: cib2: allocated memory range (0xd040-0xd04f) for rid 10 of pci0:5:0:0 map[18]: type I/O Port, range 32, base 0x3000, size 8, enabled pcib2: allocated I/O port range (0x3000-0x30ff) for rid 18 of pci0:5:0:0 map[1c]: type Memory, range 64, base 0xd030, size 20, enabled pcib2: attempting to grow memory window for (0xd030-0xd03f,0x10) front candidate range: 0xd030-0xd03f pci5: pci0:5:0:0 bar 0x1c failed to allocate pcib2: matched entry for 5.0.INTA pcib2: slot 0 INTA hardwired to IRQ 16 pmspcv0 port 0x3000-0x30ff mem 0xd040-0xd04f irq 16 at device 0.0 on pci5 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x28 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80a0d984 stack pointer = 0x28:0x821ac2c0 frame pointer = 0x28:0x821ac2d0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0x80a17a30 at kdb_backtrace+0x60 #1 0x809db196 at vpanic+0x126 #2 0x809db063 at panic+0x43 #3 0x80dee3eb at trap_fatal+0x36b #4 0x80dee6ed at trap_pfault+0x2ed #5 0x80dedd8a at trap+0x47a #6 0x80dd4102 at calltrap+0x8 #7 0x806b7a20 at agtiapi_attach+0x3a0 #8 0x80a0e6cd at device_attach+0x43d #9 0x80a0f82c at bus_generic_attach+0x4c #10 0x8038069c at acpi_pci_attach+0x15c #11 0x80a0e6cd at device_attach+0x43d #12 0x80a0f82c at bus_generic_attach+0x4c #13 0x803827cc at acpi_pcib_attach+0x22c #14 0x80383a2f at acpi_pcib_pci_attach+0x9f #15 0x80a0e6cd at device_attach+0x43d #16 0x80a0f82c at bus_generic_attach+0x4c #17 0x8038069c at acpi_pci_attach+0x15c Uptime: 1s ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pmspcv panic on boot on this box
On 2015-07-30 17:17, Glen Barber wrote: On Thu, Jul 30, 2015 at 03:20:46PM -0500, Larry Rosenman wrote: Kernel compiling -- give mr a bit and I'll boot it and make sure it comes up. Larry, have you had any luck with this patch applied? If it resolves your issue, I want to make sure it is included in the 10.2-RC2 build. Thanks. Glen https://drive.google.com/file/d/1ouZHMEWXiPcZQ_zmpJY6hhwPItXitb7DxQ/view?usp=sharing https://drive.google.com/file/d/1CBf4v9cgSc3RgVLZDLdYDztP0_29k1vzAA/view?usp=sharing https://drive.google.com/file/d/1MuvvEXROrkiP2N78v9t1xdYPR7dDGO_0lA/view?usp=sharing There are 3 pictures from the CURRENT panic. it STILL fails. :( -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pmspcv panic on boot on this box
Hi Larry, I’ve brought this to the attention of PMC Sierra and we’re pretty sure we’ve worked out what the problem is. I’m just waiting on their review of the fix I’ve suggested. Sorry this has caused you problems. Many apologies, Benno. On Jul 28, 2015, at 2:01 PM, Larry Rosenman l...@lerctr.org wrote: When I upgraded an approximately 3 month old -CURRENT system to yesterday, I got page not present panics, after a message about pmspcv not supporting my ahd(4) deviceid. I did NOT capture the panic, but adding nodevice pmspcv Allowed me to boot. Dmesg.boot from the WORKING system attached. I *CAN* work with someone if they want. dmesg.boot___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
pmspcv panic on boot on this box
When I upgraded an approximately 3 month old -CURRENT system to yesterday, I got page not present panics, after a message about pmspcv not supporting my ahd(4) deviceid. I did NOT capture the panic, but adding nodevicepmspcv Allowed me to boot. Dmesg.boot from the WORKING system attached. I *CAN* work with someone if they want. Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #10 r285925: Mon Jul 27 21:00:19 CDT 2015 r...@oldtbh.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 FreeBSD clang version 3.6.1 (tags/RELEASE_361/final 237755) 20150525 VT: running with driver vga. CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.56-MHz K8-class CPU) Origin=GenuineIntel Id=0xf43 Family=0xf Model=0x4 Stepping=3 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x641dSSE3,DTES64,MON,DS_CPL,CNXT-ID,CX16,xTPR AMD Features=0x20100800SYSCALL,NX,LM TSC: P-state invariant real memory = 9395240960 (8960 MB) avail memory = 8262250496 (7879 MB) Event timer LAPIC quality 400 ACPI APIC Table: PTLTD APIC FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP/HT): APIC ID: 7 random: unblocking device. ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard random: entropy device external interface kbd1 at kbdmux0 netmap: loaded module module_register_init: MOD_LOAD (vesa, 0x80f4d760, 0) error 19 vtvga0: VT VGA driver on motherboard cryptosoft0: software crypto on motherboard acpi0: PTLTD RSDT on motherboard acpi0: Power Button (fixed) cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff irq 0,8 on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 Event timer HPET frequency 14318180 Hz quality 450 Event timer HPET1 frequency 14318180 Hz quality 440 Event timer HPET2 frequency 14318180 Hz quality 440 atrtc0: AT realtime clock port 0x70-0x77 on acpi0 Event timer RTC frequency 32768 Hz quality 0 attimer0: AT timer port 0x40-0x43 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: unknown at device 0.1 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1 pci2: ACPI PCI bus on pcib2 ahd0: Adaptec AIC7902 Ultra320 SCSI adapter port 0x2400-0x24ff,0x2000-0x20ff mem 0xdd20-0xdd201fff irq 32 at device 2.0 on pci2 aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133MHz, 512 SCBs ahd1: Adaptec AIC7902 Ultra320 SCSI adapter port 0x2c00-0x2cff,0x2800-0x28ff mem 0xdd202000-0xdd203fff irq 33 at device 2.1 on pci2 aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133MHz, 512 SCBs pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1 pci3: ACPI PCI bus on pcib3 em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.6 port 0x3000-0x303f mem 0xdd30-0xdd31 irq 54 at device 2.0 on pci3 em0: Ethernet address: 00:30:48:2e:99:ba em0: netmap queues/slots: TX 1/256, RX 1/256 em1: Intel(R) PRO/1000 Legacy Network Connection 1.0.6 port 0x3040-0x307f mem 0xdd32-0xdd33 irq 55 at device 2.1 on pci3 em1: Ethernet address: 00:30:48:2e:99:bb em1: netmap queues/slots: TX 1/256, RX 1/256 pcib4: ACPI PCI-PCI bridge irq 16 at device 4.0 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge irq 16 at device 6.0 on pci0 pci5: ACPI PCI bus on pcib5 uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0x1400-0x141f irq 16 at device 29.0 on pci0 uhci0: LegSup = 0x2f00 usbus0 on uhci0 uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0x1420-0x143f irq 19 at device 29.1 on pci0 uhci1: LegSup = 0x2f00 usbus1 on uhci1 uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0x1440-0x145f irq 18 at device 29.2 on pci0 uhci2: LegSup = 0x2f00 usbus2 on uhci2 uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0x1460-0x147f irq 16 at device 29.3 on pci0 uhci3: LegSup = 0x2f00 usbus3 on uhci3 ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xdd001000-0xdd0013ff irq 23 at device 29.7 on pci0 usbus4: EHCI version 1.0 usbus4 on ehci0 pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0 pci6: ACPI PCI bus on pcib6 vgapci0: VGA-compatible display port 0x4000-0x40ff mem
