Re: Framebuffer device under FreeBSD?
i. Is it feasible to port Linux fbdev modules to FreeBSD (as a modules, again)? I was under the impression that the subsystem is there ( /usr/src/sys/dev/fb ? ). Maybe not the specific accelerated drivers, but the basics look there. I will say the video mode selection looks weak though, Linux does have a much more flexible mode selection. P.S. - I have been trying to get NVidia docs ( I have to sign an NDA ) to build a GeForce3 framebuffer. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: IPFW module
Yes, there is an open pr regarding this. In -current all this is fixed, but I know ipfw and, iirc, nfs modules have these problems in 4.4. Andrew On Fri, 9 Nov 2001, Dimitar Peikov wrote: : :This morning I've cvsuped to STABLE and put 'options IPFIREWALL' into my :kernel configuration file. After installing all I try to 'kldload ipfw' which :complains that ipfw module is already in kernel, but kldstat reports that :module is being loaded! Then I've decided to kldunload it Kernel panic : reboot! : :It is regular to kernel crash if ipfw is loaded as module, but why when it was :build into kernel? In that case it would be good kldload/kldunload to exit! :Why kldload loads module in case that it is compiled in kernel? : :-- :Dimitar Peikov :Programmer Analyst :Globalization Group :We Build e-Business : :RILA Solutions :27 Building, Acad.G.Bonchev Str. :1113 Sofia, Bulgaria : :phone: (+359 2) 9797320 :phone: (+359 2) 9797300 :fax: (+359 2) 9733355 :http://www.rila.com : : : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with unsubscribe freebsd-net in the body of the message : -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: processor recommendations for multi-user freeBSD system ?
--- Joesh Juphland [EMAIL PROTECTED] wrote: I am planning on building a true multi-user system (as opposed to a NFS server, or a web server, or a mail server) - many people with many shells will be doing many things. Two things have been decided: - it will run freeBSD - it will be dual processor - So what two processors should I use ? Coming from a Sun hardware background, I originally thought to use PIII Xeons .. since they have a lot of cache, and fast cache. I was thinking 512meg cache p3 xeons running at 550mhz. But what about a modern athlon MP processor ? Much less cache, but it runs at 266mhz, and it is much faster ... 1700mhz or so. One specific question might be, at what bus speed and mhz speed do the advantages of a good processor like a xeon start to not matter ? hi joesh, i think the two Xeon Processors will do the job. As long as you have that good cache with ya... thanks, regards, Hiten Pandya [EMAIL PROTECTED] = thanks, regards, Hiten Pandya [EMAIL PROTECTED] http://www.geocities.com/hitmaster2k __ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Convertisseurs euro : nous avons votre solution
Title: Passer l'euro et gagnez un convertisseur CBM-Bureautique vous invite sur son site : www.cbm-bureautique.com pour dcouvrir sa collection de calculatrices et convertisseurs Euros, adapts tous vos besoins (calculatrices de poche, portes-cls, calculatrices professionnelles de bureau, rendu de monnaie, ).* Contactez-nous, dcouvrez nos tarifs, commandez et recevez ce convertisseur ** *Marquage sur devis partir de 500 pices **(porte-cls muni dun jeton de caddie, offre valable jusquau 31/12/2201, pour un montant minimum de commande de 1 500 Frs) A bientt sur www.cbm-bureautique.com Pour ne plus recevoir de message rpondez avec comme objet dsabonnement
pcap/bpf in a multi-threaded environment
Greetings,
The past couple of days I've been plagued by a strange behaviour
of something between libpcap and the bpf-device. As you can read
in PR bin/31649, the behaviour of libpcap is very different if you
compile it on gcc with or without -pthread:
Without -pthread, it calls the callback function everytime it has
received a packet.
With -pthread, it calls the callback function only when the
input-buffer (about 32Kb) is nearly full.
I've done some investigation (with my limited knowledge of what
happens between a call to read() and when it ends up in bpfread())
and saw the difference between a call with and without the -pthreads
option:
in /usr/src/contrib/libpcap/pcap-bpf.c, line 81, the function pcap_read():
cc = read(p-fd, (char *)p-buffer, p-bufsize);
at a certain moment, in the read()-code, bpfread() is called:
/sys/net/bpf.c, line 491
In a non-threaded environment, this if-statement is false
if (ioflag IO_NDELAY) {
splx(s);
return (EWOULDBLOCK);
}
In a threaded environment, the if-statement is true, splx(s) is
called and EWOULDBLOCK is returned. Then it's silent for a while,
while the packets are being collected (somewhere) and at a certain
moment the buffer is nearly full and the read() in pcap_read() is
finished.
So yeah, I'm stuck. All I want is in threaded mode to have the same
behaviour as I have in non-threaded mode. Anybody any ideas on how
to fix this?
Thanks in advance,
Edwin
--
Edwin Groothuis | Personal website: http://www.MavEtJu.org
[EMAIL PROTECTED] | Interested in MUDs? Visit Fatal Dimensions:
--+ http://www.FatalDimensions.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: IPFW module
On Fri, Nov 09, 2001 at 09:12:49AM +0200, Dimitar Peikov wrote: It is regular to kernel crash if ipfw is loaded as module, but why when it was build into kernel? In that case it would be good kldload/kldunload to exit! If you want to turn ipfw off when it is compiled into the kernel, you can execute : sysctl -w net.inet.ip.fw.enable=0 Ceri -- keep a mild groove on To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: IPFW module
On Friday 09 November 2001 02:12 am, you wrote: if you included options IPFIREWALL in your kernel, you don't need to kldload the module, and it may mess some things up if you do try to kldload it. This morning I've cvsuped to STABLE and put 'options IPFIREWALL' into my kernel configuration file. After installing all I try to 'kldload ipfw' which complains that ipfw module is already in kernel, but kldstat reports that module is being loaded! Then I've decided to kldunload it Kernel panic reboot! It is regular to kernel crash if ipfw is loaded as module, but why when it was build into kernel? In that case it would be good kldload/kldunload to exit! Why kldload loads module in case that it is compiled in kernel? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
CPU Temp and Fan speed as entropy?
Out of curiousity, has anyone looked into using cpu temperature and fan speed as an entropy source? The thought came to last time I was in bios, looking at the temperature stats; to my untrained eye, it sure looks like those numbers bounce around a lot. I think most motherboards are coming with such sensors onboard these days, and I also believe that we have userland support for reading the values. I think we're doing just fine wrt entropy in -current, but it would still be rather neat to harvest hardware-derived entropy on a wide variety of machines. Just curious, Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: mmap/madvise -- Thanks!
Wow! The responses to my question have been amazing! I never expected to get the wealth of information that you people have given me. Thank you all! Jason. Jason Mawdsley ~ [EMAIL PROTECTED] Software Designer ~ m_ a c a d a m i a nt e c h n o l o g i e s Software developers for the world's leading technology companies. http://www.macadamian.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: pcap/bpf in a multi-threaded environment
On Friday, November 09, 2001 5:56 AM Edwin Groothuis [EMAIL PROTECTED]
wrote:
The past couple of days I've been plagued by a strange behaviour
of something between libpcap and the bpf-device. As you can read
in PR bin/31649, the behaviour of libpcap is very different if you
compile it on gcc with or without -pthread:
Without -pthread, it calls the callback function everytime it has
received a packet.
With -pthread, it calls the callback function only when the
input-buffer (about 32Kb) is nearly full.
I've done some investigation (with my limited knowledge of what
happens between a call to read() and when it ends up in bpfread())
and saw the difference between a call with and without the -pthreads
option:
in /usr/src/contrib/libpcap/pcap-bpf.c, line 81, the function pcap_read():
cc = read(p-fd, (char *)p-buffer, p-bufsize);
at a certain moment, in the read()-code, bpfread() is called:
/sys/net/bpf.c, line 491
In a non-threaded environment, this if-statement is false
if (ioflag IO_NDELAY) {
splx(s);
return (EWOULDBLOCK);
}
In a threaded environment, the if-statement is true, splx(s) is
called and EWOULDBLOCK is returned. Then it's silent for a while,
while the packets are being collected (somewhere) and at a certain
moment the buffer is nearly full and the read() in pcap_read() is
finished.
So yeah, I'm stuck. All I want is in threaded mode to have the same
behaviour as I have in non-threaded mode. Anybody any ideas on how
to fix this?
The problem is probably due to the poll system call that the threaded
library does before performing the read(). In the non-threaded case, the
read() returns when the timeout is hit; in the threaded case, the threaded
library's poll() has to succeed before the read system call will be
executed, and poll() won't succeed until the buffer is full.
If you would like to try this patch (relative to FreeBSD 4.3) to
/sys/net/bpf.c and /sys/net/bpfdesc.h and let me know if it helps, I will
add this patch to PR 22063 and perhaps commit it if it passes review.
Guy Helmer
bpf-new.diff
Description: Binary data
Re: Measuring interrupt latency
In message [EMAIL PROTECTED] Poul-Henning Kamp writes: : We found at Timing Solutions when we were trying to measure interrupt : latency that the system time (getnanotime()) gave us measurements with : a larger variance than our expensive scopes that does statistical : gathering. : : Uhm, you should have used nanotime(), not getnanotime(). : : getnanotime() returns a timestamp in nanoseconds of the last : stored timestamp which may be up to 1/hz seconds old. H. Actually looking at the code, we did use nanotime()... But we do have a few drivers that are using getnanotime() incorrectly... The larger variance was something like a factor of 2 larger than the one that we'd measured on the scopes. I don't have the data online, or I'd be more precise. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Measuring interrupt latency
One a related, timekeeping note: is there any interest in updating or extending the SO_TIMESTAMP socket option to return higher resolution timestamps? Currently, it returns a struct timeval. I did a quick survey, and it appears that there are applications which use this facility (though, surprisingly, not NTP despite the patch I sent off years ago). I suspect these applications would be surprised to discover a struct timespec. Also, NetBSD and OpenBSD have picked up this code and apparently Linux has a form of it as well. Based on some email from a week or two ago, I wonder if there's value in returning a timestamp in the 64.64 format that phk proposed previously, along with some additional status information. Related to the packet timestamping work I mentioned in a previous message, I added a SO_TIMESTAMP2 socket option which returned a higher resolution timestamp, along with auxilary data to identify the source of the timestamp where there might be more than one clock available, as well as some quality information (synchronized, estimated freq and phase error, etc.) If this interface was going to be extended, then it would be good to only revisit this once. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
September, 2001 FreeBSD Development Status Report
This report was created with the assistance of Nik Clayton and Chris Costello. September 2001 Status Report Introduction In the month of September, the FreeBSD Project continued its investment in long-term projects, including continuing work on a fine-grained SMP implementation, support for Kernel Schedulable Entities (KSE) supporting highly efficient threading, and broadening support for modern hardware platforms, including Intel's new IA64 architecture, UltraSparc, and PowerPC. Additional focus was placed on the release process, including work on the release notes infrastructure, support for DVD releases, and work on a binary updating tool. Due to the delay in getting the September report out the door, the November status report will also cover October. During the month of November, we look forward to BSDCon Europe, the first such event outside the continental United States. The USENIX conference paper submission deadlines are also in November, and FreeBSD users and developers are encouraged to submit to the general and FREENIX tracks. Please see www.usenix.org for more information. * binup * Compressed TCP state * Fibre Channel Support * FreeBSD C99/POSIX Conformance Project * FreeBSD DVD generation * FreeBSD Java Project * FreeBSD libh Project * FreeBSD/sparc64 port * Improving FreeBSD startup scripts * Intel Gigabit driver * Intel Gigabit Ethernet * jpman project * KSE * Multiple console support * Netgraph ATM * Network console * Network device nodes * Network SMP locking * New Mount(2) API * Porting ppp to hurd linux * PowerPC Port * PPP IPv6 Support * PRFW * RELNOTESng * SMPng Status Report * SYN cache implementation for FreeBSD * TIRPC binup URL: http://www.FreeBSD.org/projects/updater.html Contact: Eric Melville [EMAIL PROTECTED] Contact: Murray Stokely [EMAIL PROTECTED] The project has gained a mailing list, [EMAIL PROTECTED] - and the source tree has been moved into the projects/ directory in the FreeBSD CVS repository. Current work is focusing on extending the FreeBSD package framework, and the client library should be rewritten and completed by the end of the year. TODO: make the projects/ hierarchy into a cvsup distribution and add it to cvs-all. Then update distrib.self. --- Compressed TCP state Contact: Jonathan Lemon [EMAIL PROTECTED] Development on this project has been slowed, pending the commit of the syncache code, as this builds on part of that work. --- Fibre Channel Support URL: http://www.feral.com/isp.html Contact: Matthew Jacob [EMAIL PROTECTED] Bug fixing and move to -STABLE of 2Gb support. --- FreeBSD C99/POSIX Conformance Project URL: http://people.FreeBSD.org/~mike/c99/ Contact: Mike Barcroft [EMAIL PROTECTED] Contact: FreeBSD-Standards Mailing List [EMAIL PROTECTED] The FreeBSD C99/POSIX Conformance Project aims to implement all requirements of the C99 Standard and the latest 1003.1-200x POSIX draft (currently Draft 7). In cases where aspects of the standard cannot be followed, those aspects will be documented in the c99(7) or posix(7) manuals. It is also an aim of this project to implement regression tests to ensure correctness whenever possible. Patches that implement the stdint.h and inttypes.h headers, and modifications to printf(3) have been developed and will be committed shortly. They will allow us to use some of the new types C99 introduces, such as intmax_t and the printf(3) conversion specifier %j. --- FreeBSD DVD generation Contact: Brian Somers [EMAIL PROTECTED] A two disc set has been mastered and sent for pressing. There are a few surprises with this release - details will be given in the official announcement (at BSDConEurope). --- FreeBSD Java Project URL: http://www.freebsd.org/java/ Contact: Greg Lewis [EMAIL PROTECTED] The project has moved forward on JDK 1.3.1 development this month, with the release of two more patchsets. The team is reasonably confident that the latest patchset is a stable release of the core JDK 1.3.1 tools and classes, when the default green threads subsystem is used. This is mostly thanks to hard work by Fuyuhiko Maruyama to stabilise and fix the code. Bill Huey has also been progressing with his work on the native threads subsystem, although this hasn't yet reached the stability of green threads. Another (arguably the) major highlight of the latest patchset was the integration of NetBSD support by Scott Bartram and Alistair Crooks (the latter of NetBSD packages fame). Hopefully OpenBSD support will follow, making it truly a united BSD Java Project.
Re: mmap/madvise
I am creating a virtual memory manager. Currently I am doing a mmap(...PROT_NONE, MAP_ANON ) to reserve the memory. then when committing the memory I am using mprotect( ...PROT_READ | PROT_WRITE ) mmap For reservation of memory; you should mmap the fd for /dev/zero, with MAP_ANON to grab pages initially. The man pages state that the fd must be -1 for MAP_ANON. an open() /dev/zero will return an valid file descriptor. So how would I mmap using /dev/zero? Too bad there isn't an Advance UNIX programming for Windows Programmers book. 8-(. Sounds like their could be a good market for one ;-) Jason Jason Mawdsley ~ [EMAIL PROTECTED] Software Designer ~ m_ a c a d a m i a nt e c h n o l o g i e s Software developers for the world's leading technology companies. http://www.macadamian.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ports/31188: New port: www/orion-current
Dear All, I've tried to get someone to commit this port over on -ports, but I got no response. Is there someone who could commit this port, please? Thanks in advance. Yours, Kees Jan --- Kees Jan Koster e-mail: kjkoster at kjkoster.org www: http://www.kjkoster.org/ --- File not found. Should I fake it? [Y/N] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
*.info documentation missing for CVS (and other GNU tools)
/usr/share/info/ is empty on a more or less default installation of 4.4-RELEASE, even though GCC, CVS, and other GNU tools are part of the base system. Especially in the case of CVS (and I believe also GCC and others) this is extremely bad, because the man pages of these programs are incomplete, and the only way to get the full documentation is by using the *.info files. Is there any specific reason why these are not included in FreeBSD? pulcherrima[173]:/FreeBSD/src/contrib/cvs% find . -name '*info*' ./src/parseinfo.c ./doc/cvs.texinfo *.info files are generated from *.texinfo, and cvs.texinfo *is* part of the FreeBSD source tree, as are /usr/bin/info (the info browser) and /usr/bin/makeinfo (the compiler). Could we also have the generated *.info files become part of the base system? Gerald -- Gerald Jerry [EMAIL PROTECTED] http://www.dbai.tuwien.ac.at/~pfeifer/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: mmap/madvise
Jason Mawdsley wrote: I am creating a virtual memory manager. Currently I am doing a mmap(...PROT_NONE, MAP_ANON ) to reserve the memory. then when committing the memory I am using mprotect( ...PROT_READ | PROT_WRITE ) mmap For reservation of memory; you should mmap the fd for /dev/zero, with MAP_ANON to grab pages initially. The man pages state that the fd must be -1 for MAP_ANON. an open() /dev/zero will return an valid file descriptor. So how would I mmap using /dev/zero? Mmap'ing /dev/zero gives you anopnymous pages; they can't be not private. It's pretty much the same thing. I would use /dev/zero, since it's portable. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: *.info documentation missing for CVS (and other GNU tools)
In the last episode (Nov 09), Gerald Pfeifer said: /usr/share/info/ is empty on a more or less default installation of 4.4-RELEASE, even though GCC, CVS, and other GNU tools are part of the base system. I just installed 4.4-RELEASE and it installed all the info pages. Maybe you didn't check the info distribution checkbox in sysinstall? -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: *.info documentation missing for CVS (and other GNU tools)
On Fri, 9 Nov 2001, Dan Nelson wrote: I just installed 4.4-RELEASE and it installed all the info pages. Maybe you didn't check the info distribution checkbox in sysinstall? Sheesh! I'll go ahead and AART[1] the colleague who installed said box (for this was supposed to be enabled) and then I will properly punish myself. :-( Embarrassing. Gerald [1] echo LART | sed -e s/Luser/Admin/ -- Gerald Jerry [EMAIL PROTECTED] http://www.dbai.tuwien.ac.at/~pfeifer/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Framebuffer device under FreeBSD?
On Fri, 9 Nov 2001, Kevin D.Wooten wrote: i. Is it feasible to port Linux fbdev modules to FreeBSD (as a modules, again)? I was under the impression that the subsystem is there ( /usr/src/sys/dev/fb ? ). Maybe not the specific accelerated drivers, but the basics look there. I will say the video mode selection looks weak though, Linux does have a much more flexible mode selection. P.S. - I have been trying to get NVidia docs ( I have to sign an NDA ) to build a GeForce3 framebuffer. Actually, rivafb under Linux provides some HW acceleration (based on utah-glx code, I think). There's no GeForce3 there, though. -- Vladimir Kushnir - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: pcap/bpf in a multi-threaded environment
On Fri, Nov 09, 2001 at 10:56:30AM -0600, Guy Helmer wrote: The problem is probably due to the poll system call that the threaded library does before performing the read(). In the non-threaded case, the read() returns when the timeout is hit; in the threaded case, the threaded library's poll() has to succeed before the read system call will be executed, and poll() won't succeed until the buffer is full. If you would like to try this patch (relative to FreeBSD 4.3) to /sys/net/bpf.c and /sys/net/bpfdesc.h and let me know if it helps, I will add this patch to PR 22063 and perhaps commit it if it passes review. It works like a charm now! Thanks for this. It's really really nice to have a 'proper' working application now :-) I would be happy if you could get this fixed in the source-tree, so that I (and other people of course) can enjoy the charms of bpf-access in a threaded environment! Edwin -- Edwin Groothuis | Personal website: http://www.MavEtJu.org [EMAIL PROTECTED] | Interested in MUDs? Visit Fatal Dimensions: --+ http://www.FatalDimensions.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
fxp driver problems
I've got 4 identical machines all showing the same problem, and a search of the archives didn't turn up anything. They all experience network timeouts when you do more than ping them, here's the relivant dmesg info: fxp0: Intel PLC 10/100 Ethernet port 0xde80-0xdebf mem 0xff8fe000-0xff8fefff irq 11 at device 8.0 on pci1 fxp0: Ethernet address 00:03:47:84:d6:a0 fxp0: device timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: device timeout fxp0: SCB timeout fxp0: device timeout fxp0 in this case is the onboard ethernet on an Intel motherboard. It's connected to a good old fashoned 10 meg hub now: %ifconfig fxp0 fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet [deleted] inet6 [deleted] ether 00:03:47:84:d6:a0 media: 10baseT/UTP status: active supported media: autoselect 100baseTX full-duplex 100baseTX 10baseT/UTP full-duplex 10baseT/UTP This is on 4.3-RELEASE, of course while I'm trying to sup to to stable. *sigh* Anyone seen something like this before? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: fxp driver problems
On Sat, 10 Nov 2001 01:02:58 + (UTC), in sentex.lists.freebsd.hackers you wrote: I've got 4 identical machines all showing the same problem, and a search of the archives didn't turn up anything. They all experience There must be something broken with the search page you used as this has been discussed quite a bit in the stable list. To answer your question, cvsup'ing to something post 4.4 will fix your problem. You have an Intel 815 board probably... ---Mike Mike Tancsa ([EMAIL PROTECTED]) Sentex Communications Corp, Waterloo, Ontario, Canada Given enough time, 100 monkeys on 100 routers could setup a national IP network. (KDW2) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Status of Tekram DC-395 drivers
There is a FreeBSD driver for Tekram DC-395 SCSI adapters: ftp://ftp.tekram.com/SCSI/3X5/FreeBSD/FreeBSD400/dc395x_trm.tar.gz There are such strings in it: /* * ** Imported into FreeBSD source repository, and updated to compile under ** FreeBSD-3.0-DEVELOPMENT, by Stefan Esser [EMAIL PROTECTED], 1996-12-17 * */ But I can't find anything in FreeBSD CVS repository about it. Why? -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
VIA 82231 South Bridge
Are there any planes to support VIA 82231 south bridge for UDMA33/66/100 ? Yes, I know, WDMA2 works with it -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: VIA 82231 South Bridge
It seems [EMAIL PROTECTED] wrote: Are there any planes to support VIA 82231 south bridge for UDMA33/66/100 ? Yes, I know, WDMA2 works with it Could you do a pciconf -l and mail me that please ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
