Re: Probing for devices
Geoff Glasson wrote: I'm trying to port the Linux i810 Direct Rendering Interface ( DRI ) kernel module to FreeBSD. I have reached the point where the thing compiles, and I can load it as a kernel module, but it can't find the graphics device. Through a process of elimination I have come to the conclusion that once the AGP kernel module probes and attaches to the i810 graphics device, nothing else can attach to it. When I read the section on PCI devices it implied ( to me at least ) that multiple kernel modules should be able to attach to the same device. I have tried to get it to work without any success. How would you expect the hardware to act if both drivers were being accessed simultaneously? In general, multiple device attaches are only possible on multifunction devices, where the driver claims by function, rather than merely by PCI ID. You will likely need to have the two drivers intentionally cooperate with each other on the management of the device, in order to accomplish your goal. If your driver is an actual port of the Linux driver, rather than a rewrite, licensing dictates that it talk to the FreeBSD driver and ask it to step out of the way so it can do what it wants to do, and that it act gracefully if the FreeBSD driver refuses because someone is using it. Ideally, your driver would leave the FreeBSD driver in place, and ask it to do some of the device management functions you need on behalf of your driver, rather than your driver attempting to do them directly. If your driver is in the exact same ecological niche (e.g. it provides the same AGP services the FreeBSD driver does), then you will need to ensure that only one driver is ever loaded into the kernel at a time. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Network pipes
On Thu, 2003-07-24 at 21:51, Leo Bicknell wrote: In a message written on Thu, Jul 24, 2003 at 12:48:23PM -0700, Tim Kientzle wrote: Another approach would be to add a new option to SSH so that it could encrypt only the initial authentication, then pass data unencrypted after that. This would go a long way to addressing the performance concerns. ssh -c none? [EMAIL PROTECTED]:~$ uname -srm FreeBSD 5.1-RELEASE i386 [EMAIL PROTECTED]:~$ ssh -c none localhost No valid ciphers for protocol version 2 given, using defaults. Nice idea. OpenSSH has deliberately broken this, and last time I looked will not entertain unbreaking it. The patch is trivial, though. Note, you don't want to use password authentication in this case, but public key should still be ok. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Network pipes
Kirk Strauser wrote: # ssh -f remotehost nc -l -p 54321 | dd of=/dev/st0 bs=32k # tar cvf - / | nc remotehost 54321 Netcat implements a TCP/UDP transports and basically nothing else. Isn't that what you're trying to achieve? You still have the overhead of two nc instances copying data and context switching. The same is also the problem with the ssh -c none approach. My original proposal would setup a direct socket connection from tar to dd. I think I can package the proposed sh changes as a separate command, following Luigi's suggestion. The syntax will not include a pipe symbol and layout, but the performance benefits will still be there. It will also be a lot more portable and also usable within any shell. Many thanks to all for your feedback. Diomidis - http://www.spinellis.gr ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Network pipes
On Thu, Jul 24, 2003 at 05:51:27PM -0400, Leo Bicknell wrote: In a message written on Thu, Jul 24, 2003 at 12:48:23PM -0700, Tim Kientzle wrote: Another approach would be to add a new option to SSH so that it could encrypt only the initial authentication, then pass data unencrypted after that. This would go a long way to addressing the performance concerns. ssh -c none? Note, you don't want to use password authentication in this case, but public key should still be ok. I have patches for this, they may be a little out-of-date: http://www.incunabulum.com/code/patches/openssh/ http://www.incunabulum.com/code/patches/openssl/ BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Network pipes
At 2003-07-25T06:06:01Z, Diomidis Spinellis [EMAIL PROTECTED] writes: You still have the overhead of two nc instances copying data and context switching. Forgive my ignorance, but is that significantly higher than two /bin/sh instances copying data and context switching? -- Kirk Strauser pgp0.pgp Description: PGP signature
Re: Probing for devices
Geoff Glasson wrote: I'm trying to port the Linux i810 Direct Rendering Interface ( DRI ) kernel module to FreeBSD. I have reached the point where the thing compiles, and I can load it as a kernel module, but it can't find the graphics device. Through a process of elimination I have come to the conclusion that once the AGP kernel module probes and attaches to the i810 graphics device, nothing else can attach to it. When I read the section on PCI devices it implied ( to me at least ) that multiple kernel modules should be able to attach to the same device. I have tried to get it to work without any success. You can't. One device cannot serve two master. The closest you can get is to create a bus device that then other drivers can attach to. The bus device can arbitrate access to the actual hardware. The second closest is if a chip has multiple functions, each of the functions can have their own driver. This is fairly fundamental to most operating systems. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Network pipes
Kirk Strauser wrote: At 2003-07-25T06:06:01Z, Diomidis Spinellis [EMAIL PROTECTED] writes: You still have the overhead of two nc instances copying data and context switching. Forgive my ignorance, but is that significantly higher than two /bin/sh instances copying data and context switching? When the shell connects two local processes with a pipe it just redirects the output of the one and the input of the other to the two ends of a pipe(2) IPC abstraction and leaves them to communicate with each other simply wait(2)ing until they finish. The shell does not shuffle the data between the two processes. The same can also be done when connecting a local process with a remote process through a socket(2); there is no need for an intermediary, and this is what I have implemented. Diomidis - http://www.spinellis.gr ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Network pipes
At 2003-07-25T15:48:13Z, Diomidis Spinellis [EMAIL PROTECTED] writes: The same can also be done when connecting a local process with a remote process through a socket(2); there is no need for an intermediary, and this is what I have implemented. Gotcha. -- Kirk Strauser pgp0.pgp Description: PGP signature
recent mplayer port spinning?
Dunno how much further I want to chase this, but I wanted to ask the world first: For FreeBSD 4.7-R, I just (as in two days ago) reinstalled all of my packages via ports (cvsupped nightly). Now, often, mplayer spins upon quitting. It does print Exiting... (End of file), then never actually quits, it spins, eating my CPU, and I jave to -KILL it. A ktrace shows me: 3230 mplayer RET write 1 3230 mplayer CALL write(0x1,0x84e4000,0x19) 3230 mplayer GIO fd 1 wrote 25 bytes Exiting... (End of file) 3230 mplayer RET write 25/0x19 3230 mplayer CALL getpid 3230 mplayer RET getpid 3230/0xc9e 3230 mplayer CALL getpid 3230 mplayer RET getpid 3230/0xc9e 3230 mplayer PSIG SIGSEGV caught handler=0x28a23568 mask=0x0 code=0x0 3230 mplayer CALL sigreturn(0x8440e7c) 3230 mplayer RET sigreturn JUSTRETURN 3230 mplayer PSIG SIGSEGV caught handler=0x28a23568 mask=0x0 code=0x0 3230 mplayer CALL sigreturn(0x8440e7c) 3230 mplayer RET sigreturn JUSTRETURN 3230 mplayer PSIG SIGSEGV caught handler=0x28a23568 mask=0x0 code=0x0 3230 mplayer CALL sigreturn(0x8440e7c) 3230 mplayer RET sigreturn JUSTRETURN ... I _do_ want to open a PR on this, but I'm uncertain if if I should just claim it's an mplayer issue, or should I do more research to track what the point of failure it 'really' is, or just open a PR describing my symptoms, as-is. Any advice? -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA BSD admin/developer at large ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent mplayer port spinnin
Dunno how much further I want to chase this, but I wanted to ask the world first: For FreeBSD 4.7-R, I just (as in two days ago) reinstalled all of my packages via ports (cvsupped nightly). Now, often, mplayer spins upon quitting. It does print Exiting... (End of file), then never actually quits, it spins, eating my CPU, and I jave to -KILL it. Maybe try it with FreeBSD-STABLE, or even FreeBSD 4.8? I've found that occasionally, ports will work on later versions of FreeBSD when they won't work on earlier ones. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
NATD and Address Redirection
I'm wondering about the characteristics of the redirect_address option of natd. I tried this on -questions, but no one replied, so I thought I'd ask on here, hoping to find folks more familiar with kernel mechanisms here. Consider a FreeBSD NAT gateway between a public IP on one network interface and a private LAN address on the 2nd interface serving a group of windows machines on the LAN with private IPS. We wanted to allow outside access to one of the LAN machines. According to the documentation, as I read it, redirect_address sets up a static NAT which is symmetrical between a public address on the outside interface of a FreeBSD machine and a machine on a private IP attached to the inside or LAN network interface. The procedure we used was to alias a 2nd public address to the outside interface and use a redirect_address statement in natd.conf to redirect connections to the new public IP to the inside machine. This doesn't seem to be symmetrical. You can ping the inside machine from outside using the new address and if you connect outwards from the inside machine, the outside world sees the connection as coming form the new public IP. However, a test running VNC server on the inside machine and connecting from outside does not work. You can connect to the inside machine and it sees mouse and keyboard, but the virtual screen does not work. It seems that the connection works properly redirecting inward but not outward. VNC disconnects in about a minute. If you connect to the inside machine using the -via option of VNC to build an encrypted tunnel to the FreeBSD gateway and then connect to the inside machine directly, it works properly, so it doesn't appear to be a VNC problem. I'm questioning whether the connection is really symmetrical? -Jim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent mplayer port spinning?
On Fri, Jul 25, 2003 at 12:46:49PM -0400, Brian Reichert wrote: I _do_ want to open a PR on this, but I'm uncertain if if I should just claim it's an mplayer issue, or should I do more research to track what the point of failure it 'really' is, or just open a PR describing my symptoms, as-is. FWIW, mplayer works great for me here. 554 taran:/home/bandix/media/video% uname -a FreeBSD taran 4.8-RELEASE FreeBSD 4.8-RELEASE #10: Tue Jul 22 01:21:11 CDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TARAN i386 555 taran:/home/bandix/media/video% pkg_info | grep mplayer mplayer-fonts-0.50 A font pack for the mplayer OSD and SUB mplayer-gtk-esound-0.90.0.110_2 High performance media player/encoder supporting many forma mplayer-skins-1.0.5_1 Skins for MPlayer's Graphical User Interface (GUI) mplayerplug-in-0.80 A Mozilla plugin for the MPlayer media player Perhaps you should try upgrading your system to 4.8. There should be no reason that the mplayer port won't compile and work on 4.7, but there may be a bogon hidden somewhere in the binaries you have installed that caused problems in the mplayer compile. It's almost always worth updating your system to the latest release before filing a bug report just to make certain that the bug has not already been fixed. Brandon D. Valentine -- [EMAIL PROTECTED] http://www.geekpunk.net Pseudo-Random Googlism: beauty is breaking ground to the girl in the equivalent of a kansas cornfield retro progressive ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NATD and Address Redirection
On Fri, 25 Jul 2003 13:49:38 -0400 Jim Durham [EMAIL PROTECTED] wrote: Hi, I'm wondering about the characteristics of the redirect_address option of natd. I tried this on -questions, but no one replied, so I thought I'd ask on here, hoping to find folks more familiar with kernel mechanisms here. Except for DIVERT, there isn't any kernel mechanisms for address translatation. Consider a FreeBSD NAT gateway between a public IP on one network interface and a private LAN address on the 2nd interface serving a group of windows machines on the LAN with private IPS. We wanted to allow outside access to one of the LAN machines. According to the documentation, as I read it, redirect_address sets up a static NAT which is symmetrical between a public address on the outside interface of a FreeBSD machine and a machine on a private IP attached to the inside or LAN network interface. The procedure we used was to alias a 2nd public address to the outside interface and use a redirect_address statement in natd.conf to redirect connections to the new public IP to the inside machine. This doesn't seem to be symmetrical. snip I'm questioning whether the connection is really symmetrical? for incoming traffic, you must use -redirect_address, but for outgoing you have to set -alias_address. If you want to use a specific public IP to map incoming AND outgoing packets, you need to run 2 natd, using ipfw matching. regards, clem ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NATD and Address Redirection
On Friday 25 July 2003 08:22 pm, Clement Laforet wrote: On Fri, 25 Jul 2003 13:49:38 -0400 Jim Durham [EMAIL PROTECTED] wrote: Hi, I'm wondering about the characteristics of the redirect_address option of natd. I tried this on -questions, but no one replied, so I thought I'd ask on here, hoping to find folks more familiar with kernel mechanisms here. Except for DIVERT, there isn't any kernel mechanisms for address translatation. Consider a FreeBSD NAT gateway between a public IP on one network interface and a private LAN address on the 2nd interface serving a group of windows machines on the LAN with private IPS. We wanted to allow outside access to one of the LAN machines. According to the documentation, as I read it, redirect_address sets up a static NAT which is symmetrical between a public address on the outside interface of a FreeBSD machine and a machine on a private IP attached to the inside or LAN network interface. The procedure we used was to alias a 2nd public address to the outside interface and use a redirect_address statement in natd.conf to redirect connections to the new public IP to the inside machine. This doesn't seem to be symmetrical. snip I'm questioning whether the connection is really symmetrical? for incoming traffic, you must use -redirect_address, but for outgoing you have to set -alias_address. First, Thanks much for your reply I can add alias_address, but please note that the inside machine already seems to be getting aliased, at least in some cases. If you connect to one of those what's my IP sites using tne browser on the inside machine , you get the correct answer back. IE; you get the 2nd public IP instead of the main public IP. If you want to use a specific public IP to map incoming AND outgoing packets, you need to run 2 natd, using ipfw matching. Can you point me to some documentation on how this is set up? Google returns nothing useful. -Jim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
