From owner-freebsd-sparc64@FreeBSD.ORG Mon Mar 20 11:03:17 2006 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9BE016A400 for ; Mon, 20 Mar 2006 11:03:17 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D233743D69 for ; Mon, 20 Mar 2006 11:03:11 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k2KB3AA3082681 for ; Mon, 20 Mar 2006 11:03:10 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k2KB38Sv082675 for freebsd-sparc64@freebsd.org; Mon, 20 Mar 2006 11:03:08 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 20 Mar 2006 11:03:08 GMT Message-Id: <200603201103.k2KB38Sv082675@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-sparc64@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2006 11:03:17 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/09/14] sparc64/71729sparc64 printf in kernel thread causes panic on S o [2004/10/21] sparc64/72962sparc64 [sysinstall] Sysinstall panics on sparc64 o [2005/04/27] sparc64/80410sparc64 [netgraph] netgraph is causing crash with o [2005/05/11] sparc64/80890sparc64 [panic] kmem_malloc(73728): kmem_map too o [2005/06/23] sparc64/82569sparc64 USB mass storage plug/unplug causes syste o [2005/11/24] sparc64/89486sparc64 firefox and thunderbird is broken on spar o [2006/01/16] sparc64/91882sparc64 Ultra 10 mouse/keyboard o [2006/01/20] sparc64/92033sparc64 [dc] dc(4) issues on Ultra10 o [2006/03/17] sparc64/94613sparc64 The ethernet address is the same with mul 9 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/10/22] sparc64/72998sparc64 [kernel] [patch] set_mcontext() change sy s [2005/06/26] sparc64/82681sparc64 [dc] dc state messages o [2005/12/13] sparc64/90316sparc64 Keyboard "lock" key lights not working pr f [2006/01/05] sparc64/91334sparc64 FreeBSD 6.0 don't support tftp boot from o [2006/03/07] sparc64/94190sparc64 hw.physmem tunable does not work on sparc o [2006/03/15] sparc64/94483sparc64 ath_hal does not work on 6-release/sparc6 6 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Mon Mar 20 21:17:31 2006 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F036216A400 for ; Mon, 20 Mar 2006 21:17:31 +0000 (UTC) (envelope-from j@uriah.heep.sax.de) Received: from uriah.heep.sax.de (uriah.heep.sax.de [213.240.137.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 088C443D48 for ; Mon, 20 Mar 2006 21:17:31 +0000 (GMT) (envelope-from j@uriah.heep.sax.de) Received: from localhost (localhost [127.0.0.1]) by uriah.heep.sax.de (Postfix) with ESMTP id 13B9813C for ; Mon, 20 Mar 2006 22:17:28 +0100 (MET) Received: from uriah.heep.sax.de (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.2-10) id 31694-0B0369AC; Mon, 20 Mar 2006 22:17:27 +0100 Received: from uriah.heep.sax.de (localhost [127.0.0.1]) by uriah.heep.sax.de (Postfix) with ESMTP id A5F09C6 for ; Mon, 20 Mar 2006 22:17:21 +0100 (MET) Received: from uriah.heep.sax.de (localhost [127.0.0.1]) by uriah.heep.sax.de (Postfix) with ESMTP for ; Mon, 20 Mar 2006 22:17:21 +0100 (MET) Received: (from j@localhost) by uriah.heep.sax.de (8.13.4/8.13.1/Submit) id k2KLHL3Q031691 for freebsd-sparc64@freebsd.org; Mon, 20 Mar 2006 22:17:21 +0100 (MET) (envelope-from j) Date: Mon, 20 Mar 2006 22:17:21 +0100 From: Joerg Wunsch To: freebsd-sparc64@freebsd.org Message-ID: <20060320211720.GB31216@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 User-Agent: Mutt/1.5.11 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on uriah.heep.sax.de X-Spam-Level: X-Spam-Status: No, score=0.0 required=6.5 tests=none autolearn=failed version=3.0.2 X-AntiVirus: checked by AntiVir MailGate (version: 2.0.2-10; AVE: 6.33.0.19; VDF: 6.33.0.62; host: uriah.heep.sax.de) Subject: hme(4) broken on non-sparc64 systems in -current X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joerg Wunsch List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2006 21:17:32 -0000 Even though this problem is not related to sparc64 system (I hope, the least), I think all those who know about hme(4) are listening here. I used to run a PCI QFE card in my (i386) scratch machine at home, for various experiments. After upgrading the machine from a 6-stable of about a year ago to -current, the QFE ceased to work. The symptoms were that I could still ping anyone (even with large packets), but all TCP and UDP traffic seemingly didn't ``arrive'' at the IP stack, even though the packets made it into the NIC at the lowest level (so tcpdump could still display them). This made me suspect the TCP/UDP checksum offloading, and indeed, after uncommenting the checksum capability: Index: if_hme.c =================================================================== RCS file: /home/ncvs/src/sys/dev/hme/if_hme.c,v retrieving revision 1.46 diff -u -r1.46 if_hme.c --- if_hme.c 17 Jan 2006 06:02:22 -0000 1.46 +++ if_hme.c 20 Mar 2006 20:56:54 -0000 @@ -340,9 +340,9 @@ * Tell the upper layer(s) we support long frames/checksum offloads. */ ifp->if_data.ifi_hdrlen = sizeof(struct ether_vlan_header); - ifp->if_capabilities |= IFCAP_VLAN_MTU | IFCAP_HWCSUM; + ifp->if_capabilities |= IFCAP_VLAN_MTU /* | IFCAP_HWCSUM */; ifp->if_hwassist |= sc->sc_csum_features; - ifp->if_capenable |= IFCAP_VLAN_MTU | IFCAP_HWCSUM; + ifp->if_capenable |= IFCAP_VLAN_MTU /* | IFCAP_HWCSUM */; return (0); fail_txdesc: everything works again. If anyone has any further ideas what might have broken this, I'm all ears, otherwise I might start digging down into the code myself. (I don't have a FreeBSD-sparc64 machine running -current around, so I cannot test right now whether it would work there.) -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-sparc64@FreeBSD.ORG Mon Mar 20 21:35:51 2006 Return-Path: X-Original-To: sparc64@FreeBSD.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1859716A400 for ; Mon, 20 Mar 2006 21:35:51 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFF7243D46 for ; Mon, 20 Mar 2006 21:35:50 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 69CAA1A4D91; Mon, 20 Mar 2006 13:35:50 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 22D7151BF0; Mon, 20 Mar 2006 16:35:49 -0500 (EST) Date: Mon, 20 Mar 2006 16:35:48 -0500 From: Kris Kennaway To: Kris Kennaway Message-ID: <20060320213548.GA77776@xor.obsecurity.org> References: <441955A7.1020204@samsco.org> <20060316140435.K95579@newtrinity.zeist.de> <20060316190305.GA25561@xor.obsecurity.org> <20060320165139.D98160@newtrinity.zeist.de> <20060320173134.GA42022@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <20060320173134.GA42022@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i Cc: sparc64@FreeBSD.org Subject: Re: TODO list status update X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2006 21:35:51 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 20, 2006 at 12:31:34PM -0500, Kris Kennaway wrote: > > > Another problem is in hardclock: > > >=20 > > > panic: blockable sleep lock (sleep mutex) system map @ vm/vm_map.c:29= 95 > > > cpuid =3D 2 > > > KDB: enter: panic > > > [thread pid 35 tid 100037 ] > > > Stopped at kdb_enter+0x3c: ta %xcc, 1 > > > db> wh > > > Tracing pid 35 tid 100037 td 0xfffff803fe9faac0 > > > panic() at panic+0x164 > > > witness_checkorder() at witness_checkorder+0xc8 > > > _mtx_lock_flags() at _mtx_lock_flags+0x80 > > > _vm_map_lock_read() at _vm_map_lock_read+0x3c > > > vm_map_lookup() at vm_map_lookup+0x1c > > > vm_fault() at vm_fault+0x68 > > > trap_pfault() at trap_pfault+0x1a8 > > > trap() at trap+0x2b0 > > > -- fast data access mmu miss tar=3D0x18c0790000 %o7=3D0xc01c24d0 -- > > > witness_checkorder() at witness_checkorder+0x1c4 > > > _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x7c > > > hardclock_cpu() at hardclock_cpu+0x20 > > > tick_hardclock() at tick_hardclock+0xc4 > > > -- interrupt level=3D0xe pil=3D0 %o7=3D0xc01c2f9c -- > >=20 > > Sorry, I'm missing the big picture to determine what's at > > fault here. Knowing what tick_hardclock() did interrupt > > probably would help. Shouldn't be the another page fault > > though as then PIL still would be set to 14 which in > > turn means tick interrupts are turned off in the first > > place. >=20 > I'll grab another trace next time it happens. Here's another panic: SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! sssiinnlckkssched loc hhl bbb 0xfffff802be9e22d0fooo 55seconds spin lock sched lock held by 0xfffff802be9eb2d0 for > 5 seconds KDB: stack backtrace: _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0xdc hardclock_cpu() at hardclock_cpu+0x20 hardclock() at hardclock+0x8 tick_hardclock() at tick_hardclock+0xac -- interrupt level=3D0xe pil=3D0 %o7=3D0xc01c4898 -- strncmp() at strncmp+0x54 witness_unlock() at witness_unlock+0x5c _mtx_unlock_flags() at _mtx_unlock_flags+0x7c fdinit() at fdinit+0xc0 fdcopy() at fdcopy+0x10 fork1() at fork1+0x768 kthread_create() at kthread_create+0x3c kproc_start() at kproc_start+0x24 mi_startup() at mi_startup+0x12c btext() at btext+0x34 panic: spin lock held too long cpuid =3D 0 KDB: enter: panic [thread pid 0 tid 0 ] Stopped at kdb_enter+0x3c: ta %xcc, 1 db> KDB: stack backtrace: _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0xdc hardclock_cpu() at hardclock_cpu+0x20 tick_hardclock() at tick_hardclock+0xc4 -- interrupt level=3D0xe pil=3D0 %o7=3D0xc018a278 -- _mtx_lock_spin() at _mtx_lock_spin+0x110 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0xdc cpu_mp_bootstrap() at cpu_mp_bootstrap+0xa8 mp_startup() at mp_startup+0xbc mtx_pool_destroy() at mtx_pool_destroy+0x8 KDB: stack backtrace: _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0xdc hardclock_cpu() at hardclock_cpu+0x20 tick_hardclock() at tick_hardclock+0xc4 -- interrupt level=3D0xe pil=3D0 %o7=3D0xc018a184 -- _mtx_lock_sleep() at _mtx_lock_sleep+0x140 _mtx_lock_flags() at _mtx_lock_flags+0xb8 start_init() at start_init+0x18 fork_exit() at fork_exit+0x94 fork_trampoline() at fork_trampoline+0x8 KDB: stack backtrace: _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0xdc hardclock_cpu() at hardclock_cpu+0x20 tick_hardclock() at tick_hardclock+0xc4 -- interrupt level=3D0xe pil=3D0 %o7=3D0xc018a278 -- _mtx_lock_spin() at _mtx_lock_spin+0x114 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0xdc ithread_loop() at ithread_loop+0xf0 fork_exit() at fork_exit+0x94 fork_trampoline() at fork_trampoline+0x8 KDB: stack backtrace: _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0xdc hardclock_cpu() at hardclock_cpu+0x20 tick_hardclock() at tick_hardclock+0xc4 -- interrupt level=3D0xe pil=3D0 %o7=3D0xc018a278 -- _mtx_lock_spin() at _mtx_lock_spin+0x114 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0xdc cpu_mp_bootstrap() at cpu_mp_bootstrap+0xa8 mp_startup() at mp_startup+0xbc KDB: stack backtrace: _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0xdc hardclock_cpu() at hardclock_cpu+0x20 tick_hardclock() at tick_hardclock+0xc4 -- interrupt level=3D0xe pil=3D0 %o7=3D0xc018a184 -- _mtx_lock_sleep() at _mtx_lock_sleep+0x140 _mtx_lock_flags() at _mtx_lock_flags+0xb8 ithread_execute_handlers() at ithread_execute_handlers+0x138 ithread_loop() at ithread_loop+0xa4 fork_exit() at fork_exit+0x94 fork_trampoline() at fork_trampoline+0x8 KDB: stack backtrace: _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0xdc hardclock_cpu() at hardclock_cpu+0x20 tick_hardclock() at tick_hardclock+0xc4 -- interrupt level=3D0xe pil=3D0 %o7=3D0xc018a278 -- _mtx_lock_spin() at _mtx_lock_spin+0x110 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0xdc cpu_mp_bootstrap() at cpu_mp_bootstrap+0xa8 mp_startup() at mp_startup+0xbc blk_dump() at blk_dump+0x10c KDB: stack backtrace: _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0xdc hardclock_cpu() at hardclock_cpu+0x20 tick_hardclock() at tick_hardclock+0xc4 -- interrupt level=3D0xe pil=3D0 %o7=3D0xc018a278 -- _mtx_lock_spin() at _mtx_lock_spin+0x114 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0xdc roundrobin() at roundrobin+0x18 softclock() at softclock+0x238 ithread_execute_handlers() at ithread_execute_handlers+0x144 ithread_loop() at ithread_loop+0xa4 fork_exit() at fork_exit+0x94 fork_trampoline() at fork_trampoline+0x8 KDB: stack backtrace: _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0xdc hardclock_cpu() at hardclock_cpu+0x20 tick_hardclock() at tick_hardclock+0xc4 -- interrupt level=3D0xe pil=3D0 %o7=3D0xc01acd24 -- cpu_switch() at cpu_switch+0xa0 tl_text_end() at tl_text_end+0xc KDB: stack backtrace: _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0xdc hardclock_cpu() at hardclock_cpu+0x20 tick_hardclock() at tick_hardclock+0xc4 -- interrupt level=3D0xe pil=3D0 %o7=3D0xc018a184 -- _mtx_lock_sleep() at _mtx_lock_sleep+0x12c _mtx_lock_flags() at _mtx_lock_flags+0xb8 vm_daemon() at vm_daemon+0x18 fork_exit() at fork_exit+0x94 fork_trampoline() at fork_trampoline+0x8 KDB: stack backtrace: _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0xdc hardclock_cpu() at hardclock_cpu+0x20 tick_hardclock() at tick_hardclock+0xc4 -- interrupt level=3D0xe pil=3D0 %o7=3D0xc02ed6c8 -- bzero() at bzero+0x68 uma_zalloc_internal() at uma_zalloc_internal+0xe0 uma_zcreate() at uma_zcreate+0x3c swap_pager_swap_init() at swap_pager_swap_init+0xf0 vm_pageout() at vm_pageout+0x26c fork_exit() at fork_exit+0x94 fork_trampoline() at fork_trampoline+0x8 KDB: stack backtrace: _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0xdc hardclock_cpu() at hardclock_cpu+0x20 tick_hardclock() at tick_hardclock+0xc4 -- interrupt level=3D0xe pil=3D0 %o7=3D0xc018a184 -- _mtx_lock_sleep() at _mtx_lock_sleep+0x144 _mtx_lock_flags() at _mtx_lock_flags+0xb8 ithread_execute_handlers() at ithread_execute_handlers+0x138 ithread_loop() at ithread_loop+0xa4 fork_exit() at fork_exit+0x94 fork_trampoline() at fork_trampoline+0x8 These are traces from the other CPUs; I have it hacked to do kdb_backtrace() before trying to enter DDB, since this so often doesn't work. Remarkably, it did this time though: db> show witness Sleep locks: 0 ip6qlock -- last acquired @ netinet6/frag6.c:682 0 ipqlock -- last acquired @ netinet/ip_input.c:1069 0 if_afdata -- last acquired @ net/if.c:539 0 LED sx -- last acquired @ dev/led/led.c:249 2 unit# allocation -- last acquired @ kern/subr_unit.c:592 6 cdev -- last acquired @ kern/kern_conf.c:61 3 UMA zone -- last acquired @ vm/uma_core.c:1841 0 bio queue -- last acquired @ geom/geom_io.c:68 0 GEOM topology -- last acquired @ geom/geom_event.c:183 2 GEOM orphanage -- last acquired @ geom/geom_event.c:196 3 UMA zone -- (already displayed) 2 UMA lock -- last acquired @ vm/uma_core.c:1315 3 UMA zone -- (already displayed) 2 devstat -- last acquired @ kern/subr_devstat.c:83 1 Giant -- last acquired @ dev/ata/ata-all.c:527 2 filedesc structure -- last acquired @ kern/kern_descrip.c:1404 3 pipe mutex -- last acquired @ order list:0 4 sigio lock -- last acquired @ order list:0 5 process group -- last acquired @ kern/kern_fork.c:589 6 process lock -- last acquired @ kern/kern_fork.c:377 7 session -- last acquired @ kern/kern_fork.c:599 8 uidinfo hash -- last acquired @ kern/kern_resource.c:1039 9 uidinfo struct -- last acquired @ order list:0 10 allprison -- last acquired @ order list:0 9 sleep mtxpool -- last acquired @ kern/kern_resource.c:1147 7 sigacts -- last acquired @ kern/kern_kthread.c:98 9 sleep mtxpool -- (already displayed) 7 ktrace -- last acquired @ kern/kern_fork.c:617 3 accept -- last acquired @ order list:0 4 so_snd -- last acquired @ order list:0 5 so_rcv -- last acquired @ order list:0 6 sellck -- last acquired @ kern/sys_generic.c:1140 6 radix node head -- last acquired @ netinet/if_ether.c:136 7 rtentry -- last acquired @ order list:0 8 ifaddr -- last acquired @ order list:0 3 UMA zone -- (already displayed) 2 UMA lock -- (already displayed) 2 UMA boot pages -- last acquired @ vm/uma_core.c:917 2 eventhandler -- last acquired @ kern/subr_eventhandler.c:212 2 eventhandler list -- last acquired @ kern/subr_eventhandler.c:132 2 kobj -- last acquired @ kern/subr_kobj.c:307 2 kernel linker -- last acquired @ kern/kern_linker.c:470 2 system map -- last acquired @ vm/vm_map.c:1096 4 vm page queue mutex -- last acquired @ sparc64/sparc64/pmap.c:937 5 vnode interlock -- last acquired @ order list:0 6 cdev -- (already displayed) 5 pmap -- last acquired @ sparc64/sparc64/pmap.c:1289 3 kernel object -- last acquired @ vm/vm_object.c:444 4 vm page queue mutex -- (already displayed) 3 KMAP ENTRY -- last acquired @ vm/uma_core.c:1841 3 UMA zone -- (already displayed) 3 kmem object -- last acquired @ vm/vm_kern.c:397 4 vm page queue mutex -- (already displayed) 3 kernel object -- (already displayed) 6 process lock -- (already displayed) 2 vm object_list -- last acquired @ vm/vm_object.c:228 3 KMAP ENTRY -- (already displayed) 8 uidinfo hash -- (already displayed) 9 sleep mtxpool -- (already displayed) 4 vm page queue mutex -- (already displayed) 2 standard object -- last acquired @ vm/vm_glue.c:362 4 vm page queue mutex -- (already displayed) 2 TID lock -- last acquired @ kern/subr_unit.c:592 2 intr event -- last acquired @ kern/kern_intr.c:380 6 cdev -- (already displayed) 2 GEOM orphanage -- (already displayed) 2 taskqueue list -- last acquired @ kern/subr_taskqueue.c:125 2 rman head -- last acquired @ kern/subr_rman.c:172 2 rman -- last acquired @ kern/subr_rman.c:511 3 UMA zone -- (already displayed) 2 eeprom_mtx -- last acquired @ sparc64/sparc64/eeprom.c:184 2 devd -- last acquired @ kern/subr_bus.c:517 6 sellck -- (already displayed) 2 ttylist -- last acquired @ kern/tty.c:2842 2 unit# allocation -- (already displayed) 2 LED mtx -- last acquired @ dev/led/led.c:52 2 network driver -- last acquired @ dev/hme/if_hme.c:203 3 iommu -- last acquired @ sparc64/sparc64/iommu.c:1007 2 ifnet -- last acquired @ net/if.c:1170 2 bpf global lock -- last acquired @ net/bpf.c:1597 3 bpf interface lock -- last acquired @ order list:0 4 bpf cdev lock -- last acquired @ order list:0 2 ncr53c9x lock -- last acquired @ dev/esp/ncr53c9x.c:2143 3 UMA zone -- (already displayed) 3 iommu -- (already displayed) 3 CAM BIOQ lock -- last acquired @ cam/cam_xpt.c:4957 2 random reseed -- last acquired @ dev/random/yarrow.c:280 2 arc4_mtx -- last acquired @ libkern/arc4random.c:137 2 pseudofs -- last acquired @ fs/pseudofs/pseudofs_fileno.c:55 2 nfsd_mtx -- last acquired @ nfsserver/nfs_srvsock.c:812 4 so_snd -- (already displayed) 2 if_clone lock -- last acquired @ net/if_clone.c:161 2 if_cloners lock -- last acquired @ net/if_clone.c:245 2 domain list -- last acquired @ kern/uipc_domain.c:226 3 pfil_head_list lock -- last acquired @ net/pfil.c:114 2 PFil hook read/write mutex -- last acquired @ net/pfil.c:108 3 pfil_head_list lock -- (already displayed) 2 tcp -- last acquired @ netinet/tcp_subr.c:1409 3 tcpinp -- last acquired @ order list:0 4 so_snd -- (already displayed) 6 radix node head -- (already displayed) 2 lo_mtx -- last acquired @ net/if_loop.c:160 2 in6_addr_list -- last acquired @ netinet6/nd6.c:556 3 CAM BIOQ lock -- (already displayed) 2 devstat -- (already displayed) 2 taskqueue -- last acquired @ kern/subr_taskqueue.c:73 6 process lock -- (already displayed) 0 pbuf mutex -- last acquired @ vm/swap_pager.c:403 0 module subsystem sx lock -- last acquired @ kern/kern_module.c:115 0 kernel environment -- last acquired @ kern/kern_environment.c:291 0 user map -- last acquired @ vm/vm_map.c:2485 3 UMA zone -- (already displayed) 2 system map -- (already displayed) 2 vm object_list -- (already displayed) 2 standard object -- (already displayed) 4 vm page queue mutex -- (already displayed) 0 ddp_list_mtx -- last acquired @ order list:0 1 ddp_mtx -- last acquired @ order list:0 0 slip_mtx -- last acquired @ order list:0 1 slip sc_mtx -- last acquired @ order list:0 0 udp -- last acquired @ order list:0 1 udpinp -- last acquired @ order list:0 2 in_multi_mtx -- last acquired @ order list:0 3 igmp_mtx -- last acquired @ netinet/igmp.c:444 4 if_addr_mtx -- last acquired @ order list:0 4 so_snd -- (already displayed) 0 unp -- last acquired @ order list:0 4 so_snd -- (already displayed) 0 proctree -- last acquired @ kern/kern_fork.c:301 1 allproc -- last acquired @ kern/kern_fork.c:310 6 process lock -- (already displayed) 5 process group -- (already displayed) Spin locks: 0 ap boot -- last acquired @ order list:0 1 rm.mutex_mtx -- last acquired @ order list:0 2 hptlock -- last acquired @ order list:0 3 sio -- last acquired @ order list:0 4 uart_hwmtx -- last acquired @ dev/uart/uart_dev_z8530.c:401 5 sabtty -- last acquired @ order list:0 6 zstty -- last acquired @ order list:0 7 ng_node -- last acquired @ order list:0 8 ng_worklist -- last acquired @ order list:0 9 taskqueue_fast -- last acquired @ order list:0 10 intr table -- last acquired @ sparc64/sparc64/intr_machdep.c:294 11 sleepq chain -- last acquired @ kern/subr_sleepqueue.c:223 12 sched lock -- last acquired @ sparc64/sparc64/mp_machdep.c:366 13 turnstile chain -- last acquired @ kern/subr_turnstile.c:478 14 td_contested -- last acquired @ order list:0 15 callout -- last acquired @ kern/kern_timeout.c:293 16 entropy harvest mutex -- last acquired @ dev/random/rando= mdev_soft.c:256 17 allpmaps -- last acquired @ order list:0 18 vm page queue free mutex -- last acquired @ vm/vm_page.= c:792 19 icu -- last acquired @ order list:0 20 smp rendezvous -- last acquired @ order list:0 21 ipi -- last acquired @ order list:0 22 rtc_mtx -- last acquired @ order list:0 23 clk -- last acquired @ order list:0 24 mutex profiling lock -- last acquired @ order lis= t:0 25 kse zombie lock -- last acquired @ order list:0 26 ALD Queue -- last acquired @ order list:0 27 tw_osl_io_lock -- last acquired @ order list:0 28 tw_osl_q_lock -- last acquired @ order list:0 29 tw_cl_io_lock -- last acquired @ order list:0 30 tw_cl_intr_lock -- last acquired @ order li= st:0 31 tw_cl_gen_lock -- last acquired @ order li= st:0 15 callout -- (already displayed) 15 callout -- (already displayed) Locks which were never acquired: g_disk_done MD config lock arp_inq rts_inq addrsel_sxlock addrsel_lock scope6_lock ip6_inq rip tcp_hc_entry ip_inq pseudofs_vncache gif_mtx ppp_softc_list_mtx tunmtx msq sem semid Synch NFS reply posting NFS reqq lock nfs4dev state nfs4dev waitq nfs4dev newq nullhs dirhash list vfs hash Syncer mtx vnode_free_list mntid if send queue tty fast_taskqueue pt_mtx nfslock sf_bufs list lock ktrace_sx uma object p_peers bpin lock bdone lock buffer daemon lock needsbuffer lock runningbufspace lock buf queue lock umtxq_lock fifo mutex Name Cache UUID generator mutex lock so_glabel knlist lock for lockless objects encapmtx protect sysfilt_ops kqueue order rtsock route_cb lock mountlist rawcb Softdep Lock accept_filter_mtx securelevel mutex lock DEVFS ruleset lock acct_sx pmc shared lock fdesc filelist lock sysctl lock malloc phys_pager list dev_pager list dev_pager create swapdev swap_pager list vm map sleep mutex db> show locks exclusive sleep mutex filedesc structure r =3D 0 (0xfffff80002c89c48) locke= d @ kern/kern_descrip.c:1404 exclusive sleep mutex Giant r =3D 0 (0xc0710980) locked @ dev/ata/ata-all.c= :527 db> show alllocks Process 2 (g_event) thread 0xfffff802be9ea000 (100011) exclusive sx GEOM topology r =3D 0 (0xc044da50) locked @ geom/geom_event.c:= 183 Process 0 (swapper) thread 0xc044dfd8 (0) exclusive sleep mutex filedesc structure r =3D 0 (0xfffff80002c89c48) locke= d @ kern/kern_descrip.c:1404 exclusive sleep mutex Giant r =3D 0 (0xc0710980) locked @ dev/ata/ata-all.c= :527 db> show allpcpu Current CPU: 0 cpuid =3D 0 curthread =3D 0xc044dfd8: pid 0 "swapper" curpcb =3D 0xc0c17980 fpcurthread =3D none idlethread =3D 0xfffff802be9f1ae0: pid 21 "idle: cpu0" spin locks held: cpuid =3D -371328640 curthread =3D 0xfffff802be9f1830: pid 20 "idle: cpu1" curpcb =3D 0xc0080540 fpcurthread =3D [hung, grr] Kris --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEHyA0Wry0BWjoQKURAgmYAJ0X0v2gC8NTyFoCoWErJMcotfQkSgCgyVAn Ol9gfL7D3gbkUF9Ekajh3q8= =tIav -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From owner-freebsd-sparc64@FreeBSD.ORG Mon Mar 20 23:05:34 2006 Return-Path: X-Original-To: sparc64@FreeBSD.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 217C716A400 for ; Mon, 20 Mar 2006 23:05:34 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FF4843D66 for ; Mon, 20 Mar 2006 23:05:30 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 244071A3C1B; Mon, 20 Mar 2006 15:05:30 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 0DDA1528FB; Mon, 20 Mar 2006 18:05:29 -0500 (EST) Date: Mon, 20 Mar 2006 18:05:28 -0500 From: Kris Kennaway To: Kris Kennaway Message-ID: <20060320230528.GA79866@xor.obsecurity.org> References: <441955A7.1020204@samsco.org> <20060316140435.K95579@newtrinity.zeist.de> <20060316190305.GA25561@xor.obsecurity.org> <20060320165139.D98160@newtrinity.zeist.de> <20060320183227.GA74259@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: <20060320183227.GA74259@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i Cc: sparc64@FreeBSD.org Subject: Re: TODO list status update X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2006 23:05:34 -0000 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 20, 2006 at 01:32:27PM -0500, Kris Kennaway wrote: > On Mon, Mar 20, 2006 at 04:51:39PM +0100, Marius Strobl wrote: >=20 > > foreign pcpu structs. Could you please test whether the > > patch at: > > http://alchemy.franken.de/~marius/ipi.diff > > fixes this? >=20 > This patch doesn't cause immediate problems (i.e. it boots), but I ran > stress2 and it instantly panicked with >=20 > panic: _mtx_lock_sleep: recursed on non-recursive mutex system map @ ../.= ./../vm/vm_map.c:2993 > panic() at panic+0x164 > _mtx_lock_sleep() at _mtx_lock_sleep+0x40 > _mtx_lock_flags() at _mtx_lock_flags+0x98 > _vm_map_lock_read() at _vm_map_lock_read+0x1c > vm_map_lookup() at vm_map_lookup+0x1c > vm_fault() at vm_fault+0x68 > trap_pfault() at trap_pfault+0x1a8 > trap() at trap+0x2b0 > -- fast data access mmu miss tar=3D0xe85a6000 %o7=3D0xc02f3b08 -- > vm_map_entry_splay() at vm_map_entry_splay+0x10 > vm_map_find() at vm_map_find+0x34 > kmem_alloc_nofault() at kmem_alloc_nofault+0x44 > vm_thread_new() at vm_thread_new+0x44 > thread_init() at thread_init+0x8 > slab_zalloc() at slab_zalloc+0x264 > uma_zone_slab() at uma_zone_slab+0x1ac > uma_zalloc_bucket() at uma_zalloc_bucket+0x1b4 > uma_zalloc_arg() at uma_zalloc_arg+0x398 > thread_alloc() at thread_alloc+0x18 > create_thread() at create_thread+0x78 > thr_new() at thr_new+0x64 > syscall() at syscall+0x2dc > -- syscall (455, FreeBSD ELF64, thr_new) %o7=3D0x40348e7c -- >=20 > Unfortunately it hung here, so I couldn't get further debugging. I'll tr= y again. After about a dozen attempts that just caused fatal resets after the panic, I got one that entered DDB properly: panic: _mtx_lock_sleep: recursed on non-recursive mutex system map @ ../../= ../vm/vm_map.c:2993 db> wh Tracing pid 523 tid 100099 td 0xfffff80045b9e560 panic() at panic+0x164 _mtx_lock_sleep() at _mtx_lock_sleep+0x40 _mtx_lock_flags() at _mtx_lock_flags+0xb8 _vm_map_lock_read() at _vm_map_lock_read+0x1c vm_map_lookup() at vm_map_lookup+0x1c vm_fault() at vm_fault+0x68 trap_pfault() at trap_pfault+0x1a8 trap() at trap+0x2b0 -- fast data access mmu miss tar=3D0xe85a4000 %o7=3D0xc02f7728 -- vm_map_entry_splay() at vm_map_entry_splay+0x10 vm_map_find() at vm_map_find+0x34 kmem_alloc_nofault() at kmem_alloc_nofault+0x44 pmap_pinit() at pmap_pinit+0x30 vmspace_zinit() at vmspace_zinit+0x14 slab_zalloc() at slab_zalloc+0x264 uma_zone_slab() at uma_zone_slab+0x1ac uma_zalloc_bucket() at uma_zalloc_bucket+0x1b4 uma_zalloc_arg() at uma_zalloc_arg+0x3dc vmspace_alloc() at vmspace_alloc+0x14 vmspace_fork() at vmspace_fork+0x24 vm_forkproc() at vm_forkproc+0xe4 fork1() at fork1+0xf1c fork() at fork+0x10 syscall() at syscall+0x2dc -- syscall (2, FreeBSD ELF64, fork) %o7=3D0x101f18 -- userland() at 0x403b74e8 user trace: trap %o7=3D0x101f18 pc 0x403b74e8, sp 0x7fdffffdf81 pc 0x101214, sp 0x7fdffffe0d1 pc 0x4020cd74, sp 0x7fdffffe191 done db> show locks exclusive sleep mutex system map r =3D 0 (0xfffff802bfd000d8) locked @ vm/v= m_map.c:1096 exclusive sx user map r =3D 0 (0xfffff80042e56cd0) locked @ vm/vm_map.c:2485 Kris --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEHzU4Wry0BWjoQKURAirrAKC0SrVvQlXgVVL/ehsOy9rKPgUzjQCgwCx3 5VclTUJAzM0ifJlEoRdsVG0= =ffP0 -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l-- From owner-freebsd-sparc64@FreeBSD.ORG Mon Mar 20 23:57:30 2006 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B5D616A420 for ; Mon, 20 Mar 2006 23:57:30 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3D5243D48 for ; Mon, 20 Mar 2006 23:57:29 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by zproxy.gmail.com with SMTP id l8so1302183nzf for ; Mon, 20 Mar 2006 15:57:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=V39wYYjsNMbkzT9nmK8H3cIIEgmeho5v/pBqmeEhGOSF9YVaA47FxOpi1kOw+YQBJtGhj7YjQdFnez4TUevQnjP4s5q8EN3ZE2uNQ+bhy3MRhuo1l29dcDe4UgtfJvHhKPESEoToiYh042jWh7SugigTv4V2swdEqgoBGE6FutI= Received: by 10.36.38.8 with SMTP id l8mr1168557nzl; Mon, 20 Mar 2006 15:57:28 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 15sm3819549nzo.2006.03.20.15.57.27; Mon, 20 Mar 2006 15:57:28 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k2KNvXDA079391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Mar 2006 08:57:33 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k2KNvWHF079390; Tue, 21 Mar 2006 08:57:32 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 21 Mar 2006 08:57:32 +0900 From: Pyun YongHyeon To: Joerg Wunsch Message-ID: <20060320235732.GA79203@cdnetworks.co.kr> References: <20060320211720.GB31216@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060320211720.GB31216@uriah.heep.sax.de> User-Agent: Mutt/1.4.2.1i Cc: freebsd-sparc64@freebsd.org Subject: Re: hme(4) broken on non-sparc64 systems in -current X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2006 23:57:30 -0000 On Mon, Mar 20, 2006 at 10:17:21PM +0100, Joerg Wunsch wrote: > Even though this problem is not related to sparc64 system (I hope, the > least), I think all those who know about hme(4) are listening here. > > I used to run a PCI QFE card in my (i386) scratch machine at home, for > various experiments. After upgrading the machine from a 6-stable of > about a year ago to -current, the QFE ceased to work. The symptoms > were that I could still ping anyone (even with large packets), but all > TCP and UDP traffic seemingly didn't ``arrive'' at the IP stack, even > though the packets made it into the NIC at the lowest level (so > tcpdump could still display them). > > This made me suspect the TCP/UDP checksum offloading, and indeed, > after uncommenting the checksum capability: > > Index: if_hme.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/hme/if_hme.c,v > retrieving revision 1.46 > diff -u -r1.46 if_hme.c > --- if_hme.c 17 Jan 2006 06:02:22 -0000 1.46 > +++ if_hme.c 20 Mar 2006 20:56:54 -0000 > @@ -340,9 +340,9 @@ > * Tell the upper layer(s) we support long frames/checksum offloads. > */ > ifp->if_data.ifi_hdrlen = sizeof(struct ether_vlan_header); > - ifp->if_capabilities |= IFCAP_VLAN_MTU | IFCAP_HWCSUM; > + ifp->if_capabilities |= IFCAP_VLAN_MTU /* | IFCAP_HWCSUM */; > ifp->if_hwassist |= sc->sc_csum_features; > - ifp->if_capenable |= IFCAP_VLAN_MTU | IFCAP_HWCSUM; > + ifp->if_capenable |= IFCAP_VLAN_MTU /* | IFCAP_HWCSUM */; > return (0); > > fail_txdesc: > > everything works again. If anyone has any further ideas what might > have broken this, I'm all ears, otherwise I might start digging down > into the code myself. > > (I don't have a FreeBSD-sparc64 machine running -current around, so I > cannot test right now whether it would work there.) > How about backing out rev. 1.46(if_hme.c)? For the same patch sent to bard@OpenBSD I got a positive report so it's strange to me though.(brad@OpenBSD reported Rx checksum offload breakage on little endian systems.) Since I don't have PCI HME NIC I can't test it on little endian systems. :-( -- Regards, Pyun YongHyeon From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 21 06:15:18 2006 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26B0716A41F for ; Tue, 21 Mar 2006 06:15:18 +0000 (UTC) (envelope-from j@uriah.heep.sax.de) Received: from uriah.heep.sax.de (uriah.heep.sax.de [213.240.137.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4169E43D45 for ; Tue, 21 Mar 2006 06:15:17 +0000 (GMT) (envelope-from j@uriah.heep.sax.de) Received: from localhost (localhost [127.0.0.1]) by uriah.heep.sax.de (Postfix) with ESMTP id 0F919AF; Tue, 21 Mar 2006 07:15:15 +0100 (MET) Received: from uriah.heep.sax.de (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.2-10) id 87324-6B04FF1B; Tue, 21 Mar 2006 07:15:15 +0100 Received: from uriah.heep.sax.de (localhost [127.0.0.1]) by uriah.heep.sax.de (Postfix) with ESMTP id EFD9653; Tue, 21 Mar 2006 07:15:09 +0100 (MET) Received: from uriah.heep.sax.de (localhost [127.0.0.1]) by uriah.heep.sax.de (Postfix) with ESMTP; Tue, 21 Mar 2006 07:15:09 +0100 (MET) Received: (from j@localhost) by uriah.heep.sax.de (8.13.4/8.13.1/Submit) id k2L6F9xw087322; Tue, 21 Mar 2006 07:15:09 +0100 (MET) (envelope-from j) Date: Tue, 21 Mar 2006 07:15:09 +0100 From: Joerg Wunsch To: freebsd-sparc64@freebsd.org Message-ID: <20060321061508.GK31216@uriah.heep.sax.de> References: <20060320211720.GB31216@uriah.heep.sax.de> <20060320235732.GA79203@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060320235732.GA79203@cdnetworks.co.kr> X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 User-Agent: Mutt/1.5.11 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on uriah.heep.sax.de X-Spam-Level: X-Spam-Status: No, score=0.0 required=6.5 tests=none autolearn=failed version=3.0.2 X-AntiVirus: checked by AntiVir MailGate (version: 2.0.2-10; AVE: 6.33.0.19; VDF: 6.33.0.62; host: uriah.heep.sax.de) Cc: Subject: Re: hme(4) broken on non-sparc64 systems in -current X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joerg Wunsch List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2006 06:15:18 -0000 As Pyun YongHyeon wrote: > How about backing out rev. 1.46(if_hme.c)? > For the same patch sent to bard@OpenBSD I got a positive report > so it's strange to me though.(brad@OpenBSD reported Rx checksum > offload breakage on little endian systems.) Yes, backing that out helps. I'm not sure what this change was trying to fix. I've noticed before that tools like ethereal reported the checksum as invalid but the traffic itself was unaffected. Anyway, as it was now, the traffic was blocked, so perhaps there's more than one spot where this needs to be fixed? I'll look a bit further into it tonight. Thanks! -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 21 06:20:28 2006 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9DAA16A400 for ; Tue, 21 Mar 2006 06:20:28 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 297FB43D49 for ; Tue, 21 Mar 2006 06:20:27 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k2L6KQgB022792; Mon, 20 Mar 2006 23:20:26 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <441F9B28.7030602@samsco.org> Date: Mon, 20 Mar 2006 23:20:24 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joerg Wunsch References: <20060320211720.GB31216@uriah.heep.sax.de> <20060320235732.GA79203@cdnetworks.co.kr> <20060321061508.GK31216@uriah.heep.sax.de> In-Reply-To: <20060321061508.GK31216@uriah.heep.sax.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-sparc64@freebsd.org Subject: Re: hme(4) broken on non-sparc64 systems in -current X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2006 06:20:28 -0000 Joerg Wunsch wrote: > As Pyun YongHyeon wrote: > > >>How about backing out rev. 1.46(if_hme.c)? > > >>For the same patch sent to bard@OpenBSD I got a positive report >>so it's strange to me though.(brad@OpenBSD reported Rx checksum >>offload breakage on little endian systems.) > > > Yes, backing that out helps. I'm not sure what this change was trying > to fix. I've noticed before that tools like ethereal reported the > checksum as invalid but the traffic itself was unaffected. Anyway, as > it was now, the traffic was blocked, so perhaps there's more than one > spot where this needs to be fixed? > > I'll look a bit further into it tonight. Thanks! > When tx checksum offloading is enabled, you'll always get checksum errors when capturing the local end of the transmission. That expected, since the checksum never gets computed until long after the bpf tap has captured it. Scott From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 21 06:27:05 2006 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7050B16A400 for ; Tue, 21 Mar 2006 06:27:05 +0000 (UTC) (envelope-from arr@watson.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id C32E943D45 for ; Tue, 21 Mar 2006 06:27:02 +0000 (GMT) (envelope-from arr@watson.org) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.13.4/8.13.4) with ESMTP id k2L6R1i7095757; Tue, 21 Mar 2006 01:27:01 -0500 (EST) (envelope-from arr@watson.org) Received: from localhost (arr@localhost) by fledge.watson.org (8.13.4/8.13.4/Submit) with ESMTP id k2L6R04E095754; Tue, 21 Mar 2006 01:27:01 -0500 (EST) (envelope-from arr@watson.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Tue, 21 Mar 2006 01:27:00 -0500 (EST) From: "Andrew R. Reiter" To: Scott Long In-Reply-To: <441F9B28.7030602@samsco.org> Message-ID: <20060321012458.I92974@fledge.watson.org> References: <20060320211720.GB31216@uriah.heep.sax.de> <20060320235732.GA79203@cdnetworks.co.kr> <20060321061508.GK31216@uriah.heep.sax.de> <441F9B28.7030602@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Joerg Wunsch , freebsd-sparc64@freebsd.org Subject: Re: hme(4) broken on non-sparc64 systems in -current X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2006 06:27:05 -0000 On Mon, 20 Mar 2006, Scott Long wrote: :Joerg Wunsch wrote: :> As Pyun YongHyeon wrote: :> :> :> > How about backing out rev. 1.46(if_hme.c)? :> :> :> > For the same patch sent to bard@OpenBSD I got a positive report :> > so it's strange to me though.(brad@OpenBSD reported Rx checksum :> > offload breakage on little endian systems.) :> :> :> Yes, backing that out helps. I'm not sure what this change was trying :> to fix. I've noticed before that tools like ethereal reported the :> checksum as invalid but the traffic itself was unaffected. Anyway, as :> it was now, the traffic was blocked, so perhaps there's more than one :> spot where this needs to be fixed? :> :> I'll look a bit further into it tonight. Thanks! :> : :When tx checksum offloading is enabled, you'll always get checksum errors when :capturing the local end of the transmission. That expected, :since the checksum never gets computed until long after the bpf tap has :captured it. : :Scott : Something to note (from the application side) is that many applications that use libnids don't offer the option to deal with cksum offloading. Things like dsniff will want you to turn offloading off since there is no simple way (unless you modify the source, which then weakens the reliabliity of the stream assembly) to deal with this. Just an extra thought to thing of. Cheers, Andrew -- arr@watson.org From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 21 06:52:21 2006 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B14816A400 for ; Tue, 21 Mar 2006 06:52:21 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40EDC43D49 for ; Tue, 21 Mar 2006 06:52:12 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by zproxy.gmail.com with SMTP id 4so1586358nzn for ; Mon, 20 Mar 2006 22:52:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=KfZ0RkfHfZFz8j2rn9LmR0C9mcugFJk6U/b9SqzPspsuLP4lMEE2ZpVITbj+0BWHrposzpR/haGsxPFXNBxQ6Oc8k9PmLKe4OEfgBBshHs9L6875SB9bBkOt8hXCEM7OJicHm3IQxwAOR2CJhiHGTAPuGjrnvml99GkusJiSllo= Received: by 10.36.222.70 with SMTP id u70mr2546079nzg; Mon, 20 Mar 2006 22:52:12 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 7sm437856nzn.2006.03.20.22.52.10; Mon, 20 Mar 2006 22:52:11 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k2L6qKot080592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Mar 2006 15:52:20 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k2L6qJNr080591; Tue, 21 Mar 2006 15:52:19 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 21 Mar 2006 15:52:19 +0900 From: Pyun YongHyeon To: Joerg Wunsch Message-ID: <20060321065219.GB79203@cdnetworks.co.kr> References: <20060320211720.GB31216@uriah.heep.sax.de> <20060320235732.GA79203@cdnetworks.co.kr> <20060321061508.GK31216@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060321061508.GK31216@uriah.heep.sax.de> User-Agent: Mutt/1.4.2.1i Cc: freebsd-sparc64@freebsd.org Subject: Re: hme(4) broken on non-sparc64 systems in -current X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2006 06:52:21 -0000 On Tue, Mar 21, 2006 at 07:15:09AM +0100, Joerg Wunsch wrote: > As Pyun YongHyeon wrote: > > > How about backing out rev. 1.46(if_hme.c)? > > > For the same patch sent to bard@OpenBSD I got a positive report > > so it's strange to me though.(brad@OpenBSD reported Rx checksum > > offload breakage on little endian systems.) > > Yes, backing that out helps. I'm not sure what this change was trying > to fix. I've noticed before that tools like ethereal reported the If my memory serve right, the flag variable holds host byte order data. The lower 16bit has a checksum value computed by HME hardware. Since the checksum value should be computed with network byte order I applied htos to the value in order to get correct value. > checksum as invalid but the traffic itself was unaffected. Anyway, as If you see checksum invalid message on Tx traffic it's normal for checksum offloaded NIC. However if you see the checksum error on Rx traffic it's real checksum error. > it was now, the traffic was blocked, so perhaps there's more than one > spot where this needs to be fixed? > Maybe. I have no idea yet. > I'll look a bit further into it tonight. Thanks! > You're welcome. Sorry for the breakge. -- Regards, Pyun YongHyeon From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 21 14:10:22 2006 Return-Path: X-Original-To: freebsd-sparc64@hub.freebsd.org Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 462F716A422 for ; Tue, 21 Mar 2006 14:10:22 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73A9943D64 for ; Tue, 21 Mar 2006 14:10:16 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k2LEAFjj005329 for ; Tue, 21 Mar 2006 14:10:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k2LEAFxt005328; Tue, 21 Mar 2006 14:10:15 GMT (envelope-from gnats) Resent-Date: Tue, 21 Mar 2006 14:10:15 GMT Resent-Message-Id: <200603211410.k2LEAFxt005328@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-sparc64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Andrew Belashov Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C77D16A41F for ; Tue, 21 Mar 2006 14:09:51 +0000 (UTC) (envelope-from bel@white.orel.ru) Received: from white.orel.ru (white.orel.ru [213.59.64.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id A54D343D49 for ; Tue, 21 Mar 2006 14:09:50 +0000 (GMT) (envelope-from bel@white.orel.ru) Received: from white.orel.ru (localhost [127.0.0.1]) by white.orel.ru (8.13.4/8.13.4) with ESMTP id k2LE9gVi095862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Mar 2006 17:09:44 +0300 (MSK) (envelope-from bel@white.orel.ru) Received: (from bel@localhost) by white.orel.ru (8.13.4/8.13.4/Submit) id k2LE9gJ1095861; Tue, 21 Mar 2006 17:09:42 +0300 (MSK) (envelope-from bel) Message-Id: <200603211409.k2LE9gJ1095861@white.orel.ru> Date: Tue, 21 Mar 2006 17:09:42 +0300 (MSK) From: Andrew Belashov To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: sparc64/94778: panic in intr_fast() X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrew Belashov List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2006 14:10:22 -0000 >Number: 94778 >Category: sparc64 >Synopsis: panic in intr_fast() >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-sparc64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Mar 21 14:10:15 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Andrew Belashov >Release: FreeBSD 6.0-RELEASE-p4 sparc64 >Organization: JSC CenterTelecom >Environment: System: FreeBSD bel.localdomain 6.0-RELEASE-p4 FreeBSD 6.0-RELEASE-p4 #1: Mon Mar 20 09:59:01 MSK 2006 bel@bel.localdomain:/usr/obj/usr/src/sys/SUNC3D sparc64 Hardware: Ultra 60 Creator 3D, 2 x USII @ 450 MHz, HP surestore dlt vs80 Software: xorg-6.8.2, kde-lite-3.5.0_1, amanda-server-2.4.5_2,1 >Description: I have reproducible kernel panic with amanda Network Disk Archiver. panic: trap: fast instruction access mmu miss cpuid = 0 KDB: enter: panic [thread pid 12 tid 100006 ] Stopped at kdb_enter+0x3c: ta %xcc, 1 db> bt Tracing pid 12 tid 100006 td 0xfffff800bfa3b0a0 panic() at panic+0x160 trap() at trap+0x390 -- fast instruction access mmu miss tar=0 %o7=0xc00512dc -- db> ps pid proc uid ppid pgrp flag stat wmesg wchan cmd [...] 12 fffff800bfa393e0 0 0 0 000020c [CPU 0] idle: cpu0 [...] db> show intrcnt ??? 2 stray 1 pil4: ast 2289936 pil5: stop 1 pil13: fast 16560 pil2: ithrd 4488976 vec2027: puc0 166 vec2025: uart2 7746 vec2026: uart3 8814 vec2020: pcm0 123652 vec2017: hme0 3769678 vec2016: sym0 590176 vec2022: sym1 15568 vec2000: fwohci0+ 1 pil14: tick 24242583 db> show pcpu cpuid = 0 curthread = 0xfffff800bfa3b0a0: pid 12 "idle: cpu0" curpcb = 0xe0429980 fpcurthread = none idlethread = 0xfffff800bfa3b0a0: pid 12 "idle: cpu0" Backtrace: #13 0x00000000c0365b58 in trap (tf=0xe04292c0) at /usr/src/sys/sparc64/sparc64/trap.c:369 #14 0x00000000c0050fc0 in tl1_trap () #15 0x0000000000000000 in ?? () #16 0x00000000c00512e4 in intr_fast () at /usr/src/sys/sparc64/sparc64/interrupt.S:193 (kgdb) frame 13 #13 0x00000000c0365b58 in trap (tf=0xe04292c0) at /usr/src/sys/sparc64/sparc64/trap.c:369 369 panic("trap: %s", trap_msg[tf->tf_type & ~T_KERNEL]); (kgdb) p/x tf[0] $1 = {tf_global = {0xc0358b24, 0x2, 0xfffff800bfa3b0a0, 0xfffff800bfa3b0a0, 0x4, 0xc048b800, 0xe0429980, 0xc04d67b8}, tf_out = {0x0, 0x0, 0x0, 0xc0487758, 0x2fac, 0xc0487758, 0xe0428bc1, 0xc00512dc}, tf_fprs = 0xc04cf7b0, tf_fsr = 0xc04cf7b0, tf_gsr = 0x7e1, tf_level = 0x0, tf_pil = 0x2, tf_sfar = 0x0, tf_sfsr = 0x0, tf_tar = 0x0, tf_tnpc = 0x4, tf_tpc = 0x0, tf_tstate = 0x9915001602, tf_type = 0x62, tf_y = 0x0, tf_wstate = 0x5ea, tf_pad = {0x0, 0x0}} (kgdb) frame 16 #16 0x00000000c00512e4 in intr_fast () at /usr/src/sys/sparc64/sparc64/interrupt.S:193 193 mov %o1, %o0 Current language: auto; currently asm (kgdb) l 188 stx %l0, [PCPU(IRFREE)] 189 190 wrpr %g0, PSTATE_KERNEL, %pstate 191 192 FAULT ---> call %o0 # $o0 == 0, Why? 193 mov %o1, %o0 194 ba,a %xcc, 1b 195 nop 196 END(intr_fast) (kgdb) x/4i 0xc00512dc 0xc00512dc : call %o0 0xc00512e0 : mov %o1, %o0 0xc00512e4 : b,a %xcc, 0xc0051264 0xc00512e8 : nop >How-To-Repeat: Run amdump. Keyboard or mouse activity lead to a kernel panic. >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 21 21:52:09 2006 Return-Path: X-Original-To: sparc64@FreeBSD.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6868916A41F for ; Tue, 21 Mar 2006 21:52:09 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F06C43D46 for ; Tue, 21 Mar 2006 21:52:09 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id D330F1A4DD2; Tue, 21 Mar 2006 13:52:08 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id D713E515BE; Tue, 21 Mar 2006 16:52:07 -0500 (EST) Date: Tue, 21 Mar 2006 16:52:07 -0500 From: Kris Kennaway To: Kris Kennaway Message-ID: <20060321215207.GA23908@xor.obsecurity.org> References: <441955A7.1020204@samsco.org> <20060316140435.K95579@newtrinity.zeist.de> <20060316190305.GA25561@xor.obsecurity.org> <20060320165139.D98160@newtrinity.zeist.de> <20060320183227.GA74259@xor.obsecurity.org> <20060320230528.GA79866@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: <20060320230528.GA79866@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i Cc: sparc64@FreeBSD.org Subject: Re: TODO list status update X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2006 21:52:09 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 20, 2006 at 06:05:28PM -0500, Kris Kennaway wrote: > On Mon, Mar 20, 2006 at 01:32:27PM -0500, Kris Kennaway wrote: > > On Mon, Mar 20, 2006 at 04:51:39PM +0100, Marius Strobl wrote: > >=20 > > > foreign pcpu structs. Could you please test whether the > > > patch at: > > > http://alchemy.franken.de/~marius/ipi.diff > > > fixes this? > >=20 > > This patch doesn't cause immediate problems (i.e. it boots), but I ran > > stress2 and it instantly panicked with When I disabled the stress2 thread test (which causes the panic below) the e4500 survived the night running the rest of stress2. That's good news since it panics fairly easily without your patch. Thanks! Kris > After about a dozen attempts that just caused fatal resets after the > panic, I got one that entered DDB properly: >=20 > panic: _mtx_lock_sleep: recursed on non-recursive mutex system map @ ../.= ./../vm/vm_map.c:2993 >=20 > db> wh > Tracing pid 523 tid 100099 td 0xfffff80045b9e560 > panic() at panic+0x164 > _mtx_lock_sleep() at _mtx_lock_sleep+0x40 > _mtx_lock_flags() at _mtx_lock_flags+0xb8 > _vm_map_lock_read() at _vm_map_lock_read+0x1c > vm_map_lookup() at vm_map_lookup+0x1c > vm_fault() at vm_fault+0x68 > trap_pfault() at trap_pfault+0x1a8 > trap() at trap+0x2b0 > -- fast data access mmu miss tar=3D0xe85a4000 %o7=3D0xc02f7728 -- > vm_map_entry_splay() at vm_map_entry_splay+0x10 > vm_map_find() at vm_map_find+0x34 > kmem_alloc_nofault() at kmem_alloc_nofault+0x44 > pmap_pinit() at pmap_pinit+0x30 > vmspace_zinit() at vmspace_zinit+0x14 > slab_zalloc() at slab_zalloc+0x264 > uma_zone_slab() at uma_zone_slab+0x1ac > uma_zalloc_bucket() at uma_zalloc_bucket+0x1b4 > uma_zalloc_arg() at uma_zalloc_arg+0x3dc > vmspace_alloc() at vmspace_alloc+0x14 > vmspace_fork() at vmspace_fork+0x24 > vm_forkproc() at vm_forkproc+0xe4 > fork1() at fork1+0xf1c > fork() at fork+0x10 > syscall() at syscall+0x2dc > -- syscall (2, FreeBSD ELF64, fork) %o7=3D0x101f18 -- > userland() at 0x403b74e8 > user trace: trap %o7=3D0x101f18 > pc 0x403b74e8, sp 0x7fdffffdf81 > pc 0x101214, sp 0x7fdffffe0d1 > pc 0x4020cd74, sp 0x7fdffffe191 > done > db> show locks > exclusive sleep mutex system map r =3D 0 (0xfffff802bfd000d8) locked @ vm= /vm_map.c:1096 > exclusive sx user map r =3D 0 (0xfffff80042e56cd0) locked @ vm/vm_map.c:2= 485 >=20 > Kris --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD4DBQFEIHWHWry0BWjoQKURAtYiAJUYXGie9b8/5NQ6D0Voc8vh7mpCAKDNsftc Ns1k72wZsSo/c1OP+uRd3Q== =jIDz -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-sparc64@FreeBSD.ORG Wed Mar 22 11:07:33 2006 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B280716A401; Wed, 22 Mar 2006 11:07:33 +0000 (UTC) (envelope-from jema@sendmail.ru) Received: from mail.agtel.net (babylon.agtel.net [212.111.64.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2E5943D4C; Wed, 22 Mar 2006 11:07:29 +0000 (GMT) (envelope-from jema@sendmail.ru) Received: from [193.26.135.2] (account jema@sendmail.ru) by mail.agtel.net (CommuniGate Pro WebUser 4.2.8) with HTTP id 72561994; Wed, 22 Mar 2006 14:07:19 +0300 From: "Andy Jema" To: freebsd-sparc64@freebsd.org X-Mailer: CommuniGate Pro WebUser Interface v.4.2.8 Date: Wed, 22 Mar 2006 14:07:19 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: (no subject) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2006 11:07:33 -0000 Hello! I gave a new try to 6.1-BETA4 on my Blade 150 recently but there are some errors still spitting out during an installation: acd0: TIMEOUT - READ_BIG retrying (1 retry left) Interrupt storm detected on "vec1996:"; throttling interrupt source acd0: TIMEOUT - READ_BIG retrying (1 retry left) hw.ata.atapi_dma to 0 dmesg: Sun Blade 150 (UltraSPARC-IIe 650MHz), No Keyboard Copyright 1998-2002 Sun Microsystems, Inc. All rights reserved. OpenBoot 4.6, 512 MB memory installed, Serial #53155393. Ethernet address 0:3:ba:2b:16:41, Host ID: 832b1641. Rebooting with command: boot cdrom Boot device: /pci@1f,0/ide@d/cdrom@1,0:f File and args: >> FreeBSD/sparc64 boot block Boot path: /pci@1f,0/ide@d/cdrom@1,0:f Boot loader: /boot/loader Consoles: Open Firmware console Boot path set to /pci@1f,0/ide@d/cdrom@1,0:a FreeBSD/sparc64 bootstrap loader, Revision 1.0 (root@s-dallas.cse.buffalo.edu, Thu Mar 16 00:29:29 UTC 2006) bootpath="/pci@1f,0/ide@d/cdrom@1,0:a" Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x490f08+0x5bbb8 syms=[0x8+0x63960+0x8+0x5396f] / Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... nothing to autoload yet. jumping to kernel entry at 0xc0060000. Copyright (c) 1992-2006 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 6.1-BETA4 #0: Thu Mar 16 15:20:20 UTC 2006 root@s-dallas.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "tick" frequency 650000000 Hz quality 1000 real memory = 536870912 (512 MB) avail memory = 506642432 (483 MB) cpu0: Sun Microsystems UltraSparc-IIe Processor (650.00 MHz CPU) nexus0: pcib0: on nexus0 pcib0: Hummingbird compatible, impl 0, version 0, ign 0x7c0, bus A pcib0: [FAST] pcib0: [FAST] pcib0: [GIANT-LOCKED] pcib0: [GIANT-LOCKED] pcib0 dvma: DVMA map: 0xc0000000 to 0xc3ffffff pci0: on pcib0 ebus0: mem 0xf0000000-0xf0ffffff,0xf1000000-0xf17fffff at device 12.0 on pci0 ebus0: : incomplete ebus0: addr 0-0xfffff (no driver attached) eeprom0: addr 0x100000000-0x100001fff on ebus0 eeprom0: model mk48t59 eeprom0: hostid 832b1641 isab0: at device 7.0 on pci0 isa0: on isab0 gem0: mem 0x400000-0x41ffff at device 12.1 on pci0 miibus0: on gem0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto gem0: 2kB RX FIFO, 2kB TX FIFO gem0: Ethernet address: 00:03:ba:2b:16:41 fwohci0: mem 0x420000-0x4207ff,0x422000-0x4227ff at device 12.2 on pci0 fwohci0: OHCI version 1.0 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:03:ba:ff:fe:2b:16:41 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 sbp0: on firewire0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:03:ba:2b:16:41 fwe0: Ethernet address: 02:03:ba:2b:16:41 fwe0: if_start running deferred for Giant fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ohci0: mem 0x2000000-0x2007fff at device 12.3 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x108e) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered pci0: at device 3.0 (no driver attached) pci0: at device 8.0 (no driver attached) atapci0: port 0xa00-0xa07,0xa18-0xa1b,0xa10-0xa17,0xa08-0xa0b,0xa20-0xa2f at device 13.0 on pci0 atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug, expect reduced performance ata2: on atapci0 ata3: on atapci0 pcib1: at device 5.0 on pci0 pci1: on pcib1 machfb0: port 0xb00-0xbff mem 0x3000000-0x3ffffff,0x426000-0x426fff at device 19.0 on pci0 machfb0: 16 MB aperture at 0xd5d14000, 1 KB registers at 0x037ffc00 machfb0: 8188 KB SDRAM 114.992 MHz, maximum RAMDAC clock 230 MHz, DSP machfb0: resolution 1152x900 at 8 bpp syscons0: on nexus0 syscons0: Unknown <16 virtual consoles, flags=0x100> uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 43 on isa0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> at port 0x2e8-0x2ef irq 43 on isa0 Timecounters tick every 1.000 msec md0: Preloaded image 4194304 bytes at 0xc05a3da0 ad0: 38166MB at ata2-master UDMA66 acd0: CDRW at ata2-slave UDMA66 Trying to mount root from ufs:/dev/md0 /stand/sysinstall running as init on serial console Setting hw.ata.atapi_dma to 0 gives no luck :( Sincerely yours, Andy From owner-freebsd-sparc64@FreeBSD.ORG Thu Mar 23 06:08:27 2006 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 166CB16A400 for ; Thu, 23 Mar 2006 06:08:27 +0000 (UTC) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 347ED43D6B for ; Thu, 23 Mar 2006 06:08:20 +0000 (GMT) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 21281) id D24831CC54; Thu, 23 Mar 2006 01:08:19 -0500 (EST) Date: Thu, 23 Mar 2006 01:08:19 -0500 From: Adam McDougall To: freebsd-sparc64@freebsd.org Message-ID: <20060323060819.GH17711@egr.msu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 Subject: Missing kernel, files on sparc64 6.1-BETA4 cdrom install X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2006 06:08:27 -0000 I tried installing 6.1-BETA4 to my Ultra 60 yesterday using a recently downloaded ISO. I ran through it twice and both times I end up with no kernel and hardly any files inside the target root partition. I told it to install base + man using express install and custom dist selection. Both times it acted like it was installing base, made no indications of anything being wrong. I was installing from an external cdrom drive for which I had created a slightly custom devalias (or typed out the whole path for boot /pci/....) since the cdrom drive was external (on controller 3,1 instead of 3 in the normal path in the PROM. Is this in anyway a known issue or should I spend more time with different install options or ISOs to help debug? From owner-freebsd-sparc64@FreeBSD.ORG Thu Mar 23 20:37:57 2006 Return-Path: X-Original-To: sparc@freebsd.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2AF516A420 for ; Thu, 23 Mar 2006 20:37:57 +0000 (UTC) (envelope-from rebut@securityforum.org) Received: from chello087207099030.chello.pl (chello087207099030.chello.pl [87.207.99.30]) by mx1.FreeBSD.org (Postfix) with SMTP id 4FC8643D45 for ; Thu, 23 Mar 2006 20:37:55 +0000 (GMT) (envelope-from rebut@securityforum.org) From: "brandon oluwadamil" To: "keng caylee" Date: Thu, 23 Mar 2006 20:41:42 +0000 Message-ID: <36fa01c64eba$098c4a2a$1e63cf57@chello087207099030.chello.pl> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1441 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: Subject: Re[3]: Love is not blind, it sees more not less X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2006 20:37:57 -0000 Good morning, Just one bottle will change your life! Gain MASSIVE Sexual Chemistry on Demand! Instantly Arouse, Attract, Excite, Intrigue and Seduce Gorgeous Women Whenever You Want, Wherever You Want, As Often As You Want ... Any Time YOU Are In the Mood. Increase your self-confidence and masculinity big-time. then this may be the most important news you will read all year. Here's why ... If YOU have ever experienced even one of those frustrating "What did I do wrong?" moments, trying to meet and seduce good-looking women, it's time for you to stop wondering and fumbling, ever again. But the fact of the matter is, for most guys, this "chemistry" is rare. Way more often you have awkward silences, embarrassing miscues, wrong turns and dead ends . You know what I mean? It hurts. Well, just suppose for a moment . Suppose you could have total control. Suppose you could turn on the chemistry whenever and with whoever YOU want? Suppose you knew you could turn ON this magical attraction with as many women as you want, whenever YOU want it? "Now You Can!!!" More information you will get on our wwwebbbsssitee: yournewpower[DOT]info (replace "[DOT]" to ".") ------------ Never; perhaps in her place I should have done the same. I don't and can't enter into that," she said, glancing timidly at his gloomy face. "But one must call things by their names. You want me to go and see her, to ask her here, and to rehabilitate her in society; but do understand that I _cannot_ do so. I have daughters growing up, and I must live in the world for my husband's sake. Well, I'm ready to come and see Anna Arkadyevna: she will understand that I can't ask her here, or I should have to do so in such a way that she would not meet people who look at things differently; that would offend her. I can't raise her..." "Oh, I don't regard her as fallen more than hundreds of women you do receive!" Vronsky interrupted her still more gloomily, and he got up in silence, understanding that his sister-in-law's decision was not to be shaken. "Alexey! don't be angry with me. Please understand that I'm not to blame," began Varya, looking at him with a timid smile. "I'm not angry with you," he said still as gloomily; "but I'm sorry in two ways. I'm sorry, too, that this means breaking up From owner-freebsd-sparc64@FreeBSD.ORG Thu Mar 23 23:00:31 2006 Return-Path: X-Original-To: freebsd-sparc64@hub.freebsd.org Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0687916A400 for ; Thu, 23 Mar 2006 23:00:30 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50CC943D48 for ; Thu, 23 Mar 2006 23:00:30 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k2NN0UGg035412 for ; Thu, 23 Mar 2006 23:00:30 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k2NN0UQk035410; Thu, 23 Mar 2006 23:00:30 GMT (envelope-from gnats) Resent-Date: Thu, 23 Mar 2006 23:00:30 GMT Resent-Message-Id: <200603232300.k2NN0UQk035410@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-sparc64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Andrew Grillet Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BDEF16A426 for ; Thu, 23 Mar 2006 22:53:51 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CB4B43D46 for ; Thu, 23 Mar 2006 22:53:51 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k2NMrogC068372 for ; Thu, 23 Mar 2006 22:53:50 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k2NMroIj068371; Thu, 23 Mar 2006 22:53:50 GMT (envelope-from nobody) Message-Id: <200603232253.k2NMroIj068371@www.freebsd.org> Date: Thu, 23 Mar 2006 22:53:50 GMT From: Andrew Grillet To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: sparc64/94886: Cant install xorg/sparc64/Creator3D X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2006 23:00:31 -0000 >Number: 94886 >Category: sparc64 >Synopsis: Cant install xorg/sparc64/Creator3D >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-sparc64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Mar 23 23:00:29 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Andrew Grillet >Release: 5.5-PRERELEASE >Organization: Grillet family >Environment: FreeBSD u60.grillet.home 5.5-PRERELEASE #1 Mon Mar 20 22:18:31 GMT 2006 andrew@u60.grillet.home:/usr/obj/usr/src/sys/U60 sparc64 >Description: Cannot do startx -configure (or use my own config file) log shows dlopen: /usr/X11R6/lib/modules/drivers/sunffb_drv.so Undefined symbol "cfbPutImage" Failed to load, etc. I have tried cvsup, and rebuilding, and using an xorg.conf copied from the internet. The result is the same. I had alook at the source, and was not able to understand the structure enough to fix it. >How-To-Repeat: On a u60 with a Creator3d, try to install and configure xorg >Fix: none known. >Release-Note: >Audit-Trail: >Unformatted: