Re: (jail) problem and a (possible) solution ?
Yes I've had the same problem. One system runs just fine with it's jails, and another crashes habitually. It has to do with a certain jail (and services). Our system are set up to be able to move jails between them (great for backups and near perfect uptime), and a certain set of jails always hangs the system in this way. I'm trying to narrow it down. Do you get a core dump or does it just hang? Nate - Original Message - From: Patrick Thomas [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 21, 2002 16:43 Subject: (jail) problem and a (possible) solution ? A test server of mine running a number of jails keeps locking up - but the odd thing about the lockup is that the userland stops, but the kernel keeps running (sockets can be opened, but the servers never respond on them, the machine still responds to pings, but logs show that all real activity stops) I just noticed today that some jails still have writable /dev/mem and /dev/kmem and /dev/io nodes. I think it is plausable that some kind of fiddling (writing) to these nodes is causing this kind of lockup. Is this assumption reasonable, or if some jail user fiddled with their /dev/mem or /dev/kmem or /dev/io node would it just totally crash out the machine and I _wouldn't_ still be able to ping the server after it crashes ? thanks, PT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
help with PicoBSD for the DAR
Im currently attemting to build a embeded type Digital Audio Recorder running PicoBSD booting off a zip disk. its a pretty strait forward project. unfortunatly none of the default scripts to make PicoBSD seem to work out of the box, let alone after adding the features i need, or writing a different image size. could anyone out there tell a proper step by step for making the picobsd image after adding the devices i need and removing those i dont, and how i configure the crunched binaries to include those progs i need, as well as how to call those binaries, the documentation is none to clear about any of it. has picoBSD stopped devel? that would be a shame. it has been extreamly usefull whenever i have been able to hack it into what i need the hack i have for this, so far , is just not pretty, i cant bear it. any help or comments would be appreciated, John Fränz [EMAIL PROTECTED] icq: 44901799 PinkoBSD -- superiority through equality. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: help with PicoBSD for the DAR
On Sat, Jun 22, 2002 at 12:31:35AM -0700, John Franz wrote: Im currently attemting to build a embeded type Digital Audio Recorder running PicoBSD booting off a zip disk. its a pretty strait forward project. unfortunatly none of the default scripts to make PicoBSD seem to work out of the box, let alone after adding the features i need, or writing a different image size. the scripts with 4.5 and above work reasonably well. At least the bridge image should even compile. cheers luigi could anyone out there tell a proper step by step for making the picobsd image after adding the devices i need and removing those i dont, and how i configure the crunched binaries to include those progs i need, as well as how to call those binaries, the documentation is none to clear about any of it. has picoBSD stopped devel? that would be a shame. it has been extreamly usefull whenever i have been able to hack it into what i need the hack i have for this, so far , is just not pretty, i cant bear it. any help or comments would be appreciated, John Fränz [EMAIL PROTECTED] icq: 44901799 PinkoBSD -- superiority through equality. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: LINT CPU features table
Let me turn my original inquiry into an offer: I volunteer to write the section for the Handbook or other documentation detailing the various CPU options in LINT if somebody who fully understands what these options do is willing to spend 30 minutes on the phone with me answering questions about the options. Any takers? Thanks, --Lucky To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
Chris Dillon wrote: While I appreciate the positive support of Cyrus, I guess I need to point out that this approach only works if you are willing to send passwords over the wire in plaintext. Yes, but this is the case with any IMAP server and doesn't really have anything to do with Cyrus in particular. Unlike other IMAP servers, however, Cyrus supports SASL which offers plenty of non-plain-text authentication options, unfortunately none of which work with a local FreeBSD password database that I know of. There is always the option to use SSL, which is my preference, but unfortunately neither SSL nor SASL have widespread IMAP client support yet. SASL requires a shared secret, not a crypt(3) hash of a shared secret. That's why the passwords have to be stored plaintext on the mail server, and why, if you use the UNIX password database as the account database for Cyrus, you must pass the passwords over the wire in plaintext. Personally, I think SASL should have specified that you crypt(3) the passwords, and then use the resulting hash as the password value for the shared secret on both ends. At least that way, you would not have to pass cleartext to use the UNIX account database. This is a client problem. Or you could assign paswords to the client, so that the user sees the hashed value as their mail password, and the unhashed value as their shell account password. But in actuality, the issue is still a client issue (because clients don't hash shared secrets before using them in SASL exchanges). Pretty obvious, really. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: (jail) problem and a (possible) solution ?
What it does is the userland hangs, but the kernel keeps running. When the system is crashed, I can still ping it successfully, and I can still open sockets (like I can open a connection to a jails httpd or sshd, or the sshd of the underlying server itself) but nothing answers on the sockets - they just hang open. So everything stops running, but it is still up - still responds to pings...syslog stops logging though, cron stops running Two questions for you: 1) do you allow them write access to their /dev/mem, /dev/kmem, /dev/io ? 2) does this sound like what you see? Can you still ping the crashed server ? I'm mostly just curious if this kind of crash (userland hung but kernel running) is a possible outcome of someone in a jail fiddling with those /dev nodes, or if fiddling with dev/mem or /dev/kmem or io would just lock the machine up hard and completely. Terry? --PT On Fri, 21 Jun 2002, Nielsen wrote: Yes I've had the same problem. One system runs just fine with it's jails, and another crashes habitually. It has to do with a certain jail (and services). Our system are set up to be able to move jails between them (great for backups and near perfect uptime), and a certain set of jails always hangs the system in this way. I'm trying to narrow it down. Do you get a core dump or does it just hang? Nate - Original Message - From: Patrick Thomas [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 21, 2002 16:43 Subject: (jail) problem and a (possible) solution ? A test server of mine running a number of jails keeps locking up - but the odd thing about the lockup is that the userland stops, but the kernel keeps running (sockets can be opened, but the servers never respond on them, the machine still responds to pings, but logs show that all real activity stops) I just noticed today that some jails still have writable /dev/mem and /dev/kmem and /dev/io nodes. I think it is plausable that some kind of fiddling (writing) to these nodes is causing this kind of lockup. Is this assumption reasonable, or if some jail user fiddled with their /dev/mem or /dev/kmem or /dev/io node would it just totally crash out the machine and I _wouldn't_ still be able to ping the server after it crashes ? thanks, PT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: (jail) problem and a (possible) solution ?
* Patrick Thomas [EMAIL PROTECTED] [020622 01:56] wrote: What it does is the userland hangs, but the kernel keeps running. ... I'm mostly just curious if this kind of crash (userland hung but kernel running) is a possible outcome of someone in a jail fiddling with those /dev nodes, or if fiddling with dev/mem or /dev/kmem or io would just lock the machine up hard and completely. Terry? This typically means some sort of deadlock has happened, if possible getting a crash dump (this is detailed in the handbook i think) would help. The reason why it seems like apps are responding is because the kernel is only processing interrupts, something has hung the scheduler or deadlocked the kernel somehow... FYI, the kernel is not running except when interrupted by a device. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: (jail) problem and a (possible) solution ?
Patrick Thomas wrote: What it does is the userland hangs, but the kernel keeps running. When the system is crashed, I can still ping it successfully, and I can still open sockets (like I can open a connection to a jails httpd or sshd, or the sshd of the underlying server itself) but nothing answers on the sockets - they just hang open. So everything stops running, but it is still up - still responds to pings...syslog stops logging though, cron stops running Two questions for you: 1) do you allow them write access to their /dev/mem, /dev/kmem, /dev/io ? 2) does this sound like what you see? Can you still ping the crashed server ? I'm mostly just curious if this kind of crash (userland hung but kernel running) is a possible outcome of someone in a jail fiddling with those /dev nodes, or if fiddling with dev/mem or /dev/kmem or io would just lock the machine up hard and completely. Terry? I've kept quiet so far because I'm not the jail expert; Poul actually wrote the jail code, and there was someone else who understood it enough to recently add multiple IP support. Given your symptoms, I can pretty much guess where the problem is, but not really how to fix it, other than trial-and-error, since I tend to run jails on a number of my machines, and make them do things they aren't supposed to do... Knowing what version of FreeBSD you are running would be helpful. That you can still ping indicates that both hardware interrupts and NETISR are running. That NETISR runs indicates that things are still calling splx(), which means things are still calling spl*() and coming back from it. The fact that you can still connect to servers that have active listens posted, but that you get no data is also indicative that the NETISR is running, at least up to the accept. It would be interesting to attempt a large number of connections, to see if the connections stop being accepted after you've tried more times than you set in listen(3) as the queue depth for the number of sockets allowed to sit there pending accept. If this happens (connection attempts start hanging, rather than being accepted), you know for certain that the process you are trying to talk to is not being scheduled to run. Basically, this implies one of two things is happening: 1) Your scheduler lost its head entry, so it's not scheduling anything to run, OR 2) You've used up all your resources on the machine (usually memory), and all of your processes are hung on a copy-on-write or allocate request, pending being serviced by the kernel If you can, compile the kernel for the box with the kernel debugger enabled, and break to debugger enabled, and break to the debugger on the console. The type ps and see what you get back as the wait channel everything you are trying to connect to is waiting on. This should be very informative, and it should be easy to locate the problem from there. If you have to, you can look at the scheduler queues, if there is anything in runnable state, and find out what's not there. Probably, it's not enough RAM, and your tuning parameters are set such that this isn't fatal to processes, when it should be. That you are able to ping, etc. guaranteed that you are not out of mbufs, and that you can connect that you aren't out of inpcb's or tcpcb's -- but mbufs are freelisted, so that's to be expected there (may not need more) and the pcb's are allocated at boot time (so are sockets, based on maxfiles), so tuning any of them after boot can get you in trouble. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: (jail) problem and a (possible) solution ?
Terry, Thanks for that informative email - just a quick reality check though (for myself) - the last time this type of crash happened, I was running and watching `top` on the machine - and when it froze, the `top` output froze as well, and this was the last display on the screen: last pid: 6603; load averages: 3.81, 1.84, 1.48 1032 processes:1 running, 1026 sleeping, 5 zombie CPU states: 1.8% user, 0.8% nice, 3.2% system, 0.1% interrupt, 94.1% idle Mem: 1129M Active, 1404M Inact, 351M Wired, 103M Cache, 199M Buf, 28M Free Swap: 2018M Total, 2732K Used, 2015M Free Since all of the things you spoke of basically revolved around you're running out of memory, is it possible or reasonable to think that within the space of 1 second, I ran through 1404 megs inactive and 28 megs free memory ? machine is 4.5-RELEASE with 3gigs ram. swap never gets touched, although there is in fact 2gigs of swap. `pstat -s` always shows 0% used. I'll do the debug actions you suggested. --PT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: (jail) problem and a (possible) solution ?
Patrick Thomas wrote: Since all of the things you spoke of basically revolved around you're running out of memory, is it possible or reasonable to think that within the space of 1 second, I ran through 1404 megs inactive and 28 megs free memory ? machine is 4.5-RELEASE with 3gigs ram. swap never gets touched, although there is in fact 2gigs of swap. `pstat -s` always shows 0% used. OK, there's memory, and then there's memory. The amount of swap you have, the fact that it's 4.5, and the amount of RAM you have imply to me that the problem is that you are out of pmap entries. You should up your KVA space to 2G or maybe even 3G; the default in 4.5 was 1G. Basically, I now think that you don't have enough memory to map how much memory and virtual memory you have. Amusingly enough, you might actually have *better* luck with a lot less swap... If your KVA space is already enlarged above the default, then you can ignore this and just go ahead with the debugging to see what the wait channels for all the processes that won't run are stuck at. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
On Sat 2002-06-22 (00:06), Chris Dillon wrote: Yes, but this is the case with any IMAP server and doesn't really have anything to do with Cyrus in particular. Unlike other IMAP servers, however, Cyrus supports SASL which offers plenty of non-plain-text authentication options, unfortunately none of which work with a local FreeBSD password database that I know of. Courier-IMAP supports SASL (PLAIN, LOGIN, CRAM-MD5, CRAM-SHA1). There is always the option to use SSL, which is my preference, but unfortunately neither SSL nor SASL have widespread IMAP client support yet. Most IMAP clients I know of support SSL. Outlook, Outlook Express, Eudora, Netscape, Evolution, mutt, pine, ... Which IMAP clients don't? Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Start now look great this summer
As seen on NBC, CBS, CNN, and even Oprah! The health discovery that actually reverses aging while burning fat, without dieting or exercise! This proven discovery has even been reported on by the New England Journal of Medicine. Forget aging and dieting forever! And it's Guaranteed! Click here: http://web.kuhleersparnis.ch/hgh/index.html Would you like to lose weight while you sleep! No dieting! No hunger pains! No Cravings! No strenuous exercise! Change your life forever! 100% GUARANTEED! 1.Body Fat Loss82% improvement. 2.Wrinkle Reduction 61% improvement. 3.Energy Level 84% improvement. 4.Muscle Strength 88% improvement. 5.Sexual Potency 75% improvement. 6.Emotional Stability 67% improvement. 7.Memory 62% improvement. *** You are receiving this email as a subscriber to the Opt-In America Mailing List. To unsubscribe from future offers, just click here: mailto:[EMAIL PROTECTED]?Subject=off To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: (jail) problem and a (possible) solution ?
1) do you allow them write access to their /dev/mem, /dev/kmem, /dev/io ? Actually haven't yet let anyone else inside a jail with root capabilities. Will soon though. So, no probably not, unless there's a daemon which does just that. 2) does this sound like what you see? Can you still ping the crashed server ? Kernel routing still works. And yes ping too. But come to think of this I've seen it on other (4.5, patched pretty much to date) machines I use exclusively as routers. These have no jails on them. In these cases after uptimes of let's say 2 or 3 months, the machine's daemons stop responding and although a socket can be opened (just barely) it closes again when the process listening on the other side doesn't pick it up. IPSEC, firewalls, kernel routing, and all that continue to function just fine. Like you said it's just the userland stuff that has problems. The strange thing is, on one of my machines I was (eventually) able to log in from the console, take the system down to single user mode and back up and then everything worked like a charm. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: LINT CPU features table
If memory serves me right, Lucky Green wrote: Let me turn my original inquiry into an offer: I volunteer to write the section for the Handbook or other documentation detailing the various CPU options in LINT if somebody who fully understands what these options do is willing to spend 30 minutes on the phone with me answering questions about the options. Any takers? Hi Lucky-- An excellent idea. A few thoughts for you: 1. You could peruse recent release notes (at least for i386) to get started. What little I know about the CPU-related options is encapsulated there, so thirty minutes on the phone with me is not likely to be useful, BTW. :-p 2. The CPU options in LINT are both version- and architecture-dependent. This fact probably makes this information a good candidate for the architecture-dependent hardware notes in the release documentation, with a pointer from the Handbook. 3. If you want a review on markup (or you want someone to mark up text for you), freebsd-doc is a great place to send things for feedback. Good luck, and thanks for volunteering to document this stuff! Bruce. msg35196/pgp0.pgp Description: PGP signature
RE: LINT CPU features table
On Sat, 22 Jun 2002, Lucky Green wrote: Let me turn my original inquiry into an offer: I volunteer to write the section for the Handbook or other documentation detailing the various CPU options in LINT if somebody who fully understands what these options do is willing to spend 30 minutes on the phone with me answering questions about the options. Any takers? Thanks, --Lucky Despite your enthusiasm, it's still a rather pointless exercise. To make explaining the cpu options worthwhile, you must show that only specifying I686 is sufficiently more optimal than specifying I686/I586/I486/I386. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
Terry == Terry Lambert [EMAIL PROTECTED] writes: Terry Personally, I think SASL should have specified that you Terry crypt(3) the passwords, and then use the resulting hash as Terry the password value for the shared secret on both ends. At Terry least that way, you would not have to pass cleartext to use Terry the UNIX account database. The problem with this is that if you serve up your password database via NIS an attacker can grab the crypt()ed password and use it to perform a forged authentication. Note that in the next revision of the IMAP4 spec STARTTLS will be mandatory to implement. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: LINT CPU features table
In the last episode (Jun 22), Mike Silbersack said: On Sat, 22 Jun 2002, Lucky Green wrote: Let me turn my original inquiry into an offer: I volunteer to write the section for the Handbook or other documentation detailing the various CPU options in LINT if somebody who fully understands what these options do is willing to spend 30 minutes on the phone with me answering questions about the options. Despite your enthusiasm, it's still a rather pointless exercise. To make explaining the cpu options worthwhile, you must show that only specifying I686 is sufficiently more optimal than specifying I686/I586/I486/I386. I think he's referring to the flotilla of CPU feature options, mainly aimed at AMD and old Cyrix processors. A while back I went through all the places the I?86_CPU defines were used and determined that the only option that degraded performace when added to a kernel that didn't need it was I386_CPU; due to the 386's lack of locking primitives. For 486 and higher chips it doesn't matter if you have all three I[456]86_CPU defined or just the one you need. Most of the code activated by the options are specialized bcopy routines accessed through an indirect pointer, or initialization code used only once during bootup. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Weird problems with BIND 8.3.1-REL
I am having weird problems with BIND. It started happening about a month and a half ago. named would start returning immediate host name lookup failures for just about everything and never recover. I dumped named in one of these instances. The dump file (500K) is temporarily at: http://apollo.backplane.com/named_dump.db . If there are any DNS gurus out there I would appreciate a look-see. Is anyone aware of any issues with named? I see that the current version in the tree appears to be 8.3.2-T1B (which I just installed a second ago). -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: (jail) problem and a (possible) solution ?
How do you increase KVA space these days ? I see that in earlier releases you had to edit /sys/conf/ldscript.i386 and /sys/i386/include/pmap.h and do all sorts of crazy stuff. What is the procedure in 4.5-RELEASE (please say just change KVA_PAGES=260 to KVA_PAGES=512) That's what you want me to do, right ? Is that all - can it be done just by changing that one value in my kernel config ? Again, thank you Terry for all your help. --PT On Sat, 22 Jun 2002, Terry Lambert wrote: Patrick Thomas wrote: Since all of the things you spoke of basically revolved around you're running out of memory, is it possible or reasonable to think that within the space of 1 second, I ran through 1404 megs inactive and 28 megs free memory ? machine is 4.5-RELEASE with 3gigs ram. swap never gets touched, although there is in fact 2gigs of swap. `pstat -s` always shows 0% used. OK, there's memory, and then there's memory. The amount of swap you have, the fact that it's 4.5, and the amount of RAM you have imply to me that the problem is that you are out of pmap entries. You should up your KVA space to 2G or maybe even 3G; the default in 4.5 was 1G. Basically, I now think that you don't have enough memory to map how much memory and virtual memory you have. Amusingly enough, you might actually have *better* luck with a lot less swap... If your KVA space is already enlarged above the default, then you can ignore this and just go ahead with the debugging to see what the wait channels for all the processes that won't run are stuck at. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
On Sat, 22 Jun 2002, Neil Blakey-Milner wrote: On Sat 2002-06-22 (00:06), Chris Dillon wrote: Yes, but this is the case with any IMAP server and doesn't really have anything to do with Cyrus in particular. Unlike other IMAP servers, however, Cyrus supports SASL which offers plenty of non-plain-text authentication options, unfortunately none of which work with a local FreeBSD password database that I know of. Courier-IMAP supports SASL (PLAIN, LOGIN, CRAM-MD5, CRAM-SHA1). I should have said unlike some other IMAP servers. Thanks to the simple BSD-like license on the Cyrus SASL implementation, it has found its way into a lot of places. There is always the option to use SSL, which is my preference, but unfortunately neither SSL nor SASL have widespread IMAP client support yet. Most IMAP clients I know of support SSL. Outlook, Outlook Express, Eudora, Netscape, Evolution, mutt, pine, ... I know Netscape didn't have that ability for a long time, and neither did Outlook or OE. Mutt and Pine have had it since around 1999, though. Which IMAP clients don't? If all of the above now support SSL for IMAP connections, then I can't think of any. -- Chris Dillon - cdillon(at)wolves.k12.mo.us - cdillon(at)inter-linc.net FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, and ARM architectures under development - http://www.freebsd.org No trees were harmed in the composition of this message, although some electrons were mildly inconvenienced. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
USB mouse probes, but I get uhci_timeout
Under FreeBSD-RELEASE, I'm messing with a USB mouse. I've compiled into the kernel the lot of USB devices, and the USB debug options. (More specifcally, the device is a Twiddler2, which acts as a keyboard and a mouse, and a keyboard/mouse - USB converter the vendor sold me.) I get as far as: ... uhci0: VIA 83C572 USB controller port 0xe400-0xe41f irq 9 at device 7.2 on pci 0 uhci_run: setting run=0 uhci_run: done cmd=0x0 sts=0x20 uhci_run: setting run=1 uhci_run: done cmd=0x81 sts=0x0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ukbd0: MT606 MT606-1 PS/2 KB MOUSE TO USB ADAPTOR, rev 1.00/0.01, addr 2, iclass 3/1 ukbd:set_leds: state=0xc043fa80 leds=0 kbd1 at ukbd0 ums0: MT606 MT606-1 PS/2 KB MOUSE TO USB ADAPTOR, rev 1.00/0.01, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. ums_attach: sc=0xc236e800 ums_attach: X 8/8 ums_attach: Y 16/8 ums_attach: Z 24/8 ums_attach: B1 0/1 ums_attach: B2 1/1 ums_attach: B3 2/1 ums_attach: size=4, id=0 ... uhci_timeout: ii=0xc2050120 The uhci0 on irq 9 worries me, as it's shared by other things: % dmesg | grep 'irq 9' IOAPIC #0 intpin 16 - irq 9 pci1: NVidia Riva TNT graphics accelerator at 0.0 irq 9 uhci0: VIA 83C572 USB controller port 0xe400-0xe41f irq 9 at device 7.2 on pci0 This is with the motherboard set to utililze PnP. If I disable _that_, the diff between dmesg's is: % diff dmesg.pnpos.* 14c14 IOAPIC #0 intpin 16 - irq 9 --- IOAPIC #0 intpin 16 - irq 5 15a16 IOAPIC #0 intpin 19 - irq 9 32c33 pci1: NVidia Riva TNT graphics accelerator at 0.0 irq 9 --- pci1: NVidia Riva TNT graphics accelerator at 0.0 irq 5 uhci0 doesn't move, I still get timeouts, and now my video card causes my sound card to time out. :/ I know the Twiddler2/USB combo works, per se, in that I can get it to work on a Vaio with Win98. I haven't further explored said combo on the same laptop under FreeBSD; I'll try that next. But, in the meantime, can someone shed some light on why I'm seeing the uhci_timeout message, and what steps I can take to getting this all to work? -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: LINT CPU features table
On Sat, 22 Jun 2002, Dan Nelson wrote: In the last episode (Jun 22), Mike Silbersack said: On Sat, 22 Jun 2002, Lucky Green wrote: Let me turn my original inquiry into an offer: I volunteer to write the section for the Handbook or other documentation detailing the various CPU options in LINT if somebody who fully understands what these options do is willing to spend 30 minutes on the phone with me answering questions about the options. Despite your enthusiasm, it's still a rather pointless exercise. To make explaining the cpu options worthwhile, you must show that only specifying I686 is sufficiently more optimal than specifying I686/I586/I486/I386. I think he's referring to the flotilla of CPU feature options, mainly aimed at AMD and old Cyrix processors. [snip] I would argue that any effort put toward documenting this is better spent documenting something else. That particular flotilla of options relates entirely to a group of rather old, rather slow, and rather rare processors. The incidence of their use or necessity in the general FreeBSD user base is likely to be quite small. If you're running on asome ancient bastard child of Cyrix processor then chances are you're not running a performance critical application. At that level I say to anyone who tries to squeeze every last ounce of performance out of their CPU, buy a faster CPU or UTFSL. Feel free to disagree and work on what interests you. Brandon D. Valentine -- http://www.geekpunk.net [EMAIL PROTECTED] ++[++-][++-].[+-][+-]+.+++..++ +.+[++-]++.+++..+++.--..+. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Visor USB Problems
I am having some trouble reading data from a Handspring Visor Platinum. What I am trying to do is make the necessary modifications to pilot-link so that it will work with the usb on FreeBSD. My problem is that I can open a connection to the /dev/ugen0.2 endpoint, but whenever I try to call a read() it returns with error 5 (Input/Output Error). I used the coldsync code as a base, but the read keeps failing. I can post the code, I just wanted to see if there were anyone with a similar problem. I have checked the permissions on the device nodes and they are fine, the same problem occurs when running as root. What I do: 1) Press the HotSync Button on my crade 2) Run ./pilot-xfer -p usb:/dev/ugen0 --sync /home/amistry/bk 3) Watch it fail Thanks, -- Anish Mistry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Weird problems with BIND 8.3.1-REL
Matthew Dillon wrote: I am having weird problems with BIND. It started happening about a month and a half ago. named would start returning immediate host name lookup failures for just about everything and never recover. That's not good. :) I assume you're using it as a resolver from the dump. I dumped named in one of these instances. The dump file (500K) is temporarily at: http://apollo.backplane.com/named_dump.db . If there are any DNS gurus out there I would appreciate a look-see. Unfortunately, the db is generally not the problem. The only way to diagnose it is to up the debug level and log what's happening while it's actually broken. Is anyone aware of any issues with named? I see that the current version in the tree appears to be 8.3.2-T1B (which I just installed a second ago). I just updated the bind8 port to 8.3.2-RELEASE, which I recommend that you run instead. I saw some weird problems with the pre-release versions of 8.3.2 that seem to be fixed now. I also added a new knob to the port so you can make -DREPLACE_SYSTEM_BIND install and have it update the stuff in /usr instead of installing to /usr/local. Good luck, Doug -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Ultra320 drivers?
Jonathan Lemon wrote: I have an IBM box that has a dual LSI 53c1030 controller on the motherboard. Our SYM driver doesn't appear to have support for this device; under Linux it is supported by a Fusion/MPT driver from LSI. Any chance of getting a driver for this chip? I have an IA64 box with a 1030 as well. :-/ 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: Cyrus vs. UW IMAP (was: Re: I Volunteer)
Lyndon Nerenberg wrote: Terry Personally, I think SASL should have specified that you Terry crypt(3) the passwords, and then use the resulting hash as Terry the password value for the shared secret on both ends. At Terry least that way, you would not have to pass cleartext to use Terry the UNIX account database. The problem with this is that if you serve up your password database via NIS an attacker can grab the crypt()ed password and use it to perform a forged authentication. I understand this. Which is why you don't use NIS, or at least do not make it externally accessible. The exchange would have to include the salt, anyway, or the client couldn't crypt the value to the correct hash. The point is really to allow all the SASL methods to be used by a client, when all the server has is a UNIX password database. Even you've got to admit that storing crypted passwords on the server is better than permitting unprivilged applications access to the plaintext passwords. 8-). Note that in the next revision of the IMAP4 spec STARTTLS will be mandatory to implement. Yeah, this is incredibly bogus. The proper way of handling this is SSL. It's very easy to man-in-the-middle a session that starts out unencrypted when a STARTTLS goes by for SMTP; it is just as easy for anything else that uses that rather bogus method. 8-(. -- TErry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: (jail) problem and a (possible) solution ?
Patrick Thomas wrote: How do you increase KVA space these days ? I see that in earlier releases you had to edit /sys/conf/ldscript.i386 and /sys/i386/include/pmap.h and do all sorts of crazy stuff. What is the procedure in 4.5-RELEASE (please say just change KVA_PAGES=260 to KVA_PAGES=512) That's what you want me to do, right ? Is that all - can it be done just by changing that one value in my kernel config ? It's what I want you to do. For 4.5, you have to hack ldscript.i386 and pmap.h. I've posted on how to do this before (should be in the archives). The pages are all going to be off-by-one from your calculations, for the recursive page mapping, or off-by-two if your kernel is an SMP kernel, for the per CPU page, so remember that, or you will end up with a kernel that simply doesn't boot. The easiest way is to look at the numbers in pmap.h, and figure out how they relate to 0xc000 (remember to OR in 0x0010 after your math, to count the kernel loading at 1M). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: (jail) problem and a (possible) solution ?
I think I'll just decrease my swap size from 2 gigs to 1 gig - is that a reasonable alternative that provides the same benefit and possible solution to this problem ? ...since bsically 0 swap has ever been used on the machine anyway... --PT On Sat, 22 Jun 2002, Terry Lambert wrote: Patrick Thomas wrote: How do you increase KVA space these days ? I see that in earlier releases you had to edit /sys/conf/ldscript.i386 and /sys/i386/include/pmap.h and do all sorts of crazy stuff. What is the procedure in 4.5-RELEASE (please say just change KVA_PAGES=260 to KVA_PAGES=512) That's what you want me to do, right ? Is that all - can it be done just by changing that one value in my kernel config ? It's what I want you to do. For 4.5, you have to hack ldscript.i386 and pmap.h. I've posted on how to do this before (should be in the archives). The pages are all going to be off-by-one from your calculations, for the recursive page mapping, or off-by-two if your kernel is an SMP kernel, for the per CPU page, so remember that, or you will end up with a kernel that simply doesn't boot. The easiest way is to look at the numbers in pmap.h, and figure out how they relate to 0xc000 (remember to OR in 0x0010 after your math, to count the kernel loading at 1M). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD NFS server benchmarks vs. OpenBSD, NetBSD?
On Fri, Jun 21, 2002 at 09:57:55AM -0400, Matt Simerson wrote: FreeBSD has very solid NFS code in addition to being a very robust, versatile, and downright fun operating system. It's very easy to do everything I want to with FreeBSD. It's NFS is missing locking support but it's very fast and works very well with FreeBSD and Mac OS X clients. I haven't used it with anything else. Actually Matt Jacob has some NFS testsuites that makes FreeBSD servers blow chunks. Solaris still is the most robust NFS server of the general purpose UNIXes. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD NFS server benchmarks vs. OpenBSD, NetBSD?
On Sat, 22 Jun 2002, David O'Brien wrote: Actually Matt Jacob has some NFS testsuites that makes FreeBSD servers blow chunks. Solaris still is the most robust NFS server of the general purpose UNIXes. I'm quite happy with the performance of my SGI machines as NFS servers. They're quite robust in my experience. I'd love to find some time to beat up on them a bit and compare my results to Slowlaris and FreeBSD. Brandon D. Valentine -- http://www.geekpunk.net [EMAIL PROTECTED] ++[++-][++-].[+-][+-]+.+++..++ +.+[++-]++.+++..+++.--..+. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
bge driver not working in Dell 2650
Anyone get the Broadcom BCM5701 gigibit ethernet working on new Dell 2650? I noted it has been fixed in latest STABLE branch from freebsd-hacker list. http://www.geocrawler.com/mail/thread.php3?subject=Broadcom+BCM5701+GigE+Ethernet+problems%3F%3Flist=159 I grabed the latest -STABLE branch but it still doesn't work for the Dell 2650. Any clues? Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Weird problems with BIND 8.3.1-REL
David O'Brien wrote: On Sat, Jun 22, 2002 at 02:52:19PM -0700, Doug Barton wrote: version in the tree appears to be 8.3.2-T1B (which I just installed a second ago). I just updated the bind8 port to 8.3.2-RELEASE, which I recommend that you run instead. I saw some weird problems with the pre-release versions Any reason to not import that version into /usr/src/contrib/bind? I'm actually working on that, but there are a few bogons I need to clean up first. -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: inuring FreeBSD to the apache bug without upgrading apache ?
On Thu, 20 Jun 2002 19:59:20 -0700 Terry Lambert [EMAIL PROTECTED] wrote: Patrick Thomas wrote: Is it possible to patch/recompile FreeBSD 4.5 in such a way that your system is no longer vulnerable to the chunking attack, even if you are still running a vulnerable apache ? Not FreeBSD, but it's possible to reconfigure Apache. The way you would deal with this would be to tell Apache that it was an HTTP 1.0 server, since chunking is an HTTP 1.1 feature. I've found a better solution! On today's freshports there is something called mod_blowchunks :-) If installed, it will reject chunking and log it. This is an alternative to upgrading Apache. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD NFS server benchmarks vs. OpenBSD, NetBSD?
* David O'Brien [EMAIL PROTECTED] [020622 19:28] wrote: On Fri, Jun 21, 2002 at 09:57:55AM -0400, Matt Simerson wrote: FreeBSD has very solid NFS code in addition to being a very robust, versatile, and downright fun operating system. It's very easy to do everything I want to with FreeBSD. It's NFS is missing locking support but it's very fast and works very well with FreeBSD and Mac OS X clients. I haven't used it with anything else. Actually FreeBSD 5.x should have lockd support. I should know, I ported it from BSD/os. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
