Re: i386-current bsd.rd fails on net6501

[Mike Larkin]

On Tue, Sep 08, 2015 at 08:02:45PM +0200, Christian Weisgerber wrote:
> Mark Kettenis:
> 
> > Does the bsd kernel from the same snapshot blow up as well?
> 
> Yes.
> 
> booting hd0a:bsd.i386: 7520308+2015344+189444+0+1069056 
> [72+411072+405023]=0xb155c4
> entry point at 0x2000d4 [7205c766, 3404, 24448b12, de60a304]
> 
> [ using 816580 bytes of bsd ELF symbol table ]
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2015 OpenBSD. All rights reserved.  http://www.OpenBSD.org
> 
> OpenBSD 5.8-current (GENERIC) #1156: Mon Sep  7 07:02:35 MDT 2015
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Genuine Intel(R) CPU @ 1.00GHz ("GenuineIntel" 686-class) 1.01 GHz
> cpu0: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF,SENSOR
> real mem  = 1073086464 (1023MB)
> avail mem = 1040211968 (992MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 20/21/15, BIOS32 rev. 0 @ 0xfac40
> mpbios0 at bios0: Intel MP Specification 1.4
> cpu0 at mainbus0: apid 0 (boot processor)
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 100MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2.0.3, IBE
> cpu at mainbus0: not configured
> mpbios0: bus 0 is type PCI   
> mpbios0: bus 64 is type ISA   
> ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
> uvm_fault(0xd0b6c5e0, 0xd0d7e000, 0, 4) -> d
> kernel: page fault trap, code=0
> Stopped at  __kernel_bss_end+0x130c40:  cmpl$0x49435024,%eax
> ddb> 
>

That address and instruction seem bogus. When did it last work?

This seems awfully similar to the other bug we fixed in Calgary a couple
months back; I'm wondering if there is another similar issue. I looked last
time and didn't see anything but may have missed something.
 
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 

Re: i386-current bsd.rd fails on net6501

[Mark Kettenis]

> Date: Tue, 8 Sep 2015 20:02:45 +0200
> From: Christian Weisgerber 
> 
> Mark Kettenis:
> 
> > Does the bsd kernel from the same snapshot blow up as well?
> 
> Yes.
> 
> booting hd0a:bsd.i386: 7520308+2015344+189444+0+1069056 
> [72+411072+405023]=0xb155c4
> entry point at 0x2000d4 [7205c766, 3404, 24448b12, de60a304]
> 
> [ using 816580 bytes of bsd ELF symbol table ]
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2015 OpenBSD. All rights reserved.  http://www.OpenBSD.org
> 
> OpenBSD 5.8-current (GENERIC) #1156: Mon Sep  7 07:02:35 MDT 2015
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Genuine Intel(R) CPU @ 1.00GHz ("GenuineIntel" 686-class) 1.01 GHz
> cpu0: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF,SENSOR
> real mem  = 1073086464 (1023MB)
> avail mem = 1040211968 (992MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 20/21/15, BIOS32 rev. 0 @ 0xfac40
> mpbios0 at bios0: Intel MP Specification 1.4
> cpu0 at mainbus0: apid 0 (boot processor)
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 100MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2.0.3, IBE
> cpu at mainbus0: not configured
> mpbios0: bus 0 is type PCI   
> mpbios0: bus 64 is type ISA   
> ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
> uvm_fault(0xd0b6c5e0, 0xd0d7e000, 0, 4) -> d
> kernel: page fault trap, code=0
> Stopped at  __kernel_bss_end+0x130c40:  cmpl$0x49435024,%eax
> ddb> 

no trace?

Re: i386-current bsd.rd fails on net6501

[Christian Weisgerber]

Mark Kettenis:

> > ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
> > uvm_fault(0xd0b6c5e0, 0xd0d7e000, 0, 4) -> d
> > kernel: page fault trap, code=0
> > Stopped at  __kernel_bss_end+0x130c40:  cmpl$0x49435024,%eax
> > ddb> 
> 
> no trace?

__kernel_bss_end(49435024,d0c4bf84,d0c4bf8a,e06671f9,7) at __kernel_bss_end+0x1
30c40
pcibiosprobe(d211a0c0,d0b1e7c0,d0d17d2c,d0850965,d0b86508) at pcibiosprobe+0x64

config_scan(d0b25244,5,0,0,0) at config_scan+0x10e
config_search(0,d211a0c0,d0d17d2c,0,0) at config_search+0xf4
config_found_sm(d211a0c0,d0d17d2c,d084c8d0,0,31) at config_found_sm+0x2b
biosattach(d211a080,d211a0c0,d0d17e40,d03bdf4b,0) at biosattach+0x7e4
config_attach(d211a080,d0b1e720,d0d17e40,d0590de0,8) at config_attach+0x1bc
mainbus_attach(0,d211a080,0,d20ea080,0) at mainbus_attach+0x5e
config_attach(0,d0b1c040,0,0,d0d16000) at config_attach+0x1bc
config_rootfound(d09d3256,0,7,0,d03bbb80) at config_rootfound+0x46
cpu_configure(d09a3268,0,1000,cfb3e000,1) at cpu_configure+0x4f
main(d02004c1,d02004c9,0,0,0) at main+0x3ef

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: i386-current bsd.rd fails on net6501

[Mark Kettenis]

> Date: Tue, 8 Sep 2015 12:03:28 -0700
> From: Mike Larkin 
> 
> On Tue, Sep 08, 2015 at 08:02:45PM +0200, Christian Weisgerber wrote:
> > Mark Kettenis:
> > 
> > > Does the bsd kernel from the same snapshot blow up as well?
> > 
> > Yes.
> > 
> > booting hd0a:bsd.i386: 7520308+2015344+189444+0+1069056 
> > [72+411072+405023]=0xb155c4
> > entry point at 0x2000d4 [7205c766, 3404, 24448b12, de60a304]
> > 
> > [ using 816580 bytes of bsd ELF symbol table ]
> > Copyright (c) 1982, 1986, 1989, 1991, 1993
> > The Regents of the University of California.  All rights reserved.
> > Copyright (c) 1995-2015 OpenBSD. All rights reserved.  
> > http://www.OpenBSD.org
> > 
> > OpenBSD 5.8-current (GENERIC) #1156: Mon Sep  7 07:02:35 MDT 2015
> > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> > cpu0: Genuine Intel(R) CPU @ 1.00GHz ("GenuineIntel" 686-class) 1.01 GHz
> > cpu0: 
> > FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF,SENSOR
> > real mem  = 1073086464 (1023MB)
> > avail mem = 1040211968 (992MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: date 20/21/15, BIOS32 rev. 0 @ 0xfac40
> > mpbios0 at bios0: Intel MP Specification 1.4
> > cpu0 at mainbus0: apid 0 (boot processor)
> > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> > cpu0: apic clock running at 100MHz
> > cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2.0.3, IBE
> > cpu at mainbus0: not configured
> > mpbios0: bus 0 is type PCI   
> > mpbios0: bus 64 is type ISA   
> > ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
> > uvm_fault(0xd0b6c5e0, 0xd0d7e000, 0, 4) -> d
> > kernel: page fault trap, code=0
> > Stopped at  __kernel_bss_end+0x130c40:  cmpl$0x49435024,%eax
> > ddb> 
> >
> 
> That address and instruction seem bogus. When did it last work?

Before your i386 W^X commit?

0x49435025 is $PCI aka PCIBIOS_SIGNATURE.  That's pretty strong
evidence we're in the pcibiosprobe(), doing the bios32_service() call.

Re: i386-current bsd.rd fails on net6501

[Mike Larkin]

On Tue, Sep 08, 2015 at 09:34:04PM +0200, Mark Kettenis wrote:
> > Date: Tue, 8 Sep 2015 12:03:28 -0700
> > From: Mike Larkin 
> > 
> > On Tue, Sep 08, 2015 at 08:02:45PM +0200, Christian Weisgerber wrote:
> > > Mark Kettenis:
> > > 
> > > > Does the bsd kernel from the same snapshot blow up as well?
> > > 
> > > Yes.
> > > 
> > > booting hd0a:bsd.i386: 7520308+2015344+189444+0+1069056 
> > > [72+411072+405023]=0xb155c4
> > > entry point at 0x2000d4 [7205c766, 3404, 24448b12, de60a304]
> > > 
> > > [ using 816580 bytes of bsd ELF symbol table ]
> > > Copyright (c) 1982, 1986, 1989, 1991, 1993
> > > The Regents of the University of California.  All rights reserved.
> > > Copyright (c) 1995-2015 OpenBSD. All rights reserved.  
> > > http://www.OpenBSD.org
> > > 
> > > OpenBSD 5.8-current (GENERIC) #1156: Mon Sep  7 07:02:35 MDT 2015
> > > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> > > cpu0: Genuine Intel(R) CPU @ 1.00GHz ("GenuineIntel" 686-class) 1.01 GHz
> > > cpu0: 
> > > FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF,SENSOR
> > > real mem  = 1073086464 (1023MB)
> > > avail mem = 1040211968 (992MB)
> > > mpath0 at root
> > > scsibus0 at mpath0: 256 targets
> > > mainbus0 at root
> > > bios0 at mainbus0: date 20/21/15, BIOS32 rev. 0 @ 0xfac40
> > > mpbios0 at bios0: Intel MP Specification 1.4
> > > cpu0 at mainbus0: apid 0 (boot processor)
> > > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> > > cpu0: apic clock running at 100MHz
> > > cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2.0.3, IBE
> > > cpu at mainbus0: not configured
> > > mpbios0: bus 0 is type PCI   
> > > mpbios0: bus 64 is type ISA   
> > > ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
> > > uvm_fault(0xd0b6c5e0, 0xd0d7e000, 0, 4) -> d
> > > kernel: page fault trap, code=0
> > > Stopped at  __kernel_bss_end+0x130c40:  cmpl$0x49435024,%eax
> > > ddb> 
> > >
> > 
> > That address and instruction seem bogus. When did it last work?
> 
> Before your i386 W^X commit?
> 

Could be, although I thought I got all the regions that needed executable
bits set for BIOS. I'll take a look.

> 0x49435025 is $PCI aka PCIBIOS_SIGNATURE.  That's pretty strong
> evidence we're in the pcibiosprobe(), doing the bios32_service() call.
> 

Yeah, just noticed that as well. The wrong symbol there threw me off.

-ml

Re: i386-current bsd.rd fails on net6501

[Christian Weisgerber]

Mike Larkin:

> That address and instruction seem bogus. When did it last work?
> 
> This seems awfully similar to the other bug we fixed in Calgary a couple
> months back;

And that may very well be the last time I tried i386 on that machine.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

iwm doesn't provide link changes

[Ted Unangst]

when switching between wifi networks, iwm does not create link change
messages. this makes dhclient not work properly.

Re: Weekly network disconnect with G4 Mac Mini (gem0)

[Stuart Henderson]

On 2015/09/08 17:28, Carlos Fenollosa wrote:
> 
> > On 07 Sep 2015, at 20:40, Stuart Henderson  wrote:
> > 
> > On 2015/09/07 20:26, Landry Breuil wrote:
> >> I cant help you on the issue itself, but i can confirm you that i've
> >> been seeing the exact same issue with gem0 on my g4 mac mini here, and
> >> since some releases. randomly, gem0 just doesnt receive/send pkts
> >> anymore and needs to be downed/upped.
> > 
> > Interesting - I don't see that on mine.
> > 
> > Out of interest does your switch have flow control enabled? (you will
> > see rxpause and/or txpause in the ifconfig output). If it does, is there
> > any change if you disable it on the switch (if you can do so)?
> > 
> > gem0: flags=8863 mtu 1500
> >lladdr 00:0d:93:63:da:5a
> >priority: 0
> >groups: egress
> >media: Ethernet autoselect (100baseTX full-duplex)
> >status: active
> 
> Yes, it seems to be the case:
> 
> gem0: flags=8863 mtu 1500
> lladdr 00:11:24:87:a7:64
> priority: 0
> groups: egress
> media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
> status: active
> inet 192.168.1.199 netmask 0xff00 broadcast 192.168.1.255
> 
> 
> I have a crappy telco router, I’m actually not sure if I can disable it 
> there. There is a section on QoS, but the option is disabled.
> Could the driver be forced to disable flow control? At least I could try 
> running it for a couple weeks to see if the bug is triggered again.
> 
> 
> Thanks a lot,
> Carlos
> 

Flow control was a complete guess btw and might be unconnected.
This diff ought to disable it but my mac is 1500km away at the moment
so untested!

Landry, does yours show rxpause/txpause on this line?


Index: gem.c
===
RCS file: /cvs/src/sys/dev/ic/gem.c,v
retrieving revision 1.112
diff -u -p -r1.112 gem.c
--- gem.c   24 Jun 2015 09:40:54 -  1.112
+++ gem.c   8 Sep 2015 15:43:51 -
@@ -240,7 +240,7 @@ gem_config(struct gem_softc *sc)
 
gem_mifinit(sc);
 
-   mii_flags = MIIF_DOPAUSE;
+   mii_flags = 0;
 
/* 
 * Look for an external PHY.
@@ -905,7 +905,7 @@ gem_init_regs(struct gem_softc *sc)
bus_space_write_4(t, h, GEM_MAC_RX_CODE_VIOL, 0);
 
/* Set XOFF PAUSE time */
-   bus_space_write_4(t, h, GEM_MAC_SEND_PAUSE_CMD, 0x1bf0);
+   bus_space_write_4(t, h, GEM_MAC_SEND_PAUSE_CMD, 0);
 
/*
 * Set the internal arbitration to "infinite" bursts of the
@@ -1357,17 +1357,6 @@ gem_mii_statchg(struct device *dev)
v &= ~GEM_MAC_XIF_GMII_MODE;
}
bus_space_write_4(t, mac, GEM_MAC_XIF_CONFIG, v);
-
-   /*
-* 802.3x flow control
-*/
-   v = bus_space_read_4(t, mac, GEM_MAC_CONTROL_CONFIG);
-   v &= ~(GEM_MAC_CC_RX_PAUSE | GEM_MAC_CC_TX_PAUSE);
-   if ((IFM_OPTIONS(sc->sc_mii.mii_media_active) & IFM_ETH_RXPAUSE) != 0)
-   v |= GEM_MAC_CC_RX_PAUSE;
-   if ((IFM_OPTIONS(sc->sc_mii.mii_media_active) & IFM_ETH_TXPAUSE) != 0)
-   v |= GEM_MAC_CC_TX_PAUSE;
-   bus_space_write_4(t, mac, GEM_MAC_CONTROL_CONFIG, v);
 }
 
 int

Re: Weekly network disconnect with G4 Mac Mini (gem0)

[Landry Breuil]

On Tue, Sep 08, 2015 at 04:44:57PM +0100, Stuart Henderson wrote:
> On 2015/09/08 17:28, Carlos Fenollosa wrote:
> > 
> > > On 07 Sep 2015, at 20:40, Stuart Henderson  wrote:
> > > 
> > > On 2015/09/07 20:26, Landry Breuil wrote:
> > >> I cant help you on the issue itself, but i can confirm you that i've
> > >> been seeing the exact same issue with gem0 on my g4 mac mini here, and
> > >> since some releases. randomly, gem0 just doesnt receive/send pkts
> > >> anymore and needs to be downed/upped.
> > > 
> > > Interesting - I don't see that on mine.
> > > 
> > > Out of interest does your switch have flow control enabled? (you will
> > > see rxpause and/or txpause in the ifconfig output). If it does, is there
> > > any change if you disable it on the switch (if you can do so)?
> > > 
> > > gem0: flags=8863 mtu 
> > > 1500
> > >lladdr 00:0d:93:63:da:5a
> > >priority: 0
> > >groups: egress
> > >media: Ethernet autoselect (100baseTX full-duplex)
> > >status: active
> > 
> > Yes, it seems to be the case:
> > 
> > gem0: flags=8863 mtu 1500
> > lladdr 00:11:24:87:a7:64
> > priority: 0
> > groups: egress
> > media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
> > status: active
> > inet 192.168.1.199 netmask 0xff00 broadcast 192.168.1.255
> > 
> > 
> > I have a crappy telco router, I’m actually not sure if I can disable it 
> > there. There is a section on QoS, but the option is disabled.
> > Could the driver be forced to disable flow control? At least I could try 
> > running it for a couple weeks to see if the bug is triggered again.
> > 
> > 
> > Thanks a lot,
> > Carlos
> > 
> 
> Flow control was a complete guess btw and might be unconnected.
> This diff ought to disable it but my mac is 1500km away at the moment
> so untested!
> 
> Landry, does yours show rxpause/txpause on this line?

nope, as i said my switch is more than basic..

gem0: flags=8863 mtu 1500
lladdr 00:14:51:1f:5c:f4
priority: 0
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 10.246.200.1 netmask 0xff00 broadcast 10.255.255.255
inet6 fe80::214:51ff:fe1f:5cf4%gem0 prefixlen 64 scopeid 0x2
inet6 2a01:e34:edcb:85c0::1 prefixlen 120

Landry

Re: Weekly network disconnect with G4 Mac Mini (gem0)

[Carlos Fenollosa]

> On 07 Sep 2015, at 20:40, Stuart Henderson  wrote:
> 
> On 2015/09/07 20:26, Landry Breuil wrote:
>> I cant help you on the issue itself, but i can confirm you that i've
>> been seeing the exact same issue with gem0 on my g4 mac mini here, and
>> since some releases. randomly, gem0 just doesnt receive/send pkts
>> anymore and needs to be downed/upped.
> 
> Interesting - I don't see that on mine.
> 
> Out of interest does your switch have flow control enabled? (you will
> see rxpause and/or txpause in the ifconfig output). If it does, is there
> any change if you disable it on the switch (if you can do so)?
> 
> gem0: flags=8863 mtu 1500
>lladdr 00:0d:93:63:da:5a
>priority: 0
>groups: egress
>media: Ethernet autoselect (100baseTX full-duplex)
>status: active

Yes, it seems to be the case:

gem0: flags=8863 mtu 1500
lladdr 00:11:24:87:a7:64
priority: 0
groups: egress
media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
status: active
inet 192.168.1.199 netmask 0xff00 broadcast 192.168.1.255


I have a crappy telco router, I’m actually not sure if I can disable it there. 
There is a section on QoS, but the option is disabled.
Could the driver be forced to disable flow control? At least I could try 
running it for a couple weeks to see if the bug is triggered again.


Thanks a lot,
Carlos

i386-current bsd.rd fails on net6501

[Christian Weisgerber]

When I try to boot bsd.rd from the Sep 7 i386 snapshot on my Soekris
net6501, it blows up.

boot> boot bsd.rd
booting hd0a:bsd.rd: 3176316+1310736+2057216+0+425984 
[72+247696+238008]=0x71eb2c
entry point at 0x2000d4 [7205c766, 3404, 24448b12, e568a304]

Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2015 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 5.8-current (RAMDISK_CD) #1123: Mon Sep  7 07:13:10 MDT 2015
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
cpu0: Genuine Intel(R) CPU @ 1.00GHz ("GenuineIntel" 686-class) 1.01 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF,SENSOR
real mem  = 1073131520 (1023MB)
avail mem = 1043435520 (995MB)
mainbus0 at root
bios0 at mainbus0: date 20/21/15, BIOS32 rev. 0 @ 0xfac40
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2.0.3, IBE
cpu at mainbus0: not configured
mpbios0: bus 0 is type PCI   
mpbios0: bus 64 is type ISA   
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
uvm_fault(0xd08627d8, 0xd0a68000, 0, 4) -> d
fatal page fault (6) in supervisor mode
trap type 6 code 11 eip d0a68c40 cs 8 eflags 10246 cr2 d0a68c40 cpl 0
panic: trap type 6, code=11, pc=d0a68c40

The operating system has halted.
Please press any key to reboot.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: i386-current bsd.rd fails on net6501

[Mark Kettenis]

> Date: Tue, 8 Sep 2015 18:28:12 +0200
> From: Christian Weisgerber 
> 
> When I try to boot bsd.rd from the Sep 7 i386 snapshot on my Soekris
> net6501, it blows up.
> 
> boot> boot bsd.rd
> booting hd0a:bsd.rd: 3176316+1310736+2057216+0+425984 
> [72+247696+238008]=0x71eb2c
> entry point at 0x2000d4 [7205c766, 3404, 24448b12, e568a304]
> 
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2015 OpenBSD. All rights reserved.  http://www.OpenBSD.org
> 
> OpenBSD 5.8-current (RAMDISK_CD) #1123: Mon Sep  7 07:13:10 MDT 2015
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
> cpu0: Genuine Intel(R) CPU @ 1.00GHz ("GenuineIntel" 686-class) 1.01 GHz
> cpu0: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF,SENSOR
> real mem  = 1073131520 (1023MB)
> avail mem = 1043435520 (995MB)
> mainbus0 at root
> bios0 at mainbus0: date 20/21/15, BIOS32 rev. 0 @ 0xfac40
> mpbios0 at bios0: Intel MP Specification 1.4
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2.0.3, IBE
> cpu at mainbus0: not configured
> mpbios0: bus 0 is type PCI   
> mpbios0: bus 64 is type ISA   
> ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
> uvm_fault(0xd08627d8, 0xd0a68000, 0, 4) -> d
> fatal page fault (6) in supervisor mode
> trap type 6 code 11 eip d0a68c40 cs 8 eflags 10246 cr2 d0a68c40 cpl 0
> panic: trap type 6, code=11, pc=d0a68c40

Does the bsd kernel from the same snapshot blow up as well?

Re: i386-current bsd.rd fails on net6501

[Andre Smagin]

On Tue, 8 Sep 2015 18:28:12 +0200
Christian Weisgerber  wrote:

> When I try to boot bsd.rd from the Sep 7 i386 snapshot on my Soekris
> net6501, it blows up.
 
> uvm_fault(0xd08627d8, 0xd0a68000, 0, 4) -> d
> fatal page fault (6) in supervisor mode
> trap type 6 code 11 eip d0a68c40 cs 8 eflags 10246 cr2 d0a68c40 cpl 0
> panic: trap type 6, code=11, pc=d0a68c40

Sounds just like the problem I ran into a week ago (reported here):
http://openbsd-archive.7691.n7.nabble.com/quot-kernel-page-fault-trap-quot-uvm-fault-in-current-i386-td277207.html

--
Andre

Re: Weekly network disconnect with G4 Mac Mini (gem0)

[Mark Kettenis]

> From: Carlos Fenollosa 
> Date: Tue, 8 Sep 2015 17:28:08 +0200
> 
> > On 07 Sep 2015, at 20:40, Stuart Henderson  wrote:
> > 
> > On 2015/09/07 20:26, Landry Breuil wrote:
> >> I cant help you on the issue itself, but i can confirm you that i've
> >> been seeing the exact same issue with gem0 on my g4 mac mini here, and
> >> since some releases. randomly, gem0 just doesnt receive/send pkts
> >> anymore and needs to be downed/upped.
> > 
> > Interesting - I don't see that on mine.
> > 
> > Out of interest does your switch have flow control enabled? (you will
> > see rxpause and/or txpause in the ifconfig output). If it does, is there
> > any change if you disable it on the switch (if you can do so)?
> > 
> > gem0: flags=8863 mtu 1500
> >lladdr 00:0d:93:63:da:5a
> >priority: 0
> >groups: egress
> >media: Ethernet autoselect (100baseTX full-duplex)
> >status: active
> 
> Yes, it seems to be the case:
> 
> gem0: flags=8863 mtu 1500
> lladdr 00:11:24:87:a7:64
> priority: 0
> groups: egress
> media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
> status: active
> inet 192.168.1.199 netmask 0xff00 broadcast 192.168.1.255
> 
> 
> I have a crappy telco router, I’m actually not sure if I
> can disable it there. There is a section on QoS, but the option is
> disabled.  Could the driver be forced to disable flow control? At
> least I could try running it for a couple weeks to see if the bug is
> triggered again.

Diff below should do the trick.

Index: gem.c
===
RCS file: /cvs/src/sys/dev/ic/gem.c,v
retrieving revision 1.112
diff -u -p -r1.112 gem.c
--- gem.c   24 Jun 2015 09:40:54 -  1.112
+++ gem.c   8 Sep 2015 15:36:45 -
@@ -240,7 +240,7 @@ gem_config(struct gem_softc *sc)
 
gem_mifinit(sc);
 
-   mii_flags = MIIF_DOPAUSE;
+   mii_flags = 0;
 
/* 
 * Look for an external PHY.

Re: i386-current bsd.rd fails on net6501

[Christian Weisgerber]

Mark Kettenis:

> Does the bsd kernel from the same snapshot blow up as well?

Yes.

booting hd0a:bsd.i386: 7520308+2015344+189444+0+1069056 
[72+411072+405023]=0xb155c4
entry point at 0x2000d4 [7205c766, 3404, 24448b12, de60a304]

[ using 816580 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2015 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 5.8-current (GENERIC) #1156: Mon Sep  7 07:02:35 MDT 2015
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Genuine Intel(R) CPU @ 1.00GHz ("GenuineIntel" 686-class) 1.01 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF,SENSOR
real mem  = 1073086464 (1023MB)
avail mem = 1040211968 (992MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 20/21/15, BIOS32 rev. 0 @ 0xfac40
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2.0.3, IBE
cpu at mainbus0: not configured
mpbios0: bus 0 is type PCI   
mpbios0: bus 64 is type ISA   
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
uvm_fault(0xd0b6c5e0, 0xd0d7e000, 0, 4) -> d
kernel: page fault trap, code=0
Stopped at  __kernel_bss_end+0x130c40:  cmpl$0x49435024,%eax
ddb> 

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: Weekly network disconnect with G4 Mac Mini (gem0)

[Stuart Henderson]

On 2015/09/08 17:54, Landry Breuil wrote:
> nope, as i said my switch is more than basic..

Many basic switches do actually have that, just no way to disable it.

Hmm then. Any other candidates? We had rx checksumming in for a while but
removed it again.

It's probably worth getting output from systat mb during normal operations
and when it's disconnected.


> gem0: flags=8863 mtu 1500
> lladdr 00:14:51:1f:5c:f4
> priority: 0
> media: Ethernet autoselect (100baseTX full-duplex)
> status: active
> inet 10.246.200.1 netmask 0xff00 broadcast 10.255.255.255
> inet6 fe80::214:51ff:fe1f:5cf4%gem0 prefixlen 64 scopeid 0x2
> inet6 2a01:e34:edcb:85c0::1 prefixlen 120
> 
> Landry
>