Re: kernel panic: uvm_fault

[Thomas Klausner <wiz%NetBSD.org@localhost>]

On Mon, Jan 26, 2015 at 10:01:41AM -0500, Thor Lancelot Simon wrote:
> alloc_bouncebus?  On amd64?  I think you've got a trashed pointer
> somewhere.

I have
makeoptions   DEBUG="-g"      # compile full symbol table

# grep -r _bus_dma_alloc_bouncebuf /usr/src/sys/arch/amd64/
Binary file /usr/src/sys/arch/amd64/compile/obj/KERNELNAME/bus_dma.o matches

 Thomas

> On Mon, Jan 26, 2015 at 02:47:55PM +0100, Thomas Klausner wrote:
> > On Mon, Dec 22, 2014 at 03:56:43PM +0000, Robert Swindells wrote:
> > > 
> > > Thomas Klausner wrote:
> > > >On Mon, Dec 22, 2014 at 03:29:58PM +0000, Robert Swindells wrote:
> > > >> 
> > > >> Thomas Klausner wrote:
> > > >> >I had a kernel panic today with a amd64/7.99.3 kernel from Dec 20. The
> > > >> >last activity I had started was downloading a file from network to an
> > > >> >NFS directory mounted from a Synology.
> > > 
> > > >> It looks the same as the panic you had back in September to me:
> > > >> 
> > > >> <http://mail-index.netbsd.org/current-users/2014/09/13/msg025777.html>
> > > >> 
> > > >> Can you turn on HW checksumming on this machine ?
> > > 
> > > >I've just done that ("ifconfig wm0 tcp4csum ip4csum udp4csum"):
> > > >
> > > >wm0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> > > >	capabilities=7ff80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx>
> > > >	capabilities=7ff80<TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx>
> > > >	capabilities=7ff80<TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6>
> > > >	enabled=3f00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx>
> > > >	enabled=3f00<UDP4CSUM_Rx,UDP4CSUM_Tx>
> > > >	ec_capabilities=7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
> > > >	ec_enabled=0
> > > >...
> > > >
> > > >I had in the back of my memory that hardware checksumming was usually
> > > >the cause of bugs, not when it's turned off. Am I misremembering?
> > > 
> > > Depends on the network controller, wm works well for me with
> > > everything enabled.
> > > 
> > > wm0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> > >         capabilities=7ff80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx>
> > >         capabilities=7ff80<TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx>
> > >         capabilities=7ff80<TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6>
> > >         enabled=7ff80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx>
> > >         enabled=7ff80<TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx>
> > >         enabled=7ff80<TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6>
> > >         ec_capabilities=7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
> > >         ec_enabled=0
> > > 
> > > I have had similar crashes to you when using sw checksumming on
> > > amd64, never seen it on i386 or arm.
> > > 
> > > There was also this:
> > > 
> > > <http://mail-index.netbsd.org/port-sparc64/2014/11/29/msg002298.html>
> > > 
> > > I guess we need to add some more KASSERT() checks.
> > 
> > Ok, the Synology installed an opsys update again last night, and a
> > couple minutes ago I tried writing to a still-mounted file system from
> > it. And got a panic. From dmesg:
> > 
> > 192.168.1.2:/volume1/roms: re-enabling wcc
> > 192.168.1.2:/volume1/video: re-enabling wcc
> > panic: _bus_virt_to_bus
> > cpu1: Begin traceback...
> > vpanic() at netbsd:vpanic+0x13c
> > snprintf() at netbsd:snprintf
> > _bus_dma_alloc_bouncebuf() at netbsd:_bus_dma_alloc_bouncebuf
> > bus_dmamap_load_mbuf() at netbsd:bus_dmamap_load_mbuf+0xf0
> > wm_nq_start() at netbsd:wm_nq_start+0x1c5
> > ifq_enqueue() at netbsd:ifq_enqueue+0xae
> > ether_output() at netbsd:ether_output+0x579
> > ip_output() at netbsd:ip_output+0xdeb
> > tcp_output() at netbsd:tcp_output+0x15cf
> > tcp_send_wrapper() at netbsd:tcp_send_wrapper+0xa2
> > sosend() at netbsd:sosend+0x712
> > nfs_send() at netbsd:nfs_send+0x8e
> > nfs_request() at netbsd:nfs_request+0x39d
> > nfs_writerpc() at netbsd:nfs_writerpc+0x3b0
> > nfs_doio() at netbsd:nfs_doio+0x250
> > nfssvc_iod() at netbsd:nfssvc_iod+0x1a1
> > cpu1: End traceback...
> > 
> > 
> > I had and still have all the checksum options turned on as you
> > suggested.
> > 
> > wm0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> >         capabilities=7ff80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx>
> >         capabilities=7ff80<TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx>
> >         capabilities=7ff80<TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6>
> >         enabled=3ff00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx>
> >         enabled=3ff00<UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx,TCP6CSUM_Tx>
> >         enabled=3ff00<UDP6CSUM_Rx,UDP6CSUM_Tx>
> >         ec_capabilities=7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
> >         ec_enabled=0
> >  
> > At least the backtrace looks nfs related this time :)
> >  Thomas
> 
> -- 
>  Thor Lancelot Simon	                                      tls%panix.com@localhost
> "From the tooth paste you use in the morning to the salt on your evening meal,
> it's easy to take for granted the many products brought to us with explosives."
>     - Institute of Manufacturers of Explosives, "Explosives Make It Possible" 
>