Re: Increasing KVM on amd64
Tz-Huan Huang wrote: On Sun, Jun 8, 2008 at 7:59 AM, Alan Cox [EMAIL PROTECTED] wrote: You can download a patch from http://www.cs.rice.edu/~alc/amd64_kvm_6GB.patch that increases amd64's kernel virtual address space to 6GB. This patch also increases the default for the kmem map to almost 2GB. I believe that kernel loadable modules still work. However, I suspect that mini-dumps are broken. I don't plan on committing this patch in its current form. Some of the changes are done in a hackish way. I am, however, curious to hear whether or not it works for you. Thanks for the patch. I applied it on 7-stable but got failed on pmap.c. [snip] We have no machine running 8-current with more than 6G memory now... Sorry, at this point the patch is only applicable to HEAD. That said, the failed chunk is probably easily applied by hand to RELENG_7. Thanks, Alan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Increasing KVM on amd64
On Sun, Jun 8, 2008 at 2:02 PM, Alan Cox [EMAIL PROTECTED] wrote: Tz-Huan Huang wrote: On Sun, Jun 8, 2008 at 7:59 AM, Alan Cox [EMAIL PROTECTED] wrote: You can download a patch from http://www.cs.rice.edu/~alc/amd64_kvm_6GB.patch that increases amd64's kernel virtual address space to 6GB. This patch also increases the default for the kmem map to almost 2GB. I believe that kernel loadable modules still work. However, I suspect that mini-dumps are broken. I don't plan on committing this patch in its current form. Some of the changes are done in a hackish way. I am, however, curious to hear whether or not it works for you. Thanks for the patch. I applied it on 7-stable but got failed on pmap.c. [snip] We have no machine running 8-current with more than 6G memory now... Sorry, at this point the patch is only applicable to HEAD. That said, the failed chunk is probably easily applied by hand to RELENG_7. Ok, I applied the patch and fixed the failed chunk by hand. I also modified the type of vm_kmem_size from u_int to u_long. Here is the diff: http://w.csie.org/~tzhuan/tmp/vm_kmem_size.diff The patched kernel is compiled and boots without problem. I set the vm.kmem_size/vm.kmem_size_max to 3G and vfs.zfs.arc_max to 2G, everything looks fine. Some stress tests are running now, I'll report if any problem. Thanks, Tz-Huan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
ntpd jail problem
Anybody know why ntpd might not work in a jail? I'm running an openntpd instance on the host machine, which syncs the clock from the pool at pool.ntp.org. From the log output, ntpd claims to be synced and the time does seem to be correct. I'm then running another openntpd in a jail which doesn't set the time, just serves it to clients. Something appears to be wrong, however. Any client that tries to get the time from the jailed openntpd simply says: $ sudo /usr/local/sbin/ntpd -ds listening on 127.0.0.1 ntp engine ready reply from 192.168.3.21: not synced, next query 615s The ntpd *never* appears to sync. Am I doing something fundamentally wrong, here? Is there some problem with jailed openntpd (that doesn't attempt to set the time) that I'm not aware of? Any help would be appreciated. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
timestamping for kernel messages (like Solaris and Linux)
Hi, Has anyone thought about implementing an option to prepend all kernel console messages with timestamps, like Linux and Solaris do? Is it just a matter of hacking up the kernel printf() implementation? Any possible caveats? Regards, Niki ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd jail problem
On 20080608 12:19:23, Steven Hartland wrote: I assume as it would effect the entire machine and hence should be run on the base machine instead, not the jail? I think you might've misunderstood. The ntpd I'm running on the host syncs the clock (and therefore the whole machine), the ntpd in the jail just publishes the time for the network (doesn't affect the clock). The problem is that the ntpd in the jail seems to believe that the host clock is out of sync (from what I can gather), even though it isn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd jail problem
I assume as it would effect the entire machine and hence should be run on the base machine instead, not the jail? - Original Message - From: [EMAIL PROTECTED] Anybody know why ntpd might not work in a jail? This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AMD Geode LX crypto accelerator (glxsb)
Le Sat, 7 Jun 2008 06:18:55 +0200, Pawel Jakub Dawidek [EMAIL PROTECTED] a écrit : Well, it seems to work but i've got few problems to test the module : - How check the encryption/decryption ? Openssl seems ok, i've got quite the same results as NetBSD on a Soekris net5501 box. But i must use -engine cryptodev, why ? This is ok, as you may not want to use it, right? I think it should be automatic with an option to not use it. Simon replied for this problem. Try comparing result of openssl encryption with and without '-engine cryptodev'. Remember to use -nosalt (and maybe -raw) prevent openssl from putting salt in front of the ciphertext. Thank you. I checked the encryption with and without 'engine cryptodev'. It works \o/ $ openssl enc -e -aes-128-cbc -in file -out file.enc -nosalt -k abcdefhij $ openssl enc -d -aes-128-cbc -in file.enc -out file.dec -nosalt -k abcdefhij $ md5 file file.dec Time to encode a 300 MB file soft : 1m29.72s real, 1m8.74s user, 8.68s sys hard : 42.98s real, 1.80s user, 22.94s sys - The driver does a busy wait to check the completion of the encryption. I think it would be beter to use the interrupt. I will look later. I remember looking at that code sometime ago and that bit is really lame, so lame that I think they would do it in a different way if that was possible. Maybe it's worth contacting OpenBSD/NetBSD and ask? There might be a good reason for that. Yes it seems strange, i've sent a mail to the author about this. I've looked the Linux version of the driver and they use a busy wait too. [CUT] - Any comment is welcome, this is my first work on a driver. Looks good:) I can do a final review and commit once you are done and if I'll be able to start my Soekris and test it. Thanks. I think it is ok for a review and test, i added the RNG stuff since the last time and a manual page 'glxsb.4' http://user.lamaiziere.net/patrick/glxsb.c http://user.lamaiziere.net/patrick/glxsb.tar.gz (all the module) Regards. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: timestamping for kernel messages (like Solaris and Linux)
On 2008-Jun-08 10:24:53 +0300, Niki Denev [EMAIL PROTECTED] wrote: Has anyone thought about implementing an option to prepend all kernel console messages with timestamps, like Linux and Solaris do? The only time I've seen Solaris do this is when the console message is syslog'd - which FreeBSD also does. Is it just a matter of hacking up the kernel printf() implementation? Pretty much. Any possible caveats? The kernel works in UTC only and has only a very restricted ability to translate between epoch seconds and a human-readable date/time (it's currently only used to talk to the RTC). -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpvxVbhYKCp4.pgp Description: PGP signature
Re: ntpd jail problem
On 2008-Jun-08 11:32:54 +0100, [EMAIL PROTECTED] wrote: I'm running an openntpd instance on the host machine, which syncs the clock from the pool at pool.ntp.org. From the log output, ntpd claims to be synced and the time does seem to be correct. I'm then running another openntpd in a jail which doesn't set the time, just serves it to clients. I've never used openntpd but for the base ntpd, you should be able to just use 'server 127.127.1.0' to make it trust (and not alter) the base system time. Note that this openntpd will not have access to the stratum information from the main ntpd but will have a fixed value and may need to be adjusted using a 'fudge' command (or equivalent). I'd be interested in knowing why you chose this approach rather than just syncing clients to the [open]ntpd instance in the host machine. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpxEy6X1tjEd.pgp Description: PGP signature
Re: timestamping for kernel messages (like Solaris and Linux)
On Sun, Jun 8, 2008 at 2:59 PM, Peter Jeremy [EMAIL PROTECTED] wrote: On 2008-Jun-08 10:24:53 +0300, Niki Denev [EMAIL PROTECTED] wrote: Has anyone thought about implementing an option to prepend all kernel console messages with timestamps, like Linux and Solaris do? The only time I've seen Solaris do this is when the console message is syslog'd - which FreeBSD also does. Is it just a matter of hacking up the kernel printf() implementation? Pretty much. Any possible caveats? The kernel works in UTC only and has only a very restricted ability to translate between epoch seconds and a human-readable date/time (it's currently only used to talk to the RTC). I'm looking at a Linux machine right now, and it looks like they use the time since boot (actually uptime) for the timestamps. Anyways, does this sound like something that FreeBSD should have? It could be useful in some situations, like embedded applications without running syslog, full /var partitions, etc. -- Niki ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd jail problem
On 20080608 19:56:03, Eugene Grosbein wrote: On Sun, Jun 08, 2008 at 12:25:00PM +0100, [EMAIL PROTECTED] wrote: The problem is that the ntpd in the jail seems to believe that the host clock is out of sync (from what I can gather), even though it isn't. That's because ntpd won't blindly assume that your host has right time. If you make client/server connection between your two copies of NTP daemons, the server insures the client that time is right and client will serve your network just right. Eugene Grosbein That would explain it... I'll make the adjustment now and see what happens. Thanks. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd jail problem
On 20080608 22:10:27, Peter Jeremy wrote: On 2008-Jun-08 11:32:54 +0100, [EMAIL PROTECTED] wrote: I'm running an openntpd instance on the host machine, which syncs the clock from the pool at pool.ntp.org. From the log output, ntpd claims to be synced and the time does seem to be correct. I'm then running another openntpd in a jail which doesn't set the time, just serves it to clients. I've never used openntpd but for the base ntpd, you should be able to just use 'server 127.127.1.0' to make it trust (and not alter) the base system time. Note that this openntpd will not have access to the stratum information from the main ntpd but will have a fixed value and may need to be adjusted using a 'fudge' command (or equivalent). Ok. Right. I'd be interested in knowing why you chose this approach rather than just syncing clients to the [open]ntpd instance in the host machine. Just basic paranoia really. Nothing on the host is network-visible, all the services are in jails. Thanks for the information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd jail problem
On Sun, Jun 08, 2008 at 12:25:00PM +0100, [EMAIL PROTECTED] wrote: The problem is that the ntpd in the jail seems to believe that the host clock is out of sync (from what I can gather), even though it isn't. That's because ntpd won't blindly assume that your host has right time. If you make client/server connection between your two copies of NTP daemons, the server insures the client that time is right and client will serve your network just right. Eugene Grosbein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: number of /dev/usb nodes
On Sat, Jun 07, 2008 at 01:18:41PM -0400, Chuck Robey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I can't seem to find how many /dev/usbN bus devices there can be. I'm writing some code that scans them all looking for anything that has my device, but I while I know to start at usb0, just how high do I go? There seem to be 128 device minors, is that the number? (from dev/usb/usb.h) There shouldn't be a limit anymore. I can't see any definition of 128 in usb.h that limits the number of busses. The major/minor differenciation is long time ago. You must be looking at old code. -- B.Walter [EMAIL PROTECTED] http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: number of /dev/usb nodes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernd Walter wrote: On Sat, Jun 07, 2008 at 01:18:41PM -0400, Chuck Robey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I can't seem to find how many /dev/usbN bus devices there can be. I'm writing some code that scans them all looking for anything that has my device, but I while I know to start at usb0, just how high do I go? There seem to be 128 device minors, is that the number? (from dev/usb/usb.h) There shouldn't be a limit anymore. I can't see any definition of 128 in usb.h that limits the number of busses. The major/minor differenciation is long time ago. You must be looking at old code. I was trying to find a good way to do scanning, whjen I create the files like /dev/usb0, how far to go in my loop? Does the lowest available device always get created? That would imply that as soon as I began to get No such device errors, I could stop iterating. If the rules for picking device filenames are pretty loose, then I could (for instance) stop scanning, say, 4 numbers past the first No such device returnee. Any idea on this? I didn't see this i nthe code, but I just need some sane limit on what filenames to scan about in. I look for item info, and if the usb vendor and prodict look friendly, I just snag the filename involved, and use that. Like, a scan of the usb1 bus might yield me a uhid0 which might be my meat, whereupon I coulld drop the usb1 open, and replace it with a uhid0 open. There's more than 1 place that my devices could show, depending on the user's kernel devices. I just want to have some sane limit on how many usb buses I open for my scanning. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIS+m6z62J6PPcoOkRAgBoAJ0XYYfUat/fJDChSybpNtFzCwUr9ACdGxNf UoCeHzvriXfQ+bj5LDxE8vA= =sTcT -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kerberized CIFS client?
smbclient (and other samba utilities) do not refer to krb5.conf when figuring out the kerberos realm. you will have to put to your krb5.conf on both client and server: [domain_realms] cifs.example.com = realm.example.com Otherwise it will just try to use example.com as the realm. On 6/6/08, Derek Taylor [EMAIL PROTECTED] wrote: On Tue, 03 Jun 2008, Atte Peltomki wrote: You will have to adjust your krb5.conf to map a given domain or hostname to a kerberos realm, if you are doing cross-realm authentication. See MIT kerberos admin guide for details. I'm pretty sure it's set up ok. I can use smbclient -k just fine: $ kinit [EMAIL PROTECTED]'s Password: kinit: NOTICE: ticket renewable lifetime is 1 week $ klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: [EMAIL PROTECTED] Issued Expires Principal Jun 6 15:08:47 Jun 7 01:08:47 krbtgt/[EMAIL PROTECTED] $ smbclient -k -U det135 //cifs.example.com/dir1 OS=[Unix] Server=[Samba 3.0.30] smb: \ ls . D0 Thu Feb 14 14:46:42 2008 .. D0 Fri Jun 6 10:16:29 2008 [ other files/directories here ] smb: \ quit $ cd ~/mount/smbbeta.pass.psu.edu/pass $ ls ls: .: Permission denied $ klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: [EMAIL PROTECTED] Issued Expires Principal Jun 6 15:08:47 Jun 7 01:08:47 krbtgt/[EMAIL PROTECTED] Jun 6 15:09:17 Jun 7 01:08:47 cifs/[EMAIL PROTECTED] $ -Derek. On 6/3/08, Derek Taylor [EMAIL PROTECTED] wrote: On Tue, 03 Jun 2008, Harti Brandt wrote: On Tue, 3 Jun 2008, Derek Taylor wrote: DTOn Thu, 22 May 2008, Hartmut Brandt wrote: DTDerek Taylor wrote: DT This question was previously posed of the freebsd-questions list, but DT with no response for a week, I'd like to try my luck here. If there's DT any more information I should include, please speak up: I would be glad DT to oblige. DT DT I would like to use smb/cifs with kerberos auth, but mount_smbfs doesn't DT seem to support this. DT DT Is anyone aware of an alternate means of performing a mount via smb/cifs DT or any patches to provide such functionality? DT DT I already have smbclient working with -k, but I am also interested in a DT mount. DT DTTry smbnetfs from ports. It's fuse based and seems to work very nice. If DTyou have a large amount of shares floating in your network you want to DTrestrict it to mount only the needed shares via the config file. DTOtherwise it will mount what it can find... DT DTIt plays nicely with kerberors. When your ticket expires you immediately DTloose access; when you renew it you gain access again. All without the DTneed to unmount/mount. Just call smbnetfs once you have your ticket. You DTmay even do this from your .profile. DT DTharti DT DTSorry for not replying sooner. DT DTInitial tests here are promising (I can see some mount paths being DTexported from the server), but it's not fully working (I don't see all DTof the mount paths that *should* be exported and I get permission denied DTerrors). My thoughts are leaning towards an issue in negotiating auth DTwith the server -- perhaps my krb creds aren't being used? You can test this easily: if your ticket expires you get permission denied errors when you try to look into the mounted directories. As soon as you renew the ticket you get access again. All without restarting smbnetfs. harti I replaced all server names below with example.com (and derivatives) where appropriate: From my FreeBSD machine, using smbnetfs: $ klist klist: No ticket file: /tmp/krb5cc_1001 $ kinit det135 [EMAIL PROTECTED]'s Password: kinit: NOTICE: ticket renewable lifetime is 1 week $ klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: [EMAIL PROTECTED] Issued Expires Principal Jun 3 11:51:20 Jun 3 21:51:04 krbtgt/[EMAIL PROTECTED] $ cd ~/mount/cifs.example.com/dir1 $ ls ls: .: Permission denied $ cd .. $ ls dir1 dir2 $ klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: [EMAIL PROTECTED] Issued Expires Principal Jun 3 11:51:20 Jun 3 21:51:04 krbtgt/[EMAIL PROTECTED] From my Mac, using (from Finder) Go - Connect to Server - cifs://cifs.example.com/dir1 $ klist klist: No Kerberos 5 tickets in credentials cache $ kinit det135 Please enter the password for [EMAIL PROTECTED]: $ klist Kerberos 5 ticket cache: 'API:Initial default ccache' Default principal: [EMAIL PROTECTED] Valid Starting ExpiresService Principal 06/03/08 11:59:41 06/03/08 21:59:41 krbtgt/[EMAIL PROTECTED] renew until 06/10/08 11:59:41 Here I mount via Finder before continuing with the commands below $ cd /Volumes/dir1/ $ ls subdir1 subdir2 file1 file2 $ klist Kerberos 5 ticket cache: 'API:Initial default ccache' Default principal: [EMAIL PROTECTED] Valid Starting Expires
Re: number of /dev/usb nodes
On Sun, Jun 08, 2008 at 10:16:26AM -0400, Chuck Robey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernd Walter wrote: On Sat, Jun 07, 2008 at 01:18:41PM -0400, Chuck Robey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I can't seem to find how many /dev/usbN bus devices there can be. I'm writing some code that scans them all looking for anything that has my device, but I while I know to start at usb0, just how high do I go? There seem to be 128 device minors, is that the number? (from dev/usb/usb.h) There shouldn't be a limit anymore. I can't see any definition of 128 in usb.h that limits the number of busses. The major/minor differenciation is long time ago. You must be looking at old code. I was trying to find a good way to do scanning, whjen I create the files like /dev/usb0, how far to go in my loop? Does the lowest available device always get created? That would imply that as soon as I began to get No such device errors, I could stop iterating. If the rules for picking device filenames are pretty loose, then I could (for instance) stop scanning, say, 4 numbers past the first No such device returnee. This wouldn't work if a USB controller is remove - e.g. a pulling a cardbus card. Any idea on this? I didn't see this i nthe code, but I just need some sane limit on what filenames to scan about in. I look for item info, and if the usb vendor and prodict look friendly, I just snag the filename involved, and use that. Like, a scan of the usb1 bus might yield me a uhid0 which might be my meat, whereupon I coulld drop the usb1 open, and replace it with a uhid0 open. There's more than 1 place that my devices could show, depending on the user's kernel devices. I just want to have some sane limit on how many usb buses I open for my scanning. I never had to deal with this, since writing a USB driver is simple and as a driver you get informed for each new device. No need to scan the busses yourself. But I would say that the most reliable way is to just scan /dev/ for usb... -- B.Walter [EMAIL PROTECTED] http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: number of /dev/usb nodes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernd Walter wrote: On Sun, Jun 08, 2008 at 10:16:26AM -0400, Chuck Robey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernd Walter wrote: On Sat, Jun 07, 2008 at 01:18:41PM -0400, Chuck Robey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I can't seem to find how many /dev/usbN bus devices there can be. I'm writing some code that scans them all looking for anything that has my device, but I while I know to start at usb0, just how high do I go? There seem to be 128 device minors, is that the number? (from dev/usb/usb.h) There shouldn't be a limit anymore. I can't see any definition of 128 in usb.h that limits the number of busses. The major/minor differenciation is long time ago. You must be looking at old code. I was trying to find a good way to do scanning, whjen I create the files like /dev/usb0, how far to go in my loop? Does the lowest available device always get created? That would imply that as soon as I began to get No such device errors, I could stop iterating. If the rules for picking device filenames are pretty loose, then I could (for instance) stop scanning, say, 4 numbers past the first No such device returnee. This wouldn't work if a USB controller is remove - e.g. a pulling a cardbus card. Any idea on this? I didn't see this i nthe code, but I just need some sane limit on what filenames to scan about in. I look for item info, and if the usb vendor and prodict look friendly, I just snag the filename involved, and use that. Like, a scan of the usb1 bus might yield me a uhid0 which might be my meat, whereupon I coulld drop the usb1 open, and replace it with a uhid0 open. There's more than 1 place that my devices could show, depending on the user's kernel devices. I just want to have some sane limit on how many usb buses I open for my scanning. I never had to deal with this, since writing a USB driver is simple and as a driver you get informed for each new device. No need to scan the busses yourself. But I would say that the most reliable way is to just scan /dev/ for usb... Assumptions I never said I was writing a FreeBSD driver... I am writing what Xorg calls an input driver (Xinput). I could rely on the config file, I thought I would try to use a scan in case I can't find the dev the user passes me. I see no reason to write a FreeBSD driver when I can do everything I need within the uhid driver (at least so far, in my test prog). There IS one caveat: I've posted to the FreeBSD-USB list that there is a part of the libusbhid that I can't yet get working. Writing a FreeBSD driver would allow me to use other available data marshalling code, like what's in the ums driver. If I can't interest anyone to comment about the libusbhid, I might be forced down that path, but I don't want to. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFITA5rz62J6PPcoOkRArTGAJ938MKH9L1HRuIpaH3QCy38huJwkQCfUCeF dE0dyEG+GZUMhi8fAIXNfRk= =ddvg -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AMD Geode LX crypto accelerator (glxsb)
Le Sun, 8 Jun 2008 13:58:46 +0200, Patrick Lamaiziere [EMAIL PROTECTED] a écrit : Thanks. I think it is ok for a review and test, i added the RNG stuff since the last time and a manual page 'glxsb.4' http://user.lamaiziere.net/patrick/glxsb.c http://user.lamaiziere.net/patrick/glxsb.tar.gz (all the module) I think I shall add software HMAC algorithms, like the driver padlock(4) and the latest version of glxsb on OpenBSD. To be able to work with IPsec. Anyway comments are still welcome. Regards. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AMD Geode LX crypto accelerator (glxsb)
Le Sun, 8 Jun 2008 19:26:49 +0200, Patrick Lamaizière [EMAIL PROTECTED] a écrit : http://user.lamaiziere.net/patrick/glxsb.c http://user.lamaiziere.net/patrick/glxsb.tar.gz (all the module) All my apologies : this is not the good version :-( I've made a 'tar xzf' instead a 'tar czf' and i've lost all my work since saturday. et merde. Going to sleep. Sorry... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Debugging rtld
Hi Kostik, hackers,
On Sat, May 17, 2008 at 08:46:37PM +0300, Kostik Belousov wrote:
On Sat, May 17, 2008 at 07:35:25PM +0200, Jeremie Le Hen wrote:
Hi,
On Sat, May 17, 2008 at 01:26:53PM +0300, Kostik Belousov wrote:
On Sat, May 17, 2008 at 11:17:40AM +0200, Jeremie Le Hen wrote:
I tried to compile my source tree with -fstack-protector-all, and it
happens that rtld breaks with this: once the new rtld is installed every
single problem coredumps. I tried to compile rtld-elf without SSP, but
it didn't solve the problem. Then I had to compile libc_pic.a without
SSP and it worked, but I don't understand the root of the problem.
So I want to use the generated coredump for post-mortem analysis with
gdb.
I compiled world with DEBUG_FLAGS=-g. But GDB gives me a backtrace so
long that it can't be real. Moreoever it doesn't seem to bring in the
required symbols. I'm a GDB novice, so I'd like some help.
chroot === libexec/rtld-elf (install)
chroot chflags noschg /usr/libexec/ld-elf.so.1
chroot install -s -o root -g wheel -m 555 -C -b -fschg -S ld-elf.so.1
/libexec
chroot install -o root -g wheel -m 444 rtld.1.gz /usr/share/man/man1
chroot *** Signal 11
chroot
chroot jarjarbinks# cd /root; ls
chroot Segmentation fault
host jarjarbinks:145# ls -l /space/chroot/root/ls.core
host -rw--- 1 root wheel 184320 May 17 10:19
/space/chroot/root/ls.core
host jarjarbinks:149# gdb -c /space/chroot/root/ls.core -e
/space/chroot/bin/ls
host GNU gdb 6.1.1 [FreeBSD]
host [...]
host This GDB was configured as i386-marcel-freebsd.
host Core was generated by `ls'.
host Program terminated with signal 11, Segmentation fault.
host #0 0x280583e4 in ?? ()
host (gdb) bt
host #0 0x280583e4 in ?? ()
host #1 0x in ?? ()
host #2 0x in ?? ()
host #3 0x in ?? ()
host #4 0x in ?? ()
host #5 0x in ?? ()
host #6 0x in ?? ()
host #7 0x in ?? ()
host #8 0x in ?? ()
host #9 0x in ?? ()
host #10 0x in ?? ()
host #11 0x in ?? ()
host #12 0x1000 in ?? ()
host [...]
host #359 0x73763a68 in ?? ()
host #360 0x5b455c3d in ?? ()
host [...]
host #855 0x in ?? ()
host [...]
Any hint on how to proceed would be welcome.
I usually add the CFLAGS+=-g to the rtld-elf/Makefile. Also, you do not
need to bring down the whole host by the broken ld.so.1. Do not install
it at all, and specify the path to the rtld by the --dynamic-linker
switch,
see into ld.
Hmm, info
Thank you for this tip. However the backtrace is still unusable.
I've recompiled libc_pic.a with -g, then rtld-elf with -g and finally
/bin/ls with you tip and -g.
I'm really brought to a standstill here.
Looks like you have a stack corruption, that is reasonable given the
matters you touching. The easiest, althought somewhat time-consuming way
of searching the point where the things break is to insert some break
into the code of the rtld, int3 may be good, and moving it forward
until you start hitting the breakage instead of the breakpoint.
I've naively added
asm(int3;);
to the rtld-elf source, but I definitely can't debug rtld as an usual
program. According to the rtld source, I'd say GDB needs some
cooperation from rtld itself. Chicken and egg problem here.
I've tested various methods to achieve debugging, such as explicitely
use the add-symbol-file GDB command to load ld-elf.so.1 at its entry
point. Given that the backtrace is unusable, I've tried to dump the
stack starting from $ebp, and I think I could identify one or two
pointers into the text, but GDB says there is nothing to disassemble at
those address.
I don't have enough {linker,loader,gdb}-fu to go on this way.
FWIW, I succeded to understand where is the segmentation fault by
dichotomy placing assert(NULL) in the code. Interestingly, when libc
is compiled *with* -fstack-protector-all (but sys/stack_protector.c),
rtld is compiled *without* stack protection, the call to mmap(2) in
libexec/rtld-elf/i386/reloc.c:reloc_non_plt() triggers a SIGSEGV.
Any hint from a rtld guru would be welcome...
Thanks.
--
Jeremie Le Hen
jeremie at le-hen dot org ttz at chchile dot org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Impact of having a large number of open file descriptors
Ivan Voras wrote: Hi, Im thinking again of the old idea of implementing poor man's file replication system using kqueue to monitor changes on files. I made something with the idea, available here: http://ivoras.sharanet.org/stuff/adfs.tgz It was hacked up over the weekend and probably contains many bugs, and the whole idea has scalability problems because of the need to have all those files open. I think it's OK for what I want to do, YMMV. If there's interest I'll keep updating it. signature.asc Description: OpenPGP digital signature
