Disabling glxsb in kernel prevents the system from crashing.  

mb

On Mon, Oct 28, 2013 at 02:19:03PM -0500, iamatt wrote:
> Ok got working and recompiled kernel, installed.
> 
> Still can crash system while connecting
> 
> login: Data modified on freelist: word 153278916 of object 0xd172ad20 size
> 0x20)
> panic: Data modified on freelist: word 3 of object 0xd172ad20 size 0x20
> previou)
> 
> 
> Starting stack
> trace...
> panic(d097eaed,f53be6d8,d095a824,f53be6d8,d0a9e034) at
> panic+0x75
> panic(d095a824,d095a7cc,3,d172ad20,20) at
> panic+0x75
> malloc(20,4c,1,f53be7b8,d0b0e220) at
> malloc+0x5e4
> esp_init(d175e000,d0a9fcf8,f53be900,d175bb80,d175bb38) at
> esp_init+0x148
> pfkeyv2_send(d5d10008,d175ba00,198,d175bb98,d0b0e220) at
> pfkeyv2_send+0x175a
> pfkey_register(d5d96800,d5d10008,f53bedbc,d03c3d3a,8acde240) at
> pfkey_register+8
> raw_usrreq(d5d10008,9,d5d96800,0,0) at
> raw_usrreq+0x221
> sosend(d5d10008,0,f53beeb0,d5d96800,0) at
> sosend+0x48d
> soo_write(d5d170ac,d5d170c8,f53beeb0,d5e2a2d0,e3b7a840) at
> soo_write+0x3b
> dofilewritev(d5d3f618,8,d5d170ac,82c75600,11) at
> dofilewritev+0x133
> sys_writev(d5d3f618,f53bef64,f53bef84,f53befa8,d5e1b600) at
> sys_writev+0x7c
> syscall() at syscall+0x1f9
> --- syscall (number 5)
> ---
> 0x2:
> 
> End of stack
> trace.
> syncing disks... 21 21 21 21 15 4
> done
> 
> 
> 
> On Fri, Oct 25, 2013 at 11:00 PM, Philip Guenther 
> <[email protected]>wrote:
> On Fri, 25 Oct 2013, iamatt wrote:
> > Hello that does not work.  I've downloaded the patch using mutt and
> > still fails.  Would really like to try and see if this works and not
> > sure what I am doing wrong.
> 
> How are we to diagnose why it's not working if you don't describe in any
> way what happened when you tried to do so?  When in doubt, show what
> output!
> 
> 
> Here's what's happen when I (successfully) do it.  Note: my shell's prompt
> is ": morgaine; ".
> 
> : morgaine; cd /usr/src
> : morgaine; cvs -q up -APd sys/arch/i386
> : morgaine; ftp -o- '
> http://marc.info/?l=openbsd-bugs&m=138252383014899&q=raw'  | patch
> Trying 173.79.223.25...
> Requesting http://marc.info/?l=openbsd-bugs&m=138252383014899&q=raw
> 7395 bytes received in 0.12 seconds (60.95 KB/s)
> Hmm...  Looks like a unified diff to me...
> The text leading up to this was:
> --------------------------
> |On Wed, Oct 23, 2013 at 08:45 +0100, Stuart Henderson wrote:
> |> The panic seems odd (0x594f69b5 !=
> |> 0x594f69b5 - these are the same value)       , maybe someone else will
> be able to comment on that.
> |>
> |> It would be useful to know what isakmpd is doing at the time e.g. run it
> in the foreground with fairly high debug settings (maybe "isakmpd -K -d
> -DA=99" and "ipsecctl -f /etc/ipsrc.conf" - there will be a lot of output
> so run from ssh not serial console).
> |>
> |> You may be able to workaround by using 'boot -c' at the bootloader
> prompt, then 'disable glxsb' and 'quit', or the kernel on-disk could be
> modified using 'config -ef /bsd'. (glxsb is for hardware AES acceleration
> for Geode LX systems).
> |>
> |> iamatt <[email protected]> wrote:
> |> ># Data modified on freelist: word 153288032 of object 0xd17218e0 size
> |> >0x18
> |> >previ
> |> >ous type ??? (invalid addr
> |> >0x3557935e)
> |> >panic: Data modified on freelist: word 3 of object 0xd17218e0 size 0x18
> |> >previous
> |> > type ??? (0x594f69b5 !=
> |> >0x594f69b5)
> |> >
> |> >
> |> >Stopped at      Debugger+0x4:   popl
> |> >%ebp
> |> >RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS
> |> >PANIC!
> |> >DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT
> |> >INFORMATION!
> |> >ddb>
> |> >trace
> |> >Debugger(d0976848,f53be668,
> >
> > d0952384,f53be668,d0a95014) at
> > |> >Debugger+0x4
> > |> >panic(d0952384,d095232c,3,d17218e0,18) at
> > |> >panic+0x67
> > |> >malloc(18,6c,a,f53be6fc,d1613000) at
> > |> >malloc+0x5e4
> > |> >glxsb_crypto_newsession(f53be73c,f53be794,0,10,40) at
> > |> >glxsb_crypto_newsession+0
> > |> >x133
> > |> >
> > |> >crypto_newsession(d17264f0,f53be794,0,f53be7b8,d0b05340) at
> > |> >crypto_newsession+0
> > |> >x135
> > |> >
> > |> >esp_init(d1726400,d0a96cd8,f53be900,d1724f50,d1724f68) at
> > |> >esp_init+0x245
> > |> >pfkeyv2_send(d5d1f008,d1724e00,198,d1724f98,d0b05340) at
> > |> >pfkeyv2_send+0x1a6e
> > |> >pfkey_register(d5d8cc00,d5d1f008,f53bedbc,d03c0a4a,88ab98a0) at
> > |> >pfkey_register+
> > |> >0x278
> > |> >
> > |> >raw_usrreq(d5d1f008,9,d5d8cc00,0,0) at
> > |> >raw_usrreq+0x221
> > |> >sosend(d5d1f008,0,f53beeb0,d5d8cc00,0) at
> > |> >sosend+0x48d
> > |> >soo_write(d5d230ac,d5d230c8,f53beeb0,d5e202d0,55187908) at
> > |> >soo_write+0x3b
> > |> >dofilewritev(d5d3c618,8,d5d230ac,84fa7500,11) at
> > |> >dofilewritev+0x133
> > |> >sys_writev(d5d3c618,f53bef64,f53bef84,f53befa8,d5e11600) at
> > |> >sys_writev+0x7c
> > |> >syscall() at
> > |> >syscall+0x1f9
> > |> >--- syscall (number 5)
> > |> >---
> > |> >0x2:
> > |> >
> > |> >ddb>
> > |> >ps
> > |> >   PID   PPID   PGRP    UID  S       FLAGS  WAIT
> > |> >COMMAND
> > |> > 31132      1  31132      0  3        0x83  ttyin
> > |> >ksh
> > |> >  6230      1   6230      0  3        0x80  select
> > |> >cron
> > |> >  1331      1   1331    601  3        0x90  kqread
> > |> >unbound
> > |> > 30501      1  30501    535  3        0x90  nanosleep
> > |> >symon
> > |> > 16688      1  16688     99  3        0x90  poll
> > |> >sndiod
> > |> > 27774  30105  30105      0  3        0xb0  netcon2
> > |> >sendmail
> > |> > 30105      1  30105      0  3        0xb0  select
> > |> >sendmail
> > |> > 11400      1  11400     77  3        0x90  poll
> > |> >dhcpd
> > |> >  1054      1   1054      0  3        0x80  kqread
> > |> >ifstated
> > |> >  7646      1   7646      0  3        0x80  select
> > |> >sshd
> > |> > 18014      0      0      0  3    0x100280  nfsidl
> > |> >nfsio
> > |> > 20915      0      0      0  3    0x100280  nfsidl
> > |> >nfsio
> > |> >  8480      0      0      0  3    0x100280  nfsidl
> > |> >nfsio
> > |> > 13835      0      0      0  3    0x100280  nfsidl
> > |> >nfsio
> > |> >*25527  31834  31834     68  7        0x10
> > |> >isakmpd
> > |> > 31834      1  31834      0  3        0x80  netio
> > |> >isakmpd
> > |> > 19715  24693  17897     83  3        0x90  poll
> > |> >ntpd
> > |> > 24693  17897  17897     83  3        0x90  poll
> > |> >ntpd
> > |> > 17897      1  17897      0  3        0x80  poll
> > |> >ntpd
> > |> >   630   4742   4742     74  3        0x90  bpf
> > |> >pflogd
> > |> >  4742      1   4742      0  3        0x80  netio
> > |> >pflogd
> > |> >  9803   9138   9138     73  2        0x90
> > |> >syslogd
> > |> >  9138      1   9138      0  3        0x80  netio
> > |> >syslogd
> > |> > 18744      1  18744     77  3        0x90  poll
> > |> >dhclient
> > |> > 22501      1  22501      0  3        0x80  poll
> > |> >dhclient
> > |> >    13      0      0      0  3    0x100200  aiodoned
> > |> >aiodoned
> > |> >    12      0      0      0  3    0x100200  syncer
> > |> >update
> > |> >    11      0      0      0  3    0x100200  cleaner
> > |> >cleaner
> > |> >    10      0      0      0  3    0x100200  reaper
> > |> >reaper
> > |> >     9      0      0      0  3    0x100200  pgdaemon
> > |> >pagedaemon
> > |> >     8      0      0      0  3    0x100200  bored
> > |> >crypto
> > |> >     7      0      0      0  3    0x100200  pftm
> > |> >pfpurge
> > |> >     6      0      0      0  3    0x100200  usbtsk
> > |> >usbtask
> > |> >     5      0      0      0  3    0x100200  usbatsk
> > |> >usbatsk
> > |> >     4      0      0      0  3    0x100200  bored
> > |> >syswq
> > |> >     3      0      0      0  3  0x40100200
> > |> >idle0
> > |> >     2      0      0      0  3    0x100200  kmalloc
> > |> >kmthread
> > |> >     1      0      1      0  3        0x82  wait
> > |> >init
> > |> >     0     -1      0      0  3       0x200  scheduler
> > |> >swapper
> > |> >ddb>
> > |> >
> > |> >
> > |> >
> > |> >On Mon, Oct 21, 2013 at 5:20 PM, Stuart Henderson <[email protected]>
> > |> >wrote:
> > |> >
> > |> >> 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).
> > |>
> > |
> > |hi,
> > |
> > |this is partially my screwup.  please try the diff below.  we
> > |forget to actually allocate the memory for our key schedule
> > |but free it later on in the glxsb_crypto_freesession.  that's
> > |why you get memory corruption all the way.
> > |
> > |it has another seemingly unrelated chunk (pctr.h -> cpufunc.h
> > |change) that i would like to commit as well (perhaps separately)
> > |to limit pctr.h usage in kernel.  so it would be nice to test
> > |the whole thing together.
> > |
> > |i also reformat one malloc block to shorten it (:
> > |
> > |ok's are welcome (assuming this will pass the test).
> > |
> > |diff --git sys/arch/i386/pci/glxsb.c sys/arch/i386/pci/glxsb.c
> > |index dacb500..59a7e06 100644
> > |--- sys/arch/i386/pci/glxsb.c
> > |+++ sys/arch/i386/pci/glxsb.c
> > --------------------------
> > Patching file sys/arch/i386/pci/glxsb.c using Plan A...
> > Hunk #1 succeeded at 32.
> > Hunk #2 succeeded at 398.
> > done
> > : morgaine;
> >
> >
> > Philip Guenther

Reply via email to