Re: ATAPICAM for ATA-MKIII
* Scott Long, 2005-03-31 : Attached are patches for atapicam for ATA-MKIII. I've only done light testing, but they seem to work as expected. They work both as a module and compiled into the kernel. Thanks Scott, this is immensely helpful. I'll try to test and commit that this weekend. Thomas. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atapicam hangs system
Le 2003-07-17, Daniel Lang écrivait : I found out, that the hangs do not appear (or way less likely), if the writing speed used is = 12. But they seem to occur very likely if the (attempted) writing speed is like 48. Hum, nasty, nasty. Looks like the amount of interrupts caused by high-speed burning might trigger a race condition between two instances of camisr(). camisr() does splcam(), but maybe this is not sufficient to correctly prevent concurrent execution when interrupts from the ATA driver occur. Maybe the freebsd-scsi people will have a clearer idea of what is going on here. Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [CFR] diskpart(1) buffer overflow fix
Le 2002-12-02, Peter Pentchev écrivait : Ahhh; of course this would be better. Updated patch attached. Looks fine. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Debuggers for FreeBSD
Le 2001-05-30, Terry Lambert écrivait : SoftICE is actually overkill; ddd and gdb are probably best, unless you are talking protected mode code. For a nice visual debugger, you can also give GVD (GNU Visual Debugger) a try. See: http://libre.act-europe.fr/gvd/ Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
Le 2001-05-13, Peter Wemm écrivait : The simplest thing is to do a ssh-keygen to generate a new RSA key and update ~/.ssh/authorized_keys2 once per remote machine that you connect to. Once that is done, it never bothers you again. You can change /etc/ssh/ssh_config so that it says 'Protocol 1,2', but that is avoiding the problem rather than using the more robust, cryptographically secure sshv2 wire protocol. Ah. This seems to work around the very unfortunate situation described in PR bin/27264. It seems very strange that one has to change the setup on the *server* side to work around a regression on the client side. Why cannot one use the same RSA public key for v1 and v2 client authentication? Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: VPN
Le 2001-04-26, Jesús Arnáiz écrivait : I want to set VPN on my system, I see there is many programs created to do it. Any advantages or disadvantages of using one or other?. What is better (is the first time I set VPN on a UNIX system).? If your requirements are not too complicated, you can use pipsecd (from ports/net), which is an implementation of ipsec that requires only very limited setup. Besides, pipsecd has been successfully tested for interoperation with other ipsec products. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: login.c
Le 2001-04-24, Jamie Heckford écrivait : Noticed getpass() is in libc, is there a definition somewhere else that would prevent me from changing the Password: prompt? Try /usr/src/lib/libpam/modules/pam_unix/pam_unix.c. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SCSI-over-* hacks
Le 2001-03-21, Soren Schmidt crivait : - a CAM transport for ATAPI devices; What do you want it for actually ? It is a possible solution for me to be able to use cdparanoia and cdrdao with my ATAPI CD drive. An alternative solution would be to implement an atapi-cd ioctl to send a raw command to an ATAPI device, and make libscg use that. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI-over-* hacks
Le 2001-03-21, Mike Smith crivait : SCSI is way of encapsulating scanner commands so that you can transport them to the scanner. So is USB. The command set your scanner uses is probably the same as the SCSI command set, but this is not what a CAM transport would give you - it would only give you the layers beneath, which would not be useful, since you already have this in the form of USB. Um. The CAM tranport in question would not be a reimplementation of the USB layer, of course. What I was mentioning was the possibility of having a CAM transport that wraps a uscan device (just as there is one already that wraps umass devices to make them appear as SCSI disks). This would allow all USB scanners that use an SCSI command set to be accessible through pass*, and thus be supported by any scanning software that can use a SCSI scanner. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI-over-* hacks
Le 2001-03-19, Nat Lanza crivait : FreeBSD already has an equivalent to the SCSI generic device -- take a look at pass(4). Yep, I am aware of pass(4), but some closed-source software that comes only as Linux binaries insist on having a /dev/sg device (which, under FreeBSD, would most likely be implemented as a wrapper around pass.) As far as ATAPI-over-CAM, there's been some discussion of having ATA become part of CAM, but I don't remember what the result of it was. You might want to check the list archives. Thanks, I'll do that. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
