Re: Random freeze with Thinkpad R400 (7UET46WW)
On Sun, Oct 20, 2013 at 05:32:03PM +0200, Antoine Jacoutot wrote: > On Sun, Oct 20, 2013 at 02:56:52PM +0100, Stuart Henderson wrote: > > On 2013/10/20 15:36, BESSOT Jean-Michel wrote: > > > Hello > > > > > > There is some freeze on Thinkpad R400 in current and they do seem > > > random. It runs well for hours or, sometimes, it just freeze in the > > > first hour after a boot or a resume. I have no Idea on how to trigger it > > > at will. > > > > Do you use apmd, especially with any auto-speed-changing flags? If so, > > try disabling it - either run it with no flags, or don't run it completely - > > one or other of these has fixed hangs for several people. > > Don't run it at all. It will not fix your hangs but migitate them by a huge > amount. > I only see hangs with GENERIC.MP. I've no problems with GENERIC. Maybe this helps to other users. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: repeatable isakmpd kernel panic using shrewsoft vpn client
On 2013/10/21 10:29, iamatt wrote: > I do not have the console debug screen but I do have the files from > /var/crash/ Is there some commands I can run on them using gdb that can > be of use? If you have a crashdump, possibly, see "man crash". As the panic message goes, RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! This is much easier than for somebody else to install Linux and the shrewsoft client before they can even start looking at the bug (and even then, they might not be able to replicate it).
Re: repeatable isakmpd kernel panic using shrewsoft vpn client
I do not have the console debug screen but I do have the files from
/var/crash/ Is there some commands I can run on them using gdb that can
be of use?
Re,
Matt
On Oct 19, 2013 4:46 AM, "Stuart Henderson" wrote:
> Please include the panic message and output from 'trace' in ddb.
>
> iamatt wrote:
> >Synopsis: Shrewsoft vpn client 2.2.0 (linux) causes openbsd to kernel
> >panic
> >Category: isakmpd using basic psk
> >Environment:
> >System : OpenBSD 5.4
> >Details : OpenBSD 5.4-current (GENERIC) #63: Tue Oct 1
> >12:33:25 MDT 2013
> > dera...@i386.openbsd.org:
> >/usr/src/sys/arch/i386/compile/GENERIC
> >
> >Architecture: OpenBSD.i386
> >Machine : i386
> >Description:
> >The Shrewsoft VPN client compiled version 2.2.0 for linux immediately
> >causes the openbsd server to kernel panic when initiating a connection.
> >Other vpn clients (strongswan, and NCP vpn for android ) do not crash
> >the
> >server.
> >
> >sample ipsec.conf
> >
> >#isakmpd -4dv && ipsecctl -F -f /etc/ipsec.conf
> >
> >dmz="172.18.1.0/24"
> >lan="10.22.1.0/24"
> >ike passive esp from any to {$dmz, $lan} \
> >main auth hmac-sha1 enc 3des \
> >quick auth hmac-sha1 enc 3des \
> >psk whatthehell
> >
> >shrewsoft client version (http://www.shrew.net)
> >
> >matt@linux-smuw:~> ikec -v
> >ii : ## : VPN Connect, ver 2.2.0
> >## : Copyright 2013 Shrew Soft Inc.
> >
> >linux-smuw:/home/matt # /usr/sbin/iked
> >ii : created ike socket 0.0.0.0:500
> >ii : created natt socket 0.0.0.0:4500
> >## : IKE Daemon, ver 2.2.0
> >## : Copyright 2013 Shrew Soft Inc.
> >## : This product linked OpenSSL 1.0.1e 11 Feb 2013
> >
> >
> >
> >How-To-Repeat:
> >Initiate an ikev1 vpn connection to openbsd using the ipsec.conf file
> >and
> >shrewsoft vpn client versions included in this bug report.
> >Fix:
> >
> >dmesg:
> >OpenBSD 5.4-current (GENERIC) #63: Tue Oct 1 12:33:25 MDT 2013
> >dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> >cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD"
> >586-class)
> >500 MHz
> >cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
> >real mem = 536408064 (511MB)
> >avail mem = 515915776 (492MB)
> >mainbus0 at root
> >bios0 at mainbus0: AT/286+ BIOS, date 20/71/05, BIOS32 rev. 0 @ 0xfac40
> >pcibios0 at bios0: rev 2.0 @ 0xf/0x1
> >pcibios0: pcibios_get_intr_routing - function not supported
> >pcibios0: PCI IRQ Routing information unavailable.
> >pcibios0: PCI bus #0 is the last bus
> >bios0: ROM list: 0xc8000/0xa800
> >cpu0 at mainbus0: (uniprocessor)
> >amdmsr0 at mainbus0
> >pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> >0:20:0: io address conflict 0x6100/0x100
> >0:20:0: io address conflict 0x6200/0x200
> >pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x31
> >glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
> >vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11,
> >address 00:00:24:c9:58:d0
> >ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> >0x004063, model 0x0034
> >vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5,
> >address 00:00:24:c9:58:d1
> >ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> >0x004063, model 0x0034
> >vr2 at pci0 dev 8 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 9,
> >address 00:00:24:c9:58:d2
> >ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> >0x004063, model 0x0034
> >vr3 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12,
> >address 00:00:24:c9:58:d3
> >ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> >0x004063, model 0x0034
> >glxpcib0 at pci0 dev 20 function 0 "AMD CS5536 ISA" rev 0x03: rev 3,
> >32-bit
> >3579545Hz timer, watchdog, gpio, i2c
> >gpio0 at glxpcib0: 32 pins
> >iic0 at glxpcib0
> >pciide0 at pci0 dev 20 function 2 "AMD CS5536 IDE" rev 0x01: DMA,
> >channel 0
> >wired to compatibility, channel 1 wired to compatibility
> >wd0 at pciide0 channel 0 drive 1:
> >wd0: 1-sector PIO, LBA, 7631MB, 15630048 sectors
> >wd0(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2
> >pciide0: channel 1 ignored (disabled)
> >ohci0 at pci0 dev 21 function 0 "AMD CS5536 USB" rev 0x02: irq 15,
> >version
> >1.0, legacy support
> >ehci0 at pci0 dev 21 function 1 "AMD CS5536 USB" rev 0x02: irq 15
> >usb0 at ehci0: USB revision 2.0
> >uhub0 at usb0 "AMD EHCI root hub" rev 2.00/1.00 addr 1
> >isa0 at glxpcib0
> >isadma0 at isa0
> >com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> >com0: console
> >com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
> >pckbc0 at isa0 port 0x60/5
> >pckbd0 at pckbc0 (kbd slot)
> >pckbc0: using irq 1 for kbd slot
> >wskbd0 at pckbd0: console keyboard
> >pcppi0 at isa0 port 0x61
> >spkr0 at pcppi0
> >nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 10: GPIO VLM TMS
> >gpio1 at nsclpcsio0: 29 pins
> >npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 1
Re: Regular Kernel Panic
I managed to get into the office early today to boot into single user mode and run fsck. Sure enough, the /var file system had some serious errors that are now fixed. All the other file systems seemed fine. Hopefully the problem is resolved; I should only have to wait a couple of days before I can confirm. On 18 October 2013 13:19, Peter Green wrote: > Thanks Otto, > > When it's appropriate, I will do as suggested. :) > > Pete > > > On 18 October 2013 12:19, Otto Moerbeek wrote: > >> On Fri, Oct 18, 2013 at 10:57:56AM +0100, Peter Green wrote: >> >> > Hi, >> > >> > I have a Dell R200 running OpenBSD 4.9, which operates as the edge >> router >> > for our office. It's been working for a long time without any >> intervention >> > required until recently, when it began exhibiting kernel panics. >> > >> > At first, I thought it was a random occurrence, but I dutifully took >> screen >> > shots of trace and ps outputs via dbb and rebooted the box. Since that >> > time, it's happened on two or three further occasions, but >> unfortunately, I >> > wasn't the one in the office and so no screen caps were taken. >> > >> > Today, I arrived at the office to find the system panicked again, so I >> took >> > screen caps and compared them to the first time it happened. I'm not >> > experienced in debugging BSD kernel panicks, but it appears that the >> same >> > function is causing the problem: ffs_blkfree() >> > >> > My initial searches online seem to suggest this is potentially a problem >> > with the disk(s); perhaps a bad block. The machine runs a Symbios Logic >> > SAS1068E hardware RAID controller, which appears to the OS as a device >> > mpi0. Running bioctl mpi0 shows the following: >> > >> > # bioctl mpi0 >> > Volume Status Size Device >> > mpi0 0 Online 249376538112 sd0 RAID1 >> > 0 Online 24999488 0:8.0 noencl > > MA08> >> > 1 Online 24999488 0:1.0 noencl > > MA08> >> > >> > >> > So, the RAID controller seems to think the underlying disks are ok. >> > >> > Here are the links for the dbb output I grabbed on both occasions: >> > >> > https://www.dropbox.com/s/vmvuzn3qg2af85l/2013-10-10%2008.53.35.jpg >> > >> > https://www.dropbox.com/s/r9jaofaotvjr6gx/2013-10-10%2008.53.41.jpg >> > >> > https://www.dropbox.com/s/creu48dcb48yirh/2013-10-10%2008.53.49.jpg >> > >> > https://www.dropbox.com/s/w0h4sjkkfe5ns1j/2013-10-10%2008.56.17.jpg >> > >> > https://www.dropbox.com/s/5ol10lmaznii3yp/2013-10-10%2008.56.30.jpg >> > >> > https://www.dropbox.com/s/154er8pans2dph5/2013-10-18%2009.29.51.jpg >> > >> > https://www.dropbox.com/s/aqte9poi8p4ezcp/2013-10-18%2009.30.21.jpg >> > >> > https://www.dropbox.com/s/lxl5l8vylavo64o/2013-10-18%2009.30.30.jpg >> > >> > https://www.dropbox.com/s/g2zf1fnk2zrvqml/2013-10-18%2009.30.34.jpg >> > >> > https://www.dropbox.com/s/wnpx6mh7uyrlht2/2013-10-18%2009.30.53.jpg >> > >> > https://www.dropbox.com/s/amf8z1s73g8ovxi/2013-10-18%2009.31.00.jpg >> > >> > https://www.dropbox.com/s/q0yf37n6wbr98cl/2013-10-18%2009.31.06.jpg >> > >> > I hope this helps. As I've stated, I suspect a hardware issue, but I'd >> just >> > like some further analysis from people more experienced than I. >> > >> > Thanks, >> > >> > Pete >> >> Could indeeed be hardware, but first make sure your filesystems are >> not corrupt: >> >> boot into single user more and force a check of all filesystems: fsck -f >> This exercises disk and memory as well. >> >> -Otto
