10TB test completed w/ AHCI
The AHCI driver passed its 10TB test (with 5x2TB drives behind a PM). So both the SILI 3132 driver and the AHCI driver have now passed their storage tests. There are still two outstanding bug reports, one related to a particular DVD writer which doesn't work w/cdrecord and one related to AHCI not working on a fancy Intel server motherboard. Basically, though, the driver works and in places where it does work it works quite well. -Matt
Re: Call for testers: new pci code
On Mon, Jul 6, 2009 at 3:42 AM, Matthew Dillondil...@apollo.backplane.com wrote: :Hi all, : :After some additional work, I integrated Polakov's new pci code ported :from FreeBSD 7.2: :http://gitweb.dragonflybsd.org/~sephe/dragonfly.git/shortlog/refs/heads/pci : :I have tested SMP+IOAPIC, SMP+ICU, UP (there is not improvement in :IOAPIC in this branch; my boxes just work with the current IOAPIC :) :CARDBUS and PCCARD is tested on an old Dell laptop. : :I am currently running it on all of my boxes :) : :Though it should be safe to be tested, but I still suggest you to keep :one copy of your working kernel and module! :I also suggest to test it with HPET enabled. : :If there are any problems, please post the boot verbose dmesg first :) : :Best Regards, :sephe Here is the output for a SMP build on my new Phenom-based shuttle test box, without APIC_IO and with APIC_IO. With SMP, without APIC_IO (works normally): Good to know :) fetch http://apollo.backplane.com/DFlyMisc/dmesg01.boot With SMP, With APIC_IO (did not work before, does not work now): heh fetch http://apollo.backplane.com/DFlyMisc/dmesg02.boot With APIC_IO the AHCI device seems to route its interrupt ok. However, just about everything else is still broken. i.e. NFE, EHCI, etc... all route to irq 2 and are broken. I guess that is to be expected at this stage?. It never worked with APIC_IO before and still doesn't :-) Yep, there is no improvement in respect to APIC_IO in this patch. There is an ACPI entry for the HPET but I don't see any recognition of it as a clock source. Ah, you need to set tunable: debug.acpi.enabled=hpet In anycase, the machine boots without APIC_IO like it always has but I'm not sure if there is some sort of loader.conf option I need to set to test the new code or not. Nope, there are no additional tunables (at least the irq overridden tunable has no effect if APIC_IO is defined) Best Regards, sephe -- Live Free or Die
Re: Call for testers: new pci code
On Mon, Jul 6, 2009 at 3:48 AM, Hasso Tepperha...@estpak.ee wrote: Seems to work fine here on my laptop. And it also seems to fix one of most annoying issues I had on it - interrupt storms with pcmcia devices. Good! Thank you for testing! Best Regards, sephe -- Live Free or Die
Re: Call for testers: new pci code
On Sun, Jul 5, 2009 at 9:29 PM, Sepherosa Ziehausepher...@gmail.com wrote: Hi all, After some additional work, I integrated Polakov's new pci code ported from FreeBSD 7.2: http://gitweb.dragonflybsd.org/~sephe/dragonfly.git/shortlog/refs/heads/pci I have applied patches swildner and hasso sent me, and amd64 builds now. If no objection comes, I plan to push it within next one or two days. Best Regards, sephe -- Live Free or Die
required/suggested devfs userland tool functionality
Hi, as I soon want to start with the userland tool for devfs, I would like to hear some thoughts on what userland functionality is needed for devfs. While my original intentions were to also replace the current devd, I don't see the need for it, neither do I think it's appropriate as it for example can execute commands for devices that nobody ( as in: no driver ) attached to, which is something devfs won't be able to do. So what is left for devfs userland tool to do is to apply certain permissions/rules to devices that are created. I currently see two solutions to this: 1) notify the userland tool of every single device attach/detach and give it some time to answer with a set of permissions for the newly created device. This approach requires running the devfs userland tool as a daemon, with one instance per devfs mount point. This has the advantage that rules could be kept in userspace. 2) let the userland tool load a whole set of rules (for each devfs mount point) into the kernel. In turn the kernel applies the set of rules every time a device is attached. This has several advantages: - userland wouldn't have to be asked for every device attach - rules would continue to be applied even if the userland tool isn't running - for that same reason, userland tool wouldn't have to be a daemon. While I prefer the second approach, I would like to hear your thoughts about this before making a final decision on which one to use. I'd also welcome suggestions of other things you think the userland devfs tool should be able to do. Cheers, Alex Hornung
Re: required/suggested devfs userland tool functionality
:2) let the userland tool load a whole set of rules (for each devfs :mount point) into the kernel. In turn the kernel applies the set of :rules every time a device is attached. This has several advantages: :- userland wouldn't have to be asked for every device attach :- rules would continue to be applied even if the userland tool isn't running :- for that same reason, userland tool wouldn't have to be a daemon. : :While I prefer the second approach, I would like to hear your thoughts :about this before making a final decision on which one to use. I'd :also welcome suggestions of other things you think the userland devfs :tool should be able to do. : :Cheers, :Alex Hornung I like the second approach. Particularly since you already have a a VOP interface so loading the rules into devd could be as simple as doing a write() to a special node in devd. -Matt Matthew Dillon dil...@backplane.com
Re: Call for testers: new pci code
Looks good to me! Really excellent work, Alexander! Sephe, I think we are good to go for committing it on your schedule. -Matt Matthew Dillon dil...@backplane.com
Re: Call for testers: new pci code
:There is an ACPI entry for the HPET but I don't see any recognition of :it as a clock source. : :Ah, you need to set tunable: :debug.acpi.enabled=hpet : :Best Regards, :sephe Here's the boot with the HPET recognized (a bit cutoff, my dmesg buffer isn't big enough): fetch http://apollo.backplane.com/DFlyMisc/dmesg03.boot And kern.cputimer: test29:/root# sysctl kern.cputimer kern.cputimer.intr.select: lapic kern.cputimer.intr.freq: 10502 kern.cputimer.intr.reglist: lapic i8254 kern.cputimer.freq: 2500 kern.cputimer.clock: 2883370353 kern.cputimer.name: HPET kern.cputimer.select: HPET ACPI-safe24 i8254_timer2 dummy -Matt Matthew Dillon dil...@backplane.com
Re: required/suggested devfs userland tool functionality
Matthew Dillon wrote: :2) let the userland tool load a whole set of rules (for each devfs :mount point) into the kernel. In turn the kernel applies the set of :rules every time a device is attached. This has several advantages: :- userland wouldn't have to be asked for every device attach :- rules would continue to be applied even if the userland tool isn't running :- for that same reason, userland tool wouldn't have to be a daemon. : :While I prefer the second approach, I would like to hear your thoughts :about this before making a final decision on which one to use. I'd :also welcome suggestions of other things you think the userland devfs :tool should be able to do. : :Cheers, :Alex Hornung I like the second approach. Particularly since you already have a a VOP interface so loading the rules into devd could be as simple as doing a write() to a special node in devd. But do you really want to perform regexp/glob matching in the kernel? Or do you want to restrict the users to prefix matching? I think we basically need to deal with multiple things here: 1. no race conditions when creating device nodes 2. give the user enough flexibility 3. allow the user to use chmod/chown? I don't have an opinion yet what is better, but maybe we should assess which kind of rules a user is expected to write (which rules do we want to ship per default?), and then we can decide whether it is worthwhile to put the rules management in the kernel, or whether it better goes into userland. cheers simon -- 3 the future +++ RENT this banner advert +++ ASCII Ribbon /\ rock the past +++ space for low CHF NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
Re: required/suggested devfs userland tool functionality
As a matter of fact I only intended to do partial string matching, at best a few special formatters or so to specify a beginning or end of a string. Do we need anything besides that? In my opinion you normally would want to match them by prefix or device group (ad*, da*, ...) or so, no need for fancy regexps... And also I'd prefer not having to rely on a daemon to do all the ruling, it's probably safer and easier to just load rules. As for chmod/chown, you can already use that; that hasn't much to do with the userland tool. Cheers, Alex 2009/7/6 Simon 'corecode' Schubert corec...@fs.ei.tum.de: Matthew Dillon wrote: :2) let the userland tool load a whole set of rules (for each devfs :mount point) into the kernel. In turn the kernel applies the set of :rules every time a device is attached. This has several advantages: :- userland wouldn't have to be asked for every device attach :- rules would continue to be applied even if the userland tool isn't running :- for that same reason, userland tool wouldn't have to be a daemon. : :While I prefer the second approach, I would like to hear your thoughts :about this before making a final decision on which one to use. I'd :also welcome suggestions of other things you think the userland devfs :tool should be able to do. : :Cheers, :Alex Hornung I like the second approach. Particularly since you already have a a VOP interface so loading the rules into devd could be as simple as doing a write() to a special node in devd. But do you really want to perform regexp/glob matching in the kernel? Or do you want to restrict the users to prefix matching? I think we basically need to deal with multiple things here: 1. no race conditions when creating device nodes 2. give the user enough flexibility 3. allow the user to use chmod/chown? I don't have an opinion yet what is better, but maybe we should assess which kind of rules a user is expected to write (which rules do we want to ship per default?), and then we can decide whether it is worthwhile to put the rules management in the kernel, or whether it better goes into userland. cheers simon -- 3 the future +++ RENT this banner advert +++ ASCII Ribbon /\ rock the past +++ space for low CHF NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
Re: required/suggested devfs userland tool functionality
:But do you really want to perform regexp/glob matching in the kernel? Or :do you want to restrict the users to prefix matching? Yes, it is not a problem. It is not a critical path. But not Regex. Just simple ?/* wildcarding. Regex is overrated and unnecessarily complex for what we want to accomplish. :I think we basically need to deal with multiple things here: : :1. no race conditions when creating device nodes I think Alex's locks will deal with that case. :2. give the user enough flexibility :3. allow the user to use chmod/chown? Yes, absolutely. Those are important functions and there is no reason not to allow them. The initial permissions and ownership can be set based on the rule set, and changed thereafter by userland. :I don't have an opinion yet what is better, but maybe we should assess :which kind of rules a user is expected to write (which rules do we want to :ship per default?), and then we can decide whether it is worthwhile to put :the rules management in the kernel, or whether it better goes into userland. : :cheers : simon I'd expect something simple like: da* 640 rootoperator And even a short-cut by classification so we don't have to list every disk driver under the sun: D_DISK 640 rootoperator -Matt
Re: required/suggested devfs userland tool functionality
:As a matter of fact I only intended to do partial string matching, at :best a few special formatters or so to specify a beginning or end of a :string. : :Do we need anything besides that? In my opinion you normally would :want to match them by prefix or device group (ad*, da*, ...) or so, no :need for fancy regexps... And also I'd prefer not having to rely on a :daemon to do all the ruling, it's probably safer and easier to just :load rules. * and ? wildcarding. Here, you can adapt this code (change the copyright to the DragonFly general copyright and maybe fixup the capitalization in the procedure names to match kernel usage): fetch http://apollo.backplane.com/DFlyMisc/wildcmp.c While you could do simple prefix matching, my preference is to actually have */? wildcard support in there because it's a clearer format. -Matt
pkgsrc-HEAD DragonFly 2.3.1/i386 2009-07-04 02:33
pkgsrc bulk build report DragonFly 2.3.1/i386 Compiler: gcc Build start: 2009-07-04 02:33 Build end: 2009-07-06 18:55 Full report: http://leaf.dragonflybsd.org/~hasso/pbulk-logs/20090704.0233/meta/report.html Machine readable version: http://leaf.dragonflybsd.org/~hasso/pbulk-logs/20090704.0233/meta/report.bz2 Total number of packages: 8855 Successfully built: 8064 Failed to build: 358 Depending on failed package: 107 Explicitly broken or masked: 264 Depending on masked package:62 Packages breaking the most other packages Package Breaks Maintainer - sysutils/libgtop 17 pkgsrc-us...@netbsd.org lang/sun-jre15 8 pkgsrc-us...@netbsd.org lang/sun-jre14 8 pkgsrc-us...@netbsd.org devel/flim 6 tech-pkg...@jp.netbsd.org graphics/GeometryKit 5 pkgsrc-us...@netbsd.org security/openvas-libraries 4 adri...@netbsd.org security/nessus-libraries 4 pkgsrc-us...@netbsd.org graphics/libv4l4 tech-multime...@netbsd.org time/py-mxDateTime 3 pkgsrc-us...@netbsd.org sysutils/liboobs 3 pkgsrc-us...@netbsd.org Build failures Package Breaks Maintainer - archivers/jamjar sk...@netbsd.org archivers/sapcar pkgsrc-us...@netbsd.org audio/bmp-macpkgsrc-us...@netbsd.org audio/csound5pkgsrc-us...@netbsd.org audio/gogo pkgsrc-us...@netbsd.org audio/gtkpod s...@netbsd.org audio/libao-nas pkgsrc-us...@netbsd.org audio/libvisual0.2-plugins pkgsrc-us...@netbsd.org audio/sndpkgsrc-us...@netbsd.org benchmarks/iozonepkgsrc-us...@netbsd.org benchmarks/lmbench pkgsrc-us...@netbsd.org benchmarks/randread gr...@netbsd.org biology/py-mol pkgsrc-us...@netbsd.org py26-mol-0.98nb4 pkgsrc-us...@netbsd.org biology/rasmol pkgsrc-us...@netbsd.org cad/boolean pkgsrc-us...@netbsd.org cad/eagler...@netbsd.org chat/irchat-pj 1 tech-pkg...@jp.netbsd.org chat/silc-client-icb s...@netbsd.org chat/tircpkgsrc-us...@netbsd.org chat/zircon pkgsrc-us...@netbsd.org comms/asterisk16 jnem...@netbsd.org comms/modemd tsa...@netbsd.org comms/plptools pkgsrc-us...@netbsd.org comms/xtel bou...@netbsd.org cross/avr-gcc 2 pkgsrc-us...@netbsd.org cross/avrdudepkgsrc-us...@netbsd.org cross/h8300-hms-gcc pkgsrc-us...@netbsd.org cross/i386-cygwin32 pkgsrc-us...@netbsd.org cross/i386-linux pkgsrc-us...@netbsd.org cross/i386-mingw32 pkgsrc-us...@netbsd.org cross/i386-msdosdjgpppkgsrc-us...@netbsd.org cross/mipsEEel-netbsdpkgsrc-us...@netbsd.org databases/openldap-smbk5pwd g...@netbsd.org databases/php-mssql1 jdole...@netbsd.org php4-mssql-4.4.9 1 jdole...@netbsd.org devel/anjuta 1 pkgsrc-us...@netbsd.org devel/cfitsiopkgsrc-us...@netbsd.org devel/electricfence pkgsrc-us...@netbsd.org devel/elfsh pkgsrc-us...@netbsd.org devel/emacs-ilisp 1 pkgsrc-us...@netbsd.org devel/flim 6 tech-pkg...@jp.netbsd.org devel/gdbpkgsrc-us...@netbsd.org devel/gdb6 shanno...@netbsd.org devel/gdbada j...@johnrshannon.com devel/gobo-eiffelpkgsrc-us...@netbsd.org devel/gtlpkgsrc-us...@netbsd.org devel/java-subversiong...@netbsd.org devel/libFoundation2 pkgsrc-us...@netbsd.org devel/libscsi 2 pkgsrc-us...@netbsd.org devel/libstatgrab 1
Re: pkgsrc-HEAD DragonFly 2.3.1/i386 2009-07-04 02:33
-Build start: 2009-06-21 03:42 +Build start: 2009-07-04 02:33 -Total number of packages: 8853 - Successfully built: 8034 - Failed to build: 371 - Depending on failed package: 122 +Total number of packages: 8855 + Successfully built: 8064 + Failed to build: 358 + Depending on failed package: 107 -audio/wsoundprefspkgsrc-us...@netbsd.org -chat/gg2 a...@netbsd.org -chat/pidgin-silc pkgsrc-us...@netbsd.org -chat/telepathy-gabble 3 pkgsrc-us...@netbsd.org -editors/obby 1 pkgsrc-us...@netbsd.org -games/civctp-demoa...@netbsd.org -geography/viking g...@netbsd.org -graphics/evas-sdlya...@yazzy.org -graphics/evas-sdl-16 ya...@yazzy.org +graphics/xfigpkgsrc-us...@netbsd.org +mail/courier-mta 1 j...@pkgsrc.org -net/lftp s...@netbsd.org -net/powerdns-recursorr...@netbsd.org -net/py-twisted pkgsrc-us...@netbsd.org -py26-twisted-8.1.0 pkgsrc-us...@netbsd.org -security/courier-authlib 6 j...@pkgsrc.org -security/libprelude9 shanno...@netbsd.org +security/prelude-manager shanno...@netbsd.org +security/prelude-pfloggershanno...@netbsd.org -sysutils/fsviewerjoh...@mail.kemper.org -wm/wmdrawer1 j...@carnat.net -www/kazehakase tonne...@netbsd.org -www/squid27 t...@netbsd.org -www/squid30 t...@netbsd.org -www/squid311 t...@netbsd.org +x11/py-qt4 2 pkgsrc-us...@netbsd.org
