Re: converted iwi(4) for testing Was: [Testers needed!] WiFi drivers changes
On Thu, Jun 04, 2015 at 09:21:06PM +0300, Gleb Smirnoff wrote: I've uploaded updated patch that should fix this issue. Please try it and report once you have time. With this version of the patch everything is working as expected again, thanks for your efforts. Regards -- Michael Moll pgp8GLTEzzQDr.pgp Description: PGP signature
Re: converted iwi(4) for testing Was: [Testers needed!] WiFi drivers changes
Hi, On Wed, Jun 03, 2015 at 01:42:22PM +0300, Gleb Smirnoff wrote: M This already is resulting in a working connection. I'll test more M extensively tomorrow and report back. Thanks a lot. Please check that 'netstat -hI wlan0 1' reports sane data about packets and bytes. All working well, the only thing I'm seeing is that a shutdown or reboot is hanging, tracing via kdb shows: Tracing command wpa_supplicant pid 293 tid 100075 td 0xc81b7960 sched_switch(c81b7960,0,104,0,0,...) at sched_switch+0x2d8/frame 0xc72b88f4 mi_switch(104,0,c81b7960,c72b8944,c81b7960,c78e00b0) at mi_switch+0x11e/frame 0xc72b8928 sleepq_switch(c81b7960,0,c12d53b2,276,2710,...) at sleepq_switch+0x15b/frame 0xc72b8950 sleepq_wait(c78e00b0,6c,c12c0672,0,0,...) at sleepq_wait+0x3f/frame 0xc72b897c _sleep(c78e00b0,c7775c98,6c,c12c0672,0,...) at _sleep+0x311/frame 0xc72b89c0 taskqueue_drain(c7775c80,c78e00b0,c81b7960,c72b8a48,c0d0f121,...) at taskqueue_drain+0x1a5/frame 0xc72b89fc ieee80211_waitfor_parent(c78e0014,0,0,0,0,...) at ieee80211_waitfor_parent+0x30/frame 0xc72b8a10 ieee80211_ioctl(c7879400,80206910,c72b8b78,c72b8a78,c0b9515c,...) at ieee80211_ioctl+0x391/frame 0xc72b8a48 ifioctl(c88fe720,80206910,c72b8b78,c81b7960,1000,...) at ifioctl+0x144a/frame 0xc72b8ad4 soo_ioctl(c8664700,80206910,c72b8b78,c76ee900,c81b7960,...) at soo_ioctl+0x25d/frame 0xc72b8b08 kern_ioctl(c81b7960,3,80206910,c72b8b78,10,...) at kern_ioctl+0x31d/frame 0xc72b8b50 sys_ioctl(c81b7960,c72b8ca8,28ce9000,283f8f12,c77189c0,...) at sys_ioctl+0x11b/frame 0xc72b8c10 syscall(c72b8ce8) at syscall+0x5e0/frame 0xc72b8cdc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xc72b8cdc --- syscall (54, FreeBSD ELF32, sys_ioctl), eip = 0x284a1d4f, esp = 0xbfbfec3c, ebp = 0xbfbfec98 --- But i guess that might be another iwi bug that got uncovered now and is not related to the conversion. Regards -- Michael Moll pgp7ITmUJ0vJI.pgp Description: PGP signature
Re: converted iwi(4) for testing Was: [Testers needed!] WiFi drivers changes
Hi, On Wed, Jun 03, 2015 at 01:48:06AM +0300, Gleb Smirnoff wrote: On Tue, Jun 02, 2015 at 11:47:36PM +0200, Michael Moll wrote: M On Tue, Jun 02, 2015 at 07:20:21PM +0300, Gleb Smirnoff wrote: M I've converted iwi(4) and refreshed the D2655. I will appreciate M if you test it. Please report if there are any problems. Thanks! M M Some seconds after bringing it up I'm getting: M M kernel trap 12 with interrupts disabled Oh, we have just uncovered a very funny bug in the current iwi(4) code. Nice one. :) I have fixed the bug in head, and updated the phab revision. The current phab revision will apply only to the fresh head. Please retry! And thanks a lot for your efforts. :) This already is resulting in a working connection. I'll test more extensively tomorrow and report back. Thanks! -- Michael Moll pgpoGIBB_7j9u.pgp Description: PGP signature
Re: converted iwi(4) for testing Was: [Testers needed!] WiFi drivers changes
Hi, On Tue, Jun 02, 2015 at 07:20:21PM +0300, Gleb Smirnoff wrote: I've converted iwi(4) and refreshed the D2655. I will appreciate if you test it. Please report if there are any problems. Thanks! Some seconds after bringing it up I'm getting: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x6864733b fault code = supervisor read, page not present instruction pointer = 0x20:0xc0babee6 stack pointer = 0x28:0xc7211ac0 frame pointer = 0x28:0xc7211b24 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 0 (iwi0 net80211 taskq) [ thread pid 0 tid 100048 ] Stopped at thread_lock_flags_+0x56:movl0x10(%edi),%eax db bt Tracing pid 0 tid 100048 td 0xc82cf960 thread_lock_flags_(c8223400,10,c12d590d,d2,c0bdec1d,...) at thread_lock_flags_+0x56/frame 0xc7211b24 propagate_priority(c82cf960,c758f900,c12d590d,2da,11,...) at propagate_priority+0xcb/frame 0xc7211b50 turnstile_wait(c758f900,c8223400,0,c82cf960,87abb22,...) at turnstile_wait+0x3fe/frame 0xc7211b80 __mtx_lock_sleep(c759d7d0,c82cf960,0,0,0,...) at __mtx_lock_sleep+0x17f/frame 0xc7211bf0 iwi_update_wme(c78e,1,c7775c98,0,c12c0692,...) at iwi_update_wme+0xa4/frame 0xc7211c20 taskqueue_run_locked(c7775c80,c7775c98,0,c12c0692,0,...) at taskqueue_run_locked+0x176/frame 0xc7211c6c taskqueue_thread_loop(c78e00ac,c7211ce8,0,0,0,...) at taskqueue_thread_loop+0x117/frame 0xc7211ca4 fork_exit(c0c308b0,c78e00ac,c7211ce8) at fork_exit+0xa2/frame 0xc7211cd4 fork_trampoline() at fork_trampoline+0x8/frame 0xc7211cd4 --- trap 0, eip = 0, esp = 0xc7211d20, ebp = 0 --- Regards -- Michael Moll pgpxyVFicHTbR.pgp Description: PGP signature
Re: Memory corruption in a master perl process after child exits - only under FreeBSD 10.0 amd64 (not in 10.1 or 9.*)
Hi, On Wed, Jan 28, 2015 at 03:53:25PM -0600, Mark Felder wrote: https://rt.perl.org/Ticket/Display.html?id=122199 Given the ability to reproduce this 100% it seems perfect for using git bisect command to figure out which commit between 10.0 and 10.1 solves this. Sorry for coming late to this thread, but depending on the CPU it might be worth a try if it's fixed on 10.0 with vm.pmap.pcid_enabled set to 0. Regards -- Michael Moll ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: sparc64 backend for llvm/clang imported
Hi,
On Fri, Feb 28, 2014 at 08:22:06PM +0100, Dimitry Andric wrote:
If you have any sparc64 hardware, and are not afraid to encounter rough
edges, please try out building and running your system with clang. To
On all my sparc64 machines the loader seems to be broken:
{0} ok boot net:dhcp
Boot device: /pci@1f,70/network@2:dhcp File and args:
1000 Mbps FDX Link up
Consoles: Open Firmware console
panic: tlb_init_sun4u: no node for bootcpu?!?!
-- Press a key on the console to reboot --
I'm booting via TFTP, the boot environment was built on amd64 with
TARGET=sparc64.
Regards
--
Michael Moll
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
config(8) dumps core
Hi All, after upgrading a FreeBSD/sparc64 machine from CURRENT sources of 3rd March to ones of 28th April config(8) doesn't work correctly anymore: server01# config -x /boot/kernel/kernel options CONFIG_AUTOGENERATED ident GENERIC machine sparc64 cpu SUN4U [...] device fwe device fwip device dcons device dcons_crom Assertion failed: (r != '\0' (Char present in the configuration string mustn't be equal to 0)), function kernconfdump, file /usr/src/usr.sbin/config/main.c, line 721. Abort (core dumped) A backtrace does not bring up anything useful: (gdb) bt #0 0x40580668 in kill () from /lib/libc.so.7 #1 0x404b6be0 in abort () from /lib/libc.so.7 #2 0x4056848c in __assert () from /lib/libc.so.7 #3 0x00104064 in ?? () Previous frame identical to this frame (corrupt stack?) (gdb) Any ideas on this? Kind Regards -- Michael Moll ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: config(8) dumps core
Hi, On Thu, Apr 29, 2010 at 11:33:30PM +0300, Andriy Gapon wrote: on 29/04/2010 18:31 Michael Moll said the following: You can use hd to see if you indeed have '\0' (0x00) symbol somewhere within your kernel config file. Thanks, I checked this and there are no 0x00s in the config file itself, but a hd to /boot/kernel/kernel reveals: 09 66 77 69 70 0a 64 65 76 69 63 65 09 64 63 6f |.fwip.device.dco| 6e 73 0a 64 65 76 69 63 65 09 64 63 6f 6e 73 5f |ns.device.dcons_| 63 72 6f 6d 0a 00 00 00 00 00 00 00 00 00 00 00 |crom| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || This also explains why a recent config-binary worked against the old kernel... The were some commits to /src/usr.sbin/config/* in the last weeks, maybe one of them broke this. Kind Regards -- Michael Moll ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: config(8) dumps core
Hi, On Thu, Apr 29, 2010 at 11:30:06PM +0100, Bruce Cran wrote: /boot/kernel/kernel. It looks like it thinks there's more data available than there is. config/main.c gets the size of the configuration by running elfdump: elfdump -c /boot/kernel/kernel | grep -A 5 kern_conf | tail -2 | cut -d ' ' -f 2 | paste - - - 100533682656 The first column is the offset, and the second is the number of bytes, but the embedded configuration only has 2649 bytes. OK, that explains that with all the related commits backup out (207265-206664) the resulting config-binary still fails. I don't have time today to build the kernel with the different revisions to hunt the problem down to one commit... imp@: The last commits to usr.sbin/config/* might have raised this problem, could you have a look at it? Kind Regards -- Michael Moll ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: config(8) dumps core
On Thu, Apr 29, 2010 at 05:07:00PM -0600, M. Warner Losh wrote: Do you have a small, reproducible sequence of events that will recreate this problem? I've seen no problems at all in my testing. I assume this is in -current? Yes, -CURRENT. Compile a kernel on sparc64 (didn't try this yet on other archs) and run config -x on the resulting file. Kind Regards -- Michael Moll ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
