Re: newsyslog patch implementing file includes
22.04.2010 07:55, Gordon Tetlow пишет: I wanted the ability for a port to have a rotating log policy so I wrote a patch for newsyslog to implement includes of other newsyslog.conf style files. Please find the patch at: http://people.freebsd.org/~gordon/patches/newsyslog.diffhttp://people.freebsd.org/%7Egordon/patches/newsyslog.diff Format for the include line in /etc/newsyslog.conf is: include /etc/defaults/newsyslog.conf Here's a quick overview of the changes: Convert the conf_entry struct from using a home rolled linked list to the queue(3) macros. Add a STAILQ to process include files. Add support forinclude tag to specify include files. Globbing is supported ininclude statements. Properly detect circular include loop dependencies. Please take a look and send me any comments you might have. It's need feature. I test patch - it work for me (CURRENT, amd64) Can I use some as: include /path/to/dir/*.conf ? and can I create recursive include? ___ 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: Does makeoptions WITH_CTF=yes actually work?
Quoting Navdeep Parhar npar...@gmail.com (from Wed, 21 Apr 2010 18:23:33 -0700): Your patch works for me, thanks. There is just one more problem with the CTF I found a case where it does not work (not kernel related), I have another one which works better. generation that needs to be fixed: http://lists.freebsd.org/pipermail/freebsd-hackers/2009-April/028244.html While you're here can you take a look at the patch in that email too? Looks good in concept, but the CTFMERGE line needs the same treatment like all the other ones in the .mk files. I want to commit a suitable change today. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 I have to get back to New York tomorrow, so think about your price. -- Michael Corleone, Chapter 27, page 386 ___ 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: Does makeoptions WITH_CTF=yes actually work?
Quoting Navdeep Parhar npar...@gmail.com (from Thu, 22 Apr 2010 01:33:22 -0700): On Thu, Apr 22, 2010 at 09:44:47AM +0200, Alexander Leidinger wrote: Quoting Navdeep Parhar npar...@gmail.com (from Wed, 21 Apr 2010 18:23:33 -0700): Your patch works for me, thanks. There is just one more problem with the CTF I found a case where it does not work (not kernel related), I have another one which works better. generation that needs to be fixed: http://lists.freebsd.org/pipermail/freebsd-hackers/2009-April/028244.html While you're here can you take a look at the patch in that email too? Looks good in concept, but the CTFMERGE line needs the same treatment like all the other ones in the .mk files. I want to commit a suitable change today. Does same treatment mean it should run silently too? My personal Yes. opinion is that all ctfconvert and ctfmerge commands should show up in the output of make iff they run. I believe that used to be the case before r206082. Correct, and I agree. The problem is the inverse-logic construct for the check if it shall be run or not which is consistent with all places where this is done. There is no easy way to only display a part of the command which is executed. It was decided by ... (jhb and rwatson?) to not display at all while we still have the default to without ctf (without the @ we will even have some display of something with ctfconvert or ctfmerge in the name, when no ctf info is put into the files). They want to have the default to with ctf when it is ready/stable enough. I assume that at this point the commands get shown again, as the handling of the with/without CTF stuff can be simplified in this case. It is not as easy as all the other with/without stuff we have, due to the fact that parts of the ctf stuff is in sys.mk, which is read before every other file. Currently I want to finish the edge cases we noticed in a *consistent* way, to have something which is giving us stable behavior. After that I will go out of the loop and anyone is free to try/optimize what he wants (as long as I can get a kernel compiled with CTF info without much hassle, I do not care much what is done and how). HTH, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 A hermit is a deserter from the army of humanity. ___ 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: newsyslog patch implementing file includes
On 22 April 2010 08:33, Alex Keda ad...@lissyara.su wrote: 22.04.2010 11:29, Gordon Tetlow ?: On Thu, Apr 22, 2010 at 12:17 AM, Alex Keda ad...@lissyara.su mailto: ad...@lissyara.su wrote: It's need feature. I test patch - it work for me (CURRENT, amd64) Can I use some as: include /path/to/dir/*.conf ? and can I create recursive include? Yes, wildcards and recursive includes are supported. great job! Thanks! ___ 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 i would be real nice is newsyslog also supported a date based file renaming shceme rather than the cyclic 0,1,2,3, much like the datext option in logrotate. eg messages messages.20100422 messages.20100421 messages.20100420 ... The cyclic renaming is a pain for incremental backups as all the log files are backed up every time as their contents changes compared to their filename ___ 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: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server
Maxim Sobolev wrote: There is already a code to detect non-existing AT keyboard and avoid attaching atkbd to it. The code is i386-only at the moment, I am trying to figure out how to modify it so that it works on amd64 as well. Looks like this huge delay is caused by the inb() being astonishingly slow, which is not factored by the timeout routines. Reading keyboard status port once takes about 0.003s! I am not sure if it's common behaviour of the platform, or something specific to this particular model. Do you know by any chance? -Maxim ___ 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: newsyslog patch implementing file includes
On Thu, Apr 22, 2010 at 12:17 AM, Alex Keda ad...@lissyara.su wrote: It's need feature. I test patch - it work for me (CURRENT, amd64) Can I use some as: include /path/to/dir/*.conf ? and can I create recursive include? Yes, wildcards and recursive includes are supported. Gordon ___ 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: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server
On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote: Maxim Sobolev wrote: There is already a code to detect non-existing AT keyboard and avoid attaching atkbd to it. The code is i386-only at the moment, I am trying to figure out how to modify it so that it works on amd64 as well. Looks like this huge delay is caused by the inb() being astonishingly slow, which is not factored by the timeout routines. Reading keyboard status port once takes about 0.003s! I am not sure if it's common behaviour of the platform, or something specific to this particular model. Do you know by any chance? Well, many BIOSes trigger an SMI# when doing inb/outb to the keyboard ports so they can emulate a PS/2 keyboard when a USB keyboard is inserted. Do you have any BIOS options related to the USB legacy compat? I know of the Nehalem systems I've seen they have a separate option for controlling port 60/64 emulation which we leave disabled by default. -- 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: newsyslog patch implementing file includes
On Wednesday 21 April 2010 11:55:44 pm Gordon Tetlow wrote: I wanted the ability for a port to have a rotating log policy so I wrote a patch for newsyslog to implement includes of other newsyslog.conf style files. Please find the patch at: http://people.freebsd.org/~gordon/patches/newsyslog.diffhttp://people.freebsd.org/%7Egordon/patches/newsyslog.diff Format for the include line in /etc/newsyslog.conf is: include /etc/defaults/newsyslog.conf Here's a quick overview of the changes: Convert the conf_entry struct from using a home rolled linked list to the queue(3) macros. Add a STAILQ to process include files. Add support for include tag to specify include files. Globbing is supported in include statements. Properly detect circular include loop dependencies. Please take a look and send me any comments you might have. This is a great feature! One suggestion, I think this text in the new manpage isn't quite right: Name of the system log file to be archived, the literal string default, or include. I think it's ambiguous about include also being a literal string. Two possible suggestions: Name of the system log file to be archived, or one of the literal strings default or include. Name of the system log file to be archived, the literal string default, or the literal string include. -- 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: [CFT]: ClangBSD is selfhosting, we need testers now
On Wed, 21.04.2010 at 23:30:15 +0200, Alexander Best wrote:
Roman Divacky schrieb am 2010-04-21:
On Wed, Apr 21, 2010 at 09:44:45PM +0200, Alexander Best wrote:
Roman Divacky schrieb am 2010-04-21:
[snip]
1) cd modules/sound/sound make CC=gcc
after this step these are the sizes of sound.ko* in
modules/sound/sound:
-rw-r--r-- 1 root wheel 449120 Apr 21 21:36 sound.ko
-rw-r--r-- 1 root wheel 2284757 Apr 21 21:36 sound.ko.debug
-rw-r--r-- 1 root wheel 2055512 Apr 21 21:36 sound.ko.symbols
2) make -V SRCS | tr \n | grep -v \.h | sort | grep
^[a-m].*
| xargs touch
this line is wrong.. it creates empty files which are used instead
of touching the existing ones... it needs to be adjusted so it
touches the files (thus forcing them to be rebuilt with the second
make invocation)
i'm now 100% sure that buffer.c is causing the problem. what i did to verify
this was:
cd sys/modules/sound/sound make CC=clang touch
../../../dev/sound/pcm/buffer.c make CC=gcc make install
this gives me working sound!
Great stuff to have narrowed it down so much. Next logical step would be
to do the bisect on function-level scope.
Copy one half of buffer.c to buffer-clang.c, the other half to buffer-gcc.c,
adjust the Makefile to use buffer-{gcc,clang}.c instead of buffer.c and
compile them accordingly. Redo your tests till we know the single function(s)
where clang produces bad code.
Hang in there, the hard part is almost done!
Uli
___
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
Switchover to CAM ATA?
Hi. With time passed, CAM-based ATA infrastructure IMHO looks enough mature now to enable it in HEAD. Now we have two new stable drivers ahci(4) and siis(4), covering major part of modern SATA HBAs, `options ATA_CAM` wrapper for ata(4) to supports legacy hardware, and one more improved driver for Marvell HBAs (mvs) is now in development and soon will be present for testing. Together with many other people I have tested above at least on i386, amd64, arm and spart64 architectures. This switchover would give us significant performance improvement on new hardware because of NCQ support in ahci/siis/mvs drivers; improved functionality, including SATA Port Multipliers support, better hot-plug support; and reduced code duplication between ata(4) and cam(4) subsystems and applications. Two issues left at this moment are: 1) POLA breakage due to disk device being renamed from adX to adaY; 2) lack of araraid(4) alternative in new infrastructure. It should be reimplemented in GEOM in some way, but it still wasn't. So what is the public opinion: Is the lack of ataraid(4) fatal or we can live without it? Can we do switchover now, or some more reasons preventing this? If ataraid(4) should be reimplemented in GEOM, then how exactly? One more separate RAID infrastructure in GEOM (third?) looks excessive. Reuse gmirror, gstripe,... code would be nice, but will make them more complicated and could be not easy for RAID0+1 (due to common metadata) and RAID5 (due to lack of module in a base system). -- 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: Switchover to CAM ATA?
2010/4/22 Alexander Motin m...@freebsd.org With time passed, CAM-based ATA infrastructure IMHO looks enough mature now to enable it in HEAD. Now we have two new stable drivers ahci(4) and siis(4), covering major part of modern SATA HBAs, `options ATA_CAM` wrapper for ata(4) to supports legacy hardware, and one more improved driver for Marvell HBAs (mvs) is now in development and soon will be present for testing. Together with many other people I have tested above at least on i386, amd64, arm and spart64 architectures. I haven't updated my 8-STABLE box in a couple of weeks. Have the issues with ATAPI DVD-burners been worked out, when using ATA_CAM? Back in Jan/Feb, thereabouts, I tested an ATA_CAM kernel and could not get a device node of any kind to show up for the DVD burner (no acd0, no cd0, nothing in dmesg). A non-ATA_CAM kernel shows both acd0 and cd0. Maybe I'll update my system this weekend and give ATA_CAM another test run. This switchover would give us significant performance improvement on new hardware because of NCQ support in ahci/siis/mvs drivers; improved functionality, including SATA Port Multipliers support, better hot-plug support; and reduced code duplication between ata(4) and cam(4) subsystems and applications. Two issues left at this moment are: 1) POLA breakage due to disk device being renamed from adX to adaY; 2) lack of araraid(4) alternative in new infrastructure. It should be reimplemented in GEOM in some way, but it still wasn't. So what is the public opinion: Is the lack of ataraid(4) fatal or we can live without it? Can we do switchover now, or some more reasons preventing this? If ataraid(4) should be reimplemented in GEOM, then how exactly? One more separate RAID infrastructure in GEOM (third?) looks excessive. Reuse gmirror, gstripe,... code would be nice, but will make them more complicated and could be not easy for RAID0+1 (due to common metadata) and RAID5 (due to lack of module in a base system). If a lowly user's vote counts for anything, I'd vote for the complete removal of ataraid support. We have gstripe, gmirror, graid3, graid5, and zfs (and gvinum for the masochistics). :) We don't need to support any of the crappy pseudo-raid hardware out there. ataraid(4) has served it's purpose, tiding us over until GEOM RAID facilities were in place. Now it's time for it to be retired. -- Freddie Cash fjwc...@gmail.com ___ 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 Status Report January-March, 2010
FreeBSD Quarterly Status Report Introduction This report covers FreeBSD related projects between January and March 2010. Being the first of the four reports planned for 2010 with 46 entries, it shows a good progress of the FreeBSD Project and proves that our committers are keeping up with the latest trends in the OS development. During this period, a new minor version of FreeBSD, 7.3-RELEASE, has been released, while the release process for 8.1-RELEASE is soon to begin and is planned to be released later this summer. Thanks to all the reporters for their excellent work! We hope you enjoy the reading. Please note that the deadline for submissions covering the period between April and June 2010 is July 15th, 2010. __ Google Summer of Code * Google Summer of Code 2010 Projects * Chromium web browser * Clang replacing GCC in the base system * EFI support for FreeBSD/i386 * mfsBSD * Modular Congestion Control * NAND Flash framework for embedded FreeBSD * Out of Tree Toolchain * PC-BSD PC-SysInstall Backend * The tbemd branch * webcamd FreeBSD Team Reports * FreeBSD Bugbusting Team * Release Engineering Team * The FreeBSD Foundation Network Infrastructure * (Virtual) Network Stack resource cleanup * 802.11n support * Atheros AR9285 support * Enhancing the FreeBSD TCP Implementation * Experimental NFS subsystem (NFSv4) * ipfw and dummynet enhancements * net80211 rate control framework * TCP/UDP connection groups Kernel * CAM-based ATA implementation * Dynamic Ticks in FreeBSD * geom_sched * IPv6 without legacy IP kernel * Multichannel playback in HDA sound driver (snd_hda) * Rewrite of FreeBSD read/write path using vnode page * SUJ: Journaled Softupdates * ZFS Documentation * The FreeBSD German Documentation Project * The FreeBSD Hungarian Documentation Project Userland Programs * FreeBSD port for libunwind * LDAP support in base system Architectures * FreeBSD/arm port for TI DaVinci * FreeBSD/ia64 * FreeBSD/mips on D-Link DIR-320 * FreeBSD/powerpc * FreeBSD/powerpc64 port * FreeBSD/sparc64 Ports * Portmaster * Ports Collection * QAT Miscellaneous * BSDCan 2010 -- The BSD Conference * meetBSD 2010 -- The BSD Conference __ (Virtual) Network Stack resource cleanup Contact: Bjoern A. Zeeb b...@freebsd.org In February work was done to address resource leaks in the (virtual) network stack, especially on teardown. During that time also multiple general run-time problems and leaks were identified and fixed including leaked ipfw tables on module unload, routing entries leaked, in case of interfaces going away, as well as leaked link-layer entries in interaction with flowtable and timers. For virtual network stacks resources are are no longer allocated multiple times or freed upon teardown for eventhandlers, IP and upper level layers, like TCP syncache and host cache, flowtable, and especially radix/routing table memory. In addition epair(4) was enhanced and debugging was improved. This work was sponsored by ISPsystem. Open tasks: 1. Merge the remaining patches. 2. Work on a better teardown model and get to the point where we can free UMA zones without keeping pages for type stability and timers around. __ 802.11n support Contact: Rui Paulo rpa...@freebsd.org 802.11n support in the Atheros driver is being worked on. Right now it can do AMPDU RX in software and we are working on TX AMPDU. The code lives in a private Perforce branch, but some bits of it are already committed to HEAD. This work is being sponsored by iXsystems, inc. __ Atheros AR9285 support Contact: Rui Paulo rpa...@freebsd.org Atheros AR9285 support was added to FreeBSD HEAD and 8-STABLE. There are still some issues but in general it works fine. __ BSDCan 2010 -- The BSD Conference URL: http://www.BSDCan.org/2010/ URL: http://www.BSDCan.org/2010/schedule/ Contact: BSDCan Information i...@bsdcan.org BSDCan, a BSD conference held in Ottawa, Canada, has quickly established itself as the technical conference for people working on and with 4.4BSD based operating systems and related projects. The organizers have found a fantastic formula that appeals to a wide range of people from extreme novices to advanced developers. BSDCan 2010 will be held on 13-14 May 2010 at the University of Ottawa, and will be
Re: Switchover to CAM ATA?
Freddie Cash ha scritto: So what is the public opinion: Is the lack of ataraid(4) fatal or we can live without it? Lack of ataraid means no more arX devices, right? I'd say it's not fatal for HEAD, but it is for a -STABLE branch. ataraid(4) has served it's purpose, tiding us over until GEOM RAID facilities were in place. Now it's time for it to be retired. It doesn't seem to me that sysinstall supports gmirror or gstripe, so even if they could be better, currently I think many users still use ataraid for simple installations with mirrored disks. -- Alex Dupre ___ 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: Switchover to CAM ATA?
On Thu, Apr 22, 2010 at 11:25 AM, Julian Elischer jul...@elischer.orgwrote: just one little fly in that ointment... booting. You need to be able to act with the raid in the same way the bios does or you can't boot. I don't think geom would easlily do that but I could be wrong. Certainly if you treat teh ata raid as just a bunch of striped disks, then the bios will not be able to boot off it. of course don't take my word too seriosly asn I'm not running an ata raid system at the moment. gmirror booting works great only thing to change is fstab to reflect block dev changes, gstripe doesn't. I honestly wasn't aware ataraid could boot a striped volume, if so it does something geom can't. -- Adam Vande More ___ 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: Switchover to CAM ATA?
Short opinion from me: Yes, for HEAD. Not MFC'able. It's too major a change for that. ___ 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: Re: Switchover to CAM ATA?
22.04.10, 11:17, Adam Vande More: I think sade(and by further discussion sysinstall) is now getting some attention and now supports geom devices, zfs, etc at least in one person's testbed. I know that's it's been tried before but there are actually screenshots from it. http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016418.html Yes, I have plans to add support of simple GEOM-based RAID management in sade. -- WBR, Andrey V. Elsukov ___ 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: newsyslog patch implementing file includes
On Thu, Apr 22, 2010 at 6:26 AM, John Baldwin j...@freebsd.org wrote: This is a great feature! One suggestion, I think this text in the new manpage isn't quite right: Name of the system log file to be archived, the literal string default, or include. I think it's ambiguous about include also being a literal string. Two possible suggestions: Name of the system log file to be archived, or one of the literal strings default or include. Name of the system log file to be archived, the literal string default, or the literal string include. I took your first suggestion and updated the patch. Thanks, Gordon ___ 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: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server
John Baldwin wrote: On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote: Maxim Sobolev wrote: There is already a code to detect non-existing AT keyboard and avoid attaching atkbd to it. The code is i386-only at the moment, I am trying to figure out how to modify it so that it works on amd64 as well. Looks like this huge delay is caused by the inb() being astonishingly slow, which is not factored by the timeout routines. Reading keyboard status port once takes about 0.003s! I am not sure if it's common behaviour of the platform, or something specific to this particular model. Do you know by any chance? Well, many BIOSes trigger an SMI# when doing inb/outb to the keyboard ports so they can emulate a PS/2 keyboard when a USB keyboard is inserted. Do you have any BIOS options related to the USB legacy compat? I know of the Nehalem systems I've seen they have a separate option for controlling port 60/64 emulation which we leave disabled by default. That makes sense. Unfortunately I don't have access to the BIOS settings. This is a hosted system, and the provider keeps BIOS password for themselves. I have a patch that fixes that issue by measuring status register reading time first and then factoring it in the calculations of the number of retries: http://sobomax.sippysoft.com/atkbdc.diff It also applies the same logic to detect broken/non-existing keyboard controller to amd64 as we do to the i386. I'd appreciate if you can do a review. -Maxim ___ 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: Switchover to CAM ATA?
Hello, Alexander. You wrote 22 апреля 2010 г., 19:31:37: and RAID5 (due to lack of module in a base system). I'm cleaning up gradi5 now according to style(9) and want to make port out of it in month or two (unfortunalety, I have alot of paid work, which is not FreeBSD-related in any way). It works very well for me on, and I have one HDD crash already, recovered with graid5 :) -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ 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: Switchover to CAM ATA?
Alexander Motin wrote: So what is the public opinion: Is the lack of ataraid(4) fatal or we can live without it? I believe it's fatal in long run. This would present significant challenge for users who rely on this functionality from upgrading from 8.x to 9.0 later on. Especially for ones using striped disks and RAID5. Therefore while it's no problem to have it in HEAD for now, but it will have to be addressed before the release. -Maxim ___ 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: [CFT]: ClangBSD is selfhosting, we need testers now
Andrew Reilly schrieb am 2010-04-22: On Wed, Apr 21, 2010 at 05:23:38PM +0200, Roman Divacky wrote: On Wed, Apr 21, 2010 at 05:20:57PM +0200, Alexander Best wrote: i might have stumbled upon a problem with clang. i've compiled a kernel from the clang branch using `make kernel INSTKERNNAME=clang` and booted from it. i'm now experiencing audio problems with mp3s and certain video files. playback is awfully slow and the audio output gets distorted massively. `top` however reports no high cpu load and `vmstat -i` doesn't report anything unusual either. this problem doesn't occur with a regular gcc-kernel. both kernels are running under a regular (gcc) world. i thought it might be a problem with acpi, but disabling acpi (hint.acpi.0.disabled=1) gives me a system freeze. I've heard about this problem but did not manage to reproduce that. can you try to bisect what file is being miscompiled? ie. compile half of the kernel with gcc and half with clang and bisect this way to a single file. The FreeBSD sound subsystem has a sample-rate converter built into the feeder that (from a cursory look) is probably quite carefully tweaked to be able to perform well (or at all). I've added -multimedia to the CC line, because they're the guys who are going to know the details. It's possible that some GCC-specific manifest constants are being tested-for, with sub-optimal fall-back code being run, instead. In the mean-time, Alexander, are there any sound-related sysctls that you can tweak so that the audio playback that you're doing does *not* involve sample rate conversion? i'm not sure because i'm not an expert on audio stuff. these sysctl vars might contain the functionality you mentioned: hw.snd.feeder_rate_presets: 100:8:0.85 100:36:0.92 100:164:0.97 hw.snd.feeder_rate_polyphase_max: 183040 hw.snd.feeder_rate_min: 1 hw.snd.feeder_rate_max: 2016000 hw.snd.feeder_rate_round: 25 hw.snd.feeder_rate_quality: 1 hw.snd.feeder_eq_presets: PEQ:16000,0.2500,62,0.2500:-9,9,1.0:44100,48000,88200,96000,176400,192000 hw.snd.feeder_eq_exact_rate: 0 Cheers, -- Alexander Best ___ 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: [CFT]: ClangBSD is selfhosting, we need testers now
Ulrich Spörlein schrieb am 2010-04-22:
On Wed, 21.04.2010 at 23:30:15 +0200, Alexander Best wrote:
Roman Divacky schrieb am 2010-04-21:
On Wed, Apr 21, 2010 at 09:44:45PM +0200, Alexander Best wrote:
Roman Divacky schrieb am 2010-04-21:
[snip]
1) cd modules/sound/sound make CC=gcc
after this step these are the sizes of sound.ko* in
modules/sound/sound:
-rw-r--r-- 1 root wheel 449120 Apr 21 21:36 sound.ko
-rw-r--r-- 1 root wheel 2284757 Apr 21 21:36 sound.ko.debug
-rw-r--r-- 1 root wheel 2055512 Apr 21 21:36
sound.ko.symbols
2) make -V SRCS | tr \n | grep -v \.h | sort | grep
^[a-m].*
| xargs touch
this line is wrong.. it creates empty files which are used
instead
of touching the existing ones... it needs to be adjusted so it
touches the files (thus forcing them to be rebuilt with the
second
make invocation)
i'm now 100% sure that buffer.c is causing the problem. what i did
to verify
this was:
cd sys/modules/sound/sound make CC=clang touch
../../../dev/sound/pcm/buffer.c make CC=gcc make install
this gives me working sound!
Great stuff to have narrowed it down so much. Next logical step would
be
to do the bisect on function-level scope.
Copy one half of buffer.c to buffer-clang.c, the other half to
buffer-gcc.c,
adjust the Makefile to use buffer-{gcc,clang}.c instead of buffer.c
and
compile them accordingly. Redo your tests till we know the single
function(s)
where clang produces bad code.
thanks for the hint. i'll try and see if i can pinpoint the exact function in
buffer.c causing the problem.
Hang in there, the hard part is almost done!
Uli
--
Alexander Best
___
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: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server
On Thursday 22 April 2010 2:28:26 pm Maxim Sobolev wrote: John Baldwin wrote: On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote: Maxim Sobolev wrote: There is already a code to detect non-existing AT keyboard and avoid attaching atkbd to it. The code is i386-only at the moment, I am trying to figure out how to modify it so that it works on amd64 as well. Looks like this huge delay is caused by the inb() being astonishingly slow, which is not factored by the timeout routines. Reading keyboard status port once takes about 0.003s! I am not sure if it's common behaviour of the platform, or something specific to this particular model. Do you know by any chance? Well, many BIOSes trigger an SMI# when doing inb/outb to the keyboard ports so they can emulate a PS/2 keyboard when a USB keyboard is inserted. Do you have any BIOS options related to the USB legacy compat? I know of the Nehalem systems I've seen they have a separate option for controlling port 60/64 emulation which we leave disabled by default. That makes sense. Unfortunately I don't have access to the BIOS settings. This is a hosted system, and the provider keeps BIOS password for themselves. I have a patch that fixes that issue by measuring status register reading time first and then factoring it in the calculations of the number of retries: http://sobomax.sippysoft.com/atkbdc.diff It also applies the same logic to detect broken/non-existing keyboard controller to amd64 as we do to the i386. I'd appreciate if you can do a review. Hmm, not all i386 CPUs that we support have a TSC. Is the change to atkbdc_isa.c sufficient to fix the hang? If so, I'd rather just commit that bit and leave out the read_delay changes. -- 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: Switchover to CAM ATA?
On 22/04/2010 19:48, Maxim Sobolev wrote: Alexander Motin wrote: So what is the public opinion: Is the lack of ataraid(4) fatal or we can live without it? I believe it's fatal in long run. This would present significant challenge for users who rely on this functionality from upgrading from 8.x to 9.0 later on. Especially for ones using striped disks and RAID5. Therefore while it's no problem to have it in HEAD for now, but it will have to be addressed before the release. Could I also add that the removal of ataraid would affect those users who dual-boot with Windows and rely on the psuedo-raid provided by most Intel chipsets to be able to share the same pair of disks. Regards, Richard ___ 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: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server
John Baldwin wrote: On Thursday 22 April 2010 2:28:26 pm Maxim Sobolev wrote: John Baldwin wrote: On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote: Maxim Sobolev wrote: There is already a code to detect non-existing AT keyboard and avoid attaching atkbd to it. The code is i386-only at the moment, I am trying to figure out how to modify it so that it works on amd64 as well. Looks like this huge delay is caused by the inb() being astonishingly slow, which is not factored by the timeout routines. Reading keyboard status port once takes about 0.003s! I am not sure if it's common behaviour of the platform, or something specific to this particular model. Do you know by any chance? Well, many BIOSes trigger an SMI# when doing inb/outb to the keyboard ports so they can emulate a PS/2 keyboard when a USB keyboard is inserted. Do you have any BIOS options related to the USB legacy compat? I know of the Nehalem systems I've seen they have a separate option for controlling port 60/64 emulation which we leave disabled by default. That makes sense. Unfortunately I don't have access to the BIOS settings. This is a hosted system, and the provider keeps BIOS password for themselves. I have a patch that fixes that issue by measuring status register reading time first and then factoring it in the calculations of the number of retries: http://sobomax.sippysoft.com/atkbdc.diff It also applies the same logic to detect broken/non-existing keyboard controller to amd64 as we do to the i386. I'd appreciate if you can do a review. Hmm, not all i386 CPUs that we support have a TSC. Is the change to atkbdc_isa.c sufficient to fix the hang? If so, I'd rather just commit that bit and leave out the read_delay changes. No, it's not sufficient. The problem here is that for some reason that test passes on that system (probably emulation works) and so that normal keyboard attach routine is invoked early in boot, when we don't even have clock initialized. What if I make TSC-related changes amd64? Will that be OK? -Maxim ___ 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: Switchover to CAM ATA?
Richard Tector wrote: On 22/04/2010 19:48, Maxim Sobolev wrote: Alexander Motin wrote: So what is the public opinion: Is the lack of ataraid(4) fatal or we can live without it? I believe it's fatal in long run. This would present significant challenge for users who rely on this functionality from upgrading from 8.x to 9.0 later on. Especially for ones using striped disks and RAID5. Therefore while it's no problem to have it in HEAD for now, but it will have to be addressed before the release. Could I also add that the removal of ataraid would affect those users who dual-boot with Windows and rely on the psuedo-raid provided by most Intel chipsets to be able to share the same pair of disks. Well, this won't be a problem if we have GEOM classes that can understand metadata created by the ATA RAID BIOS(es). But we don't those classes at the moment. -Maxim ___ 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
MCA messages in /var/log/message?
How does one interpret the following MCA message? MCA: Bank 4, Status 0x945a4000d6080a13 MCA: Global Cap 0x0105, Status 0x MCA: Vendor AuthenticAMD, ID 0xf5a, APIC ID 0 MCA: CPU 0 COR BUSLG Responder RD Memory MCA: Address 0x70c42280 MCA: Bank 4, Status 0x942140012a080813 MCA: Global Cap 0x0105, Status 0x MCA: Vendor AuthenticAMD, ID 0xf5a, APIC ID 1 MCA: CPU 1 COR BUSLG Source RD Memory MCA: Address 0x1b97ca578 It appears that these messages coincide with a 15 to 30 second period where my USB mouse inexplicably loses a large number of button clicks, (which is quite noticable with firefox3). -- 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: MCA messages in /var/log/message?
on 23/04/2010 01:28 Steve Kargl said the following: How does one interpret the following MCA message? MCA: Bank 4, Status 0x945a4000d6080a13 MCA: Global Cap 0x0105, Status 0x MCA: Vendor AuthenticAMD, ID 0xf5a, APIC ID 0 MCA: CPU 0 COR BUSLG Responder RD Memory MCA: Address 0x70c42280 MCA: Bank 4, Status 0x942140012a080813 MCA: Global Cap 0x0105, Status 0x MCA: Vendor AuthenticAMD, ID 0xf5a, APIC ID 1 MCA: CPU 1 COR BUSLG Source RD Memory MCA: Address 0x1b97ca578 It appears that these messages coincide with a 15 to 30 second period where my USB mouse inexplicably loses a large number of button clicks, (which is quite noticable with firefox3). This very much looks like DRAM ECC error. You seem to have family Fh AMD processor, so I am not entirely sure. But for 10h processors BKDG table 80 (NB error signatures) definitely specifies that extended error code of 8 (in bits 20:16) means ECC error. -- 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: [CFT]: ClangBSD is selfhosting, we need testers now
The current llvm-devel package is woefully out of date. Anyone wishing to try this will need to compile the latest port. -Kip On Fri, Apr 16, 2010 at 9:08 AM, Roman Divacky rdiva...@freebsd.org wrote: Hi, ClangBSD is a branch of FreeBSD that aims at integrating clang (clang.llvm.org) into FreeBSD, replacing GCC as a system compiler. Recently, we've achieved the state when clang can compile all of FreeBSD world on i386/amd64 platforms (including all the C++ apps we have and itself) and a bootable kernel. Thus we feel that the time has come to ask the FreeBSD community for wider testing on i386/amd64 (you sure can help with other platforms too :)). How to setup ClangBSD: The default configuration of ClangBSD requires clang installed so you can either install fresh llvm-devel port (portinstall devel/llvm-devel) or change CC to gcc and CXX to g++ in share/mk/sys.mk. I recommend the former. svn co http://svn.freebsd.org/base/projects/clangbsd/ clangbsd cd clangbsd make buildworld echo NO_WERROR= /etc/make.conf echo WERROR= /etc/make.conf make DESTDIR=/clangbsd-chroot/ installworld now you have ClangBSD world installed and you can chroot into it. I don't recommend installing ClangBSD into real root as it is not tested enough. You can also start using clang compiled kernel - either build the kernel in the ClangBSD chroot (set NO_WERROR=yo and WERROR=yo in /etc/src.conf) or set CC to clang and build kernel the normal way. This information (and more) is also provided on: http://wiki.freebsd.org/BuildingFreeBSDWithClang We kindly ask you to setup ClangBSD chroot and/or use clang compiled kernel and use it as you would normally use FreeBSD. Please report back Thank you, Roman Divacky on behalf of the ClangBSD team ___ 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: MCA messages in /var/log/message?
On Fri, Apr 23, 2010 at 02:24:03AM +0300, Andriy Gapon wrote: on 23/04/2010 01:28 Steve Kargl said the following: How does one interpret the following MCA message? MCA: Bank 4, Status 0x945a4000d6080a13 MCA: Global Cap 0x0105, Status 0x MCA: Vendor AuthenticAMD, ID 0xf5a, APIC ID 0 MCA: CPU 0 COR BUSLG Responder RD Memory MCA: Address 0x70c42280 MCA: Bank 4, Status 0x942140012a080813 MCA: Global Cap 0x0105, Status 0x MCA: Vendor AuthenticAMD, ID 0xf5a, APIC ID 1 MCA: CPU 1 COR BUSLG Source RD Memory MCA: Address 0x1b97ca578 It appears that these messages coincide with a 15 to 30 second period where my USB mouse inexplicably loses a large number of button clicks, (which is quite noticable with firefox3). This very much looks like DRAM ECC error. You seem to have family Fh AMD processor, so I am not entirely sure. But for 10h processors BKDG table 80 (NB error signatures) definitely specifies that extended error code of 8 (in bits 20:16) means ECC error. Thanks for the information. The system that generates these messages is getting long in the tooth. Guess it's time to reboot and run memtest86+ on the system. -- 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: [CFT]: ClangBSD is selfhosting, we need testers now
On Thu, Apr 22, 2010 at 04:32:45PM -0700, K. Macy wrote: The current llvm-devel package is woefully out of date. Anyone wishing to try this will need to compile the latest port. For the foreseeable future, doing anything but using the latest port is a recipe for problems. -- Brooks -Kip On Fri, Apr 16, 2010 at 9:08 AM, Roman Divacky rdiva...@freebsd.org wrote: Hi, ClangBSD is a branch of FreeBSD that aims at integrating clang (clang.llvm.org) into FreeBSD, replacing GCC as a system compiler. Recently, we've achieved the state when clang can compile all of FreeBSD world on i386/amd64 platforms (including all the C++ apps we have and itself) and a bootable kernel. Thus we feel that the time has come to ask the FreeBSD community for wider testing on i386/amd64 (you sure can help with other platforms too :)). How to setup ClangBSD: The default configuration of ClangBSD requires clang installed so you can either install fresh llvm-devel port (portinstall devel/llvm-devel) or change CC to gcc and CXX to g++ in share/mk/sys.mk. I recommend the former. ? ? ? ?svn co http://svn.freebsd.org/base/projects/clangbsd/ clangbsd ? ? ? ?cd clangbsd make buildworld ? ? ? ?echo NO_WERROR= /etc/make.conf ? ? ? ?echo WERROR= ? ? /etc/make.conf ? ? ? ?make DESTDIR=/clangbsd-chroot/ installworld now you have ClangBSD world installed and you can chroot into it. I don't recommend installing ClangBSD into real root as it is not tested enough. You can also start using clang compiled kernel - either build the kernel in the ClangBSD chroot (set NO_WERROR=yo and WERROR=yo in /etc/src.conf) or set CC to clang and build kernel the normal way. This information (and more) is also provided on: ? ? ? ?http://wiki.freebsd.org/BuildingFreeBSDWithClang We kindly ask you to setup ClangBSD chroot and/or use clang compiled kernel and use it as you would normally use FreeBSD. Please report back Thank you, ? Roman Divacky on behalf of the ClangBSD team ___ 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 pgpwhrrk7fQph.pgp Description: PGP signature
Re: Switchover to CAM ATA?
Dear Alexander, dear collegaues, On Thu, Apr 22, 2010 at 06:31:37PM +0300, Alexander Motin wrote: Can we do switchover now, or some more reasons preventing this? I have been using ATA_CAM with legacy support for ata(4) for some time, and have found it to be stable and very useable. I have even removed atapicam from the kernel, since it is no longer needed, I have the /dev/cd0 device also without. So, in my opinion it is ready for prime-time also on legacy hw. There is one interesting tidbit though: previously it used to be possible to run cdda2wav also as non-root, provided the user running it had read access to the /dev/cd0 device. This seems to no longer work. Has anybody else noticed this? -- Regards: Szilveszter ADAM Budapest Hungary ___ 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: Switchover to CAM ATA?
On Thu, 22 Apr 2010 22:28:03 +0400 Lev Serebryakov l...@freebsd.org wrote: Hello, Alexander. You wrote 22 апреля 2010 г., 19:31:37: and RAID5 (due to lack of module in a base system). I'm cleaning up gradi5 now according to style(9) and want to make port out of it in month or two (unfortunalety, I have alot of paid work, which is not FreeBSD-related in any way). It works very well for me on, and I have one HDD crash already, recovered with graid5 :) this means graid5 in the tree ? if so, great :) never seen how to make simple raid5 in not-so-great memory systems tht can't afford to have zfs. I have a Pentium II with 192MB ram that is a great small file server and runs both gmirror and gstripe fine. thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ 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
