Re: USB device with multiple interfaces, sample code anyone?
On Mon, May 29, 2006 at 05:01:39PM +0200, Volker wrote: > Hi hackers, > > I'm trying to correctly implement a driver for an USB device which > has multiple (serial) interfaces (at least 3). Each interface should > be seen by the kernel as a tty device entry /dev(/cuaU* or /dev/ttyU*). You either build a device driver managing the whole device and create multiple ttys in a single device instance. uftdi(4) is an example for this, which supports single and twin channel USB-devices. Or you build a driver matching a single interface which attaches in multiple instances. ubser is a single interface driver, it creates multiple ttys on a single interface however. Although real hardware don't exist with multiple interfaces the driver would allow it. http://www.bwct.de/modbus/ubmb-0.3.tgz is a very simple interface level driver which was already used for multiple interfaces. It attaches once for each device and create a single device for each instance. But it is not a tty driver. > After reading the usb kernel sources I'm not quite sure how to deal > with that. As the device entry is being created in ucom.c > (ucom_attach calls ttycreate) I'm not quite sure which code is > responsible for scanning (enumerating) and correctly attaching to > the usb device interfaces or if there's just a wrong enumeration > return code. This is done in usbd_probe_and_attach(). Forst the whole device is offered and if no driver claims it each single interface is offered. > I haven't found any usb code which deals with more than 1 interface > per usb device (except sound/pcm/uaudio but while doing a quick read > of that code I do not understand much of uaudio). Normaly a driver only handles a single instance and attaches multiple times. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bus_dmamap_load_uio and uiomove
Hello, Just quick busdma question... I'm currently upgrading a custom device driver to use bus_dmamap_load_uio rather than uiomove. Everything works fine, but calls to "write" fail unless I set uio->uio_resid to 0 by hand (as I'm not using uiomove anymore). Am I supposed to set uio_resid by hand when using bus_dmamap_load_uio, or is there a better way to signal that all the data in uio was used? -- jimmy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: misc questions about the device&driver arch
Sir：
I have got the way to map linux pci access way to the BSD way :)
now ,several more question ,wondering :(
FIRST
struct pci_devinfo * pci_read_device(device_t pcib, int b, int s, int
f, size_t size)
struct cardbus_devinfo {
struct pci_devinfo pci;
uint8_tmprefetchable; /* bit mask of prefetchable BARs */
so what happen when dinfo = (struct cardbus_devinfo
*)pci_read_device(brdev, bus, slot, func, sizeof(struct
cardbus_devinfo));
can we use this magic as a common way to wrap common guts?
SECOND
what should we do to destroy a device and hot remove it from the system ?
1 pause the application
2 device_detach(devlist[tmp]);
3***_release_all_resources(busdev, dinfo);
4 device_delete_child(busdev, devlist[tmp]);
5 pci_freecfg((struct pci_devinfo *)dinfo);
6 shutdown power of the slot
so what exactly happens between 2 and 5?
THIRD
Because the PCIE configure space is 4k long ,shall we change the
#define PCI_REGMAX 255
to facilitate the PCI express config R/W?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: misc questions about the device&driver arch
In message: <[EMAIL PROTECTED]>
"william wallace" <[EMAIL PROTECTED]> writes:
: Sir：
: I have got the way to map linux pci access way to the BSD way :)
: now ,several more question ,wondering :(
: FIRST
: struct pci_devinfo * pci_read_device(device_t pcib, int b, int s, int
: f, size_t size)
: struct cardbus_devinfo {
: struct pci_devinfo pci;
: uint8_tmprefetchable; /* bit mask of prefetchable BARs */
:
: so what happen when dinfo = (struct cardbus_devinfo
: *)pci_read_device(brdev, bus, slot, func, sizeof(struct
: cardbus_devinfo));
: can we use this magic as a common way to wrap common guts?
Yes. It is already there when you go throuh the proper interface.
Take a look at ivars. struct pci_devinfo is not for anybody but a bus
to use.
: SECOND
: what should we do to destroy a device and hot remove it from the system ?
: 1 pause the application
impractical. What application? This is an async event, and upper
level drivers have to cope. If they don't, we're screwed anyway. If
a device can disappear, then we have to make sure that the drivers
support it.
: 2 device_detach(devlist[tmp]);
That's what we do right now in cardbus.
: 3***_release_all_resources(busdev, dinfo);
Drivers are responsible for doing this, not the bus.
: 4 device_delete_child(busdev, devlist[tmp]);
That's what we do right now in cardbus.
: 5 pci_freecfg((struct pci_devinfo *)dinfo);
Sounds good.
: 6 shutdown power of the slot
Yea.
: so what exactly happens between 2 and 5?
: THIRD
: Because the PCIE configure space is 4k long ,shall we change the
: #define PCI_REGMAX255
: to facilitate the PCI express config R/W?
Maybe. Lemme investigate because PCIe changes this from a well known
constant for all pci busses, to a variable one...
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: misc questions about the device&driver arch
M. Warner Losh wrote: > : THIRD > : Because the PCIE configure space is 4k long ,shall we change the > : #define PCI_REGMAX 255 > : to facilitate the PCI express config R/W? > > Maybe. Lemme investigate because PCIe changes this from a well known > constant for all pci busses, to a variable one... > > Warner When I added PCIe extended config support, I never took into consderation the userland access point of view. Changing this definition to 4096 might Just Work, and it might Not Work. Dunno. In the 18 months since I implemented it, no other person has asked about userland access. Other than the silly case of people trying to write device drivers in PERL, I'm not sure how much value it gives compared to the stability and security risk it imposes. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: misc questions about the device&driver arch
On 5/30/06, M. Warner Losh <[EMAIL PROTECTED]> wrote:
In message: <[EMAIL PROTECTED]>
"william wallace" <[EMAIL PROTECTED]> writes:
: Sir：
: I have got the way to map linux pci access way to the BSD way :)
: now ,several more question ,wondering :(
: FIRST
: struct pci_devinfo * pci_read_device(device_t pcib, int b, int s, int
: f, size_t size)
: struct cardbus_devinfo {
: struct pci_devinfo pci;
: uint8_tmprefetchable; /* bit mask of prefetchable BARs */
:
: so what happen when dinfo = (struct cardbus_devinfo
: *)pci_read_device(brdev, bus, slot, func, sizeof(struct
: cardbus_devinfo));
: can we use this magic as a common way to wrap common guts?
Yes. It is already there when you go throuh the proper interface.
Take a look at ivars. struct pci_devinfo is not for anybody but a bus
to use.
so ivar IS devinfo .and so when we create something special ,just
ABC_devinfo{
struct pci_devinfo pci;
: SECOND
: what should we do to destroy a device and hot remove it from the system ?
: 1 pause the application
impractical. What application? This is an async event, and upper
level drivers have to cope. If they don't, we're screwed anyway. If
a device can disappear, then we have to make sure that the drivers
support it.
SORRY:) I mean quiece the DRIVER first
: 2 device_detach(devlist[tmp]);
That's what we do right now in cardbus.
: 3***_release_all_resources(busdev, dinfo);
Drivers are responsible for doing this, not the bus.
THIS still happens in cardbus of FreeBSD 53 ~_^
: 4 device_delete_child(busdev, devlist[tmp]);
That's what we do right now in cardbus.
: 5 pci_freecfg((struct pci_devinfo *)dinfo);
Sounds good.
: 6 shutdown power of the slot
Yea.
: so what exactly happens between 2 and 5?
: THIRD
: Because the PCIE configure space is 4k long ,shall we change the
: #define PCI_REGMAX255
: to facilitate the PCI express config R/W?
Maybe. Lemme investigate because PCIe changes this from a well known
constant for all pci busses, to a variable one...
IT really make me headache ,
i decide to changePCI_REGMAXinto 4k, just port the linux way here .
Warner
--
we who r about to die,salute u!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: misc questions about the device&driver arch
On 5/30/06, Scott Long <[EMAIL PROTECTED]> wrote: M. Warner Losh wrote: > : THIRD > : Because the PCIE configure space is 4k long ,shall we change the > : #define PCI_REGMAX 255 > : to facilitate the PCI express config R/W? > > Maybe. Lemme investigate because PCIe changes this from a well known > constant for all pci busses, to a variable one... > > Warner When I added PCIe extended config support, I never took into consderation the userland access point of view. Changing this definition to 4096 might Just Work, and it might Not Work. Dunno. In the 18 months since I implemented it, no other person has asked about userland access. Other than the silly case of people trying to write device drivers in PERL, I'm not sure how much value it gives compared to the stability and security risk it imposes. Scott I have to clarify my intentions that i am not TRYing to do a userland PCI express driver . I just want to make a interesting branch whitch can do pci express native Hot plug and hot remove ,with Mr Losh and other gentlemen's help ,i am making progress ,and now a loadable module is finishing . I have borrowed many Ideas from Linux ,but several fatal difficulties paused me ,with the PCI_REGMAX included. wish to hear from u :) thank u! -- we who r about to die,salute u! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: misc questions about the device&driver arch
william wallace wrote: On 5/30/06, Scott Long <[EMAIL PROTECTED]> wrote: M. Warner Losh wrote: > : THIRD > : Because the PCIE configure space is 4k long ,shall we change the > : #define PCI_REGMAX 255 > : to facilitate the PCI express config R/W? > > Maybe. Lemme investigate because PCIe changes this from a well known > constant for all pci busses, to a variable one... > > Warner When I added PCIe extended config support, I never took into consderation the userland access point of view. Changing this definition to 4096 might Just Work, and it might Not Work. Dunno. In the 18 months since I implemented it, no other person has asked about userland access. Other than the silly case of people trying to write device drivers in PERL, I'm not sure how much value it gives compared to the stability and security risk it imposes. Scott I have to clarify my intentions that i am not TRYing to do a userland PCI express driver . I just want to make a interesting branch whitch can do pci express native Hot plug and hot remove ,with Mr Losh and other gentlemen's help ,i am making progress ,and now a loadable module is finishing . I have borrowed many Ideas from Linux ,but several fatal difficulties paused me ,with the PCI_REGMAX included. wish to hear from u :) thank u! The PCI_REGMAX definition is not used by the extended configuration space code. However, this code only exists on i386 right now. I haven't gotten around to implementing it on amd64 yet. Implementing it there is not just a trivial change of the defintion. Some platform specific memory map tricks need to be done. It would be possible to port the i386 code wholesale, but that code is not terribly efficient on the amd64 platform. So, what problem are you running into? Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gstat going negative?
I've large array that winds up providing 1TB of disk (according to df -h :) to a bunch of nfs users. On the array machine, I'm using gmirror and gconcat to build the array and right now I'm running dump on the array. I've got a gstat running and one curious thing is that gstat keeps reporting 2^32-1 as the value for l(Q) (obviously, spelt out in numbers) ... as if l(Q) is actually coming back as -1. Odd? Dave. -- |David Gilbert, Independent Contractor. | Two things can be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
truncate tool - must be root?
Is it expected that truncate(8) must be used by a superuser? If so, then the man page should probably mention it. If not, then it's broken :) Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: truncate tool - must be root?
Eric Anderson wrote: Is it expected that truncate(8) must be used by a superuser? If so, then the man page should probably mention it. If not, then it's broken :) That's a pretty weak attempt at a bug report, and a wrong one, too: $ uname -m -r -s FreeBSD 5.4-RELEASE i386 $ id uid=2028(madole) gid=2000(users) groups=2000(users) $ echo "this is a test" > test $ ls -l test -rw-r- 1 madole httpd 15 May 30 12:06 test $ truncate -s 7 test $ ls -l test -rw-r- 1 madole httpd 7 May 30 12:06 test $ cat test this is$ Want to try again, giving any sort of interesting details you can, like version you tested on or a reproducible test case? David ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: truncate tool - must be root?
On Tue, 30 May 2006, 10:59-0500, Eric Anderson wrote: > Is it expected that truncate(8) must be used by a superuser? If so, > then the man page should probably mention it. If not, then it's > broken :) Works for me: $ truncate -s 100g 100g $ ls -l 100g -rw-r--r-- 1 maxim maxim 107374182400 May 30 20:11 100g $ id uid=1001(maxim) gid=1001(maxim) groups=1001(maxim), 0(wheel), 5(operator), 68(dialer) -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: truncate tool - must be root?
On Tue, May 30, 2006 at 12:11:53PM -0400, David S. Madole wrote: > Eric Anderson wrote: > >Is it expected that truncate(8) must be used by a superuser? If so, > >then the man page should probably mention it. If not, then it's > >broken :) > > That's a pretty weak attempt at a bug report, and a wrong one, too: > > $ uname -m -r -s > FreeBSD 5.4-RELEASE i386 > $ id > uid=2028(madole) gid=2000(users) groups=2000(users) > $ echo "this is a test" > test > $ ls -l test > -rw-r- 1 madole httpd 15 May 30 12:06 test > $ truncate -s 7 test > $ ls -l test > -rw-r- 1 madole httpd 7 May 30 12:06 test > $ cat test > this is$ also works for me on 6-RELEASE-p7 Bye, Gergely Czuczy mailto: [EMAIL PROTECTED] PGP: http://phoemix.harmless.hu/phoemix.pgp Weenies test. Geniuses solve problems that arise. signature.asc Description: Digital signature
Re: truncate tool - must be root?
On Tue, May 30, 2006 at 10:59:11AM -0500, Eric Anderson wrote: > Is it expected that truncate(8) must be used by a superuser? If so, > then the man page should probably mention it. If not, then it's broken :) > If you speak about truncate(1), it works here under non-root: $ uname -sr FreeBSD 7.0-CURRENT $ dd if=/dev/zero of=foo bs=64k count=10 10+0 records in 10+0 records out 655360 bytes transferred in 0.002590 secs (253040511 bytes/sec) $ id -u 1001 $ truncate -s 0 foo $ ls -l foo -rw--- 1 ru ru 0 May 30 19:21 foo $ -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpc9Cj4qTgpw.pgp Description: PGP signature
Re: truncate tool - must be root?
On Tue, May 30, 2006 at 10:59:11AM -0500, Eric Anderson wrote: > Is it expected that truncate(8) must be used by a superuser? If so, > then the man page should probably mention it. If not, then it's broken :) > > > Eric I can use truncate on files I own without a problem. Who owns the files? A quick experiment indicates that even setting a file to mode 647 when owned by root:wheel doesn't allow it to be operated on by anyone other than root when using truncate. -- WXS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.1, crashes and a lack of vmcores
On Fri, 26 May 2006, [EMAIL PROTECTED] wrote: 0. how many hours did you run memtest86 for? One of my co-workers ran the test so I'm not entirely sure, but I'm pretty certain it was at least over night (so probably 15-16 hours). We also ended up swapping that RAM out with another box and the problem did not move to the new box. 1. did you try to swap the mainboard? Yeah we actually ended up buying an entirely new chassis (MB, power supplies, case). 2. do you suspect any corelation between net traffic intensity,type,etc, and crashes? It is possible because we do a TON of traffic through these boxes, but things like mbufs and other limited resources seem to be ok. It is definitely possible I'm not looking in the right place for something else that would be causing this. However, as I mentioned earlier, this is one box out of a farm that is acting particularly less stable and all the boxes should ideally be receiving similar traffic loads. 3. disabling ACPI made no change? Disabling ACPI resolved a number of noisy boot time messages, but didn't give us any noticeable edge in stability. Now that the long weekend is over I'll likely have some time to try a few more things related to the drive. I suspect I might have inadvertently introduced a negative variable in the drive swapping I did. I'd like to make this last change before digging too much deeper unless the trace data gives anyone else any clues. Thanks everyone for you input. Matt Ruzicka - Senior Systems Administrator Front Range Internet, Inc. [EMAIL PROTECTED] - (970) 212-0728 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: truncate tool - must be root?
David S. Madole wrote: Eric Anderson wrote: Is it expected that truncate(8) must be used by a superuser? If so, then the man page should probably mention it. If not, then it's broken :) That's a pretty weak attempt at a bug report, and a wrong one, too: $ uname -m -r -s FreeBSD 5.4-RELEASE i386 $ id uid=2028(madole) gid=2000(users) groups=2000(users) $ echo "this is a test" > test $ ls -l test -rw-r- 1 madole httpd 15 May 30 12:06 test $ truncate -s 7 test $ ls -l test -rw-r- 1 madole httpd 7 May 30 12:06 test $ cat test this is$ Want to try again, giving any sort of interesting details you can, like version you tested on or a reproducible test case? David *sigh* My mistake - I'm not even going to mention the simple nature of my problem, because I'd embarrass myself too much. :) You're right though, it was a bad report, and I should be smacked with a silly stick.. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: truncate tool - must be root?
Eric Anderson <[EMAIL PROTECTED]> wrote: > Is it expected that truncate(8) must be used by a superuser? If so, > then the man page should probably mention it. If not, then it's > broken :) What exactly is truncate(8)? On FreeBSD 6.1-STABLE I only have truncate(1) and it doesn't show any problems. Fabian -- http://www.fabiankeil.de/ signature.asc Description: PGP signature
Re: truncate tool - must be root?
Fabian Keil wrote: Eric Anderson <[EMAIL PROTECTED]> wrote: Is it expected that truncate(8) must be used by a superuser? If so, then the man page should probably mention it. If not, then it's broken :) What exactly is truncate(8)? On FreeBSD 6.1-STABLE I only have truncate(1) and it doesn't show any problems. Fabian Yea, it's just a bad message from me altogether.. Might as well just file it under 'Spam'. Sorry for the really bad report of a non-existent problem (except the one between my eyes and my brain). Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gstat going negative?
On Tue, May 30, 2006 at 11:04:35AM -0400, David Gilbert wrote: > I've large array that winds up providing 1TB of disk (according to df > -h :) to a bunch of nfs users. On the array machine, I'm using > gmirror and gconcat to build the array and right now I'm running dump > on the array. > > I've got a gstat running and one curious thing is that gstat keeps > reporting 2^32-1 as the value for l(Q) (obviously, spelt out in > numbers) ... as if l(Q) is actually coming back as -1. > > Odd? SMP race, you can increase the value of kern.geom.collectstats to make the stats collection atomic at the expense of some (probably negligible) performance. Kris pgpFgAuT9rVBD.pgp Description: PGP signature
Asymmetric ethernet throughput?
I was doing some network testing, and noticed something odd: The network throughput was asymmetric. I was sending between 2 and 5 times as much data as I was receiving. Swapping the ends of the test didn't change that. Changing the non-FBSD box for a FBSD box made the throughput symmetric. Details: One end is always a FreeBSD 5.5 box with a RealTek 8138 nic. Testing is done with netstrain, built from ports. I first saw this with an OSX 10.4.6 box, a G4 powerbook. The FreeBSD box was sending ~10MB/sec on a 100BaseT network, which I regard as excellent. But I was only receiving 3M/sec. I tried swapping the server and client ends of netstrain, and got the same results: I was sending 10MB/sec to OSX, and receiving about 3MB/sec from it. I then tried making the other end a FBSD 6.1-RELEASE box, and the throughput was symmetric, with both ends sending and receiving 10MB/sec. I rebooted the 6.1 box into Ubuntu lunix running a 2.6.12 kernel. Again, I got asymmetric results - but this time it was the other way: I was receving ~10MB/sec, but only sending about 3MB/sec. Trying this between the Linux box and the OSX box (sorry, I've only got one of each) gave me symmetric ~10MB/sec throughput. I'm just curious if there's an explanation for this. Thanks, http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Asymmetric ethernet throughput?
Does disabling net.inet.tcp.inflight.enable make any difference? I've noticed strange transfer speed differences between a samba server on freebsd 6.1 and OS 10.4.6 clients and Windows. With these set in /etc/sysctl.conf, I can get reasonable speeds on both the macs and windows box. net.inet.tcp.delayed_ack=0 net.inet.tcp.inflight.enable=0 I also needed to set these in /usr/local/etc/smb.conf socket options = TCP_NODELAY SO_SNDBUF=8576 use sendfile = yes I've also experimented with other settings like lowering the quality of the timer with kern.timecounter.hardware=TSC which seemed to increase throughput in some cases but not others. Luke ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Asymmetric ethernet throughput?
In <[EMAIL PROTECTED]>, Lucas Holt <[EMAIL PROTECTED]> typed: > Does disabling net.inet.tcp.inflight.enable make any difference? I've > noticed strange transfer speed differences between a samba server on > freebsd 6.1 and OS 10.4.6 clients and Windows. > > With these set in /etc/sysctl.conf, I can get reasonable speeds on both > the macs and windows box. > net.inet.tcp.delayed_ack=0 > net.inet.tcp.inflight.enable=0 Well, it makes the throughput closer to symmetric when I'm pushing traffic both ways - but at around 7MB/sec. If I only run traffic in one direction, I get the previous behavior. I tried it from the 6.1 system to the 5.5 system. It's not quite so out of whack - 2:1 instead of 3:1 - but those two sysctls don't make any difference. Thanks, http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[ANN] unionfs patchset-13 release
Hi Guys! It is my pleasure and honor to announce the availability of the unionfs patchset-13. Patchset-13: For 7-current http://people.freebsd.org/~daichi/unionfs/unionfs-p13.diff For 6.x http://people.freebsd.org/~daichi/unionfs/unionfs6-p13.diff Changes in unionfs-p13.diff - Fixed a bug that leads a panic around compat2 just after VOP_RENAME call. The documents of those unionfs patches: http://people.freebsd.org/~daichi/unionfs/ (English) http://people.freebsd.org/~daichi/unionfs/index-ja.html (Japanese) Guys taking some panic troubles with p12, please try the p13 :) We think that p13 is getting be no-panic code quality. Thanks -- Daichi GOTO, http://people.freebsd.org/~daichi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Asymmetric ethernet throughput?
On Tue, May 30, 2006 at 04:42:12PM -0400, Mike Meyer wrote: > Well, it makes the throughput closer to symmetric when I'm pushing > traffic both ways - but at around 7MB/sec. If I only run traffic in > one direction, I get the previous behavior. I might like to suggest that the problem is your RealTek NIC. Those NICs so utterly suck (I have 2, before anyone thinks I'm bashing without cause :). I'm speaking from an implementation point of view, read the various reports on the hoops drivers have to just through to send data. They're fine for light home use (and well priced for that). Never expect consistancy or line speed from them though. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: misc questions about the device&driver arch
thank sir ,below is my opinion On 5/30/06, Scott Long <[EMAIL PROTECTED]> wrote: On Tue, 30 May 2006, william wallace wrote: > On 5/30/06, Scott Long <[EMAIL PROTECTED]> wrote: >> william wallace wrote: > >> >> >> > I have to clarify my intentions that i am not TRYing to do a userland >> > PCI express driver . I just want to make a interesting branch whitch >> > can do pci express native Hot plug and hot remove ,with Mr Losh and >> > other gentlemen's help ,i am making progress ,and now a loadable >> > module is finishing . >> > I have borrowed many Ideas from Linux ,but several fatal difficulties >> > paused me ,with the PCI_REGMAX included. >> > wish to hear from u :) thank u! >> > >> >> The PCI_REGMAX definition is not used by the extended configuration >> space code. However, this code only exists on i386 right now. I >> haven't gotten around to implementing it on amd64 yet. Implementing >> it there is not just a trivial change of the defintion. Some platform >> specific memory map tricks need to be done. It would be possible to >> port the i386 code wholesale, but that code is not terribly efficient >> on the amd64 platform. >> >> So, what problem are you running into? >> >> Scott > I just implementing a i386 edition ,and i do not know if it is acpi > related,but as what mentioned in PCIE spec ,native pcie hotplug is > standard ,diffrent from ACPI hotplug . I've never seen hotplug implemented according to the ACPI spec except in one ia64 system from Intel, and that was 3 years ago. I consider the ACPI hotplug spec to be nearly useless. I hope that PCIe hotplug gets implemented according to the PCIe spec by all of the major vendors, and not confined to just ExpressCard. I am thinking to implement a standard way to plug and remove a PCIE device from the pcib-related slot > I am writing a demo loadable module to hot remove a specific PCIE netcard . > and the mainboard surely support pcie hotplug .E7520af2. but i do not > know if the bios support _OSC method or OSHP method > > In the software aspect , i introduce a lot of idea and code from linux > ,if not boring, i list my present code below .haven't finish ,on > progress, maybe finish this week > So what I'm asking is, what about the extended configuration register access is not working for you? The serous problem is that :I have little idea :( Also, from my brief look below, you seem to have re-implemented the pci_read_config and pci_write_config API. This is understandable because the implementation is very opaque in FreeBSD (and thus is nearly impossible to find in the source tree), and it's not very well documented in any manual pages. In any case, you really don't need to do what you are doing with it, just use the provided pci_read|write_config primitives. Also, make sure that you look at the methods written by John Baldwin for accessing PCI capability blocks; don't invent your own methods for that also. Scott first ,let me say ,i am not so familar to the Freebsd pci configure way ,so in my opinion and in my code ,i hold this truth to be self-evident:that only bridge and leaf devices can use pci_read|write_config primitives , and bus always use the PCI_READ_CONFIG one ,what is wrong with me :( and sir , on the E7520 AF2 mainboard ,the first pci e hotplug driver that i successfully run is the linux HOTPLUG_PCI_ACPI, i really had tried to get in to the acpi ,but defeated by the complicated image:( ,i think it is not of little importance, but after i have read the spec , believe the pci express native way shares a bright future for its standard form and powerfull function ,the Linux way just have talked that BTW :my current code is mainly translate the pcie natve hotplug from linux , not from the spec ,and encapsulate the BSD pci config function with the linux-alike interface , i wonder if i am walking the right way , thank u -- we who r about to die,salute u! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: misc questions about the device&driver arch
In message: <[EMAIL PROTECTED]> "william wallace" <[EMAIL PROTECTED]> writes: : BTW :my current code is mainly translate the pcie natve hotplug from : linux , not from the spec ,and encapsulate the BSD pci config function : with the linux-alike interface , i wonder if i am walking the right : way , If the code is Linux, then we can't integrate it into the kernel because we can't have GPL'd code in the kernel, per project policy. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: misc questions about the device&driver arch
Sir : thank u for ur remind . I see the difference between GPL and freebsd way .at present I am trying to find a way to Freebsd PCI hotplug , and borrow some idea from linux ;after i have make sure what to do and what's on ,i will eliminate the linux shadow and build pure native FreeBSD , that is what i am doing,thank u On 5/31/06, M. Warner Losh <[EMAIL PROTECTED]> wrote: In message: <[EMAIL PROTECTED]> "william wallace" <[EMAIL PROTECTED]> writes: : BTW :my current code is mainly translate the pcie natve hotplug from : linux , not from the spec ,and encapsulate the BSD pci config function : with the linux-alike interface , i wonder if i am walking the right : way , If the code is Linux, then we can't integrate it into the kernel because we can't have GPL'd code in the kernel, per project policy. Warner -- we who r about to die,salute u! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
