Re: [PATCH] install -s -s(trip-me-harder)
On Mon, Aug 20, 2001 at 12:16:54AM -0700, Kris Kennaway wrote:
> + execlp("strip", "strip", "-s", "-R", ".comment",
> +"-R", ".note", "-N", "gcc2_compiled",
Getting rid of .note[.ABI-tag] will interfere with ELF branding.
--
-- David ([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Recommendation for minor KVM adjustments for the release
Julian Elischer wrote: > > Are you actually going ahead with the PAE support? > > > > Will this be a compile-time option, so that it can be > > turned off? > > > > I considered doing the same, about 4 months ago but it's not > > like I could use the additional memory for mbufs, sockets, or > > other useful kernel structures, so I bailed on completing it. > > If you have the correct hardware, it can be used for > mbufs, bufs, or normal user memeory.. That would be MIPS R4400, AMD "Sledgehammer", UltraSPARC64, or Itanium hardware? 8-). I don't see how the hardware you pick -- unless it's 64 bit hardware -- is going to make it usable as mbuf targets from userspace, unless you have a big change in mind for the uiomove code that you aren't telling us about, so that the copyin can be bounced properly... just having 64 bit PCI cards that can access the memory directly via DMA isn't enough, I think. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Any ATAPI gurus out there?
It seems Jim Bryant wrote: (please wrap lines at max 70 chars) > My friend, whom I am trying to teach unix [4.3-stable] was having some > problems on his secondary ATAPI bus. A Creative CD-ROM was > the master, a HP burner was the slave. > > The CD-ROM was having data dropouts, and was due to old age, no doubt. > > Under Winblowz, the HP burner would only get 4x when it was able to burn. > it's a 12x/8x/32x drive. > > Under BSD, the CD-ROM would be usable, but would be prone to dropouts. > > Under BSD, the HP burner came up with sense errors on boot, prior to a > proper probe reply. It would hang for the duration of several timeouts > at the point before it got the probe. > > Under BSD, the HP burner would cause a terminal wait state upon any access > [such as a mount request, or a burncd command]. Red-button time... > > This last Friday, he bought a new CD-ROM, and a new burner, as we both > thought both drives had issues. > > He put his new drives in his box. Everything works now, under Winblowz > AND BSD. > > I put the the HP burner in MY box, and voila! Nothing is wrong with it... > > Questions: > > 1). Can a flaky ATAPI "Master" cause a good ATAPI "Slave" to APPEAR > [however incorrectly] that the "Slave" has a problem? Yes. > 2). If #1 is true, then, why? Crappy firmware, non-std or broken HW, those two reasons hold for both ATAPI and SCSI -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [PATCH] install -s -s(trip-me-harder)
On Wed, Aug 22, 2001 at 12:42:50AM -0700, David O'Brien wrote:
> On Mon, Aug 20, 2001 at 12:16:54AM -0700, Kris Kennaway wrote:
> > + execlp("strip", "strip", "-s", "-R", ".comment",
> > + "-R", ".note", "-N", "gcc2_compiled",
>
> Getting rid of .note[.ABI-tag] will interfere with ELF branding.
How will it do so?
Kris
PGP signature
problems problems ...
Respectiful Gentlemans, I have next problem : I have Siemens Gigaset 3070 ISDN External USB modem. My box is running FreeBSD 4.2 on Intel Pentium III. When I boot the OS, it detects it on /dev/ugen0 ... When I put ugen0 in /etc/ppp/ppp.conf and run it, my OS reboots with kernel trap error. One my friend told me that it must not be on ugen0 since it means general, and it means that OS didn't detect it. It doesn't matter if it shows vendor info. (For example I run usbd, than I plug in and out my modem, and kernel reports that Siemens Gigaset 3070 has been unpluged or pluged on /dev/ugen0 ... Please, can you help me ? I don't know, maybe I need some kernel patch or somthin' like that. Thanks p.s. I also have problem to set up Epson EPL-5800L Laserjet printer. It detects priter, tip printer says connected but then it freeze term. I would be also thankful if you could help me about it, or ISDN Thank You very much. Sinecerly Milos Marceta _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tunable support for ata interrupt sharing
On Tue, Aug 21, 2001 at 09:41:50PM +0200, Søren Schmidt wrote: > It seems Brooks Davis wrote: > > Attached it a patch to make sharing of the main ata control interrupts > > dependent on a tunable, hw.ata.shared_irqs. This is required for my new > > HP Omnibook 500 to use the CMD 648 in the expansion base to work as it > > appears hardwired to interrupt 15 (which is fairly logical given that > > there is no where to attach devices to the secondary channel.) If this > > looks ok and you don't have time to deal with it, I'd be happy to commit > > it myself. > > I have just today committed always sharing all irq's to -current, > the consensus is that if the BIOS allows sharing it should work. > This makes sense, the MB maker is the only one that knows if > this is working, if they blow it in thier BIOS, well Would this be good to have in 4.4? If Brooks's laptop needs it, it would be nice to have 4.4 run on that, too.. G'luck, Peter -- If you think this sentence is confusing, then change one pig. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tunable support for ata interrupt sharing
It seems Peter Pentchev wrote: > > I have just today committed always sharing all irq's to -current, > > the consensus is that if the BIOS allows sharing it should work. > > This makes sense, the MB maker is the only one that knows if > > this is working, if they blow it in thier BIOS, well > > Would this be good to have in 4.4? If Brooks's laptop needs it, > it would be nice to have 4.4 run on that, too.. Sure it would, and there are lots of other ATA related things from current that I need to MFC, but time is limitted here currently, and I dont know exactly how close 4.4 is to closure. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to make bootable disk boot images with vn device?
On Tue, Aug 21, 2001 at 09:41:34PM +0200, Andre Oppermann wrote: > # dd if=/dev/zero of=mfsroot bs=1k count=25000 > # vnconfig -e -s labels vn0 mfsroot > # disklabel -r -w vn0 auto > # newfs /dev/vn0c > # mount and cp blabla You need to disklabel -B vn0 to install boot blocks. And you should not use partition c which is not of type 4.2BSD. Do some scripting together with disklabel to add some partitions. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
VM statistics per process?
Hi, As a part of a little project studying the perfomance of different malloc(3) implementations I need to gather certain VM statistics. The problem is that the required data are only available globally, and I need it for a given process. Some of the values I am interested in are available from the struct vmspace, for example p->p_vmspace->vm_rssize will provide me with the number of resident pages. But I'd like to be able to also get the number of active and inactive pages belonging to a particular process. What should I do in order to get this information? =Anton. -- May the tuna salad be with you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [PATCH] install -s -s(trip-me-harder)
On Wed, Aug 22, 2001 at 01:40:07AM -0700, Kris Kennaway wrote: > > Getting rid of .note[.ABI-tag] will interfere with ELF branding. > > How will it do so? This is the ELF ABI standard-approved way of doing ELF branding: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 2] .note.ABI-tag NOTE08048110 000110 18 00 A 0 0 4 with the source of this (for FreeBSD native binaries) being src/lib/csu/common/crtbrand.c. See http://www.netbsd.org/Documentation/kernel/elf-notes.html for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.4-RC NFS panic
Warner Losh writes: > After talking with Ian Dowse, I think that we've hammered out what may > cause this. Basically, the problem is I'm afraid your patch didn't fix the problem on my laptop. It certainly changed the behaviour and the system doesn't crash any more, but I'm almost unable to use the net. A ping to my server yelds the IP address to be resolved but no ping activity is carried on. Even worse, now the pcm driver fails to detect any sound device. 8-| Regarding the warm boot, I can confirm the same behavior (already pointed out in another mail of mine). My impression it's not a PCCARD issue as it happens even with no card inserted. The system looks as frozen but if I press the "Pause" key and then type something and then press again the "Pause" key I get the the cursor moved of the amount of typing I did. No echo though. -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Ringtones and Logos
Title: newlogo Personalise You Nokia with these great Logos!!! Bitch 21692 Hope 21716 Sex Bomb 21740 Dragon 1 20110 Love Beer 20203 fcuk 21951 Loving Eyes 20142 Trust No One 20409 Rizla 21256 The Simpsons 20399 Call Now ON "0906 400 2144" Quote the 5 digit number and your logo / Ringtone will be sent immediately!! For many more please visit www.mobiledirect.uk.com Get Your Mobile Rocking with these great Ringtones!!! Description Code Listen Baha Men - Who let the dogs out 10138 Bob the Builder - Can We Fix It? 11107 Shaggy Feat Rikrok - It Wasn't Me 11762 The Simpsons 10009 James Bond Theme 1 Star Wars Imperial March 10085 Please note: the call costs £1.50 per minute and the average call length is 2 minutes. Please ask bill payer for permission. Calls from mobiles cost more depending on service. The following phones receive both logos and tones - Nokia 3210, 3310,6090, 6110, 6130, 6150, 6210, 6250, 7110, 8110i, 8210, 8810, 8850, 9000i and 9110. Nokia models: 402 and 51XX receive logos only. Motorola T250, T2288, V50, V100, V2288, V8088 receive ring tones only. Please make sure that your mobile is listed here before ordering. Mobile Direct reserves the right not to refund your money if your phone is not listed here. If you experience any problem, call Customer Service on 0800 015 1175. Orders normally sent immediately, depending on network. For hundreds more ringtones and logos just click on to www.mobiledirect.uk.com - pass this on to a friend or stick it on the notice board Important Notice: If you do not wish to receive any more emails, please mail us on [EMAIL PROTECTED] and click "send." and your address will removed
Re: VM statistics per process?
* Anton Berezin <[EMAIL PROTECTED]> [010822 10:40] wrote: > Hi, > > As a part of a little project studying the perfomance of different > malloc(3) implementations I need to gather certain VM statistics. > > The problem is that the required data are only available globally, and I > need it for a given process. > > Some of the values I am interested in are available from the struct > vmspace, for example > >p->p_vmspace->vm_rssize > > will provide me with the number of resident pages. But I'd like to be > able to also get the number of active and inactive pages belonging to a > particular process. What should I do in order to get this information? getrusage(2) -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM statistics per process?
On Wed, Aug 22, 2001 at 12:39:26PM -0500, Alfred Perlstein wrote: > * Anton Berezin <[EMAIL PROTECTED]> [010822 10:40] wrote: > > The problem is that the required data are only available globally, > > and I need it for a given process. > > > > Some of the values I am interested in are available from the struct > > vmspace, for example > > > >p->p_vmspace->vm_rssize > > > > will provide me with the number of resident pages. But I'd like to > > be able to also get the number of active and inactive pages > > belonging to a particular process. What should I do in order to get > > this information? > getrusage(2) That's not quite it - it does not provide the statistics of what number of pages is currently on PQ_ACTIVE/PQ_INACTIVE queues, and I think I need that number. I was thinking of copying pmap_pid_dump() from sys/i386/i386/pmap.c and counting the pages belonging to different queues. Is this a feasible approach? Cheers, =Anton. -- May the tuna salad be with you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tunable support for ata interrupt sharing
On Tue, Aug 21, 2001 at 09:41:50PM +0200, Søren Schmidt wrote: > I have just today committed always sharing all irq's to -current, > the consensus is that if the BIOS allows sharing it should work. > This makes sense, the MB maker is the only one that knows if > this is working, if they blow it in thier BIOS, well Cool, I've updated and the new code works. Talk about timeing. ;-) Thanks, Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
Re: VM statistics per process?
* Anton Berezin <[EMAIL PROTECTED]> [010822 12:47] wrote: > On Wed, Aug 22, 2001 at 12:39:26PM -0500, Alfred Perlstein wrote: > > * Anton Berezin <[EMAIL PROTECTED]> [010822 10:40] wrote: > > > > The problem is that the required data are only available globally, > > > and I need it for a given process. > > > > > > Some of the values I am interested in are available from the struct > > > vmspace, for example > > > > > >p->p_vmspace->vm_rssize > > > > > > will provide me with the number of resident pages. But I'd like to > > > be able to also get the number of active and inactive pages > > > belonging to a particular process. What should I do in order to get > > > this information? > > > getrusage(2) > > That's not quite it - it does not provide the statistics of what number > of pages is currently on PQ_ACTIVE/PQ_INACTIVE queues, and I think I > need that number. Why do you need this? > > I was thinking of copying pmap_pid_dump() from sys/i386/i386/pmap.c and > counting the pages belonging to different queues. Is this a feasible > approach? It may be, I'm not sure how the structures are orginized, it may be an expensive operation to calculate this, but I'm not sure. -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
vmware under freebsd-4.3
i can get vmware to start, but it seems to be having emotional problems
getting networking up and running. it gets as far as finding the vmnet
device, but ends up sending an unsupported ioctl:
linux: 'ioctl' fd=22, cmd=8940 ('\M^I',64) not implemented
if i turn networking off, vmware works fine (but is not entirely useful
for my purposes).
- j
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: VM statistics per process?
On Wed, Aug 22, 2001 at 01:24:20PM -0500, Alfred Perlstein wrote:
> * Anton Berezin <[EMAIL PROTECTED]> [010822 12:47] wrote:
> > On Wed, Aug 22, 2001 at 12:39:26PM -0500, Alfred Perlstein wrote:
> > > getrusage(2)
> > That's not quite it - it does not provide the statistics of what
> > number of pages is currently on PQ_ACTIVE/PQ_INACTIVE queues, and I
> > think I need that number.
> Why do you need this?
I am trying to measure the quality of different malloc(3)
implementations with regard to the active set size. I need the
PQ_ACTIVE number on a theory that, given a light system load and a lots
of RAM, a run of a process with a good malloc implementation will have
less active pages than the identical run of the same process with a bad
malloc implementation. Consequently, such `good' (by this criterion)
malloc(3) will be also good, or even better, in case of a heavy system
load.
I know that phkmalloc is supposed to be good in this regard, but I am
trying to see whether there are better ones, especially for specific
programs that are known to be rather harsh memory users (perl).
> > I was thinking of copying pmap_pid_dump() from sys/i386/i386/pmap.c
> > and counting the pages belonging to different queues. Is this a
> > feasible approach?
> It may be, I'm not sure how the structures are orginized, it may be an
> expensive operation to calculate this, but I'm not sure.
I am sure it is not an expensive operation to *calculate*, since
pmap_pid_dump() deals with vm_page_t structures which have a queue field
- just what I need. What I worry about is that the actual *traversal*
might be expensive. Worse, pmap_pid_dump() is undocumented, and I don't
understand what for(i=0;i<1024;i++) for(j=0;j<1024;j++) {} loop there is
supposed to do... :-(
I'd appreciate if someone would explain this to me.
=Anton.
--
May the tuna salad be with you.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
clock synchronization quality via NTP ?
Hello, I know FreeBSD can be used with great success for timing solutions (at least two core members do it ?). has someone some performance data of the quality of system clock synchronization, while using NTPd with a GPS reveiver and a hard 1PPS signal ? More precisely : is it reasonable to hope having a system clock not farther from the GPS clock by more than 50 micro-seconds ? -- Thierry Herbelot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
struct module
Hi hackers, First of all thank to all people who help me, my KLD module is almost finished. I have however a small question : why the module structure is definied in /sys/kern/kern_module.c and not in ? I'm sure this question has a stupid answer.. ;-) Bye, and thanks in advance for your answer. -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
pci_get_devid()
I'm doing some PCI related code and keep running into the function/method pci_get_devid() in FreeBSD source files (like pcisupport.c). A couple of us have looked for this function in our systems and can't seem to find it. Can anyone tell me where I can find the source for pci_get_devid()? By the way, I'm trying to write a little application that gives a detailed enumeration of the PCI bus using BIOS calls. Thanks in advance. D. Johnson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pci_get_devid()
Take a look at PCI_ACCESSOR in "pcivar.h" Good Luck Weiguang >From: djohnson <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: pci_get_devid() >Date: Wed, 22 Aug 2001 14:22:52 -0600 > >I'm doing some PCI related code and keep running into the >function/method pci_get_devid() in FreeBSD source files (like >pcisupport.c). A couple of us have looked for this function in our >systems and can't seem to find it. Can anyone tell me where I can find >the source for pci_get_devid()? By the way, I'm trying to write a >little application that gives a detailed enumeration of the PCI bus >using BIOS calls. Thanks in advance. > >D. Johnson > > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-hackers" in the body of the message _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clock synchronization quality via NTP ?
On Wed, Aug 22, 2001 at 09:47:34PM +0200, Thierry Herbelot wrote: > Hello, > > I know FreeBSD can be used with great success for timing solutions (at > least two core members do it ?). > > has someone some performance data of the quality of system clock > synchronization, while using NTPd with a GPS reveiver and a hard 1PPS > signal ? > > More precisely : is it reasonable to hope having a system clock not > farther from the GPS clock by more than 50 micro-seconds ? Talk to Poul-Henning, he is the clock/time expert ([EMAIL PROTECTED]). Poul used to have some nice Web pages around on this subject but they were killed in a disk crash IIRC. -- | / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
pci_get_devid()
A list member refered me to PCI_ACCESSOR in pcivar.h for the solution. Thanks W.S. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ports/lang/gcc{-devel,30}
Dear hackers Can somebody shed a light on the two ports ? At first sight, they seem very similar. Are there plans to update them ? They both are based on a snapshot dated April 30th, 2001. Any hints are appreciated. Ciao, derweil, -- Carlo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [PATCH] install -s -s(trip-me-harder)
On Wed, Aug 22, 2001 at 09:26:44AM -0700, David O'Brien wrote: > On Wed, Aug 22, 2001 at 01:40:07AM -0700, Kris Kennaway wrote: > > > Getting rid of .note[.ABI-tag] will interfere with ELF branding. > > > > How will it do so? > > This is the ELF ABI standard-approved way of doing ELF branding: > > Section Headers: > [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al > [ 2] .note.ABI-tag NOTE08048110 000110 18 00 A 0 0 4 > > with the source of this (for FreeBSD native binaries) being > src/lib/csu/common/crtbrand.c. > > See http://www.netbsd.org/Documentation/kernel/elf-notes.html for more > information. Thanks, but my patch doesn't seem to touch .note.ABI-tag, only .note Kris PGP signature
Firewire driver available
I saw this on Freshmeat the other day: http://www.sfc.wide.ad.jp/DVTS/ Maybe someday it can be committed? Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ssh password cracker - now this *is* cool!
This gets an 'A' on my cool-o-meter. http://www.vnunet.com/News/1124839 -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh password cracker - now this *is* cool!
* Matt Dillon <[EMAIL PROTECTED]> [010822 18:30] wrote: > This gets an 'A' on my cool-o-meter. > > http://www.vnunet.com/News/1124839 Interesting, I guess one could work around it by periodically sending bogus empty packets in the middle of activity. -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh password cracker - now this *is* cool!
: :* Matt Dillon <[EMAIL PROTECTED]> [010822 18:30] wrote: :> This gets an 'A' on my cool-o-meter. :> :> http://www.vnunet.com/News/1124839 : :Interesting, I guess one could work around it by periodically :sending bogus empty packets in the middle of activity. : :-- :-Alfred Perlstein [[EMAIL PROTECTED]] Yah, and typing backspaces also ought to work. 12345bb45bb45678b8 -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh password cracker - now this *is* cool!
> > Yah, and typing backspaces also ought to work. 12345bb45bb45678b8 > How about some control-Q's? :-) Later Mark Hittinger Earthlink [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh password cracker - now this *is* cool!
On Wed, Aug 22, 2001 at 04:30:30PM -0700, Matt Dillon wrote: > http://www.vnunet.com/News/1124839 Several people on other mailing lists have pointed out that Nagle should make this much harder, although it's unclear how Nagle and ssh interact. So far that has resulted in a number of degenerating discussions of how things work. Of course, Nagle will not help between two machines on the same ethernet segment, but probably would make the process described in the paper much harder. All of this aruges for Kerberos or some other cryptographic system so once you're authenticated once there is little or no need to type additional passwords. -- Leo Bicknell - [EMAIL PROTECTED] Systems Engineer - Internetworking Engineer - CCIE 3440 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: ssh password cracker - now this *is* cool!
If memory serves me right, Leo Bicknell wrote: > On Wed, Aug 22, 2001 at 04:30:30PM -0700, Matt Dillon wrote: > > http://www.vnunet.com/News/1124839 > > Several people on other mailing lists have pointed out that Nagle > should make this much harder, although it's unclear how Nagle and > ssh interact. So far that has resulted in a number of degenerating > discussions of how things work. Of course, Nagle will not help > between two machines on the same ethernet segment, but probably > would make the process described in the paper much harder. Indeed. They also didn't discuss (or I didn't see it) the effects of queueing or jitter in the network on their scheme. This *is* pretty neat, although it is less of a password cracker than a scheme of narrowing down the space of possible passwords. > All of this aruges for Kerberos or some other cryptographic system > so once you're authenticated once there is little or no need to type > additional passwords. ssh-agent(1)/ssh-add(1) does all of its authentication locally, so my extremely naive reading is that it'd be immune to this particular type of attack, since human-typed passphrases never cross the network. Bruce. PGP signature
Re: Where to put new bus_dmamap_load_mbuf() code
> >My understanding is that you need a dmamap for every buffer that you want > >to map into bus space. > > You need one dmamap for each independantly manageable mapping. A > single mapping may result in a long list of segments, regardless > of whether you have a single KVA buffer or multiple KVA buffers > that might contribute to the mapping. Yes yes, I understand that. But that's only if you want to map a buffer that's larger than PAGE_SIZE bytes, like, say, a 64K buffer being sent to a disk controller. What I want to make sure everyone understands here is that I'm not typically dealing with buffers this large: instead I have lots of small buffers that are smaller than PAGE_SIZE bytes. A single mbuf alone is only 256 bytes, of which only a fraction is used for data. An mbuf cluster buffer is usually only 2048 bytes. Transmitted packets are typically fragmented across 2 or 3 mbufs: the first mbuf contains the header, and the other two contain data. (Or the first one contains part of the header, the second one contains additional header data, and the third contains data -- whatever.) At most I will have 1500 bytes of data to send, which is less than PAGE_SIZE, and that 1500 bytes will be fragmented across a bunch of smaller buffers that are also smaller than PAGE_SIZE. Therefore I will not have one dmamap with multiple segments: I will have a bunch of dmamaps with one segment each. (I can hear somebody out there saying: "What about jumbo frames?" Yes, with jumbo frames, I will have 9K buffers to deal with, and in that case, you could have one dmamap with several segments, and I am taking this into account with the updated code I've written.) > >So unless I'm mistaken, for each mbuf in an mbuf list, what we > >have to do is this: > > > >- create a bus_dmamap_t for the data area in the mbuf using > > bus_dmamap_create() > > Creating a dmamap, depending on the architecture, could be expensive. > You really want to create them in advance (or pool them), with at most > one dmamap per concurrent transaction you support in your driver. The only problem here is that I can't really predict how many transactions will be going at one time. I will have at least RX_DMA_RING maps (one for each mbuf in the RX DMA ring), and some fraction of TX_DMA_RING maps. I could have the TX DMA ring completely filled with packets waiting to be DMA'ed and transmitted, or I may have only one entry in the ring currently in use. So I guess I have to allocate RX_DMA_RING + TX_DMA_RING dmamaps in order to be safe. > >- do the physical to bus mapping with bus_dmamap_load() > > bus_dmamap_load() only understands how to map a single buffer. > You will have to pull pieces of bus_dmamap_load into a new > function (or create inlines for common bits) to do this > correctly. The algorithm goes something like this: > > foreach mbuf in the mbuf chain to load > /* >* Parse this contiguous piece of KVA into >* its bus space regions. >*/ > foreach "bus space" discontiguous region > if (too_many_segs) > return (error); > Add new S/G element > > With the added complications of deferring the mapping if we're > out of space, issuing the callback, etc. Why can't I just call bus_dmamap_load() multiple times, once for each mbuf in the mbuf list? (Note: for the record, an mbuf list usually contains one packet fragmented across multiple mbufs. An mbuf chain contains several mbuf lists, linked together via the m_nextpkt pointer in the header of the first mbuf in each list. By the time we get to the device driver, we always have mbuf lists only.) > Chances are you are going to use the map again soon, so destroying > it on every transaction is a waste. Ok, I spent some more time on this. I updated the code at: http://www.freebsd.org/~wpaul/busdma The changes are: - Tried to account for the case where an mbuf data region is larger than a page, i.e. when we have an mbuf with a 9K external buffer attached for use a jumbo ethernet frame. - Added routines to allocate a chunk of maps in a singly linked list, from which the other routines can grab them as needed. The driver attach routine calls bus_dmamap_list_init() with the max number of dmamaps that it will need, then the detach routine calls bus_dmamap_list_destroy() to nuke them when the driver is unloaded. The bus_dmamap_load_mbuf() routine uses the pre-allocated dmamaps from the list and bus_dmamap_list_destroy() returns them to the list when the transaction is completed. - Updated the modified if_sf driver to use the new code. Again, I've got this code running on the test box in the lab, so it's correct inasmuch as it compiles and runs, even though it may not be aesthetically pleasing. -Bill -- = -Bill Paul(510) 749-2329 | Senior En
Re: Where to put new bus_dmamap_load_mbuf() code
>> >My understanding is that you need a dmamap for every buffer that you want >> >to map into bus space. >> >> You need one dmamap for each independantly manageable mapping. A >> single mapping may result in a long list of segments, regardless >> of whether you have a single KVA buffer or multiple KVA buffers >> that might contribute to the mapping. > >Yes yes, I understand that. But that's only if you want to map >a buffer that's larger than PAGE_SIZE bytes, like, say, a 64K >buffer being sent to a disk controller. What I want to make sure >everyone understands here is that I'm not typically dealing with >buffers this large: instead I have lots of small buffers that are >smaller than PAGE_SIZE bytes. A single mbuf alone is only 256 >bytes, of which only a fraction is used for data. An mbuf cluster >buffer is usually only 2048 bytes. Transmitted packets are typically >fragmented across 2 or 3 mbufs: the first mbuf contains the header, >and the other two contain data. (Or the first one contains part >of the header, the second one contains additional header data, >and the third contains data -- whatever.) At most I will have 1500 >bytes of data to send, which is less than PAGE_SIZE, and that 1500 >bytes will be fragmented across a bunch of smaller buffers that >are also smaller than PAGE_SIZE. Therefore I will not have one >dmamap with multiple segments: I will have a bunch of dmamaps >with one segment each. The fact that the data is less than a page in size matters little to the bus dma concept. In other words, how is this packet presented to the hardware? Does it care that all of the component pieces are < PAGE_SIZE in length? Probably not. It just wants the list of address/length pairs that compose that packet and there is no reason that each chunk needs to have it own, and potentially expensive, dmamap. >> Creating a dmamap, depending on the architecture, could be expensive. >> You really want to create them in advance (or pool them), with at most >> one dmamap per concurrent transaction you support in your driver. > >The only problem here is that I can't really predict how many transactions >will be going at one time. I will have at least RX_DMA_RING maps (one for >each mbuf in the RX DMA ring), and some fraction of TX_DMA_RING maps. >I could have the TX DMA ring completely filled with packets waiting >to be DMA'ed and transmitted, or I may have only one entry in the ring >currently in use. So I guess I have to allocate RX_DMA_RING + TX_DMA_RING >dmamaps in order to be safe. Yes or allocate them in chunks so that the total amount is only as large as the greatest demand your driver has ever seen. >> With the added complications of deferring the mapping if we're >> out of space, issuing the callback, etc. > >Why can't I just call bus_dmamap_load() multiple times, once for >each mbuf in the mbuf list? Due to the cost of the dmamaps, the cost of which is platform and bus-dma implementation dependent - e.g. could be a 1-1 mapping to a hardware resource. Consider the case of having a full TX and RX ring in your driver. Instead of #TX*#RX dmamaps, you will now have three or more times that number. There is also the issue of coalessing the discontiguous chunks if there are too many chunks for your driver to handle. Bus dma is supposed to handle that for you (the x86 implementation doesn't yet, but it should) but it can't if it doesn't understand the segment limit per transaction. You've hidden that from bus dma by using a map per segment. >(Note: for the record, an mbuf list usually contains one packet >fragmented across multiple mbufs. An mbuf chain contains several >mbuf lists, linked together via the m_nextpkt pointer in the >header of the first mbuf in each list. By the time we get to >the device driver, we always have mbuf lists only.) Okay, so I haven't written a network driver yet, but you got the idea, right? 8-) >> Chances are you are going to use the map again soon, so destroying >> it on every transaction is a waste. > >Ok, I spent some more time on this. I updated the code at: > >http://www.freebsd.org/~wpaul/busdma I'll take a look. >The changes are: ... >- Added routines to allocate a chunk of maps in a singly linked list, > from which the other routines can grab them as needed. Are these hung off the dma tag or something? dmamaps may hold settings that are peculuar to the device that allocated them, so they cannot be shared with other clients of bus_dmamap_load_mbuf. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Where to put new bus_dmamap_load_mbuf() code
> The fact that the data is less than a page in size matters little > to the bus dma concept. In other words, how is this packet presented > to the hardware? Does it care that all of the component pieces are > < PAGE_SIZE in length? Probably not. It just wants the list of > address/length pairs that compose that packet and there is no reason > that each chunk needs to have it own, and potentially expensive, dmamap. Maybe, but bus_dmamap_load() only lets you map one buffer at a time. I want to map a bunch of little buffers, and the API doesn't let me do that. And I don't want to change the API, because that would mean modifying busdma_machdep.c on each platform, which is a hell that I would rather avoid. > >Why can't I just call bus_dmamap_load() multiple times, once for > >each mbuf in the mbuf list? > > Due to the cost of the dmamaps, the cost of which is platform and > bus-dma implementation dependent - e.g. could be a 1-1 mapping to > a hardware resource. Consider the case of having a full TX and RX > ring in your driver. Instead of #TX*#RX dmamaps, you will now have > three or more times that number. > > There is also the issue of coalessing the discontiguous chunks if > there are too many chunks for your driver to handle. Bus dma is > supposed to handle that for you (the x86 implementation doesn't > yet, but it should) but it can't if it doesn't understand the segment > limit per transaction. You've hidden that from bus dma by using a > map per segment. Ok, a slightly different question: what happens if I call bus_dmamap_load() more than once with different buffers but with the same dmamap? > >(Note: for the record, an mbuf list usually contains one packet > >fragmented across multiple mbufs. An mbuf chain contains several > >mbuf lists, linked together via the m_nextpkt pointer in the > >header of the first mbuf in each list. By the time we get to > >the device driver, we always have mbuf lists only.) > > Okay, so I haven't written a network driver yet, but you got the idea, > right? 8-) Just don't get 3c509 and 3c905 misxed up and we'll be fine. :) > >- Added routines to allocate a chunk of maps in a singly linked list, > > from which the other routines can grab them as needed. > > Are these hung off the dma tag or something? dmamaps may hold settings > that are peculuar to the device that allocated them, so they cannot > be shared with other clients of bus_dmamap_load_mbuf. It's a separate list. The driver is reponsible for allocating the head of the list, then it hands it to bus_dmamap_list_alloc() along with the required dma tag. bus_dmamap_list_alloc() then calls bus_dmapap_create() to populate the list. The driver doesn't have to manipulate the list itself, until time comes to destroy it. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Where to put new bus_dmamap_load_mbuf() code
> >> The fact that the data is less than a page in size matters little >> to the bus dma concept. In other words, how is this packet presented >> to the hardware? Does it care that all of the component pieces are >> < PAGE_SIZE in length? Probably not. It just wants the list of >> address/length pairs that compose that packet and there is no reason >> that each chunk needs to have it own, and potentially expensive, dmamap. > >Maybe, but bus_dmamap_load() only lets you map one buffer at a time. >I want to map a bunch of little buffers, and the API doesn't let me >do that. And I don't want to change the API, because that would mean >modifying busdma_machdep.c on each platform, which is a hell that I >would rather avoid. bus_dmamap_load() is only one part of the API. bus_dmamap_load_mbuf or bus_dmamap_load_uio or also part of the API. They just don't happen to be impmeneted yet. 8-) Perhaps there should be an MD primitive that knows how to append to a mapping? This would allow you to write an MI loop that does exactly what you want. >> there are too many chunks for your driver to handle. Bus dma is >> supposed to handle that for you (the x86 implementation doesn't >> yet, but it should) but it can't if it doesn't understand the segment >> limit per transaction. You've hidden that from bus dma by using a >> map per segment. > >Ok, a slightly different question: what happens if I call >bus_dmamap_load() more than once with different buffers but with >the same dmamap? The behavior is undefined. >> >- Added routines to allocate a chunk of maps in a singly linked list, >> > from which the other routines can grab them as needed. >> >> Are these hung off the dma tag or something? dmamaps may hold settings >> that are peculuar to the device that allocated them, so they cannot >> be shared with other clients of bus_dmamap_load_mbuf. > >It's a separate list. The driver is reponsible for allocating the >head of the list, then it hands it to bus_dmamap_list_alloc() along >with the required dma tag. bus_dmamap_list_alloc() then calls >bus_dmapap_create() to populate the list. The driver doesn't have >to manipulate the list itself, until time comes to destroy it. Okay, but does this mean that bus_dmamap_load_mbuf no longer takes a dmamap? Drivers may want to allocate/manage the dmamaps in a different way. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Where to put new bus_dmamap_load_mbuf() code
> >Maybe, but bus_dmamap_load() only lets you map one buffer at a time. > >I want to map a bunch of little buffers, and the API doesn't let me > >do that. And I don't want to change the API, because that would mean > >modifying busdma_machdep.c on each platform, which is a hell that I > >would rather avoid. > > bus_dmamap_load() is only one part of the API. bus_dmamap_load_mbuf > or bus_dmamap_load_uio or also part of the API. They just don't happen > to be impmeneted yet. 8-) Perhaps there should be an MD primitive > that knows how to append to a mapping? This would allow you to write > an MI loop that does exactly what you want. Any one of those ideas would be just fine. I eagerly await their realization. :) > >It's a separate list. The driver is reponsible for allocating the > >head of the list, then it hands it to bus_dmamap_list_alloc() along > >with the required dma tag. bus_dmamap_list_alloc() then calls > >bus_dmapap_create() to populate the list. The driver doesn't have > >to manipulate the list itself, until time comes to destroy it. > > Okay, but does this mean that bus_dmamap_load_mbuf no longer takes > a dmamap? Drivers may want to allocate/manage the dmamaps in a > different way. Yes, bus_dmamap_load_mbuf() accepts a dma tag, the head of the dmamap list, an mbuf, an segment array and a segment count. The Driver allocates the segment array with a certain number of members. It passes the array and segment count to bus_dmamap_load_mbuf(), which treats the segment count as the maximum number of segments that it can return to the caller. Once all the mappings have been done, it updates the segment count to indicate how many segments were actually needed. Then the driver transfers the info from the segment array into its DMA descriptor structures and kicks off the DMA operation. Once the device signals the transfer is done, the driver calls bus_dmamap_unload_mbuf() and bus_dmamap_destroy_mbuf() to unload the maps and return them to the map list for later use. It isn't until the driver calls bus_dmamap_list_destroy() that the dmamaps are actually released and the list free()ed. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh password cracker - now this *is* cool!
Matt Dillon wrote: | This gets an 'A' on my cool-o-meter. | | http://www.vnunet.com/News/1124839 The real research might be interesting, but the information in the article seems to be wrong. It says: Each keystroke from a user is immediately sent to the target machine as a separate IP packet. By performing a statistical study on a user's typing patterns, and applying a key sequence prediction algorithm, the researchers managed to successfully predict key sequences from inter-keystroke timings. While this is true for events that occur while you are typing at something like an xterm, it's not true while you type in a password. In that case the ssh client at your end collects the entire password, encrypts it, and transmits the whole thing when you hit . How are they going to determine inter-keystroke timings from that? Maybe the real trick is much cooler than what is shown in the article ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh password cracker - now this *is* cool!
* Greg Black <[EMAIL PROTECTED]> [010822 19:46] wrote: > Matt Dillon wrote: > > | This gets an 'A' on my cool-o-meter. > | > | http://www.vnunet.com/News/1124839 > > The real research might be interesting, but the information in > the article seems to be wrong. It says: > > Each keystroke from a user is immediately sent to the target > machine as a separate IP packet. By performing a statistical > study on a user's typing patterns, and applying a key > sequence prediction algorithm, the researchers managed to > successfully predict key sequences from inter-keystroke > timings. > > While this is true for events that occur while you are typing at > something like an xterm, it's not true while you type in a > password. In that case the ssh client at your end collects the > entire password, encrypts it, and transmits the whole thing when > you hit . > > How are they going to determine inter-keystroke timings from > that? Maybe the real trick is much cooler than what is shown in > the article ... No, the idea is that one may have ssh'd into a remote host that's trusted, and there the user is typing a password to access something from the trusted host. One could do the statistical analysis then. -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh password cracker - now this *is* cool!
On Wed, Aug 22, 2001 at 05:10:16PM -0700, Bruce A. Mah wrote:
> > Several people on other mailing lists have pointed out that Nagle
> > should make this much harder, although it's unclear how Nagle and
> > ssh interact. So far that has resulted in a number of degenerating
> > discussions of how things work. Of course, Nagle will not help
> > between two machines on the same ethernet segment, but probably
> > would make the process described in the paper much harder.
>
> Indeed. They also didn't discuss (or I didn't see it) the effects of
> queueing or jitter in the network on their scheme.
I just had a thought. It appears from the discussion that SSH encrypts
things (internal to ssh) in whatever unit is handed to the encryption
routine, that is something like:
for(;;) {
read(stdin, buffer);
encrypt(buffer);
write(network, buffer);
}
So, if read returns a single character, it encrypts a single character
and sends it. This results in the 20 byte packets in the article. Now,
20 bytes is small enough that Nagle might combine two of them into a
single 40 byte packet or similar making this harder. That said, it would
be much harder if something similar to Nagle was done in ssh:
for (;;) {
timer = gettime();
while ((len(buffer) < 20) && ((gettime() - timer) < 20ms)) {
read(stdin, buffer);
}
encrypt(buffer);
write(network, buffer);
}
This should allow two or three characters to go into a single block (which
would probably still be 20 bytes) and completely throw off the method they
were using.
--
Leo Bicknell - [EMAIL PROTECTED]
Systems Engineer - Internetworking Engineer - CCIE 3440
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: ssh password cracker - now this *is* cool!
* Leo Bicknell <[EMAIL PROTECTED]> [010822 20:00] wrote:
> On Wed, Aug 22, 2001 at 05:10:16PM -0700, Bruce A. Mah wrote:
> > > Several people on other mailing lists have pointed out that Nagle
> > > should make this much harder, although it's unclear how Nagle and
> > > ssh interact. So far that has resulted in a number of degenerating
> > > discussions of how things work. Of course, Nagle will not help
> > > between two machines on the same ethernet segment, but probably
> > > would make the process described in the paper much harder.
> >
> > Indeed. They also didn't discuss (or I didn't see it) the effects of
> > queueing or jitter in the network on their scheme.
>
> I just had a thought. It appears from the discussion that SSH encrypts
> things (internal to ssh) in whatever unit is handed to the encryption
> routine, that is something like:
>
> for(;;) {
>read(stdin, buffer);
>encrypt(buffer);
>write(network, buffer);
> }
>
> So, if read returns a single character, it encrypts a single character
> and sends it. This results in the 20 byte packets in the article. Now,
> 20 bytes is small enough that Nagle might combine two of them into a
> single 40 byte packet or similar making this harder. That said, it would
> be much harder if something similar to Nagle was done in ssh:
>
> for (;;) {
>timer = gettime();
>while ((len(buffer) < 20) && ((gettime() - timer) < 20ms)) {
> read(stdin, buffer);
>}
>encrypt(buffer);
>write(network, buffer);
> }
>
> This should allow two or three characters to go into a single block (which
> would probably still be 20 bytes) and completely throw off the method they
> were using.
I think introducing any sort of latency would really suck, instead you
might want to consider the idea (as I've already suggested) of injecting
false 'empty' packets into the stream to throw off this sort of
cryptoanalysis.
--
-Alfred Perlstein [[EMAIL PROTECTED]]
Ok, who wrote this damn function called '??'?
And why do my programs keep crashing in it?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh password cracker - now this *is* cool!
Alfred Perlstein wrote: | * Greg Black <[EMAIL PROTECTED]> [010822 19:46] wrote: | > Matt Dillon wrote: | > | This gets an 'A' on my cool-o-meter. | > | | > | http://www.vnunet.com/News/1124839 | > | > The real research might be interesting, but the information in | > the article seems to be wrong. It says: | > | > Each keystroke from a user is immediately sent to the target | > machine as a separate IP packet. By performing a statistical | > study on a user's typing patterns, and applying a key | > sequence prediction algorithm, the researchers managed to | > successfully predict key sequences from inter-keystroke | > timings. | > | > While this is true for events that occur while you are typing at | > something like an xterm, it's not true while you type in a | > password. In that case the ssh client at your end collects the | > entire password, encrypts it, and transmits the whole thing when | > you hit . | > | > How are they going to determine inter-keystroke timings from | > that? Maybe the real trick is much cooler than what is shown in | > the article ... | | No, the idea is that one may have ssh'd into a remote host that's | trusted, and there the user is typing a password to access something | from the trusted host. | | One could do the statistical analysis then. Ah, I see. That's something that's on my list of things not to do, so I didn't consider it. My rule is never to type passwords once I'm logged into a host; and even if I have to type another ssh password to jump to another host that needs a password, my method is to type the password locally on the physical trusted machine I'm using and then cut and paste it into the application that's waiting for it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.4-RC NFS panic
In message <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: : I've been having similar problems with my 4.4-RC Vaio F807K whenever I : do a lot of NFS over my wi0 (Buffalo wireless card), every so often my : laptop just completely freezes. I think that might be due to a bug in the shared interrupt code that Ian Dowse sent me about earlier today. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tunable support for ata interrupt sharing
In message <[EMAIL PROTECTED]> S ren Schmidt writes: : and I dont know exactly how close 4.4 is to closure. My guess is that Jordan is going to wind up slipping the final release at least a week. But it is just a guess. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: VM statistics per process?
On 22-Aug-2001 Anton Berezin wrote: > will provide me with the number of resident pages. But I'd like to be > able to also get the number of active and inactive pages belonging to a > particular process. What should I do in order to get this information? The mincore() system call does this (the manpage in -stable is wrong, but may have recently been fixed?). You could steal the code from that I guess. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clock synchronization quality via NTP ?
In message <[EMAIL PROTECTED]> Thierry Herbelot writes: : I know FreeBSD can be used with great success for timing solutions (at : least two core members do it ?). Well, there's one core member, and a second committer. Or was until a few days ago... : has someone some performance data of the quality of system clock : synchronization, while using NTPd with a GPS reveiver and a hard 1PPS : signal ? : : More precisely : is it reasonable to hope having a system clock not : farther from the GPS clock by more than 50 micro-seconds ? It depends on the machine. We had troubles with 486-class hardware getting below a tens microseconds for extended periods of time. Part of this was due resolution of the timer used in the sytem. Part of it was due to thermal variance in the temperature. Part of it was due to the extremely crappy oscillator that was on the board. And we also had to hack the parallel port driver to use fast interrupts. Otherwise the interrupt latency variance caused too much jitter. Or at least enough jitter to measure and be concerned about. We've not repated the experiment now that pentium class hardware is available, which we think will yield much better results. PC hardware really sucks for timing. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pci_get_devid()
In message <[EMAIL PROTECTED]> djohnson writes: : little application that gives a detailed enumeration of the PCI bus : using BIOS calls. Thanks in advance. PCI BUS ENUMERATION WITH BIOS CALLS SUCKS. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clock synchronization quality via NTP ?
In message <[EMAIL PROTECTED]> Wilko Bulte writes: : On Wed, Aug 22, 2001 at 09:47:34PM +0200, Thierry Herbelot wrote: : > Hello, : > : > I know FreeBSD can be used with great success for timing solutions (at : > least two core members do it ?). : > : > has someone some performance data of the quality of system clock : > synchronization, while using NTPd with a GPS reveiver and a hard 1PPS : > signal ? : > : > More precisely : is it reasonable to hope having a system clock not : > farther from the GPS clock by more than 50 micro-seconds ? : : Talk to Poul-Henning, he is the clock/time expert ([EMAIL PROTECTED]). : Poul used to have some nice Web pages around on this subject but they : were killed in a disk crash IIRC. http://phk.freebsd.dk/rover.html used to be that URL... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Mounting FAT16 on USB connected Rio 600
Hackers, The overwhelming lack of response on -questions suggests I might do better here. I though this would be an easy one. In short, I simply want to know what device to mount and what to do get that device configured. I have a Rio 600 MP3 player connected via USB. The device is recognised by the system - specifically usbd - however the (SCSI) disk device which I expect to appear and expect to be able to mount as an msdos filesystem does not. I have both IDE and SCSI disks in this box, have all drivers and filesystems compiled into the kernel, have extra disk device special files in /dev and start usbd at boot. I have ad0, da0 and da1 devices for disks, so would expect da2 to be the `next' disk created for the Rio, however the system doesn't recognise any da2 device and attempting to mount /dev/da2s1 gives "Device not configured". # ls /dev/[ad][ad][0-9]s1 /dev/ad0s1 /dev/ad2s1 /dev/da0s1 /dev/da2s1 /dev/ad1s1 /dev/ad3s1 /dev/da1s1 /dev/da3s1 The USB device appears as expected and disconnection and reconnection are picked up: # usbdevs -v Controller /dev/usb0: addr 1: self powered, config 1, UHCI root hub(0x), Intel(0x), rev 0x0100 port 1 powered port 2 addr 2: self powered, config 1, Diamond Multimedia Digital Audio Player(0x5001), Diamond Multimedia(0x045a), rev 0x0100 /kernel: ugen0: at uhub0 port 2 (addr 2) disconnected /kernel: ugen0: detached /kernel: ugen0: Diamond Multimedia Diamond Multimedia Digital Audio Player, rev 1.00/1.00, addr 2 I've tried rescanning and examining devices on the SCSI bus with camcontrol to no avail: # camcontrol rescan 0 Re-scan of bus 0 was successful # camcontrol rescan 1 camcontrol: CAMIOCOMMAND ioctl failed: Invalid argument # camcontrol devlist -v scbus0 on sym0 bus 0: at scbus0 target 1 lun 0 (pass0,da0) at scbus0 target 2 lun 0 (pass1,da1) < > at scbus0 target -1 lun -1 () scbus-1 on xpt0 bus 0: < > at scbus-1 target -1 lun -1 (xpt0) # camcontrol periphlist da0 pass0: generation: 8 index: 1 status: MORE da0: generation: 8 index: 2 status: LAST # camcontrol periphlist da1 pass1: generation: 8 index: 1 status: MORE da1: generation: 8 index: 2 status: LAST # camcontrol periphlist da2 camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed cam_lookup_pass: No such file or directory cam_lookup_pass: either the pass driver isn't in your kernel cam_lookup_pass: or da2 doesn't exist I have not previously used USB, so I hope my problem is simple ignorance. I've not found anything by way of documentation which puts all the pieces together. Kernel config for USB and disk subsystem: options MSDOSFS # MS DOS File System device scbus # SCSI bus device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device fdc0at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device sym # NCR/Symbios Logic (newer chipsets) device da # Direct Access (disks) device pass# Passthrough device (direct SCSI access) device usb # General USB code (mandatory for USB) device ugen# Generic USB device driver device umass # Disks/Mass storage device uhci# UHCI PCI->USB interface Here's the trimmed dmesg output: uhci0: port 0xfca0-0xfcbf irq 11 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ugen0: Diamond Multimedia Diamond Multimedia Digital Audio Player, rev 1.00/1.00, addr 2 sym0: <875> port 0xf400-0xf4ff mem 0xfedfe000-0xfedfefff,0xfedff800-0xfedff8ff irq 7 at device 15.0 on pci0 sym0: Tekram NVRAM, ID 7, Fast-20, SE, parity checking orm0: at iomem 0xc-0xc7fff,0xc8000-0xc9fff,0xe4000-0xe on isa0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ad0: 6149MB [13328/15/63] at ata0-master UDMA33 ad1: 96MB [512/12/32] at ata1-master PIO0 acd0: CDROM at ata1-slave using PIO3 Waiting 2 seconds for SCSI devices to settle Mounting root from ufs:/dev/ad0s1a da1 at sym0 bus 0 target 2 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 4340MB (924 512 byte sectors: 255H 63S/T 553C) da0 at sym0 bus 0 target 1 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4340MB (924 512 byte sectors: 255H 63S/T 553C) Instructions, directions to such, experiences and suggestions are all welcome. -Andrew- -- __
Re: Firewire driver available
In message <[EMAIL PROTECTED]> Matthew Reimer writes: : I saw this on Freshmeat the other day: : http://www.sfc.wide.ad.jp/DVTS/ : Maybe someday it can be committed? Maybe. One problem with these patches are that they only do a certain type of firewire stuff. They treat the firewire device as only a fancy network adapter. However, you can also do other things (like disk drives) with firewire. It does look cool. I wish I had a DV camera to play with it... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: XMM[0-7] preserved across context switch?
David Malone wrote: > On Tue, Aug 21, 2001 at 11:27:38AM -0500, Kevin Day wrote: > > A quick peek at swtch.s seems to show that the SSE registers (XMM0-7) aren' t > > being preserved across context switches. Am I missing somewhere that's doin g > > this, or are they really not being saved now? > > SSE support has recently been added to -current and -stable. Yes, but the question was "how is it preserved"? The SSE stuff works the same as the FPU stuff in that it is switched lazily. See npxsave() and where it is called. If a process "attaches" to the fpu, its state is kept in the fpu the whole time. It is not extracted at context switch time. So, we can be running a different process while the fpu/xmm stuff is holding the original process's context. If the new process tries to use the SSE/fpu stuff, a trap happens, we save the original process's context in the original pcb and then give ownership to the new process. And for SMP, we handle it differently again. :-/ Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clock synchronization quality via NTP ?
In message <[EMAIL PROTECTED]>, Warner Losh writes: >: More precisely : is it reasonable to hope having a system clock not >: farther from the GPS clock by more than 50 micro-seconds ? 50 microseconds should be feasible provided that you either provide a very stable temperature or replace the 14.318 MHz xtal on the motherboard with a something more stable. >PC hardware really sucks for timing. Tell me about it... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clock synchronization quality via NTP ?
In message <46651.998541806@critter> Poul-Henning Kamp writes: : In message <[EMAIL PROTECTED]>, Warner Losh writes: : : >: More precisely : is it reasonable to hope having a system clock not : >: farther from the GPS clock by more than 50 micro-seconds ? : : 50 microseconds should be feasible provided that you either : provide a very stable temperature or replace the 14.318 MHz : xtal on the motherboard with a something more stable. Yea. I just took a look at the data that we have, and we're seeing more like +- 15us on machines here without temerpature stability beyond "normal HVAC" and stock xtals on the motherboard. This is after we've done the fast interrupt hack. Without it, the other system activity was causing enough interrupt latncy variance that we would see more like +- 80us with outliers way off in the weeds (+- just under 10ms!). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clock synchronization quality via NTP ?
> beyond "normal HVAC" and stock xtals on the motherboard. This is > after we've done the fast interrupt hack. Without it, the other > system activity was causing enough interrupt latncy variance that we > would see more like +- 80us with outliers way off in the weeds > (+- just under 10ms!). Warner, this sounds related to a problem we are having... a student of mine is seeing sporadic but relatively large (~50-100us) variations in the period of clock interrupts (int0 calls to the assembly routine). This is in the assembler part of the interrupt service routine, so the only reason I can see for these variations is that there are some significantly large sections of code (this is a 750 MHz box) which run with interrupts disable on the CPU. Is this the case ? And if so, what is the "fast interrupt hack" that you are mentioning and how would it improve things ? thanks luigi --+- Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 --+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clock synchronization quality via NTP ?
In message <[EMAIL PROTECTED]> Luigi Rizzo writes:
: Is this the case ? And if so, what is the "fast interrupt hack" that you
: are mentioning and how would it improve things ?
Yes. I think so. We were measuring on a 5x86 at 133MHz, so the
effect would be exagerated more.
The hack that we did was
Index: ppi.c
===
RCS file: /base/FreeBSD-tsc-4/sys/dev/ppbus/ppi.c,v
retrieving revision 1.1.1.4
retrieving revision 1.4
diff -u -r1.1.1.4 -r1.4
--- ppi.c 2 Nov 2000 02:30:30 - 1.1.1.4
+++ ppi.c 2 Nov 2000 18:21:29 - 1.4
@@ -264,6 +264,7 @@
device_t ppidev = UNITODEVICE(unit);
device_t ppbus = device_get_parent(ppidev);
int res;
+ int itype;
if (!ppi)
return (ENXIO);
@@ -279,8 +280,14 @@
#ifdef PERIPH_1284
if (ppi->intr_resource) {
/* register our interrupt handler */
- BUS_SETUP_INTR(device_get_parent(ppidev), ppidev,
ppi->intr_resource,
- INTR_TYPE_TTY, ppiintr, dev, &ppi->intr_cookie);
+#ifdef PPB_USE_FAST_INTR
+ itype = INTR_TYPE_TTY | INTR_TYPE_FAST;
+#else
+ itype = INTR_TYPE_TTY;
+#endif
+ BUS_SETUP_INTR(device_get_parent(ppidev), ppidev,
+ ppi->intr_resource, itype, ppiintr, dev,
+ &ppi->intr_cookie);
}
#endif /* PERIPH_1284 */
}
And we created a PPB_USE_FAST_INTR option.
Come to think of it, we weren't measuring at the FreeBSD assembler
point, but in the actual interrupt handler. And the clock interrupt
would only be masked if interrupts were turned off (which can happen
in the SIO routines for microseconds at a time) or if we were at
splhigh, and got 2 irq0 interrupts. The second one would be delayed
because we'd turn off irq0 at the PIC on the second one.
Looking at the above, I suspect that we could have gotten even better
results if we made it INTR_TYPE_MISC. This would involve shooting the
parallel port for printers in the head (since I think it needs to run
at spltty to keep invariants in the rest of the driver happy), but
given the application that we had, we certainly didn't care...
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
