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
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,
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
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
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
: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
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
: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
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
:-
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
: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
: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
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:
-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
+
14 matches
Mail list logo
