NFS broken in -CURRENT as of 16 hours ago?
Hi all, I might be completely off here, but since I did a update/buildkernel/buildworld yesterday evening, NFS seems to act up. I can mount a remote NFS resource locally and access it, but when I try to access a subdirectory it seems to hang and never return. I currently have two zombie mc-processes (midnight commander) due to this, and ls'ing the subdirs hangs infinitely. I have absolutely no clue what else the cause could be. I'm always very careful to only change one thing at a time (ok this was two things, kernel and world..) and then check that my working environment is OK. Mergemaster replaced two files, mac.conf and motd. Anyone else seeing the same or something similiar? Oh and for the record, I am right now unable to start rxvt. Xterm works. And now rxvt works again. Something funky is going on :) Could this be related to the last major change, the dynamic root? /Eirik signature.asc Description: This is a digitally signed message part
Re: sound patch for pop crackles
Hi, I've now finally managed to test this, a bit later than I anticipated. It does help the situation quite a lot, but I still have sound problems. They are much less audible now, as I cannot hear any crackles and pops. However in music with a steady rythm I notice that every now and then it must be skipping some frames or repeating some, because the rythm simply isn't right! I had a hard time believing this, so I made a semi-blind-test (after a while I could tell which box it was because of the sound signature) between two machines I have, one 4.9 and one 5.x-CURRENT with your patch, playing the same files using the same player. System load does not enter the picture, I've tried this both while running 99% idle and while running make -j 5 buildkernel. I'm on an IBM ThinkPad T21 with a snd_csa-driven card, 1ghz P3. To me it almost sounds like when I enabled PCI retries on OS/2 back in the day .. Any idea how to check this is not enabled here? /Eirik On Wed, 2003-11-12 at 19:36, Mathew Kanner wrote: Hello All, Could people experiencing pops and crackles try the attached patch and set hw.snd.fragps=128. This patch also fixes select on vchans. more details in http://www.freebsd.org/cgi/query-pr.cgi?pr=59208 Thanks, --Mat signature.asc Description: This is a digitally signed message part
Re: More ULE bugs fixed.
Sheldon Hearn wrote: On (2003/11/04 15:46), Jeff Roberson wrote: The thing is, I'm using 4BSD, not ULE, so I wouldn't trouble Jeff to look for a cause for that specific problem in ULE. How long have you been seeing this? Are you using a usb mouse? Can you try with PS/2 if you are? Since my last update, Fri Oct 24 17:47:22. I am using a USB mouse, but don't have a PS/2 one. I'm also using moused, and my WM is sawfish. The problem with all these reports is that they're scattered. It's hard to pin down exactly what the common elements are. Indeed, we may be looking at combinations of elements. I don't have time to be more helpful, which is why I hadn't complained. I just wanted to include the datapoint that over-active mouse behaviour under load exists under SCHED_4BSD as well. Incidentally, this is under ATA disk load. I don't really push my CPU. Though I am not a hardcore C programmer, much less a FreeBSD contributor in any way, I do have some experience in tracking down problems like this. Used to have a lot of them on some of the more obscure platforms I've been using in the past. My feeling is (and it might be completely wrong ofcourse) that we are dealing with atleast two completely separate issues here. The first has to do with mouse jerkiness, the second has to do with bogus mouse events. There is a significant difference between these two, and personally I am leaning towards concluding that the first has to do with the scheduler, and the second has to do with something entirely different - interrupt handler or something else of the sorts. The first is simply that the mouse stops for a brief moment and then continues from the point where it stopped. Perhaps this is the situation that is remedied by bypassing moused? Is moused perhaps not getting the CPU cycles it needs to process and pass on mouse messages? The second is that mouse messages are actually *lost*, or bogus ones are being generated. I guess it's the first, making moused or X misinterpret the messages it gets. Where along the chain it fails I obviously have no clue. The consequence of this is that when the mouse stops (like in #1) but then resumes from an entirely different point - be it 10 pixels away or at the other end of the screen - possibly even generating a button push (but not necessarily the corresponding button release) message. These two situations could at first sight be mistaken for being the same symptom, but I am pretty sure they are very different. One may influence the other, or they may by coincidence (or for some good reason) happen at the same time, but I believe the errors happen in different parts of the kernel. When you say you get the bogus mouse events (which I believe you are saying atleast ;) only during load, I'm immediately thinking that yes, that might make sense. But I guess that's better left to those who are in the know to decide ;) I have never seen it happen with the 4BSD scheduler, but that might have other reasons (hardware?). Why don't you try with the new interrupt handler? Helped me quite a lot.. :) /Eirik Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More ULE bugs fixed.
Matthew D. Fuller wrote: On Wed, Nov 05, 2003 at 11:28:50AM +0100 I heard the voice of Eirik Oeverby, and lo! it spake thus: The second is that mouse messages are actually *lost*, or bogus ones are being generated. I guess it's the first, making moused or X misinterpret the messages it gets. Where along the chain it fails I obviously have no clue. The consequence of this is that when the mouse stops (like in #1) but then resumes from an entirely different point - be it 10 pixels away or at the other end of the screen - possibly even generating a button push (but not necessarily the corresponding button release) message. Note that I've had this to a greater or lesser extent for as long as I can remember (certainly back to 3.0-CURRENT). It corresponds with syslog'd messages on my xconsole along the lines of: Nov 3 12:46:13 mortis kernel: psmintr: out of sync (00c0 != ). Nov 3 12:46:13 mortis kernel: psmintr: discard a byte (12). It's certainly a lot more common (by orders of magnitude) on 5.x in the past... oh, I dunno, year-ish, than it was previously. I lose mouse function for maybe a second, then it squirms itself off somewhere on the screen and sends some button press events. I'm currently running 5.1-R, the traditional scheduler, a PS/2 mouse with no moused. And since I got them (much more rarely) with earlier 5-CURRENT's, and with 4-CURRENT's, etc, I can't see how it's scheduler related. No idea, but I never got messages like the ones you mention, and it has absolutely never happened on 4.x or with SCHED_4BSD. Weirdness. :) /Eirik When you say you get the bogus mouse events (which I believe you are saying atleast ;) only during load, I'm immediately thinking that yes, that might make sense. I don't get it only under load; sometimes from flat idle. However, it's usually when I first move the mouse, after it sitting still for a while (where 'while' can vary from a few seconds to a few days, of course); it hardly ever happens in mid-move. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: Committing new interrupt code, tree will be broken
John Baldwin wrote: I'm committing the new i386 interrupt and SMP code, so buckle your seat belts. :) I'll be intentionally breaking the kernel build at the start and re-enable it with the last commit when I am done. Is this *only* for SMP systems, or will the interrupt code also affect UNIprocessor boxes (like my laptop)? I'm suspecting some interrupt loss here, so I might give this new code a spin around the block. /Eirik ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More ULE bugs fixed.
Jeff Roberson wrote: On Mon, 3 Nov 2003, Eirik Oeverby wrote: Hi, Just recompiled yesterday, running sched_ule.c 1.75. It seems to have re-introduced the bogus mouse events I talked about earlier, after a period of having no problems with it. The change happened between 1.69 and 1.75, and there's also the occational glitch in keyboard input. How unfortunate, it seems to have fixed other problems. Can you describe the mouse problem? Is it jittery constantly or only under load? Or are you having other problems? Have you tried reverting to SCHED_4BSD? What window manager do you run? The problem is two parts: The mouse tends to 'lock up' for brief moments when the system is under load, in particular during heavy UI operations or when doing compile jobs and such. The second part of the problem is related, and is manifested by the mouse actually making movements I never asked it to make. It's almost as if messages passed from the mouse (PS/2 type) through the kernel are being corrupted or lost - moving the mouse slowly in one direction will suddenly make it jump half across the screen and continue. Also it will quite often produce bogus clicks and drags, i.e. I'll be moving the mouse across the screen and suddenly it grabs something and doesn't let go - as if it got a MouseRightDown event but no MouseRightRelease event (or whatever they are called in the world you are in - I'm coming from OS/2 and other obscure platforms ;). The second problem usually follows the first - it's more likely to happen when the system is under some kind of load. Heavy window repainting/updating (Mozilla Thunderbird is a prime example, but other apps can be just as guilty), compile jobs, VMWare going crazy with the CPU, heavy disk/network I/O .. Anything that places load on the system/kernel can cause this. Running with SCHED_4BSD completely solves these problems, and the bogus mouse event problems did NOT appear with sched_ule 1.69 (which is the last one I tried before 1.75). It did appear with ~1.50 and thereabouts though (as reported earlier in this thread). I'm currently running WindowMaker as window manager, but the problem also exists in Gnome and xfce4. Gnome is more likely to exhibit the problem even during low system loads, given that it's more violent UI-wise. You are right though, the later sched_ule revisions DO seem to be better in many other respects - overall performance 'feels' better (atleast in console mode). The mouse issues makes X kinda hard to use though. Btw you might be interested in knowing that the keyboard from time to time shows what I think is bogus input aswell - I have a consistently higher rate of failure when typing with sched_ule 1.75 than I had with 1.69, and it definitely feels as if keystrokes are getting lost or repeated when they shouldn't be. Not often, had two or three 'suspicious' typos while writing this message, and I am reluctant to say it's a definite kernel issue, because I'm nowhere near a perfect typist - but it is nevertheless worth noting and might even be worth looking into. Might there be a connection between this and the mouse issues? Thanks, /Eirik Thanks for the report. Cheers, Jeff If you need me to do anything to track this down, let me know. I am, and have always been, running with moused, on a uniprocessor box (ThinkPad T21 1ghz p3). Best regards, /Eirik Jeff Roberson wrote: On Fri, 31 Oct 2003, Bruno Van Den Bossche wrote: Jeff Roberson [EMAIL PROTECTED] wrote: On Wed, 29 Oct 2003, Jeff Roberson wrote: On Thu, 30 Oct 2003, Bruce Evans wrote: Test for scheduling buildworlds: cd /usr/src/usr.bin for i in obj depend all do MAKEOBJDIRPREFIX=/somewhere/obj time make -s -j16 $i done /tmp/zqz 21 (Run this with an empty /somewhere/obj. The all stage doesn't quite finish.) On an ABIT BP6 system with a 400MHz and a 366MHz CPU, with/usr (including /usr/src) nfs-mounted (with 100 Mbps ethernet and a reasonably fast server) and /somewhere/obj ufs1-mounted (on a fairly slow disk; no soft-updates), this gives the following times: SCHED_ULE-yesterday, with not so careful setup: 40.37 real 8.26 user 6.26 sys 278.90 real59.35 user41.32 sys 341.82 real 307.38 user69.01 sys SCHED_ULE-today, run immediately after booting: 41.51 real 7.97 user 6.42 sys 306.64 real59.66 user40.68 sys 346.48 real 305.54 user69.97 sys SCHED_4BSD-yesterday, with not so careful setup: [same as today except the depend step was 10 seconds slower (real)] SCHED_4BSD-today, run immediately after booting: 18.89 real 8.01 user 6.66 sys 128.17 real58.33 user43.61 sys 291.59 real 308.48 user72.33 sys SCHED_4BSD-yesterday, with a UP kernel (running on the 366 MHz CPU) with many local changes and not so careful setup: 17.39 real 8.28 user 5.49 sys
Re: More ULE bugs fixed.
Sheldon Hearn wrote: On (2003/11/04 09:29), Eirik Oeverby wrote: The problem is two parts: The mouse tends to 'lock up' for brief moments when the system is under load, in particular during heavy UI operations or when doing compile jobs and such. The second part of the problem is related, and is manifested by the mouse actually making movements I never asked it to make. Wow, I just assumed it was a local problem. I'm also seeing unrequested mouse movement, as if the signals from movements are repeated or amplified. The thing is, I'm using 4BSD, not ULE, so I wouldn't trouble Jeff to look for a cause for that specific problem in ULE. That is indeed interesting. When I return to 4BSD, everything works very nicely. Perhaps this is some interrupt issue or something? I'll recompile tonight and try with a new kernel (new interrupt stuff for i386 has been checked in recently) and report back. Sorry about the (possibly) false alarm! /Eirik Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Was: More ULE bugs fixed. Is: Mouse problem?
Just for those interested: I do *not* get any messages at all from the kernel (or elsewhere) when my mouse goes haywire. And it's an absolute truth (just tested back and forth 8 times) that it *only* happens with SCHED_ULE and *only* with old versions (~1.50) and the very latest ones (1.75 as I'm currently running). 1.69 for instance did *not* show any such problems. I will, however, update my kernel again now, to get the latest sched_ule.c (if any changes have been made since 1.75) and to test with the new interrupt handler. I have a suspicion it might be a combination of SCHED_ULE and some signal/message/interrupt handling causing messages to get lost along the way. Because that's exactly how it feels... Greetings, /Eirik Morten Johansen wrote: On Tue, 4 Nov 2003, Sheldon Hearn wrote: On (2003/11/04 09:29), Eirik Oeverby wrote: The problem is two parts: The mouse tends to 'lock up' for brief moments when the system is under load, in particular during heavy UI operations or when doing compile jobs and such. The second part of the problem is related, and is manifested by the mouse actually making movements I never asked it to make. Wow, I just assumed it was a local problem. I'm also seeing unrequested mouse movement, as if the signals from movements are repeated or amplified. The thing is, I'm using 4BSD, not ULE, so I wouldn't trouble Jeff to look for a cause for that specific problem in ULE. Me too. Have had this problem since I got a Intellimouse PS/2 wheel-mouse. (It worked fine with previous mice (no wheel)). With any scheduler in 5-CURRENT and even more frequent in 4-STABLE, IIRC. Using moused or not doesn't make a difference. Get these messages on console: psmintr: out of sync, and the mouse freezes then goes wild for a few seconds. Can happen under load and sometimes when closing Mozilla (not often). It could be related to the psm-driver. Or maybe I have a bad mouse, I don't know. I will try another mouse, but it does work perfectly in Linux and Windogs... mj ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Was: More ULE bugs fixed. Is: Mouse problem?
Eirik Oeverby wrote: Just for those interested: I do *not* get any messages at all from the kernel (or elsewhere) when my mouse goes haywire. And it's an absolute truth (just tested back and forth 8 times) that it *only* happens with SCHED_ULE and *only* with old versions (~1.50) and the very latest ones (1.75 as I'm currently running). 1.69 for instance did *not* show any such problems. I will, however, update my kernel again now, to get the latest sched_ule.c (if any changes have been made since 1.75) and to test with the new interrupt handler. I have a suspicion it might be a combination of SCHED_ULE and some signal/message/interrupt handling causing messages to get lost along the way. Because that's exactly how it feels... Whee. Either the bump from sched_ule.c 1.75 to 1.77 changed something back to the old status, or the new interrupt handling has had some major influence. All I can say is - wow. My system is now more responsive than ever, I cannot (so far) reproduce any mouse jerkiness or bogus input or anything, and things seem smoother. As always I cannot guarantee that this report is not influenced by the placebo effect, but I do feel that it's a very real improvement. The fact that I can start VMWare, Firebird, Thunderbird, Gaim and gkrellm at the same time without having *one* mouse hickup speaks for itself. I couldn't even do that with ULE. So Jeff or whoever did the interrupt stuff - what did you do? /Eirik Greetings, /Eirik Morten Johansen wrote: On Tue, 4 Nov 2003, Sheldon Hearn wrote: On (2003/11/04 09:29), Eirik Oeverby wrote: The problem is two parts: The mouse tends to 'lock up' for brief moments when the system is under load, in particular during heavy UI operations or when doing compile jobs and such. The second part of the problem is related, and is manifested by the mouse actually making movements I never asked it to make. Wow, I just assumed it was a local problem. I'm also seeing unrequested mouse movement, as if the signals from movements are repeated or amplified. The thing is, I'm using 4BSD, not ULE, so I wouldn't trouble Jeff to look for a cause for that specific problem in ULE. Me too. Have had this problem since I got a Intellimouse PS/2 wheel-mouse. (It worked fine with previous mice (no wheel)). With any scheduler in 5-CURRENT and even more frequent in 4-STABLE, IIRC. Using moused or not doesn't make a difference. Get these messages on console: psmintr: out of sync, and the mouse freezes then goes wild for a few seconds. Can happen under load and sometimes when closing Mozilla (not often). It could be related to the psm-driver. Or maybe I have a bad mouse, I don't know. I will try another mouse, but it does work perfectly in Linux and Windogs... mj ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Was: More ULE bugs fixed. Is: Mouse problem?
Eirik Oeverby wrote: Eirik Oeverby wrote: Just for those interested: I do *not* get any messages at all from the kernel (or elsewhere) when my mouse goes haywire. And it's an absolute truth (just tested back and forth 8 times) that it *only* happens with SCHED_ULE and *only* with old versions (~1.50) and the very latest ones (1.75 as I'm currently running). 1.69 for instance did *not* show any such problems. I will, however, update my kernel again now, to get the latest sched_ule.c (if any changes have been made since 1.75) and to test with the new interrupt handler. I have a suspicion it might be a combination of SCHED_ULE and some signal/message/interrupt handling causing messages to get lost along the way. Because that's exactly how it feels... Whee. Either the bump from sched_ule.c 1.75 to 1.77 changed something back to the old status, or the new interrupt handling has had some major influence. All I can say is - wow. My system is now more responsive than ever, I cannot (so far) reproduce any mouse jerkiness or bogus input or anything, and things seem smoother. As always I cannot guarantee that this report is not influenced by the placebo effect, but I do feel that it's a very real improvement. The fact that I can start VMWare, Firebird, Thunderbird, Gaim and gkrellm at the same time without having *one* mouse hickup speaks for itself. I couldn't even do that with ULE. So Jeff or whoever did the interrupt stuff - what did you do? Oh and just to add to the goods/bads: A make -j 16 buildworld still makes the box sluggish when it gets to the crypto stuff, but not anywhere close to what it was like before. I'd say it probably matches or beats ULE now. And one *major* thing: I can now play sound again! Without clicks or pops like I've had since 5.1-RELEASE .. I can play sound for real! *meep* *meep* what a relief! This upped my QOL (quality-of-life) quite significantly, given that I haven't been able to play music (wihout being annoyed beyond what is good for me or anyone else near) since, what, spring? *phew* Thanks, to whomever of you guys made this possible... /Eirik /Eirik Greetings, /Eirik Morten Johansen wrote: On Tue, 4 Nov 2003, Sheldon Hearn wrote: On (2003/11/04 09:29), Eirik Oeverby wrote: The problem is two parts: The mouse tends to 'lock up' for brief moments when the system is under load, in particular during heavy UI operations or when doing compile jobs and such. The second part of the problem is related, and is manifested by the mouse actually making movements I never asked it to make. Wow, I just assumed it was a local problem. I'm also seeing unrequested mouse movement, as if the signals from movements are repeated or amplified. The thing is, I'm using 4BSD, not ULE, so I wouldn't trouble Jeff to look for a cause for that specific problem in ULE. Me too. Have had this problem since I got a Intellimouse PS/2 wheel-mouse. (It worked fine with previous mice (no wheel)). With any scheduler in 5-CURRENT and even more frequent in 4-STABLE, IIRC. Using moused or not doesn't make a difference. Get these messages on console: psmintr: out of sync, and the mouse freezes then goes wild for a few seconds. Can happen under load and sometimes when closing Mozilla (not often). It could be related to the psm-driver. Or maybe I have a bad mouse, I don't know. I will try another mouse, but it does work perfectly in Linux and Windogs... mj ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Was: More ULE bugs fixed. Is: Mouse problem?
Alex Wilkinson wrote: On Wed, Nov 05, 2003 at 12:27:04AM +0100, Eirik Oeverby wrote: Just for those interested: I do *not* get any messages at all from the kernel (or elsewhere) when my mouse goes haywire. And it's an absolute truth (just tested back and forth 8 times) that it *only* happens with SCHED_ULE and *only* with old versions (~1.50) and the very latest ones (1.75 as I'm currently running). 1.69 for instance did *not* show any such problems. I will, however, update my kernel again now, to get the latest sched_ule.c (if any changes have been made since 1.75) and to test with the new interrupt handler. I have a suspicion it might be a combination of SCHED_ULE and some signal/message/interrupt handling causing messages to get lost along the way. Because that's exactly how it feels... Question: How can I find out what verion of SCHED_ULE I am running ? I asked the same recently, and here's what I know: - check /usr/src/sys/kern/sched_ule.c - a page or so down there's a line with the revision - ident /boot/kernel/kernel | grep sched_ule /Eirik - aW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More ULE bugs fixed.
Hi, Just recompiled yesterday, running sched_ule.c 1.75. It seems to have re-introduced the bogus mouse events I talked about earlier, after a period of having no problems with it. The change happened between 1.69 and 1.75, and there's also the occational glitch in keyboard input. If you need me to do anything to track this down, let me know. I am, and have always been, running with moused, on a uniprocessor box (ThinkPad T21 1ghz p3). Best regards, /Eirik Jeff Roberson wrote: On Fri, 31 Oct 2003, Bruno Van Den Bossche wrote: Jeff Roberson [EMAIL PROTECTED] wrote: On Wed, 29 Oct 2003, Jeff Roberson wrote: On Thu, 30 Oct 2003, Bruce Evans wrote: Test for scheduling buildworlds: cd /usr/src/usr.bin for i in obj depend all do MAKEOBJDIRPREFIX=/somewhere/obj time make -s -j16 $i done /tmp/zqz 21 (Run this with an empty /somewhere/obj. The all stage doesn't quite finish.) On an ABIT BP6 system with a 400MHz and a 366MHz CPU, with/usr (including /usr/src) nfs-mounted (with 100 Mbps ethernet and a reasonably fast server) and /somewhere/obj ufs1-mounted (on a fairly slow disk; no soft-updates), this gives the following times: SCHED_ULE-yesterday, with not so careful setup: 40.37 real 8.26 user 6.26 sys 278.90 real59.35 user41.32 sys 341.82 real 307.38 user69.01 sys SCHED_ULE-today, run immediately after booting: 41.51 real 7.97 user 6.42 sys 306.64 real59.66 user40.68 sys 346.48 real 305.54 user69.97 sys SCHED_4BSD-yesterday, with not so careful setup: [same as today except the depend step was 10 seconds slower (real)] SCHED_4BSD-today, run immediately after booting: 18.89 real 8.01 user 6.66 sys 128.17 real58.33 user43.61 sys 291.59 real 308.48 user72.33 sys SCHED_4BSD-yesterday, with a UP kernel (running on the 366 MHz CPU) with many local changes and not so careful setup: 17.39 real 8.28 user 5.49 sys 130.51 real60.97 user34.63 sys 390.68 real 310.78 user60.55 sys Summary: SCHED_ULE was more than twice as slow as SCHED_4BSD for the obj and depend stages. These stages have little parallelism. SCHED_ULE was only 19% slower for the all stage. ... I reran this with -current (sched_ule.c 1.68, etc.). Result: no significant change. However, with a UP kernel there was no significant difference between the times for SCHED_ULE and SCHED_4BSD. There was a significant difference on UP until last week. I'm working on SMP now. I have some patches but they aren't quite ready yet. I have commited my SMP fixes. I would appreciate it if you could post update results. ULE now outperforms 4BSD in a single threaded kernel compile and performs almost identically in a 16 way make. I still have a few more things that I can do to improve the situation. I would expect ULE to pull further ahead in the months to come. I recently had to complete a little piece of software in a course on parallel computing. I've put it online[1] (we only had to write the pract2.cpp file). It calculates the inverse of a Vandermonde matrix and allows you to spawn multiple slave-processes who each perform a part of the work. Everything happens in memory so I've used it lately to test the different changes you made to sched_ule.c and these last fixes do improve the performance on my dual p3 machine a lot. Here are the results of my (very limited tests) : sched4bsd --- dimension slaves time 10001 90.925408 10002 58.897038 200 1 0.735962 200 2 0.676660 sched_ule 1.68 --- dimension slaves time 10001 90.951015 10002 70.402845 200 1 0.743551 200 2 1.900455 sched_ule 1.70 --- dimension slaves time 10001 90.782309 10002 57.207351 200 1 0.739998 200 2 0.383545 I'm not really sure if this is very relevant to you, but from the end-user point of view (me :-)) this does means something. Thanks! I welcome the feedback, positive or negative, as it helps me improve things. Thanks for the report! Could you run this again under 4bsd and ULE with the following in your .cshrc: set time= ( 5 %Uu %Ss %E %P %X+%Dk %I+%Oio %Fpf+%Ww %cc/%ww ) And then time ./testpract 200 2, etc. This will give me a few hints about what's impacting your performance. Thanks! Jeff [1] http://users.pandora.be/bomberboy/mptest/final.tar.bz2 It can be used by running testpract2 with two arguments, the dimension of the matrix and the number of slaves. example './testpract2 200 2' will create a matrix with
Re: ULE page fault with sched_ule.c 1.67
Hi, Jeff Roberson wrote: On Mon, 27 Oct 2003, Jonathan Fosburgh wrote: On Monday 27 October 2003 12:06 pm, Arjan van Leeuwen wrote: Hi, I just cvsupped and built a new kernel that includes sched_ule.c 1.67. I'm getting a page fault when working in Mozilla Firebird. It happens pretty soon, after opening one or two pages. The trace shows that it panics at sched_prio(). I should have said, I am getting the same panic, same trace, but not using Mozilla. I get it shortly after launching my KDE session, though I'm not sure where in my session the problem is being hit. It's KSE. You can disable it to work around temporarily. I will fix it tonight. I tried KSE with sched_ule.c 1.65 this weekend, and my computer would freeze hard very soon after starting X. I assumed it to be a problem with ULE+KSE, so I disabled KSE again. Would this problem be related to or the same as the one described here? Thanks, /Eirik ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More ULE bugs fixed.
Thanks. I should have known =) /Eirik Maxime Henrion wrote: Eirik Oeverby wrote: As a side note/question: Is there any way to figure out which ULE version I'm running in a precompiled kernel? I just nuked my src tree by accident, and am not sure if i'm on 1.65 or something older.. If there is no way, is this perhaps an idea? Try ident /boot/kernel/kernel | grep sched_ule. Cheers, Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More ULE bugs fixed.
As a side note/question: Is there any way to figure out which ULE version I'm running in a precompiled kernel? I just nuked my src tree by accident, and am not sure if i'm on 1.65 or something older.. If there is no way, is this perhaps an idea? Thanks, /Eirik Jeff Roberson wrote: On Fri, 17 Oct 2003, Bruce Evans wrote: How would one test if it was an improvement on the 4BSD scheduler? It is not even competitive in my simple tests. [scripts results deleted] Summary: SCHED_ULE was more than twice as slow as SCHED_4BSD for the obj and depend stages. These stages have little parallelism. SCHED_ULE was only 19% slower for the all stage. It apparently misses many oppurtunities to actually run useful processes. This may be related to /usr being nfs mounted. There is lots of idling waiting for nfs even in the SCHED_4BSD case. The system times are smaller for SCHED_ULE, but this might not be significant. E.g., zeroing pages can account for several percent of the system time in buildworld, but on unbalanced systems that have too much idle time most page zero gets done in idle time and doesn't show up in the system time. At one point ULE was at least as fast as 4BSD and in most cases faster. This is a regression. I'll sort it out soon. Test 1 for fair scheduling related to niceness: for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 do nice -$i sh -c while :; do echo -n;done done top -o time [Output deleted]. This shows only a vague correlation between niceness and runtime for SCHED_ULE. However, top -o cpu shows a strong correlation between %CPU and niceness. Apparently, %CPU is very innacurate and/or not enough history is kept for long-term scheduling to be fair. Test 5 for fair scheduling related to niceness: for i in -20 -16 -12 -8 -4 0 4 8 12 16 20 do nice -$i sh -c while :; do echo -n;done done time top -o cpu With SCHED_ULE, this now hangs the system, but it worked yesterday. Today it doesn't get as far as running top and it stops the nfs server responding. To unhang the system and see what the above does, run a shell at rtprio 0 and start top before the above, and use top to kill processes (I normally use killall sh to kill all the shells generated by tests 1-5, but killall doesn't work if it is on nfs when the nfs server is not responding). 661 root 112 -20 900K 608K RUN 0:24 27.80% 27.64% sh 662 root 114 -16 900K 608K RUN 0:19 12.43% 12.35% sh 663 root 114 -12 900K 608K RUN 0:15 10.66% 10.60% sh 664 root 114 -8 900K 608K RUN 0:11 9.38% 9.33% sh 665 root 115 -4 900K 608K RUN 0:10 7.91% 7.86% sh 666 root 1150 900K 608K RUN 0:07 6.83% 6.79% sh 667 root 1154 900K 608K RUN 0:06 5.01% 4.98% sh 668 root 1158 900K 608K RUN 0:04 3.83% 3.81% sh 669 root 115 12 900K 608K RUN 0:02 2.21% 2.20% sh 670 root 115 16 900K 608K RUN 0:01 0.93% 0.93% sh I think you cvsup'd at a bad time. I fixed a bug that would have caused the system to lock up in this case late last night. On my system it freezes for a few seconds and then returns. I can stop that by turning down the interactivity threshold. Thanks, Jeff Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More ULE bugs fixed.
Jeff Roberson wrote: On Wed, 15 Oct 2003, Eirik Oeverby wrote: Eirik Oeverby wrote: Jeff Roberson wrote: I fixed two bugs that were exposed due to more of the kernel running outside of Giant. ULE had some issues with priority propagation that stopped it from working very well. Things should be much improved. Feedback, as always, is welcome. I'd like to look into making this the default scheduler for 5.2 if things start looking up. I hope that scares you all into using it more. :-) Hi.. Just tested, so far it seems good. System CPU load is floored (near 0), system is very responsive, no mouse sluggishness or random mouse/keyboard input. Doing a make -j 20 buildworld now (on my 1ghz p3 thinkpad ;), and running some SQLServer stuff in VMWare. We'll see how it fares. Hi, just a followup message. I'm now running the buildworld mentioned above, and the system is pretty much unusable. It exhibits the same symptoms as I have mentioned before, mouse jumpiness, bogus mouse input (movement, clicks), and the system is generally very jerky and unresponsive. This is particularily evident when doing things like webpage loading/browsing/rendering, but it's noticeable all the time, no matter what I am doing. As an example, the last sentence I wote without seeing a single character on screen before I was finsihed writing it, and it appeared with a lot more typos than I usually make ;) I'm running *without* invariants and witness right now, i.e. a kernel 100% equal to the SCHED_4BSD kernel. Can you confirm the revision of your sys/kern/sched_ule.c file? How does SCHED_4BSD respond in this same test? Yes I can. From file: __FBSDID($FreeBSD: src/sys/kern/sched_ule.c,v 1.59 2003/10/15 07:47:06 jeff Exp $); I am running SCHED_4BSD now, with a make -j 20 buildworld running, and I do not experience any of the problems. Keyboard and mouse input is smooth, and though apps run slightly slower due to the massive load on the system, there is none of the jerkiness I have seen before. Anything else I can do to help? /Eirik Thanks, Jeff Best regards, /Eirik ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More ULE bugs fixed.
Jeff Roberson wrote: On Thu, 16 Oct 2003, Eirik Oeverby wrote: Jeff Roberson wrote: On Wed, 15 Oct 2003, Eirik Oeverby wrote: Eirik Oeverby wrote: Jeff Roberson wrote: I fixed two bugs that were exposed due to more of the kernel running outside of Giant. ULE had some issues with priority propagation that stopped it from working very well. Things should be much improved. Feedback, as always, is welcome. I'd like to look into making this the default scheduler for 5.2 if things start looking up. I hope that scares you all into using it more. :-) Hi.. Just tested, so far it seems good. System CPU load is floored (near 0), system is very responsive, no mouse sluggishness or random mouse/keyboard input. Doing a make -j 20 buildworld now (on my 1ghz p3 thinkpad ;), and running some SQLServer stuff in VMWare. We'll see how it fares. Hi, just a followup message. I'm now running the buildworld mentioned above, and the system is pretty much unusable. It exhibits the same symptoms as I have mentioned before, mouse jumpiness, bogus mouse input (movement, clicks), and the system is generally very jerky and unresponsive. This is particularily evident when doing things like webpage loading/browsing/rendering, but it's noticeable all the time, no matter what I am doing. As an example, the last sentence I wote without seeing a single character on screen before I was finsihed writing it, and it appeared with a lot more typos than I usually make ;) I'm running *without* invariants and witness right now, i.e. a kernel 100% equal to the SCHED_4BSD kernel. Can you confirm the revision of your sys/kern/sched_ule.c file? How does SCHED_4BSD respond in this same test? Yes I can. From file: __FBSDID($FreeBSD: src/sys/kern/sched_ule.c,v 1.59 2003/10/15 07:47:06 jeff Exp $); I am running SCHED_4BSD now, with a make -j 20 buildworld running, and I do not experience any of the problems. Keyboard and mouse input is smooth, and though apps run slightly slower due to the massive load on the system, there is none of the jerkiness I have seen before. Anything else I can do to help? Yup, try again. :-) I found another bug and tuned some parameters of the scheduler. The bug was introduced after I did my paper for BSDCon and so I never ran into it when I was doing serious stress testing. Hopefully this will be a huge improvement. I did a make -j16 buildworld and used mozilla while in kde2. It was fine unless I tried to scroll around rapidly in a page full of several megabyte images for many minutes. It is. Still not perfect, but now it's somewhere around the 4BSD mark I would say. Think about 'make buildworld' is that it doesn't get real tough before it hits some of the larger directories, like the crypto stuff etc., where there are many .c files in one dir - before it gets that far, there are at most 2 or 3 cc1 processes going concurrently. As soon as I get 10-20 of them, things start getting sluggish, but I suppose it's hard to avoid that. What disturbs me somewhat, though, is that I get some of this sluggishness (and other symptoms i've mentioned before) even when i'm running 'nice -n 20 make -j 20 buildworld' .. meaning the cc1 processes and all that are running (very) nice. The fact that I still have issues even when doing that, would lead me to think the problem is somewhere else than in the scheduler.. Now I can't say I'm completely sure if this is also the case with 4BSD - I only tested the nice stuff after the last reboot. But all in all, things are better now than yesterday morning. Kudos! /Eirik ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More ULE bugs fixed.
Jeff Roberson wrote: I fixed two bugs that were exposed due to more of the kernel running outside of Giant. ULE had some issues with priority propagation that stopped it from working very well. Things should be much improved. Feedback, as always, is welcome. I'd like to look into making this the default scheduler for 5.2 if things start looking up. I hope that scares you all into using it more. :-) Hi.. Just tested, so far it seems good. System CPU load is floored (near 0), system is very responsive, no mouse sluggishness or random mouse/keyboard input. Doing a make -j 20 buildworld now (on my 1ghz p3 thinkpad ;), and running some SQLServer stuff in VMWare. We'll see how it fares. Thanks, /Eirik ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More ULE bugs fixed.
Eirik Oeverby wrote: Jeff Roberson wrote: I fixed two bugs that were exposed due to more of the kernel running outside of Giant. ULE had some issues with priority propagation that stopped it from working very well. Things should be much improved. Feedback, as always, is welcome. I'd like to look into making this the default scheduler for 5.2 if things start looking up. I hope that scares you all into using it more. :-) Hi.. Just tested, so far it seems good. System CPU load is floored (near 0), system is very responsive, no mouse sluggishness or random mouse/keyboard input. Doing a make -j 20 buildworld now (on my 1ghz p3 thinkpad ;), and running some SQLServer stuff in VMWare. We'll see how it fares. Hi, just a followup message. I'm now running the buildworld mentioned above, and the system is pretty much unusable. It exhibits the same symptoms as I have mentioned before, mouse jumpiness, bogus mouse input (movement, clicks), and the system is generally very jerky and unresponsive. This is particularily evident when doing things like webpage loading/browsing/rendering, but it's noticeable all the time, no matter what I am doing. As an example, the last sentence I wote without seeing a single character on screen before I was finsihed writing it, and it appeared with a lot more typos than I usually make ;) I'm running *without* invariants and witness right now, i.e. a kernel 100% equal to the SCHED_4BSD kernel. Best regards, /Eirik ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE Update
Thanks for this update, I've been trying to make a SCHED_ULE enabled kernel work here for a few days now, thinking it would be about time to test it again (last time was ~2 months ago), but ata issues have kept me from booting it successfully. Now I know for sure I can give it atleast another week - maybe both ata and sched issues can be ironed out by then ;) Thanks for your efforts. /Eirik On Fri, 10 Oct 2003 04:01:28 -0400 (EDT) Jeff Roberson [EMAIL PROTECTED] wrote: I have reproduced the lagging mouse issue on my laptop. I tried moused to no effect. Eventually, I grudgingly installed kde and immediately started encountering problems with mouse lag. It would seem that twm was not stressing my machine in the same ways that kde is. ;-) I suspect a problem with IPC. I will know more soon. There have also been a few reports of problems related to nice. I was able to reproduce some awkward behavior but I have nothing conclusive yet. There is still a known issue with hyperthreading. I'm waiting on some of john baldwin's work to fix this. If you halt logical cpus your machine will hang. Expect some resolution on the ULE problems within a week or so. Thanks for the detailed bug reports everyone. Cheers, Jeff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Buildkernel with SCHED_ULE fails
Hi, Can someone tell me what is needed to play with the new scheduler these days? I seem to be completely unable to compile my kernel with it enabled, getting lots of undefined references to sched_*. Have I missed some critical information? /Eirik ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 To all the english speaking on this list, I'm sorry for this small internal joke - but when I observe two danes thinking they are the only ones to understand their language, I need to remind them otherwise ;) Si for all del ikke noe dritt om meg, for jeg forstår dere ; /Eirik On 07 Sep 2003 19:44:10 +0200 Christian Laursen [EMAIL PROTECTED] wrote: Soren Schmidt [EMAIL PROTECTED] writes: I have one other report of problems on the older Acer chips, I must have screwed something up there. I'll dig out my old ASUS board and see what I can find out... Great, I'll be happy to test stuff. Bortset fra det kunne vi da snakke dansk ku' vi ikke ? :) Jo, men så forstår de andre jo ikke så meget. :) -- Med venlig hilsen Christian Laursen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/W3dZdAvR8ct7fEcRAivPAJ9+CW462hrRVoiN5W2axzacfw+EJACZAUS/ NPHoaGVNJlhhHbTfjEieVGM= =nJMz -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snd_csa issues in -CURRENT
I might also point out that there are two distinct kinds of distortion happening: The click/pop/crackle kind of distortion, and one where a sound buffer is repeated over and over 5-10 times - as if the hardware has some kind of hickup. Again - this *only* happens in -CURRENT, not in -STABLE or in any other OS (tested OS/2, BeOS, Linux, winXX). Anyone? :) /Eirik On Wed, 27 Aug 2003 11:03:54 +0200 Eirik Oeverby [EMAIL PROTECTED] wrote: Hi all, Since I upgraded from 4.8 to 5.1, I've been following the -CURRENT branch, doing a new kernel/world roughly once a week. Since the upgrade, and without exception, I have had some issues with the snd_csa driver that are slowly getting on my nerves. Whenever I play back audio, be it mp3's or oggs or videos, no matter what player I use, there will be occational clicks and pops and hickups in the sound. This was most definitely not the case on 4.8, so something must have happened either to the driver or to the subsystems its talking to, causing this to happen. My sound chipset is, according to pciconf -l -v : [EMAIL PROTECTED]:5:0: class=0x040100 card=0x01531014 chip=0x60031013 rev=0x01 hdr=0x00 'Cirrus Logic' device = 'Crystal CS4610/14/22/24/30 SoundFusion PCI Audio Accelerator' This is a IBM ThinkPad T21, and the rest of pciconf -l -v is listed below. If anyone has a clue, I'd appreciate whatever hints to get rid of these distortions. Apart from them, audio works fine - no instabilities or anything. Best regards, Eirik Oeverby [EMAIL PROTECTED] ~$ pciconf -l -v [EMAIL PROTECTED]:0:0: class=0x06 card=0x chip=0x71908086 rev=0x03 hdr=0x00vendor = 'Intel Corporation' device = '82443BX/ZX 440BX/ZX CPU to PCI Bridge (AGP Implemented)' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:1:0: class=0x060400 card=0x chip=0x71918086 rev=0x03 hdr=0x01vendor = 'Intel Corporation' device = '82443BX/ZX 440BX/ZX AGPset PCI-to-PCI bridge' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:2:0: class=0x060700 card=0x01301014 chip=0xac1b104c rev=0x03 hdr=0x02vendor = 'Texas Instruments (TI)' device = 'PCI1450 PC card CardBus Controller' class= bridge subclass = PCI-CardBus [EMAIL PROTECTED]:2:1: class=0x060700 card=0x01301014 chip=0xac1b104c rev=0x03 hdr=0x02vendor = 'Texas Instruments (TI)' device = 'PCI1450 PC card CardBus Controller' class= bridge subclass = PCI-CardBus [EMAIL PROTECTED]:3:0: class=0x02 card=0x24088086 chip=0x12298086 rev=0x09 hdr=0x00vendor = 'Intel Corporation' device = '82557/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class= network subclass = ethernet [EMAIL PROTECTED]:3:1: class=0x070002 card=0x24088086 chip=0x000c115d rev=0x00 hdr=0x00vendor = 'Xircom' device = 'MPCI 3A56GSP-100 PA Mini-PCI V.90 56k Modem' class= simple comms subclass = UART [EMAIL PROTECTED]:5:0: class=0x040100 card=0x01531014 chip=0x60031013 rev=0x01 hdr=0x00vendor = 'Cirrus Logic' device = 'Crystal CS4610/14/22/24/30 SoundFusion PCI Audio Accelerator'class= multimedia subclass = audio [EMAIL PROTECTED]:7:0: class=0x068000 card=0x chip=0x71108086 rev=0x02 hdr=0x00vendor = 'Intel Corporation' device = '82371AB/EB/MB PIIX4/4E/4M ISA Bridge' class= bridge subclass = PCI-unknown [EMAIL PROTECTED]:7:1: class=0x010180 card=0x chip=0x71118086 rev=0x01 hdr=0x00vendor = 'Intel Corporation' device = '82371AB/EB/MB PIIX4/4E/4M IDE Controller' class= mass storage subclass = ATA [EMAIL PROTECTED]:7:2: class=0x0c0300 card=0x chip=0x71128086 rev=0x01 hdr=0x00vendor = 'Intel Corporation' device = '82371AB/EB/MB PIIX4/4E/4M USB Interface' class= serial bus subclass = USB [EMAIL PROTECTED]:7:3: class=0x068000 card=0x chip=0x71138086 rev=0x03 hdr=0x00vendor = 'Intel Corporation' device = '82371AB/EB/MB PIIX4/4E/4M Power Management Controller' class= bridge subclass = PCI-unknown [EMAIL PROTECTED]:0:0: class=0x03 card=0x017f1014 chip=0x8c125333 rev=0x13 hdr=0x00vendor = 'S3 Incorporated' device = '86C270 Savage/MX,274 Savage/IX,290 Savage/MX+MV,294 Savage/IX+MV'class= display subclass = VGA [EMAIL PROTECTED]:0:0: class=0x0c0010 card=0x chip=0x8023104c rev=0x00 hdr=0x00vendor = 'Texas Instruments (TI)' device = 'TSB43AB22/A IEEE1394a-2000 OHCI PHY/Link-Layer Ctrlr' class= serial bus subclass = FireWire [EMAIL PROTECTED] ~$ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http
snd_csa issues in -CURRENT
Hi all, Since I upgraded from 4.8 to 5.1, I've been following the -CURRENT branch, doing a new kernel/world roughly once a week. Since the upgrade, and without exception, I have had some issues with the snd_csa driver that are slowly getting on my nerves. Whenever I play back audio, be it mp3's or oggs or videos, no matter what player I use, there will be occational clicks and pops and hickups in the sound. This was most definitely not the case on 4.8, so something must have happened either to the driver or to the subsystems its talking to, causing this to happen. My sound chipset is, according to pciconf -l -v : [EMAIL PROTECTED]:5:0: class=0x040100 card=0x01531014 chip=0x60031013 rev=0x01 hdr=0x00 'Cirrus Logic' device = 'Crystal CS4610/14/22/24/30 SoundFusion PCI Audio Accelerator' This is a IBM ThinkPad T21, and the rest of pciconf -l -v is listed below. If anyone has a clue, I'd appreciate whatever hints to get rid of these distortions. Apart from them, audio works fine - no instabilities or anything. Best regards, Eirik Oeverby [EMAIL PROTECTED] ~$ pciconf -l -v [EMAIL PROTECTED]:0:0: class=0x06 card=0x chip=0x71908086 rev=0x03 hdr=0x00vendor = 'Intel Corporation' device = '82443BX/ZX 440BX/ZX CPU to PCI Bridge (AGP Implemented)' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:1:0: class=0x060400 card=0x chip=0x71918086 rev=0x03 hdr=0x01vendor = 'Intel Corporation' device = '82443BX/ZX 440BX/ZX AGPset PCI-to-PCI bridge' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:2:0: class=0x060700 card=0x01301014 chip=0xac1b104c rev=0x03 hdr=0x02vendor = 'Texas Instruments (TI)' device = 'PCI1450 PC card CardBus Controller' class= bridge subclass = PCI-CardBus [EMAIL PROTECTED]:2:1: class=0x060700 card=0x01301014 chip=0xac1b104c rev=0x03 hdr=0x02vendor = 'Texas Instruments (TI)' device = 'PCI1450 PC card CardBus Controller' class= bridge subclass = PCI-CardBus [EMAIL PROTECTED]:3:0: class=0x02 card=0x24088086 chip=0x12298086 rev=0x09 hdr=0x00vendor = 'Intel Corporation' device = '82557/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class= network subclass = ethernet [EMAIL PROTECTED]:3:1: class=0x070002 card=0x24088086 chip=0x000c115d rev=0x00 hdr=0x00vendor = 'Xircom' device = 'MPCI 3A56GSP-100 PA Mini-PCI V.90 56k Modem' class= simple comms subclass = UART [EMAIL PROTECTED]:5:0: class=0x040100 card=0x01531014 chip=0x60031013 rev=0x01 hdr=0x00vendor = 'Cirrus Logic' device = 'Crystal CS4610/14/22/24/30 SoundFusion PCI Audio Accelerator'class= multimedia subclass = audio [EMAIL PROTECTED]:7:0: class=0x068000 card=0x chip=0x71108086 rev=0x02 hdr=0x00vendor = 'Intel Corporation' device = '82371AB/EB/MB PIIX4/4E/4M ISA Bridge' class= bridge subclass = PCI-unknown [EMAIL PROTECTED]:7:1: class=0x010180 card=0x chip=0x71118086 rev=0x01 hdr=0x00vendor = 'Intel Corporation' device = '82371AB/EB/MB PIIX4/4E/4M IDE Controller' class= mass storage subclass = ATA [EMAIL PROTECTED]:7:2: class=0x0c0300 card=0x chip=0x71128086 rev=0x01 hdr=0x00vendor = 'Intel Corporation' device = '82371AB/EB/MB PIIX4/4E/4M USB Interface' class= serial bus subclass = USB [EMAIL PROTECTED]:7:3: class=0x068000 card=0x chip=0x71138086 rev=0x03 hdr=0x00vendor = 'Intel Corporation' device = '82371AB/EB/MB PIIX4/4E/4M Power Management Controller' class= bridge subclass = PCI-unknown [EMAIL PROTECTED]:0:0: class=0x03 card=0x017f1014 chip=0x8c125333 rev=0x13 hdr=0x00vendor = 'S3 Incorporated' device = '86C270 Savage/MX,274 Savage/IX,290 Savage/MX+MV,294 Savage/IX+MV'class= display subclass = VGA [EMAIL PROTECTED]:0:0: class=0x0c0010 card=0x chip=0x8023104c rev=0x00 hdr=0x00vendor = 'Texas Instruments (TI)' device = 'TSB43AB22/A IEEE1394a-2000 OHCI PHY/Link-Layer Ctrlr' class= serial bus subclass = FireWire [EMAIL PROTECTED] ~$ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TESTERS WANTED for ATAng preview 1
Hi, I've just compiled ATAng into my kernel, and I'm currently running it - but I had to rip out my CD-ROM to make it work. I wasn't able to grab the exact wording of the error, but it was something along the lines of a failure to identify ata1-slave - which I suppose is my CD-ROM player. It then retries and gets an error (error=0), then freezes. This is a IBM ThinkPad T21, so taking out the CD-ROM is a trivial task, but at some point I'm gonna need it again (it's actually a DVD/CD-RW combodrive)... Otherwise the driver seems to work with the 60gb IBM drive I have in my laptop. No funny behaviour so far. ;) Best regards, /Eirik pgp0.pgp Description: PGP signature
Re: Dhclient fix for systems with media settings
Hi, Then I shall provide what I possibly can. When using dhclient to configure my wi-driven lucent card (latest firmware), it will work for a while (varying number of minutes - up to 30 or so) and then stop working, while spitting out messages like: wi0: bad alloc 55c != 2a2, cur 0 nxt 0 wi0: device timeout wi0: bad alloc 573 != 2a2, cur 0 nxt 0 wi0: device timeout and wi0: timeout in wi_seek to fc02/0 wi0: timeout in wi_seek to fc03/0 Pulling the card and re-inserting it + restarting dhclient will give me a network link again for another few minutes, then the same story happens again. I have never seen this problem when using a static IP - my uptime is currently well over a week and I haven't had to reconfigure once. Hope this helps. Best regards, /Eirik On Tue, 05 Aug 2003 08:56:38 -0600 (MDT) M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Martin Blapp [EMAIL PROTECTED] writes: : Is this going to cure the cases where using DHCP results in my network: link going dead about ~30 minutes after getting a lease? At that point: it starts spitting out timeout errors and stuff, and i have to: unplug/replug the card and re-start dhclient to get connectivity again..: : Unless the lease time was ~30 minutes and you've changed networks, I doubt it.: : This sounds like a if_wi driver problem. Warner should be able to tell you: more. I still don't have a clear problem statement. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: Dhclient fix for systems with media settings
Hi,
Is this going to cure the cases where using DHCP results in my network
link going dead about ~30 minutes after getting a lease? At that point
it starts spitting out timeout errors and stuff, and i have to
unplug/replug the card and re-start dhclient to get connectivity again..
Thanks for the efforts =)
/Eirik
On Tue, 5 Aug 2003 10:45:18 +0200 (CEST)
Martin Blapp [EMAIL PROTECTED] wrote:
Hi all,
If you used wi(4) or en(4) wavelan cards and you had problems with
dhclient, you should try this patch, which treats interfaces with
media settings differently.
http://people.freebsd.org/~mbr/patches/dhclient-interfacepolling-fixup.diff
I'll produce a more clean patch this evening, and also adapt the patch
to the ISC style, so it can be submitted again.
--- src/contrib/isc-dhcp/includes/dhcpd.h.origMon Aug 4 23:57:06 2003
+++ src/contrib/isc-dhcp/includes/dhcpd.h Mon Aug 4 23:57:37 2003
@@ -782,6 +782,7 @@
char name [IFNAMSIZ]; /* Its name... */
int linkstatus; /* Link status */
int ieee802;/* True if media is ieee802 */
+ int mediaflag; /* True if dhclient.conf has media settings */
int index; /* Its index. */
int rfdesc; /* Its read file descriptor. */
int wfdesc; /* Its write file descriptor, if
--- src/contrib/isc-dhcp/client/dhclient.c.orig Tue Aug 5 00:42:37 2003
+++ src/contrib/isc-dhcp/client/dhclient.cTue Aug 5 10:01:17 2003
@@ -257,7 +257,9 @@
log_fatal (%s: interface name too long (max %ld),
argv [i], (long)strlen (argv [i]));
strlcpy (tmp - name, argv [i], IFNAMSIZ);
- set_ieee802(tmp);
+#ifdef __FreeBSD__
+ set_ieee80211(tmp);
+#endif
tmp-linkstatus = interface_active(tmp);
if (interfaces) {
interface_reference (tmp - next,
@@ -412,7 +414,16 @@
INTERFACE_AUTOMATIC)) !=
INTERFACE_REQUESTED))
continue;
- set_ieee802(ip);
+#ifdef __FreeBSD__
+ set_ieee80211(ip);
+#endif
+#ifdef ENABLE_POLLING_MODE
+ if (ip - client - config - media != NULL)
+ ip-mediaflag = 1;
+ else
+ ip-mediaflag = 0;
+#endif /* ifdef ENABLE_POLLING_MODE */
+
script_init (ip - client,
PREINIT, (struct string_list *)0);
if (ip - client - alias)
@@ -1385,9 +1396,6 @@
int interval;
int increase = 1;
- if (interface_active(client - interface) == 0)
- return;
-
/* Figure out how long it's been since we started transmitting.
*/ interval = cur_time - client - first_sending;
@@ -1427,6 +1435,9 @@
}
}
+ if (interface_active(client - interface) == 0)
+ return;
+
/* If we're supposed to increase the interval, do so. If it's
currently zero (i.e., we haven't sent any packets yet), set
it to one; otherwise, add to it a random number between
@@ -3215,14 +3226,29 @@
if (ifmr.ifm_status IFM_AVALID) {
if (ip-ieee802) {
if ((IFM_TYPE(ifmr.ifm_active) == IFM_IEEE80211)
- (ifmr.ifm_status IFM_ACTIVE))
+ (ifmr.ifm_status IFM_ACTIVE)) {
+ if (ip-mediaflag
+ ip - client - state != S_BOUND)
+ return (2);
return (1);
+ }
} else {
- if (ifmr.ifm_status IFM_ACTIVE)
+ if (ifmr.ifm_status IFM_ACTIVE) {
+ if (ip-mediaflag
+ ip - client - state != S_BOUND)
+ return (2);
return (1);
+ }
}
}
+ /*
+ * If dhclient.conf contains media settings, we cannot
+ * abort if the interface is not set to active mode.
+ */
+ if (ip-mediaflag ip - client - state != S_BOUND)
+ return (1);
+
return (0);
#else /* ifdef __FreeBSD__ */
@@ -3231,7 +3257,7 @@
}
#ifdef __FreeBSD__
-set_ieee802 (struct interface_info *ip) {
+set_ieee80211 (struct interface_info *ip) {
struct ieee80211req ireq;
u_int8_tdata[32];
@@ -3267,12 +3293,20 @@
#endif /* __FreeBSD__ */
#ifdef ENABLE_POLLING_MODE
+/* Go to background after some time */
+void state_background (cpp)
Re: Lucent IBSS mode doesn't work in -CURRENT?
Sorry, I missed the point that it had once worked. However, the point still needs to be made that in the past I have had varying success with various firmware revisions, but the latest revision is the only one that has worked everywhere I have tried it. Good thing I didn't install the kernel I built yesterday, if that means my wi-driven lucent card would stop working =) To the maintainers: Take your time. Better do it right than do it quick and dirty. It works in 4.x, and 5.x is not considered stable yet so if anyone expects everything to work they are in error. /Eirik On Mon, 4 Aug 2003 19:15:54 +0930 Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: On Monday, 4 August 2003 at 11:37:44 +0200, Brad Knowles wrote: At 11:51 PM -0600 2003/08/03, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: On Thursday, 31 July 2003 at 9:30:31 +0200, Eirik Oeverby wrote: Oh and btw.. Get the *latest* firmware onto all your cards. That is essential for anything to work right at all.. That sounds wrong to me. If it worked before, and it doesn't now, that's not the fault of the firmware. Quit harping on it, ok. We know there's a bug and carping like this makes me less willing to find and fix it. I'm confused. I agree that I have sometimes found Greg to be a bit annoying, but it seems to me that he's asking a perfectly legitimate question -- if things worked fine in the past (including the firmware versions at the time), and they don't work now, then why is a firmware update needed? I would ask: What changed so that things broke, and why can't we go back to the way things worked before? I think you're misunderstanding Warner. He's not disagreeing. My message wasn't directed at Warner, it was directed at Eirik. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: acpi - too hot, make world dies with various signals
Hi, Agree fully. I have the same problem on my ThinkPad T21 - as reported on this list earlier. Running without ACPI is no problem. Another problem when running with ACPI is that suspend mode doesn't turn the display off. Pretty annoying, and besides it will never come back from suspend either :) So for now I'm running without acpi all the time. Better that way. //Eirik On Sun, 3 Aug 2003 18:59:52 +1000 (EST) Tony Maher [EMAIL PROTECTED] wrote: Hello I attempted to do make buildworld on my N610c laptop but it kept dying with various signals *** Signal 4 *** Signal 11 The fan does go off and on in response to high CPU activity but I am guessing not enough and not soon enough. I rebooted with acpi disabled so that fan runs continuously (when there is AC power). Buildworld is now almost complete. It would be nice if acpiconf had option to switch cooling on (permanently) and off (well until acpi decided it was too hot). (Hmm maybe if I had of used 'acpiconf -d' I wouldn't have had to reboot and I could just disable thermal portion of acpi at boot. Wil that leave fan on when no ac power??? hmm.) Even better if acpi switched cooling on sooner. I'll try to look at it myself but that wont be till next weekend. But if anyone has patches or wants me to get debug info I'd be happy to try. thanks -- tonym ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: Lucent IBSS mode doesn't work in -CURRENT?
Hi, Are you sure? I believe the Win2k driver is still at the same level as the XP driver - you probably just need to download a newer one.. Correct me if I'm wrong. But I have a Sony Vaio thingie here with Win2k, and I've used that one to upgrade all my cards (Lucent, Orinoco and Avaya labelled - same card, different sticker). Can't recall which firmware version, though. Can I see that from fbsd? /Eirik Oh and btw.. Get the *latest* firmware onto all your cards. That is essential for anything to work right at all.. I'm stuck upgrading because my Windows 2K Lucent driver is too out of date for any of the newer firmware revs. I believe I need at least rev 6.1 of the Win2K driver to run any of the firmware update tools. How did you upgrade your firmware? If anyone has the bits+pieces to rev firmware I'd like it so I can test the wi driver w/ different firmware revs. Sam pgp0.pgp Description: PGP signature
Re: Lucent IBSS mode doesn't work in -CURRENT?
Hey, I have a few Orinoco cards, and they 'work' in both ad-hoc and infrastructure mode. However with dhclient it gets tricky, because it will only work the first time dhclient assigns an address to the card. Whenever it tries to refresh it or whatever, I start getting those timeout and busy bit errors, and network connectivity drops. This usually happens within a few minutes or latest after 30 minutes or so - probably depending on your dhcpd/dhclient configuration. Configuring a static IP lets me use the card, and it seems stable. I am really glad someone else is seeing this, perhaps it can get fixed some day :) Oh and btw.. Get the *latest* firmware onto all your cards. That is essential for anything to work right at all.. /Eirik On Thu, 31 Jul 2003 14:20:30 +0930 Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: Earlier this month I sent a message saying that my wireless card (Orinoco) doesn't work at all any more. In the meantime, I've narrowed the problem down to IBSS (ad-hoc) mode: it works fine in BSS (base station) mode. I'd like to know if *anybody* is using IBSS (maybe with Orinoco cards) on a -CURRENT newer than about mid-May. Here's a summary of what I see: It happens on two different cards with different firmware. The ifconfig and wicontrol outputs look identical modulo MAC address and IBSS channel. wi0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 ether 00:02:2d:04:09:3a media: IEEE 802.11 Wireless Ethernet autoselect (none) ssid stationname FreeBSD WaveLAN/IEEE node channel -1 authmode OPEN powersavemode OFF powersavesleep 100 wepmode OFF weptxkey 1 NIC serial number: [ ] Station name: [ FreeBSD WaveL ] SSID for IBSS creation: [ ] Current netname (SSID): [ ] Desired netname (SSID): [ ] Current BSSID: [ 00:00:00:00:00:00 ] Channel list: [ 7ff ] IBSS channel: [ 3 ] Current channel:[ 65535 ] Comms quality/signal/noise: [ 0 0 0 ] Promiscuous mode: [ Off ] Process 802.11b Frame: [ Off ] Intersil-Prism2 based card: [ 0 ] Port type (1=BSS, 3=ad-hoc):[ 1 ] MAC address:[ 00:02:2d:04:09:3a ] TX rate (selection):[ 0 ] TX rate (actual speed): [ 0 ] RTS/CTS handshake threshold:[ 2312 ] Create IBSS:[ Off ] Access point density: [ 1 ] Power Mgmt (1=on, 0=off): [ 0 ] Max sleep time: [ 100 ] WEP encryption: [ Off ] TX encryption key: [ 1 ] Encryption keys:[ ][ ][ ][ ] wi0: Lucent Technologies WaveLAN/IEEE at port 0x100-0x13f irq 11 function 0 config 1 on pccard1 wi0: 802.11 address: 00:02:2d:04:09:3a wi0: using Lucent Technologies, WaveLAN/IEEE wi0: Lucent Firmware: Station (6.6.1) wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps wi0: Lucent Technologies WaveLAN/IEEE at port 0x100-0x13f irq 11 function 0 config 1 on pccard1 wi0: 802.11 address: 00:02:2d:1e:d9:60 wi0: using Lucent Technologies, WaveLAN/IEEE wi0: Lucent Firmware: Station (6.16.1) wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps When I run dhclient against the first card, I don't get a connection, and the other end doesn't see any data traffic, but it finds the network: wi0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::202:2dff:fe04:93a%wi0 prefixlen 64 scopeid 0x4 inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255 ether 00:02:2d:04:09:3a media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) status: associated ssid FOOXX 1:FOOXX stationname FreeBSD WaveLAN/IEEE node channel 3 authmode OPEN powersavemode OFF powersavesleep 100 wepmode OFF weptxkey 1 I had guessed that it might be turning WEP on without saying so, but setting WEP on at both ends didn't help either. The second card is much worse than the first: when I try to start dhclient against it, I get the following messages: wi0: timeout in wi_cmd 0x0002; event status 0x8080 wi0: timeout in wi_cmd 0x0121; event status 0x8080 wi0: wi_cmd: busy bit won't clear. This last one continues forever. At least the keyboard is locked, so I can't do anything (not even get into ddb, which might have been useful). While trying to power down I got these messages: wi0: failed to allocate 2372 bytes on NIC. wi0: tx buffer allocateion failed (error 12) After that, it continued until I finally managed to power down. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers
Re: Disk/FS I/O issues in -CURRENT
Thanks. I'll be keeping my eyes wide open for this one. /Eirik On Mon, 30 Jun 2003 15:30:06 -0500 Alan L. Cox [EMAIL PROTECTED] wrote: Peter Holm wrote: On Mon, Jun 30, 2003 at 03:26:13PM +0200, Eirik Oeverby wrote: Hi, Good to see I'm not the only one. I'm currently going back to a kernel dated 2003.06.27.12.00.00, and I'll test again with that one. Ok. I see that alc@ made some recent changes to the vm (vm_pageout.c). I don't know if there's any connection to this problem? I've been able to reproduce what I believe is the problem. (In my case, I reset my machine and watched the background fsck slowly grind to a halt. Foreground fsck is fine.) The problem actually appears to be in vm_page_alloc(), not vm_pageout.c. Look for a commit to resolve this in a few hours. Regards, Alan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: Updated ec-burst.diff patch
Hi, Can you be a bit more specific as to which other problems it fixes? I would love to try, because I have had some pretty nasty ACPI problems in the past, but I only have this one box to test on (my workstation) so I don't feel like going through the compile/install/fail/restore process if there isn't a good reason (for myself) to do so ;) (Just spent a weekend trying to find another kernel regression, I need to get some real work done soon) /Eirik On Tue, 1 Jul 2003 01:07:53 -0700 (PDT) Nate Lawson [EMAIL PROTECTED] wrote: Please download and try the new version. It correctly implements burst mode to the best of the 2.0 spec. Like the previous message, please report the appropriate dmesgs (acpi_ec0* and EC Waited*) and any errors or regression. I've tested du -a / while plugging/unplugging the power cable on my laptop many times with no errors. I haven't received any feedback yet. This WILL hit the tree in a few weeks because it fixes known problems. Test it now or test it then. :) Thanks, -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Disk/FS I/O issues in -CURRENT
Hi folks, I am having some very weird problems on my laptop, which I at first thought were due to a failing drive. However after a lot of testing and trial and error I've concluded that it must be a software problem - I'm smelling filesystem issues or something. Whenever I transfer large files to or from my harddrive, I will *always* get a lockup after ~480 MB transferred. Example scenario: - I use another machine to FTP to my laptop. - I start downloading a file of about 700 MB, and after ~480 MB it simply stops. The HD led on my laptop goes off, I can switch VTs but nothing else. Even keyboard input is non-functional. - After a few seconds another small burst of data (perhaps a few hundred KB or something) will go through, keyboard buffers will be processed, and then it freezes again with only one option - power off. C-A-D is a no-go. The IP stack is up though, I can ping the machine, and I can still change VTs. - If I pause/cancel the download immediately when it freezes, my laptop will come back to life a few seconds later. I can then start downloading another file, or resume the file I had started - everything seems to be back to normal. But whenever I hit ~480 MB transferred from *one* file, it will freeze again. - Downloading many smaller files in one batch, that sum up to 500 MB, is not a problem. All the above points applies to data transfer in the opposite direction aswell. Another way to reproduce this is doing a 'dd if=/dev/random of=testfile bs=8192', or the other way round - eventually (and after between 450 and 500 MB - a bit hard to tell) it will freeze. However, if I use a partition as the output instead of a file, it will *NOT* encounter any such problems. Transferring files between two partitions on the same HD also seems to work fine - atleast when using Midnight Commander. I first encountered the problem when using unison to sync my /home with another machine, and it got a hickup when it started finding these large files (ISOs and the like) and was scanning them to produce a checksum. Once I moved the large (450 MB) files out of the way, it worked nicely. When I started copying the files over manually, I experienced the freezes again. Moving the files to another partition before copying it to the external machine did not help the issue. I have ran the Drive Fitness Test from IBM (this is a ThinkPad T21) twice, and it finds no errors whatsoever. And I know for a fact that this problem did *not* occur with 5.1-RELEASE, as it was with that version I copied the files to my disk in the first place. I hope this information makes sense to someone. I suppose this is the punishment for following -CURRENT - but unfortunately 5.1-RELEASE had other issues that I couldn't live with. Best regards, /Eirik pgp0.pgp Description: PGP signature
VMWare not working anymore
Hi, As of yesterday (I think), VMWare 3.2.1 is no longer working on my 5-CURRENT box. When I try to start it, I get = [EMAIL PROTECTED] ~$ vmware Setting TMPDIR=/var/tmp. VMware Workstation Err VMware Workstation Error: Version mismatch with vmmon module: expecting 30.0, got 0.0. You have an incorrect version of the `vmmon' kernel module. Try reinstalling VMware Workstation. Press Enter to continue... ^C = A ps shows some parts are still running: [EMAIL PROTECTED] ~$ ps ax | grep vmw 652 p1 W 0:00.10 vmware-ui -A 7 -B 4 -S -L /var/tmp/vmware-ltning-651. 653 p1 W 0:00.08 vmware-mks -A 8 -B 5 -S -L /var/tmp/vmware-ltning-651 663 p1 S+ 0:00.01 grep vmw = And kldstat shows the vmmon module(s) are indeed loaded: [EMAIL PROTECTED] ~$ kldstat Id Refs AddressSize Name 1 16 0xc010 3f5758 kernel 21 0xc04f6000 4930cacpi.ko 31 0xc406c000 5000 linprocfs.ko 43 0xc42a2000 18000linux.ko 51 0xc41f5000 8000 vmmon_up.ko 61 0xc41f1000 2000 vmnet.ko 74 0xc437a000 11000netgraph.ko 82 0xc42be000 4000 ng_ether.ko 91 0xc4361000 5000 ng_bridge.ko 101 0xc42ba000 4000 ng_socket.ko = Anyone else seeing this? Anyone have an idea how to solve it? This is pretty bad, as I've just managed to get rid of my last Windows workstation, which I only used to run a development SQLServer. Guess where that DBMS (should be/is) running now.. :-/ /Eirik pgp0.pgp Description: PGP signature
Re: VMWare not working anymore
Hi, Reinstalling what? VMWare or FreeBSD? /Eirik On Mon, 30 Jun 2003, Lutz Bichler wrote: I got the same problem/message and solved it by reinstalling ;-) Lutz -- Lutz Bichler Institute for Software Technology, Department of Computer Science Univ. of the Fed. Armed Forces Munich, D-85577 Neubiberg, Germany TEL/FAX: +49(0)89 6004-2261/-4447 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Disk/FS I/O issues in -CURRENT
Hi, Good to see I'm not the only one. I'm currently going back to a kernel dated 2003.06.27.12.00.00, and I'll test again with that one. /Eirik On Mon, 30 Jun 2003, Peter Holm wrote: On Mon, Jun 30, 2003 at 01:42:15PM +0200, Eirik Oeverby wrote: Hi folks, I am having some very weird problems on my laptop, I can repeat the problem (noticed with savecore) on a kernel from Jun 30 05:23 UTC: current# df -h . FilesystemSize Used Avail Capacity Mounted on /dev/ad0s1f 8.2G 1.9G 5.6G25%/usr current# dd if=/dev/zero of=100mb bs=1024 count=102400 load: 4.04 cmd: dd 25063 [running] 0.33u 28.67s 4% 100k 97657+0 records in 97657+0 records out 10768 bytes transferred in 48.549837 secs (2059755 bytes/sec) db ps pid proc addruid ppid pgrp flag stat wmesgwchan cmd 25063 c1e5d3c8 cd19d0000 25060 25063 0004002 [RUNQ] dd 8 c197ed3c ccc9e0000 0 0 204 [CPU 0] pagedaemon db t 8 siointr1(c0b6c800,0,c051fcc5,693,c867abf0) at siointr1+0xd5 siointr(c0b6c800) at siointr+0x35 Xfastintr4() at Xfastintr4+0x63 --- interrupt, eip = 0xc0377480, esp = 0xc867abdc, ebp = 0xc867abf0 --- strncmp(c051e785,c051df68,123,0,477b) at strncmp witness_unlock(c059c280,8,c051e785,35c,1) at witness_unlock+0x5a _mtx_unlock_flags(c059c280,0,c051e785,35c,c0ba69ec) at _mtx_unlock_flags+0x80 vm_pageout_scan(0,0,c051e785,5dd,1f4) at vm_pageout_scan+0x40c vm_pageout(0,c867ad48,c0505bfc,312,0) at vm_pageout+0x2ce fork_exit(c04688d0,0,c867ad48) at fork_exit+0xc0 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xc867ad7c, ebp = 0 --- db ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Disk/FS I/O issues in -CURRENT
Hi, Kernel from 27.06 has same behaviour. I would prefer not to have to install yet another kernel right now, since I need to get some work done. If anyone else has any possible clues as to when this regression happened, that would help me (or whoever else would want to test by adding date=.mm.dd.hh.mm.ss to their supfile) determine what date to pick for testing. /Eirik On Mon, 30 Jun 2003 23:32:26 +1000 Mark Sergeant [EMAIL PROTECTED] wrote: I get the same problem on a smp machine and my laptop both running kernels as from today. On Mon, Jun 30, 2003 at 03:26:13PM +0200, Eirik Oeverby wrote: Hi, Good to see I'm not the only one. I'm currently going back to a kernel dated 2003.06.27.12.00.00, and I'll test again with that one. /Eirik On Mon, 30 Jun 2003, Peter Holm wrote: ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: Disk/FS I/O issues in -CURRENT
Hi, I've found a kernel that works, from the 20th of June. The regression happened somewhere between 2003.06.20.12.00.00 and 2003.06.27.12.00.00 ... Hope that helps. :) /Eirik On Mon, 30 Jun 2003 10:27:08 -0400 Josh Elsasser [EMAIL PROTECTED] wrote: I think I experienced the same bug on my Sony Vaio FX200 with -CURRENT from Sat Jun 28. I had an unrelated panic, and after rebooting, the machine locked up after a minute or so during the background fsck. After rebooting several times, I finally had to boot it single-user and fsck -y, which did not lock it up. Perhaps creating/using the filesystem snapshots was triggering the lockup. -jre On Mon, Jun 30, 2003 at 03:42:58PM +0200, Eirik Oeverby wrote: Hi, Kernel from 27.06 has same behaviour. I would prefer not to have to install yet another kernel right now, since I need to get some work done. If anyone else has any possible clues as to when this regression happened, that would help me (or whoever else would want to test by adding date=.mm.dd.hh.mm.ss to their supfile) determine what date to pick for testing. /Eirik On Mon, 30 Jun 2003 23:32:26 +1000 Mark Sergeant [EMAIL PROTECTED] wrote: I get the same problem on a smp machine and my laptop both running kernels as from today. On Mon, Jun 30, 2003 at 03:26:13PM +0200, Eirik Oeverby wrote: Hi, Good to see I'm not the only one. I'm currently going back to a kernel dated 2003.06.27.12.00.00, and I'll test again with that one. /Eirik On Mon, 30 Jun 2003, Peter Holm wrote: ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: world build fails since yesterday
Hi, My suspicion is that there are problems with current (as well with 5.1 and probably 5.0) with power management that will result in overheating, which will then look like a hardware problem. YES!!! Finally someone seeing something that could explain my problems!! My machine, after installing 5.1, constantly powered itself OFF while doing buildworld. It could do so during other times aswell, but doing a buildworld would be 100% certain (in the 10-15 cases I tried) to cause my laptop (a T21) to power down. However, this would only happen while in the docking station. Now that I've checked a bit further, it seems as if it's overheating - I've never had a problem carrying my laptop before, but after a power-down like that I was not able to touch it except around the edge and at the far end of where the CPU is located. Very disturbing. Now even more disturbing is this: In the docking station, -CURRENT *ONLY* works with ACPI enabled. If I disable ACPI, it won't even mount / - it hangs while trying. I'm suspecting that ACPI keeps my CPU fan from spinnning up or spinning fast enough - and I didn't even know ACPI could control that on my particular notebook. Buildworld with ACPI disabled is never a problem. /Eirik pgp0.pgp Description: PGP signature
Re: ACPI problems on Samsung Q10 (AE_AML_NO_RETURN_VALUE /AE_BAD_PARAMETER)
Hi, I'm seeing similiar things on my setup - both the ACPI Global Lock messages and the wi0 issues. In fact, the wi driver seems to be incredibly unstable - Every half hour or so I need to remove and re-insert the card to regain network connectivity (and ofcourse killall dhclient ; ifconfig wi0 ... ; dhclient wi0 ). I have described my problems in more detail in my thread 'ACPI issues on ThinkPad T21 + Dock'. /Eirik On Mon, 23 Jun 2003 10:40:06 +0200 Hendrik Scholz [EMAIL PROTECTED] wrote: Hi! I recently bought a Samsung Q10 and on both 5.1-RELEASE and -current I get these acpi errors: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #0: Sun Jun 22 19:00:44 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/DEIMOS Preloaded elf kernel /boot/kernel/kernel at 0xc04ee000. Preloaded elf module /boot/kernel/snd_ich.ko at 0xc04ee2bc. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc04ee368. Preloaded elf module /boot/kernel/acpi.ko at 0xc04ee414. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 996682387 Hz CPU: Mobile Intel(R) Pentium(R) III CPU - M 1000MHz (996.68-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6b4 Stepping = 4 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE, MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 393740288 (375 MB) avail memory = 376864768 (359 MB) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: PTLTDRSDT on motherboard pcibios: BIOS version 2.10 Using $PIR table, 9 entries at 0xc00fdf30 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz ACPI-1287: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-0175: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-1287: *** Error: Method execution failed [\\_SB_.BAT1._STA] (Node 0xc11ae480), AE_AML_NO_RETURN_VALUE ACPI-0175: *** Error: Method execution failed [\\_SB_.BAT1._STA] (Node 0xc11ae480), AE_AML_NO_RETURN_VALUE acpi_timer0: 24-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 ACPI-1287: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-0175: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-1287: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-0175: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-1287: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-0175: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-1287: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-0175: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-1287: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-0175: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-1287: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-0175: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-1287: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-0175: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-1287: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-0175: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-1287: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-0175: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-1287: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-0175: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-1287: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node 0xc11ae620), AE_AML_NO_RETURN_VALUE ACPI-0175: *** Error: Method execution failed [\\_SB_.ADP1._STA] (Node
Re: acpi patch for dell laptop?
Hi, doesn't work for several models.. Including Inspiron 7500. WHo knows enough about this to be able to look at debug info I have? John Baldwin has posted a patch which worked for me on my Thinkpad 600X with the same ACPI-0340 error. I tried this patch, and while it does get rid of that particular error message, I have a feeling it's (ACPI/the patch/or something) causing my system to overheat, making it power down after a while. Funny thing is that this only seems to happen while I'm in a dockingstation (ThinkPad T21 + Dock). And with ACPI disabled, the machine refuses totally to boot, it hangs at 'Mounting root from ...'. If I undock the machine, I can boot with and without ACPI, with the latter option being the only usable (stable) mode. /Eirik My system gives lots of: acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% ACPI-0432: *** Error: Handler for [EmbeddedControl] returned AE_ERROR ACPI-1287: *** Error: Method execution failed [\\_SB_.BAT1._STA] (Node 0xc167ed60), AE_ERROR ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER ad0: 24207MB IBM-DARA-225000 [49184/16/63] at ata0-master UDMA33 ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER acd0: DVD-ROM TOSHIBA DVD-ROM SD-C2402 at ata1-master UDMA33 Mounting root from ufs:/dev/ad0s4a ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER [...] On Sun, 22 Jun 2003, Kenneth D. Merry wrote: On Sat, Jun 21, 2003 at 00:13:10 +0200, Stijn Hoop wrote: On Fri, Jun 20, 2003 at 05:29:30PM -0400, Mike Sturdee wrote: Where can I find the latest, greatest patch that fixes this? Try this URL: http://sandcat.nl/~stijn/freebsd/dell.php and let me know if it works. It seems to work for me. The ACPI warnings about zero length buffers go away at least. I've got a Dell Inspirion 8500, A03 BIOS. Ken -- Kenneth Merry [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: acpi patch for dell laptop?
On Mon, 23 Jun 2003 10:53:32 -0400 Jesse Guardiani [EMAIL PROTECTED] wrote: And with ACPI disabled, the machine refuses totally to boot, it hangs at 'Mounting root from ...'. If I undock the machine, I can boot with and without ACPI, with the latter option being the only usable (stable) mode. Just out of curiosity, have you tried setting hw.pci.allow_unsupported_io_range=1 in your /boot/device.hints file? I've found that this option fixes many unbootable laptops - especially thinkpads. Hmm.. Yes, I think I have. Atleast it's in my device.hints file now - however I don't know if I tried docking it and booting without ACPI after I put that line in.. Perhaps I should try again, but my gut feeling tells me it's not gonna make any difference. Atleast as long as its undocked it had no effect on any of the other problems I'm experiencing. /Eirik pgp0.pgp Description: PGP signature
Re: Problem with wi in CURRENT (and 5.1)
Hi, this is exactly the problem I have with my wi-driven card aswell. I have a pretty standard Lucent card (Orinoco Silver, 64bit), PCMCIA, in my ThinkPad T21 (see another thread specifically about that machine and its issues with 5.1). It will work for a while, then start spitting out error messages like wi0: bad alloc 55c != 2a2, cur 0 nxt 0 wi0: device timeout wi0: bad alloc 573 != 2a2, cur 0 nxt 0 wi0: device timeout and wi0: timeout in wi_seek to fc02/0 wi0: timeout in wi_seek to fc03/0 and ofcourse the messages you describe. Pulling the card out and re-inserting it, then ifconfig, brings it back to life for a few minutes or as much as half an hour or so. At first I thought it was a signal level problem, but it's not. I also thought it's an encryption problem, but that's not it either. So I'm really confused - it worked perfectly for weeks on end with 4.8, and now in 5.1/CURRENT it screws me over like this. Firmware is at the latest level. Just my two cents to confirm your story ;) /Eirik On Mon, 23 Jun 2003 09:26:11 -0700 David O'Brien [EMAIL PROTECTED] wrote: On Tue, Jun 17, 2003 at 11:48:13AM +0100, Robert Hulme wrote: I'm having some problems with wi in 5-CURRENT and 5.1 in general. I'm using a Proxim Skyline 802.11b PC Card (which I believe uses the Prism 2 chipset). The PC Card is using the 0.3.0 primary and 0.8.3 secondary firmware (which I believe is the latest). I have a Dell Inspiron 8200. The card works fine in Windows XP and FreeBSD 5.0, but in 5.1 if I use ifconfig to bring up the card (for example during boot) it locks my laptop up for about a minute while I get loads of error messages appear on screen. Eventually I get a 'init failed' and 'tx buffer allocation failed (error 12)' error, and although ifconfig says the interface is up it doesn't actually work. See if there isn't updated firmware for your card. Rumor has it the MS-Windows driver uploads the latest firmware version into the RAM on the card. For Lucent cards you want any versoin 8 firmware from http://www.expressresponse.com/cgi-bin/proxim02/showFaq.cgi?session_id=1055265419.6837.7type=product=Client_Product ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: acpi patch for dell laptop?
Hi again, No workie. No difference in behaviour whatsoever. Sorry :( /Eirik On Mon, 23 Jun 2003 13:43:14 -0400 Jesse Guardiani [EMAIL PROTECTED] wrote: Eirik Oeverby wrote: On Mon, 23 Jun 2003 10:53:32 -0400 Jesse Guardiani [EMAIL PROTECTED] wrote: And with ACPI disabled, the machine refuses totally to boot, it hangs at 'Mounting root from ...'. If I undock the machine, I can boot with and without ACPI, with the latter option being the only usable (stable) mode. Just out of curiosity, have you tried setting hw.pci.allow_unsupported_io_range=1 in your /boot/device.hints file? I've found that this option fixes many unbootable laptops - especially thinkpads. Hmm.. Yes, I think I have. Atleast it's in my device.hints file now - however I don't know if I tried docking it and booting without ACPI after I put that line in.. Perhaps I should try again, but my gut feeling tells me it's not gonna make any difference. Atleast as long as its undocked it had no effect on any of the other problems I'm experiencing. Try again and let me know. /Eirik -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: acpi patch for dell laptop?
Crap. I just saw that I had no quotes around the '1'. Will it still get that setting, or do I have to change it and try again? (My line says hw.pci.allow_unsupported_io_range=1 while I believe (according to the other examples in the file) it should say hw.pci.allow_unsupported_io_range=1 . Does this make a difference?) /Eirik On Mon, 23 Jun 2003 22:40:40 +0200 Eirik Oeverby [EMAIL PROTECTED] wrote: Hi again, No workie. No difference in behaviour whatsoever. Sorry :( /Eirik On Mon, 23 Jun 2003 13:43:14 -0400 Jesse Guardiani [EMAIL PROTECTED] wrote: Eirik Oeverby wrote: On Mon, 23 Jun 2003 10:53:32 -0400 Jesse Guardiani [EMAIL PROTECTED] wrote: And with ACPI disabled, the machine refuses totally to boot, it hangs at 'Mounting root from ...'. If I undock the machine, I can boot with and without ACPI, with the latter option being the only usable (stable) mode. Just out of curiosity, have you tried setting hw.pci.allow_unsupported_io_range=1 in your /boot/device.hints file? I've found that this option fixes many unbootable laptops - especially thinkpads. Hmm.. Yes, I think I have. Atleast it's in my device.hints file now- however I don't know if I tried docking it and booting without ACPI after I put that line in.. Perhaps I should try again, but my gut feeling tells me it's not gonna make any difference. Atleast as long as its undocked it had no effect on any of the other problems I'm experiencing. Try again and let me know. /Eirik -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
RE: Email accounts on FreeBSD 5.1-RELEASE
Hi, Your language is not the problem, I think everyone here understands what you're saying, just not what you mean. I assume you want to give people e-mail accounts and nothing more. No SSH, no FTP, nothing. In that case, creating a full-blown system account is not only a waste of resources, it's also potentially insecure and adds a lot of administrative concerns. I'd suggest you go with a virtual-domain type of mail hosting. Personally I've used qmail (the mail server - you should replace sendmail with this one on your system anyway) with both vmailmgr and vpopmail, which go about slightly differently trying to solve roughly the same problem. Basically they implement their own authentication scheme, not requiring any system accounts (well .. one is needed for administration and storage of the virtual domains, but that can be either your own account or a special account you set up for that purpose). I'd say vpopmail is closest to what you want, atleast among the solutions I've tested personally. I suggest you do a bit of googling, there are several good HOWTOs out there describing in detail how to set up qmail and these tools. Sometimes you'll have to adopt it a bit for FreeBSD, but in general that's not a problem. Good luck! /Eirik On Fri, 2003-06-20 at 23:16, Alex Ayala wrote: Ok, maybe...yes I read what I wrote and didn't quite explain what I really wanted to say. I want to setup accounts on my box so users can retrieve emails by accessing my pop server. Do I need to setup user accounts on my box with the adduser command? I don't want them to be able to have access to the shell by any means. Is like when I wanted to give someone access to my ftp server I just created an account and took out the shell part in the passwd file. Sorry my english is not the greatest. Trying to explain something and can't find the right words. Is that a bit better to understand? A -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Murray Sent: Friday, June 20, 2003 4:51 PM To: Alex Ayala Cc: [EMAIL PROTECTED] Subject: Re: Email accounts on FreeBSD 5.1-RELEASE Alex Ayala writes: I got a question, if I want to create an email account on my Freebsd 5.1 box, but not let them have shell access do I just do a adduser and specify /sbin/nologin? If I want an off-road vehicle, do I just buy a Land Rover? It usually comes to quite a lot more than that, depending on what it is you want to do _exactly_. The above will work in certain circumstances, but simple testing will tell you that. What we can't tell is whether you need a Land Rover or a Bulldozer. :-) M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: ACPI issues on ThinkPad T21 + Dock
Stijn Hoop wrote: On Thu, Jun 19, 2003 at 09:33:41AM +0200, Eirik Oeverby wrote: - When booted with ACPI enabled (docked), the machine will at some point simply power itself off. I have seen people complaining about similiar machines powering themselves *on* after a power-off, but in my case it's the opposite. Out of nothing, with no warning (that I can see), it simply powers off. It's not suspend either, or hibernation or anything. Just a shot in the dark, but might it be heat? Most laptops/PCs turn themselves off to prevent them from overheating. Maybe ACPI doesn't turn on the fans when docked or something like that. Nope, since this never happened before 5.1. I've been running 4.8 and OS/2 on this machine before, always docked, and temperature was never an issue. It's possible that ACPI in 5.1 does this - after all it has some kind of thermal support, but I have tried to disable this and it makes no difference. Just to be on the safe side, would the following line in device.hints be correct for disabling the thermal part of acpi? debug.acpi.disable=thermal I think it would be, because replacing thermal with children made my system refuse to boot. No HW was detected ;) /Eirik signature.asc Description: This is a digitally signed message part
ACPI issues on ThinkPad T21 + Dock
Hello all! I've been tinkering with 5.1 (-current) for a while now, ever since it was released. I checked out code and recompiled my kernel as late as yesterday evening. Since the install, I have encountered a few problems that I'd like to discuss: - When my machine is docked, I *have to* enable ACPI, otherwise it will not boot past 'Mounting root from ufs:/dev/ad0s1a' (and the following WARNING about / not being unmounted cleanly, if the next point happened to be true) - When booted with ACPI enabled (docked), the machine will at some point simply power itself off. I have seen people complaining about similiar machines powering themselves *on* after a power-off, but in my case it's the opposite. Out of nothing, with no warning (that I can see), it simply powers off. It's not suspend either, or hibernation or anything. - I have not been able to reproduce any of these problems while the machine is undocked. In fact, it seems to work pretty well both on battery power and while plugged in - it's only while it's docked I'm having these problems. They are consistent and effectively keep me from using the computer while docked. If anyone wants to look more into this, I'll be happy to provide whatever information is necessary. Please let me know. The system is running at the latest firmware level. There are no 'firmwares' for the docking station, so there is nothing I can do there. /Eirik Oeverby ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI issues on ThinkPad T21 + Dock
Stijn Hoop wrote: On Thu, Jun 19, 2003 at 09:33:41AM +0200, Eirik Oeverby wrote: - When booted with ACPI enabled (docked), the machine will at some point simply power itself off. I have seen people complaining about similiar machines powering themselves *on* after a power-off, but in my case it's the opposite. Out of nothing, with no warning (that I can see), it simply powers off. It's not suspend either, or hibernation or anything. Just a shot in the dark, but might it be heat? Most laptops/PCs turn themselves off to prevent them from overheating. Maybe ACPI doesn't turn on the fans when docked or something like that. Nope, since this never happened before 5.1. I've been running 4.8 and OS/2 on this machine before, always docked, and temperature was never an issue. It's possible that ACPI in 5.1 does this - after all it has some kind of thermal support, but I have tried to disable this and it makes no difference. Just to be on the safe side, would the following line in device.hints be correct for disabling the thermal part of acpi? debug.acpi.disable=thermal I think it would be, because replacing thermal with children made my system refuse to boot. No HW was detected ;) /Eirik ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
