Jenkins build is back to normal : FreeBSD_HEAD-tests2 #1036
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/1036/ ___ 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: Deja vu: panic in hdaa_coonfigure() for i386, but not amd64 -- again
On Saturday, May 09, 2015 07:27:51 AM David Wolfskill wrote: Ref. http://docs.FreeBSD.org/cgi/mid.cgi?20150415134515.GQ1224 -- similar symptoms. And again, I captured screenshots on a phone, but FreeBSD doesn't seem to recognize the (USB-attached) phone as something that might act like a file system (I guess; I'm a bit new to smartphones). In this case, my starting-point was r282623; sources were updated to r282676. I was able to update from: FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #55 r282623M/282623:1100072: Fri May 8 05:40:49 PDT 2015 r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY amd64 to FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #56 r282676M/282676:1100073: Sat May 9 05:50:15 PDT 2015 r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY amd64 without incident, but the update from: FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1590 r282623M/282623:1100072: Fri May 8 06:40:11 PDT 2015 r...@g1-254.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 was only able to build; the panic occurs before we've found any disks, so I can't get a crash dump. I do have a kdb prompt, though, so if someone has a suggestion for something to check, please let me know. (Mind, reading email will be rather awkward while the laptop is exploring the mysteries of a panic, so that might be worth bearing in mind.) Just prior to the bactrace, I see: ... hdaa1: 30 41f0 15 0 Speaker None 1/8 Rear Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex hdac1 (HDA driver mutex) r = 0 (0xcfef... src/sys/dev/sound/pci/hda/hdaa.c:1571 The most recent relevant entries in the backtrace are: hdaa_configure() hdaa_attach() device_attach() bus_generic_attach() hdacc_attach() device_attach() bus_generic_attach() hdac_attach2() run_interrupt_driven_config_hooks() boot_interrupt_driven_config_hooks() mi_startup() begin() The panic message is fatal trap 12: page fault while in kernel mode ... fault code= supervisor read, page not present ... current process = 0 (swapper) ... Stopped at ... = hdaa_configure+0x14af: movb0x3,%dl Can you do 'l *hdaa_configure+0x14af' in gdb against the kernel.debug? Perhaps set 'hint.hdac.0.disabled=1' at the loader prompt as a temporary workaround to boot if needed? -- John Baldwin ___ 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
Build failed in Jenkins: FreeBSD_HEAD #2769
See https://jenkins.freebsd.org/job/FreeBSD_HEAD/2769/changes Changes: [pfg] Break apart the gnu_inline attribute and use artificial if available. In general it is bad practice to use the gnu_inline attribute but we will need it in special cases like FORTIFY_SOURCE. In this specific case it is also useful to have the artificial attribute: This attribute is useful for small inline wrappers which if possible should appear during debugging as a unit, depending on the debug info format it will either mean marking the function as artificial or using the caller location for all instructions within the inlined body. This attribute appears to be currently implemented only in GCC. Use it only in conjuntion with gnu_inline in the cases where it is available, which is similar in spirit in how it's used in glibc. [cy] Correct location for libntpevent.a. [zbb] Introduce support for the Alpine PoC from Annapurna Labs The Alpine Platform-On-Chip offers multicore processing (quad ARM Cortex-A15), 1/10Gb Ethernet, SATA 3, PCI-E 3, DMA engines, Virtualization, Advanced Power Management and other. This code drop involves basic platform support including: SMP, IRQs, SerDes, SATA. As of now it is missing the PCIe support. Part of the functionality is provided by the low-level code (HAL) delivered by the chip vendor (Annapurna Labs) and is a subject to change in the future (is planned to be moved to sys/contrib directory). The review log for this commit is available here: https://reviews.freebsd.org/D2340 Reviewed by:andrew, ian, imp Obtained from: Semihalf Sponsored by: Annapurna Labs [ian] Add assertions that the addresses passed to tlb maintenance are page-aligned. Perform cache writebacks and invalidations in the correct (inner to outer or vice versa) order, and add comments that explain that. Consistantly use 'va' as the variable name for virtual addresses. Submitted by: Michal Meloun mel...@miracle.cz [ian] Retrieve the cache parms in the proper arch-specific way. Submitted by: Michal Meloun mel...@miracle.cz [gnn] Summary: Remove spurious, extra, next header comments. Correct the name of the pad length field. [pfg] Replace a CONSTCOND for a void value as a replacement for __unreachable builtin This only applies if we are not using clang or gcc but it lets us use the __unreachable() buitin in expressions. Suggested by: tijl [bapt] Allow MANWIDTH to work with mandoc(1) Reported by:bdrewery [pkelsey] When a netmap process terminates without the full set of buffers it was granted via rings and ni_bufs_list_head represented in those rings and lists (e.g., via SIGKILL), those buffers are no longer available for subsequent users for the lifetime of the system. To mitigate this resource leak, reset the allocator state when the last ref to that allocator is released. Note that this only recovers leaked resources for an allocator when there are no longer any users of that allocator, so there remain circumstances in which leaked allocator resources may not ever be recovered - consider a set of multiple netmap processes that are all using the same allocator (say, the global allocator) where members of that set may be killed and restarted over time but at any given point there is one member of that set running. Based on intial work by adrian@. Reviewed by: Giuseppe Lettieri (g.letti...@iet.unipi.it), luigi Approved by: jmallett (mentor) MFC after: 1 week Sponsored by: Norse Corp, Inc. [emaste] Build libgomp only if we're also building base system GCC Clang's OpenMP support will emit Intel OpenMP API library calls, and will therefore require libiomp (or whatever name is settled on). An up-to-date version of libgomp is included in ports or pkg GCC. Thus, there is no reason to build base libgomp without base system GCC. PR: 199979 (exp-run) Reviewed by:pfg Relnotes: Yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D2459 [br] Provide the number of interrupt resources added to the list by using extra argument, so caller will know that. [jhb] Previously, cv_waiters was only updated by cv_signal or cv_wait. If a thread awakened due to a time out, then cv_waiters was not decremented. If INT_MAX threads timed out on a cv without an intervening cv_broadcast, then cv_waiters could overflow. To fix this, have each sleeping thread decrement cv_waiters when it resumes. Note that previously cv_waiters was protected by the sleepq chain lock. However, that lock is not held when threads resume from sleep. In addition, the interlock is also not always reacquired after resuming (cv_wait_unlock), nor is it always held by callers of cv_signal() or cv_broadcast(). Instead, use atomic ops to update cv_waiters. Since the sleepq chain lock is still held on every increment, it should still be safe to compare cv_waiters against zero while holding the lock in the wakeup routines as the only way the race should be lost would result in extra
Re: UMA initialization failure with 48 core ARM64
On May 15, 2015, at 11:30 AM, Michał Stanek m...@semihalf.com wrote: Hi, I am experiencing an early failure of UMA on an ARM64 platform with 48 cores enabled. I get a kernel panic during initialization of VM. Here is the boot log (lines with 'MST:' are my own debug printfs). Copyright (c) 1992-2015 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #333 52fd91e(smp_48)-dirty: Fri May 15 18:26:56 CEST 2015 mst@arm64-prime:/usr/home/mst/freebsd_v8/obj_kernel/arm64.aarch64/usr/home/mst/freebsd_v8/kernel/sys/THUNDER-88XX arm64 FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225 MST: in vm_mem_init() MST: in vmem_init() with param *vm == kernel_arena MST: in vmem_xalloc() with param *vm == kernel_arena MST: in vmem_xalloc() with param *vm == kmem_arena panic: mtx_lock() of spin mutex (null) @ /usr/home/mst/freebsd_v8/kernel/sys/kern/subr_vmem.c:1165 cpuid = 0 KDB: enter: panic [ thread pid 0 tid 0 ] Stopped at 0xff80001f4f80: The kernel boots fine when MAXCPU is set to 30 or lower, but the error above always appears when it is set to a higher value. The panic is triggered by a KASSERT in __mtx_lock_flags() which is called with the macro VMEM_LOCK(vm) in vmem_xalloc(). This is line 1143 in subr_vmem.c (log shows different line number due to added printfs). It looks like the lock belongs to 'kmem_arena' which is uninitialized at this point (kmeminit() has not been called yet). While debugging, I tried modifying VM code as a quick workaround. I replaced the number of cores to 1 wherever mp_ncpus, mp_maxid or MAXCPU (and others) are read. This, I believe, limits UMA per-cpu caches to just one, while the rest of the OS (scheduler, etc) sees all 48 cores. In addition, I changed UMA_BOOT_PAGES in sys/vm/uma_int.h to 512 (default was 64). With these tweaks, I got a successful (but not really stable) boot with 48 cores. Of course these are dirty hacks and a proper solution is needed. I am a bit surprised that the kernel fails with MAXCPU==48 as the amd64 arch has this value set to '256' and I have read posts that other platforms with even more cores have worked fine. Perhaps I need to tweak some other VM parameters, apart from UMA_BOOT_PAGES (AKA vm.boot_pages), but I am not sure how. I included a full stacktrace and a more verbose log (with UMA_DEBUG macros enabled) in the attachment. There is also a diff of the hacks I used while debugging. Hi, Michal! It looks like the log attachment didn’t make it though the mailing list. Can you please resend it again? The panic suggests that a mutex was left uninitialized... -- ST4096-RIPE ___ 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: [RFC] Replace gnu groff in base by heirloom doctools
Hi Bapt current@ I think keeping a fully functionnal roff(7) toolchain part of the base system is very good on a unix. Yes, Unix has always also been a tool to get jobs done (aka PWB), as well as merely recompile more Unix. Ditto FreeBSD. From what I could check I cannot find any regression when migrating from gnu groff to heirloom doctools, if there is a particular area when you think extra care is needed please share it. Heirloom doctools: https://github.com/n-t-roff/heirloom-doctools Regression tests that use public BSD source data to build more BSD are a good start, but just a start, insufficient to discover all problems. There's non public user data sets to consider. Many users won't read current@, just announce@, so before removal hits a Release, we need a one Release warning, ie This is the last Release before old functionality goes. Assume lots of user data will Not be compatible with heirloom-doctools users wont know to start checking their data, until they see an announcement in the next Release. We'll need a copy of same version of existing tools, macros etc, copied out unchanged to a port or meta port so users affected have a lifeboat. User data Will break: (My groff usage frequently broke when groff changed: I use groff for CV, business card, letters, invoices, personal, with embedded pics, scaled offset figures, tables, fonts, sizes, ouput in all of txt ps pdf pcl html output.) Unfortnately I have'nt time to help test with my data as FreeBSD already eats too much time, shoving bind from src to ports (+planning to dump bind move on) + ripping majordomo acroread out of ports, all of which I need must restore before upgrading servers workstations. Changes would need maximal warning minimum disruption please. Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with . Reply Below as a play script. Send plain text, Not quoted-printable, HTML, or base64. ___ 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
Jenkins build is back to normal : FreeBSD_HEAD #2770
See https://jenkins.freebsd.org/job/FreeBSD_HEAD/2770/changes ___ 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
Jenkins build is back to stable : FreeBSD_HEAD-tests2 #1038
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/1038/ ___ 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
Jenkins build is back to normal : FreeBSD_HEAD_i386 #138
See https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/138/changes ___ 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
UMA initialization failure with 48 core ARM64
Hi,
I am experiencing an early failure of UMA on an ARM64 platform with 48
cores enabled. I get a kernel panic during initialization of VM. Here is
the boot log (lines with 'MST:' are my own debug printfs).
Copyright (c) 1992-2015 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 is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #333 52fd91e(smp_48)-dirty: Fri May 15 18:26:56 CEST
2015
mst@arm64-prime:/usr/home/mst/freebsd_v8/obj_kernel/arm64.aarch64/usr/home/mst/freebsd_v8/kernel/sys/THUNDER-88XX
arm64
FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225
MST: in vm_mem_init()
MST: in vmem_init() with param *vm == kernel_arena
MST: in vmem_xalloc() with param *vm == kernel_arena
MST: in vmem_xalloc() with param *vm == kmem_arena
panic: mtx_lock() of spin mutex (null) @
/usr/home/mst/freebsd_v8/kernel/sys/kern/subr_vmem.c:1165
cpuid = 0
KDB: enter: panic
[ thread pid 0 tid 0 ]
Stopped at 0xff80001f4f80:
The kernel boots fine when MAXCPU is set to 30 or lower, but the error
above always appears when it is set to a higher value.
The panic is triggered by a KASSERT in __mtx_lock_flags() which is called
with the macro VMEM_LOCK(vm) in vmem_xalloc(). This is line 1143 in
subr_vmem.c (log shows different line number due to added printfs).
It looks like the lock belongs to 'kmem_arena' which is uninitialized at
this point (kmeminit() has not been called yet).
While debugging, I tried modifying VM code as a quick workaround. I
replaced the number of cores to 1 wherever mp_ncpus, mp_maxid or MAXCPU
(and others) are read. This, I believe, limits UMA per-cpu caches to just
one, while the rest of the OS (scheduler, etc) sees all 48 cores.
In addition, I changed UMA_BOOT_PAGES in sys/vm/uma_int.h to 512 (default
was 64).
With these tweaks, I got a successful (but not really stable) boot with 48
cores. Of course these are dirty hacks and a proper solution is needed.
I am a bit surprised that the kernel fails with MAXCPU==48 as the amd64
arch has this value set to '256' and I have read posts that other platforms
with even more cores have worked fine. Perhaps I need to tweak some other
VM parameters, apart from UMA_BOOT_PAGES (AKA vm.boot_pages), but I am not
sure how.
I included a full stacktrace and a more verbose log (with UMA_DEBUG macros
enabled) in the attachment. There is also a diff of the hacks I used while
debugging.
Best regards,
Michal Stanek
diff --git a/sys/kern/kern_malloc.c b/sys/kern/kern_malloc.c
index aef1e4e..be225fb 100644
--- a/sys/kern/kern_malloc.c
+++ b/sys/kern/kern_malloc.c
@@ -874,7 +874,7 @@ malloc_uninit(void *data)
* Look for memory leaks.
*/
temp_allocs = temp_bytes = 0;
- for (i = 0; i MAXCPU; i++) {
+ for (i = 0; i 1; i++) {
mtsp = mtip-mti_stats[i];
temp_allocs += mtsp-mts_numallocs;
temp_allocs -= mtsp-mts_numfrees;
diff --git a/sys/kern/subr_vmem.c b/sys/kern/subr_vmem.c
index 80940be..89d62ed 100644
--- a/sys/kern/subr_vmem.c
+++ b/sys/kern/subr_vmem.c
@@ -665,7 +665,8 @@ vmem_startup(void)
* CPUs to attempt to allocate new tags concurrently to limit
* false restarts in UMA.
*/
- uma_zone_reserve(vmem_bt_zone, BT_MAXALLOC * (mp_ncpus + 1) / 2);
+ //mst look here
+ uma_zone_reserve(vmem_bt_zone, BT_MAXALLOC * (1 + 1) / 2);
uma_zone_set_allocf(vmem_bt_zone, vmem_bt_alloc);
#endif
}
diff --git a/sys/vm/uma_core.c b/sys/vm/uma_core.c
index b96c421..6382437 100644
--- a/sys/vm/uma_core.c
+++ b/sys/vm/uma_core.c
@@ -98,6 +98,14 @@ __FBSDID($FreeBSD$);
#include vm/memguard.h
#endif
+//mst: override some defines
+#undef curcpu
+#definecurcpu 0
+#undef CPU_FOREACH
+#defineCPU_FOREACH(i)
\
+ for ((i) = 0; (i) = 0; (i)++) \
+ if (!CPU_ABSENT((i)))
+
/*
* This is the zone and keg from which all zones are spawned. The idea is that
* even the zone keg heads are allocated from the allocator, so we use the
@@ -1228,6 +1236,7 @@ keg_small_init(uma_keg_t keg)
if (keg-uk_flags UMA_ZONE_PCPU) {
u_int ncpus = mp_ncpus ? mp_ncpus : MAXCPU;
+ ncpus = 1;
keg-uk_slabsize = sizeof(struct pcpu);
keg-uk_ppera = howmany(ncpus * sizeof(struct pcpu),
@@ -1822,7 +1831,7 @@ uma_startup(void *bootmem, int boot_pages)
#endif
args.name = UMA Zones;
args.size = sizeof(struct uma_zone) +
- (sizeof(struct uma_cache) * (mp_maxid + 1));
+ (sizeof(struct uma_cache) * (0 + 1));
args.ctor = zone_ctor;
args.dtor = zone_dtor;
args.uminit = zero_init;
@@ -3301,7 +3310,7 @@ uma_zero_item(void *item, uma_zone_t zone)
{
if (zone-uz_flags
CFR - watchdogd exit timeout
I would like to add a new feature to watchdogd(8): -x seconds option to specify the watchdog timeout to leave in effect when the program exits (currently behavior is to disable the watchdog on exit). The change is available for review... https://reviews.freebsd.org/D2556 -- Ian ___ 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: Deja vu: panic in hdaa_coonfigure() for i386, but not amd64 -- again
On Fri, May 15, 2015 at 02:59:10PM -0400, John Baldwin wrote: ... Hummm, the only recent change is 281544, but that should be in your working kernel. Yes; that dates from 14 April, and I had been doing daily build/boots of head/i386 through thta period without incident. Absent something compelling, I'm pretty sure that experience alone removes 281544 from plausibly being implicated. It does mess with the layout of pins though so maybe try reverting it anyway? It might also be worth trying to revert just the one commit you identified earlier. It just seems odd for 'as[cnt]' to fault here but not earlier. OK; I tried reverting 282650, but the result wouldn't build because the AFMT_CHANNEL_MAX token wasn't defined. Turns out it had been used by 282651, so I reverted that (and found that it would have been cleaner had I reverted them in reverse sequence, but svn patch seemed to merely whine a bit, but cope anyway). After reverting both 282650 282651, the resulting kernel built. I commented out the 'hint.hdac.0.disabled=1' entry in /boot/device.hints, pressed the button, and watched for magic smoke FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #1598 r282948M/282952:1100072: Fri May 15 12:39:11 PDT 2015 root@localhost:/common/S4/obj/usr/src/sys/CANARY i386 localhost(11.0-C)[4] cat /dev/sndstat Installed devices: pcm0: NVIDIA (0x0042) (HDMI/DP 8ch) (play) pcm1: NVIDIA (0x0042) (HDMI/DP 8ch) (play) pcm2: Realtek ALC292 (Analog 2.0+HP/2.0) (play/rec) default pcm3: Realtek ALC292 (Analog) (play/rec) localhost(11.0-C)[5] No magic smoke leaked out this time! :-) (I note that with 'hint.hdac.0.disabled=1' in place, only the RealTek codec showed up in that output. Not that this is surprising -- rather, it's a bit of a comforting reality check after seeing so many panics.) Please also note: * head/amd64 hasn't experienced any such panics for me (yes, on the same hardware; that's one of the reasons I do this sort of thing). * This hardware exhibits a bit of a peculiarity under FreeBSD: if phones are inserted in the headphone jack, there's a loud static/hissing sound, regardless of any intentional source of a signal being played. Neither MS Windows 7, Fedora 20, nor Fedora 21 exhibits this behavior. (I'm trying to puzzle my way through the way the Linux folks document the HDA configuration to try to figure out what knob needs to be twisted in what way so I can use headphones on the machine Clues would be welcome.) Anyway, I think we have a smoking gun, as it were. Thanks for your help, John! :-) Peace, david -- David H. Wolfskill da...@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpoL6gpdvO9I.pgp Description: PGP signature
Jenkins build became unstable: FreeBSD_HEAD-tests2 #1037
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/1037/ ___ 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
Build failed in Jenkins: FreeBSD_HEAD_i386 #137
See https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/137/changes Changes: [pfg] Break apart the gnu_inline attribute and use artificial if available. In general it is bad practice to use the gnu_inline attribute but we will need it in special cases like FORTIFY_SOURCE. In this specific case it is also useful to have the artificial attribute: This attribute is useful for small inline wrappers which if possible should appear during debugging as a unit, depending on the debug info format it will either mean marking the function as artificial or using the caller location for all instructions within the inlined body. This attribute appears to be currently implemented only in GCC. Use it only in conjuntion with gnu_inline in the cases where it is available, which is similar in spirit in how it's used in glibc. [cy] Correct location for libntpevent.a. [zbb] Introduce support for the Alpine PoC from Annapurna Labs The Alpine Platform-On-Chip offers multicore processing (quad ARM Cortex-A15), 1/10Gb Ethernet, SATA 3, PCI-E 3, DMA engines, Virtualization, Advanced Power Management and other. This code drop involves basic platform support including: SMP, IRQs, SerDes, SATA. As of now it is missing the PCIe support. Part of the functionality is provided by the low-level code (HAL) delivered by the chip vendor (Annapurna Labs) and is a subject to change in the future (is planned to be moved to sys/contrib directory). The review log for this commit is available here: https://reviews.freebsd.org/D2340 Reviewed by:andrew, ian, imp Obtained from: Semihalf Sponsored by: Annapurna Labs [ian] Add assertions that the addresses passed to tlb maintenance are page-aligned. Perform cache writebacks and invalidations in the correct (inner to outer or vice versa) order, and add comments that explain that. Consistantly use 'va' as the variable name for virtual addresses. Submitted by: Michal Meloun mel...@miracle.cz [ian] Retrieve the cache parms in the proper arch-specific way. Submitted by: Michal Meloun mel...@miracle.cz [gnn] Summary: Remove spurious, extra, next header comments. Correct the name of the pad length field. [pfg] Replace a CONSTCOND for a void value as a replacement for __unreachable builtin This only applies if we are not using clang or gcc but it lets us use the __unreachable() buitin in expressions. Suggested by: tijl -- [...truncated 62285 lines...] 14 errors generated. In file included from https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/libcompiler_rt/../../contrib/compiler-rt/lib/builtins/modsi3.c:15: In file included from https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/libcompiler_rt/../../contrib/compiler-rt/lib/builtins/int_lib.h:52: In file included from https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/obj/jenkins/workspace/FreeBSD_HEAD_i386/tmp/usr/include/limits.h:36: https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/obj/jenkins/workspace/FreeBSD_HEAD_i386/tmp/usr/include/sys/cdefs.h:550:2: error: #else after #else #else ^ https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/obj/jenkins/workspace/FreeBSD_HEAD_i386/tmp/usr/include/sys/cdefs.h:36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/libcompiler_rt/../../contrib/compiler-rt/lib/builtins/modsi3.c:15: In file included from https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/libcompiler_rt/../../contrib/compiler-rt/lib/builtins/int_lib.h:52: In file included from https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/obj/jenkins/workspace/FreeBSD_HEAD_i386/tmp/usr/include/limits.h:138: In file included from https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/obj/jenkins/workspace/FreeBSD_HEAD_i386/tmp/usr/include/sys/limits.h:35: https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/obj/jenkins/workspace/FreeBSD_HEAD_i386/tmp/usr/include/sys/cdefs.h:550:2: error: #else after #else #else ^ https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/obj/jenkins/workspace/FreeBSD_HEAD_i386/tmp/usr/include/sys/cdefs.h:36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/libcompiler_rt/../../contrib/compiler-rt/lib/builtins/modsi3.c:15: In file included from https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/libcompiler_rt/../../contrib/compiler-rt/lib/builtins/int_lib.h:53: In file included from https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/obj/jenkins/workspace/FreeBSD_HEAD_i386/tmp/usr/include/stdint.h:32: https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/obj/jenkins/workspace/FreeBSD_HEAD_i386/tmp/usr/include/sys/cdefs.h:550:2: error: #else after #else #else ^ https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/obj/jenkins/workspace/FreeBSD_HEAD_i386/tmp/usr/include/sys/cdefs.h:36:2: error: unterminated conditional
Re: Deja vu: panic in hdaa_coonfigure() for i386, but not amd64 -- again
On Friday, May 15, 2015 11:39:56 AM David Wolfskill wrote:
On Fri, May 15, 2015 at 11:40:44AM -0400, John Baldwin wrote:
On Saturday, May 09, 2015 07:27:51 AM David Wolfskill wrote:
Ref. http://docs.FreeBSD.org/cgi/mid.cgi?20150415134515.GQ1224 --
similar symptoms. And again, I captured screenshots on a phone, but
FreeBSD doesn't seem to recognize the (USB-attached) phone as something
that might act like a file system (I guess; I'm a bit new to
smartphones).
In this case, my starting-point was r282623; sources were updated to
r282676. I was able to update from:
...
Stopped at ... = hdaa_configure+0x14af: movb0x3,%dl
Can you do 'l *hdaa_configure+0x14af' in gdb against the kernel.debug?
Perhaps set 'hint.hdac.0.disabled=1' at the loader prompt as a temporary
workaround to boot if needed?
...
'hint.hdac.0.disabled=1' appended to /boot/device.hints temporarily.
now running:
FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #1597
r282948M/282952:1100073: Fri May 15 09:13:17 PDT 2015
r...@g1-254.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386
Info you requested:
(gdb) l *hdaa_configure+0x14af
0xc08c8e3f is in hdaa_configure (/usr/src/sys/dev/sound/pci/hda/hdaa.c:3280).
3275as[cnt].pincnt++;
3276/* Association 15 is a multiple unassociated
pins. */
3277if (j == 15)
3278cnt++;
3279}
3280if (j != 15 as[cnt].pincnt 0) {
3281if (hpredir as[cnt].pincnt 1)
3282as[cnt].hpredir = first;
3283cnt++;
3284}
(gdb)
Hummm, the only recent change is 281544, but that should be in your working
kernel. It does mess with the layout of pins though so maybe try reverting it
anyway?
It might also be worth trying to revert just the one commit you identified
earlier. It just seems odd for 'as[cnt]' to fault here but not earlier.
--
John Baldwin
___
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: Deja vu: panic in hdaa_coonfigure() for i386, but not amd64 -- again
On Fri, May 15, 2015 at 11:40:44AM -0400, John Baldwin wrote:
On Saturday, May 09, 2015 07:27:51 AM David Wolfskill wrote:
Ref. http://docs.FreeBSD.org/cgi/mid.cgi?20150415134515.GQ1224 --
similar symptoms. And again, I captured screenshots on a phone, but
FreeBSD doesn't seem to recognize the (USB-attached) phone as something
that might act like a file system (I guess; I'm a bit new to
smartphones).
In this case, my starting-point was r282623; sources were updated to
r282676. I was able to update from:
...
Stopped at ... = hdaa_configure+0x14af: movb0x3,%dl
Can you do 'l *hdaa_configure+0x14af' in gdb against the kernel.debug?
Perhaps set 'hint.hdac.0.disabled=1' at the loader prompt as a temporary
workaround to boot if needed?
...
'hint.hdac.0.disabled=1' appended to /boot/device.hints temporarily.
now running:
FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #1597
r282948M/282952:1100073: Fri May 15 09:13:17 PDT 2015
r...@g1-254.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386
Info you requested:
(gdb) l *hdaa_configure+0x14af
0xc08c8e3f is in hdaa_configure (/usr/src/sys/dev/sound/pci/hda/hdaa.c:3280).
3275as[cnt].pincnt++;
3276/* Association 15 is a multiple unassociated
pins. */
3277if (j == 15)
3278cnt++;
3279}
3280if (j != 15 as[cnt].pincnt 0) {
3281if (hpredir as[cnt].pincnt 1)
3282as[cnt].hpredir = first;
3283cnt++;
3284}
(gdb)
Info about the machine (verbose dmesg.boot; dmidecode; pciconf -lv
output) may be found at http://www.catwhisker.org/~david/FreeBSD/m4800/.
Thanks!
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
pgpR11z563FAz.pgp
Description: PGP signature
