Re: One-shot-oriented event timers management
Brandon Gooch wrote: One thing I see: Where is *frame pointing to? It isn't initialized in the function, so... Thanks! Fixed. Patch updated. Also, for those of us testing, should we reset our timer settings back to defaults and work from there[1] (meaning, should we be futzing around with timer event sources, kern.hz, etc...)? The general logic is still applicable. Reducing HZ is less important now, but lower value allows system slightly aggregate close events by the cost of precision. Unluckily we have no better mechanism to do it now. What's about event source - there is only one timer supported now and sysctl/tunable name changed to kern.eventtimer.timer, so previous options just won't work. Also with support for one-shot mode, use of RTC and i8254 timers is not recommended any more - they do not support it. Use LAPIC or HPET. If you have Core-iX class CPU - you may use any of them, they are very close in functionality. If you use Core2 or earlier - prefer HPET, as LAPIC is dying in C3 state. If you use HPET on Core2-class CPU (actually on ICHX class south bridges, which do not support MSI-like interrupts for HPET) - you may like to set such tunables: hint.atrtc.0.clock=0 hint.attimer.0.clock=0 hint.hpet.0.legacy_route=1 It will disable RTC and i8254 timers, but grant their interrupts to HPET, allowing it to work as per-CPU for dual-CPU systems. -- Alexander Motin ___ 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: One-shot-oriented event timers management
On Sun, 29 Aug 2010 16:10:00 +0300 Alexander Motin m...@freebsd.org wrote: I have actively tested this code for a few days on my amd64 Core2Duo laptop and i386 Core-i5 desktop system. With C2/C3 states enabled systems experience only about 100-150 interrupts per second, having HZ set to 1000. These events mostly caused by several event-greedy processes in our tree. I have traced and hacked several most aggressive ones in this patch: http://people.freebsd.org/~mav/tm6292_idle.patch . It allowed me to reduce down to as low as 50 interrupts per system, including IPIs! Here is the output of `systat -vm 1` from my test system: http://people.freebsd.org/~mav/systat_w_oneshot.txt . Obviously that with additional tuning the results can be improved even more. Hmm. I applied your patches and am now running the new kernel. But I only installed the new kernel and didn't do make buildworld installworld. Mu systat -vm 1 doesn't look anything like yours. I'm seeing about 2300 interrupts per second and most of those are coming from the hpet timers: 1122 hpet0:t0 1124 hpet0:t1 So, what else did you do to reduce interrupts so much? Ah, I think I see it now. My desktop has only C1 enabled. Is that it? Unfortunately, it appears that only C1 is supported :( -- Gary Jennejohn ___ 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: patch for topology detection of Intel CPUs
On 29 August 2010 13:25, Andriy Gapon a...@freebsd.org wrote: [Reposted from stable@; edited] The below patch is against sources in FreeBSD tree, it should be applied either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending on the desired architecture: http://people.freebsd.org/~avg/intel-cpu-topo.diff Hi, Andriy. I tried your patch and see no regression on Xeon 50xx, 55xx, 54xx. It also improved CPU detection on Xeon 54xx (as well as original Junk-uk's patch). It also improved CPU detection on Xen HVM @ Xeon 55xx @ 3 cores: FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs FreeBSD/SMP: 1 package(s) x 3 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 -- wbr, pluknet ___ 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: One-shot-oriented event timers management
Gary Jennejohn wrote: Hmm. I applied your patches and am now running the new kernel. But I only installed the new kernel and didn't do make buildworld installworld. Mu systat -vm 1 doesn't look anything like yours. I'm seeing about 2300 interrupts per second and most of those are coming from the hpet timers: 1122 hpet0:t0 1124 hpet0:t1 It means 1000Hz of hardclock (hz) events mixed with 127Hz of statclock (stathz) events. HPET timer here works in one-shot mode handling it. So, what else did you do to reduce interrupts so much? Ah, I think I see it now. My desktop has only C1 enabled. Is that it? Unfortunately, it appears that only C1 is supported :( Yes, as I have said, at this moment empty ticks skipped only while CPU is in C2/C3 states. In C1 state there is no way to handle lost events on wake up. While it may be not very dangerous, it is not very good. -- Alexander Motin ___ 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: One-shot-oriented event timers management
On Mon, 30 Aug 2010 13:07:38 +0300 Alexander Motin m...@freebsd.org wrote: Gary Jennejohn wrote: Hmm. I applied your patches and am now running the new kernel. But I only installed the new kernel and didn't do make buildworld installworld. Mu systat -vm 1 doesn't look anything like yours. I'm seeing about 2300 interrupts per second and most of those are coming from the hpet timers: 1122 hpet0:t0 1124 hpet0:t1 It means 1000Hz of hardclock (hz) events mixed with 127Hz of statclock (stathz) events. HPET timer here works in one-shot mode handling it. So, what else did you do to reduce interrupts so much? Ah, I think I see it now. My desktop has only C1 enabled. Is that it? Unfortunately, it appears that only C1 is supported :( Yes, as I have said, at this moment empty ticks skipped only while CPU is in C2/C3 states. In C1 state there is no way to handle lost events on wake up. While it may be not very dangerous, it is not very good. Too bad. I'd say that systems which are limited to C1 don't benefit much (or not at all) from your changes. -- Gary Jennejohn ___ 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: One-shot-oriented event timers management
Gary Jennejohn wrote: On Mon, 30 Aug 2010 13:07:38 +0300 Alexander Motin m...@freebsd.org wrote: Gary Jennejohn wrote: Ah, I think I see it now. My desktop has only C1 enabled. Is that it? Unfortunately, it appears that only C1 is supported :( Yes, as I have said, at this moment empty ticks skipped only while CPU is in C2/C3 states. In C1 state there is no way to handle lost events on wake up. While it may be not very dangerous, it is not very good. Too bad. I'd say that systems which are limited to C1 don't benefit much (or not at all) from your changes. For this moment - indeed not much. As I have said, feature with skipping ticks is on early development stage. I've just implemented it in most straightforward way, abusing feature provided by ACPI. To benefit other systems and platforms, more tight integration with interrupt, callout and possibly scheduler subsystem will be needed. -- Alexander Motin ___ 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: One-shot-oriented event timers management
On Mon, 30 Aug 2010 13:07:38 +0300 Alexander Motin m...@freebsd.org wrote: Gary Jennejohn wrote: (snip) So, what else did you do to reduce interrupts so much? Ah, I think I see it now. My desktop has only C1 enabled. Is that it? Unfortunately, it appears that only C1 is supported :( Yes, as I have said, at this moment empty ticks skipped only while CPU is in C2/C3 states. In C1 state there is no way to handle lost events on wake up. While it may be not very dangerous, it is not very good. There's an alternative way to catch exit-from-C1 atomically: use MWAIT with bit0 of ECX set (``Treat masked interrupts as break events'' in Intel 64 and IA-32 Architecthres Software Developer's Manual). In this way we can put each core individually into deeper Cx state without additional costs (SMIs and the like) as a bonus. The problem is that it may be unavailable to earlier CPUs that support MONITOR/MWAIT instructions: we should check the presense of this feature by examining bit0 and bit1 of ECX that is returned by CPUID 5. -- YAMAMOTO, Taku t...@tackymt.homeip.net ___ 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: One-shot-oriented event timers management
YAMAMOTO, Taku wrote: On Mon, 30 Aug 2010 13:07:38 +0300 Alexander Motin m...@freebsd.org wrote: Gary Jennejohn wrote: (snip) So, what else did you do to reduce interrupts so much? Ah, I think I see it now. My desktop has only C1 enabled. Is that it? Unfortunately, it appears that only C1 is supported :( Yes, as I have said, at this moment empty ticks skipped only while CPU is in C2/C3 states. In C1 state there is no way to handle lost events on wake up. While it may be not very dangerous, it is not very good. There's an alternative way to catch exit-from-C1 atomically: use MWAIT with bit0 of ECX set (``Treat masked interrupts as break events'' in Intel 64 and IA-32 Architecthres Software Developer's Manual). In this way we can put each core individually into deeper Cx state without additional costs (SMIs and the like) as a bonus. The problem is that it may be unavailable to earlier CPUs that support MONITOR/MWAIT instructions: we should check the presense of this feature by examining bit0 and bit1 of ECX that is returned by CPUID 5. Thank you for the hint. I will investigate it now. But it still help only x86 systems. I have no idea how power management works on arm/mips/ppc/..., but I assume that periodic wake up there also may be not free. -- Alexander Motin ___ 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: patch for topology detection of Intel CPUs
on 30/08/2010 12:15 pluknet said the following: On 29 August 2010 13:25, Andriy Gapon a...@freebsd.org wrote: [Reposted from stable@; edited] The below patch is against sources in FreeBSD tree, it should be applied either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending on the desired architecture: http://people.freebsd.org/~avg/intel-cpu-topo.diff Hi, Andriy. I tried your patch and see no regression on Xeon 50xx, 55xx, 54xx. It also improved CPU detection on Xeon 54xx (as well as original Junk-uk's patch). It also improved CPU detection on Xen HVM @ Xeon 55xx @ 3 cores: FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs FreeBSD/SMP: 1 package(s) x 3 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 Thanks a lot for testing! -- Andriy Gapon ___ 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
FreeBSD 8.1 on sparc64 bge BCM5704 watchdog
Hi All, i`ve big problems on my sparc64 FIRE 240 with bge BCM5704 interfeces i upgrade my system from 8.0 to 8.1 and the problems have to begin on 8.0 work all fine. if i create some traffic about 10Mbits i see in dmesg this message: bge0: watchdog timeout -- resetting bge0: link state changed to DOWN and carp put the interfaces to backup bge0: watchdog timeout -- resetting bge0: link state changed to DOWN carp0: link state changed to DOWN carp3: MASTER - BACKUP (more frequent advertisement received) carp1: MASTER - BACKUP (more frequent advertisement received) carp3: link state changed to DOWN carp1: link state changed to DOWN carp0: INIT - BACKUP bge0: link state changed to UP carp0: link state changed to DOWN carp3: BACKUP - MASTER (preempting a slower master) carp3: link state changed to UP carp1: BACKUP - MASTER (preempting a slower master) carp1: link state changed to UP carp0: link state changed to UP Please Help me. Thanks Regards Witalij Some info from my system: # *my system is:* # FreeBSD name 8.1-RELEASE FreeBSD 8.1-RELEASE #1: Mon Aug 30 13:40:25 CEST 2010 name:/usr/obj/usr/src/sys/MICRO1 sparc64 #---* vmstat -i *#--- interrupt total rate pil4: ast 448144 89 pil2: ithrd 360185 72 vec1992: bge0 153678 30 vec1993: bge1 155592 31 vec1944: atapci0 35 0 vec1833: sym0 38564 7 vec1832: sym1 30 0 vec1885: bge3 12286 2 pil12: filter 1372 0 vec1964: uart0+ 1372 0 pil14: tick 9949609 1997 Total 11120867 2232 #- *pciconf -la* #- b...@pci3:0:2:0:class=0x02 card=0x1648108e chip=0x164814e4 rev=0x00 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme Dual Gigabit Adapter (BCM5704)' class = network subclass = ethernet b...@pci3:0:2:1:class=0x02 card=0x1648108e chip=0x164814e4 rev=0x00 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme Dual Gigabit Adapter (BCM5704)' class = network subclass = ethernet #--* KERNEL:* #--- cpu SUN4U ident GENERIC makeoptions DEBUG=-g options SCHED_4BSD # 4BSD scheduler #optionsPREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL# Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD# Network Lock Manager options NFS_ROOT# NFS usable as /, requires NFSCLIENT #optionsMSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY# BSD 4.3 TTY compat (sgtty) options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128# Prevent printf output being interspersed. options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT #
re: svn commit: r211908 - head/sys/dev/ichwd
Hi Jack, I was trying to see if your recent commits for the ichwd IDs now work with the integrated watchdog for my i5 boards, but no luck. ichsmb0: Intel PCH SMBus controller port 0x3000-0x301f mem 0xb1b23000-0xb1b230ff irq 18 at device 31.3 on pci0 ichsmb0: [ITHREAD] smbus0: System Management Bus on ichsmb0 ichwd0: Intel 3420 watchdog timer on isa0 ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 ppc0: parallel port not found. This is an actual Intel server MB (INTEL S3420GPC) and the WD is enabled in the bios. Are you able to actually get it to work on this board ? ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ 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: patch for topology detection of Intel CPUs
on 29/08/2010 12:25 Andriy Gapon said the following: The patch is substantially based on the Junk-uk's patch, but with some changes I several times mistyped Jung-uk's name, my sincere apologies. Probably should have used jkim instead :) Thanks to rdivacky for pointing this out to me. -- Andriy Gapon ___ 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: svn commit: r211908 - head/sys/dev/ichwd
2010/8/30 Mike Tancsa m...@sentex.net: Hi Jack, I was trying to see if your recent commits for the ichwd IDs now work with the integrated watchdog for my i5 boards, but no luck. ichsmb0: Intel PCH SMBus controller port 0x3000-0x301f mem 0xb1b23000-0xb1b230ff irq 18 at device 31.3 on pci0 ichsmb0: [ITHREAD] smbus0: System Management Bus on ichsmb0 ichwd0: Intel 3420 watchdog timer on isa0 ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 ppc0: parallel port not found. By any chance, is it disabled in BIOS ? Cheers, Olivier This is an actual Intel server MB (INTEL S3420GPC) and the WD is enabled in the bios. Are you able to actually get it to work on this board ? ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ 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 -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email vCards X www: http://www.gid0.org - against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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: svn commit: r211908 - head/sys/dev/ichwd
At 12:51 PM 8/30/2010, Olivier Smedts wrote: By any chance, is it disabled in BIOS ? Hi, There are a couple of options in the BIOS. There is a reboot the box if the bios does not post within 6min as well as Fire the watchdog if the dog has not been patted after 5,10 or 15min after the BIOS post. I tried all combinations without luck. If I have the reboot after x min post post, the box will reboot on its own. ---Mike Cheers, Olivier This is an actual Intel server MB (INTEL S3420GPC) and the WD is enabled in the bios. Are you able to actually get it to work on this board ? ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ 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 -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ 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
symbol versioning on libgcc?
I know that several libraries in FreeBSD uses symbol versioning. In looking through src/ I was unable to determine whether symbol versioning is used on libgcc. Any guidance would be appreciated. -- Steve ___ 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: symbol versioning on libgcc?
on 30/08/2010 20:32 Steve Kargl said the following: I know that several libraries in FreeBSD uses symbol versioning. In looking through src/ I was unable to determine whether symbol versioning is used on libgcc. Any guidance would be appreciated. Check out output of e.g. objdump -T /usr/lib/libgcc_s.so -- Andriy Gapon ___ 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: symbol versioning on libgcc?
On Mon, Aug 30, 2010 at 08:43:40PM +0300, Andriy Gapon wrote: on 30/08/2010 20:32 Steve Kargl said the following: I know that several libraries in FreeBSD uses symbol versioning. In looking through src/ I was unable to determine whether symbol versioning is used on libgcc. Any guidance would be appreciated. Check out output of e.g. objdump -T /usr/lib/libgcc_s.so Thanks. I had forgotten about objdump. A search for Symbol.map in src/ mislead me into believing the version was not happening. Further searching found the Makefile chuck that builds the map in src/gnu/lib/libgcc/Makefile. -- Steve ___ 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: symbol versioning on libgcc?
Steve Kargl wrote: I know that several libraries in FreeBSD uses symbol versioning. In looking through src/ I was unable to determine whether symbol versioning is used on libgcc. Any guidance would be appreciated. I don't think it is. I haven't poked at any sources, but there are no FBSD* symbols in /usr/lib/libgcc_s.so, which is what's used in symbol versioning in, say, /lib/libc.so.7. -Boris ___ 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: svn commit: r211908 - head/sys/dev/ichwd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Mike, On 2010/08/30 10:18, Mike Tancsa wrote: At 12:51 PM 8/30/2010, Olivier Smedts wrote: By any chance, is it disabled in BIOS ? Hi, There are a couple of options in the BIOS. There is a reboot the box if the bios does not post within 6min as well as Fire the watchdog if the dog has not been patted after 5,10 or 15min after the BIOS post. I tried all combinations without luck. If I have the reboot after x min post post, the box will reboot on its own. My guess is that your motherboard provided another watchdog (like Winbond based super I/O chips) which requires a driver, you can try this one if you wish: http://people.freebsd.org/~delphij/for_review/winbondwd/ I've no idea about your ichwd issue though. ---Mike Cheers, Olivier This is an actual Intel server MB (INTEL S3420GPC) and the WD is enabled in the bios. Are you able to actually get it to work on this board ? ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ 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 -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ 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 - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJMe/zGAAoJEATO+BI/yjfBv6oH/jsusQcssDXo+NvEfsMyQEOY y/5e0oA6GBGjkhSt6KBTYE5SyFcPv6oTi4ANwEdfPoEvw/IXEw9R6Efnam7QEDlL TdLCZr6uoHb04A5/P8FurpN94VYyr5DGbMmcRsu9mjND3cNA6odF6D26mXyr/1bC veR4EX/mkntBPDLj8+QjlYXAowXEz7QwNeCrdACBnhgsl/ybLDFXyU9xXaqebKEn 7ryN/2SHvyT8DLv3WBSKN3GybEiCHVesUfqZ3YuEpa6f0hH28RppMJrW/8sX5AJg RFB4zA+3JwJHWvpz/UgI2S1XzDZ14+tj/nwxI+n7dA+Ug8xjLaScWGhwzC1hSUs= =xI3/ -END PGP SIGNATURE- ___ 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: symbol versioning on libgcc?
Alexander Kabaev wrote: On Mon, 30 Aug 2010 13:36:03 -0400 Boris Kochergin sp...@acm.poly.edu wrote: Steve Kargl wrote: I know that several libraries in FreeBSD uses symbol versioning. In looking through src/ I was unable to determine whether symbol versioning is used on libgcc. Any guidance would be appreciated. I don't think it is. I haven't poked at any sources, but there are no FBSD* symbols in /usr/lib/libgcc_s.so, which is what's used in symbol versioning in, say, /lib/libc.so.7. -Boris And above is wrong. Just for the record. What FBSD* symbol versions have to do with the library independently versioned by FSF? My interpretation of the question was whether libgcc used FreeBSD symbol versioning. If that wasn't it, then indeed, one has nothing to do with the other. -Boris ___ 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: symbol versioning on libgcc?
On Mon, Aug 30, 2010 at 02:51:16PM -0400, Alexander Kabaev wrote: On Mon, 30 Aug 2010 13:36:03 -0400 Boris Kochergin sp...@acm.poly.edu wrote: Steve Kargl wrote: I know that several libraries in FreeBSD uses symbol versioning. In looking through src/ I was unable to determine whether symbol versioning is used on libgcc. Any guidance would be appreciated. I don't think it is. I haven't poked at any sources, but there are no FBSD* symbols in /usr/lib/libgcc_s.so, which is what's used in symbol versioning in, say, /lib/libc.so.7. -Boris And above is wrong. Just for the record. What FBSD* symbol versions have to do with the library independently versioned by FSF? I'm trying to test a gfortran 4.6.0 patch that implements REAL(16), which means that TFmode needs to be supported. The GCC infrastructure currently does not build with TFmode on FreeBSD, and so a patch has been created. The last item that needs attention is symbol versioning. See the thread starting at http://gcc.gnu.org/ml/fortran/2010-08/msg00431.html -- Steve ___ 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: svn commit: r211908 - head/sys/dev/ichwd
At 02:47 PM 8/30/2010, Xin LI wrote: My guess is that your motherboard provided another watchdog (like Winbond based super I/O chips) which requires a driver, you can try this one if you wish: http://people.freebsd.org/~delphij/for_review/winbondwd/ I've no idea about your ichwd issue though. Hi, Thanks for the link! I had a look on Intel's site and didnt find anything specifically mentioning the type of watchdog. This is an actual intel branded board and not supermicro. No luck with the driver. However, I will give it a try on some of the MBs that do have Winbond WDs. A long time ago I hacked together one for the 83697 http://www.tancsa.com/watchdog/itxwd-1.0/ ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ 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: symbol versioning on libgcc?
On Mon, 30 Aug 2010 13:36:03 -0400 Boris Kochergin sp...@acm.poly.edu wrote: Steve Kargl wrote: I know that several libraries in FreeBSD uses symbol versioning. In looking through src/ I was unable to determine whether symbol versioning is used on libgcc. Any guidance would be appreciated. I don't think it is. I haven't poked at any sources, but there are no FBSD* symbols in /usr/lib/libgcc_s.so, which is what's used in symbol versioning in, say, /lib/libc.so.7. -Boris And above is wrong. Just for the record. What FBSD* symbol versions have to do with the library independently versioned by FSF? -- Alexander Kabaev signature.asc Description: PGP signature
Re: svn commit: r211908 - head/sys/dev/ichwd
on 30/08/2010 20:18 Mike Tancsa said the following: At 12:51 PM 8/30/2010, Olivier Smedts wrote: By any chance, is it disabled in BIOS ? Hi, There are a couple of options in the BIOS. There is a reboot the box if the bios does not post within 6min as well as Fire the watchdog if the dog has not been patted after 5,10 or 15min after the BIOS post. I tried all combinations without luck. If I have the reboot after x min post post, the box will reboot on its own. I'd guess that this kind of option would enable OS use of the watchdog. Perhaps you can contact Intel about this issue, either via their official support service or via jfv (who is CCed as I see) or both. -- Andriy Gapon ___ 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: [PATCH] Use MACHINE_ARCH for boot loader
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2010/08/27 06:34, John Baldwin wrote:
On Thursday, August 26, 2010 8:50:01 pm Xin LI wrote:
Hi,
The attached patch changes FreeBSD/x86 back to FreeBSD/i386 on i386 and
FreeBSD/amd64 on amd64.
Comments welcome! I'll commit it in by the weekend if there is no
objection on this.
As others have noted, the 'x86' is on purpose, and I would rather it continue
to do that rather than this change.
What about this one? It changes the 'NEWVERSWHAT' variables from
(i386|${MACHINE_ARCH}) to x86 for consistency.
Cheers,
- --
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)
iQEcBAEBCAAGBQJMfC8RAAoJEATO+BI/yjfB6uIH/1XHiZd0U+Hojbh1GuiVCi7X
TKQJ6j6hYC1JS0cdgDcGVgqV+12b3lsvT7uFU38sV+tSALVzPltPRexqjQQ2ltcQ
EWlXRZXas/z9K/9SeLVZvVq1ZoF8vjWHvGjMjy7MRnRsSIDy9K5QEAlWbh4SkE7p
a3whNOB2o3Gn5FxWS4j3OYVyh9CLgpaiGcPrWOWQygLmY1bwRjnpC3vbby2PD7hX
9Mw1jAYJ2vdqbshZbSb4xmitUfeF4Rm7qRBxvIU4qUsVef+xabciUx74bsZlPQyi
jfvVvuuar1ToazVxxwaXlTdD5kPCtkxDSmduCx8aPh5n2w6MdRVrYTpANlamFpM=
=XeJ4
-END PGP SIGNATURE-
Index: sys/boot/i386/zfsloader/Makefile
===
--- sys/boot/i386/zfsloader/Makefile(revision 212022)
+++ sys/boot/i386/zfsloader/Makefile(working copy)
@@ -3,7 +3,7 @@
.PATH: ${.CURDIR}/../loader
LOADER=zfsloader
-NEWVERSWHAT= ZFS enabled bootstrap loader i386
+NEWVERSWHAT= ZFS enabled bootstrap loader x86
LOADER_ZFS_SUPPORT=yes
LOADER_ONLY= yes
NO_MAN=yes
Index: sys/boot/i386/efi/Makefile
===
--- sys/boot/i386/efi/Makefile (revision 212022)
+++ sys/boot/i386/efi/Makefile (working copy)
@@ -42,7 +42,7 @@ ${PROG}: ${LDSCRIPT}
CLEANFILES=vers.c loader.efi
-NEWVERSWHAT= EFI loader ${MACHINE_ARCH}
+NEWVERSWHAT= EFI loader x86
vers.c:${.CURDIR}/../../common/newvers.sh ${.CURDIR}/version
sh ${.CURDIR}/../../common/newvers.sh ${.CURDIR}/version ${NEWVERSWHAT}
Index: sys/boot/i386/loader/Makefile
===
--- sys/boot/i386/loader/Makefile (revision 212022)
+++ sys/boot/i386/loader/Makefile (working copy)
@@ -6,7 +6,7 @@ MK_SSP= no
LOADER?= loader
PROG= ${LOADER}.sym
INTERNALPROG=
-NEWVERSWHAT?= bootstrap loader i386
+NEWVERSWHAT?= bootstrap loader x86
# architecture-specific loader code
SRCS= main.c conf.c vers.c
___
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
