Software suspend?
Have we considered implementing software suspend? I've been using Gentoo on my laptops (as nobody else seems to be able to reproduce my BSD bugs on them) and have been playing with the Linux software suspend facilities. It's kind of a neat trick; basically they spawn a process that forces everything else to page out as much as it can. When simply paging the processes out is no longer possible, it stops the processes and writes their remaining memory into swap manually. It then leaves some sort of signature on the swap so that the kernel, on next boot, restores the old memory space instead of firing up init and whatnot. It's not quite perfect (for example, I don't believe it saves kernel space) but it seems to work amazingly well for such a hack. :-) I admit to being essentially unfamiliar with the innards of the FreeBSD kernel and VM, but I've worked with the Linux patches (ugg...I miss running FreeBSD and not having to manually patch my kernel) and they're amazingly simple, given their function. How hard do y'all think this would be? Is anyone else interested in this? In Linux it basically lets us work around broken ACPI suspend routines. -Cliff L. Biffle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI: LCD
On Wednesday 18 June 2003 09:42 am, Sebastian Yepes [ESN] wrote: Any one know how to turn off the screen on a notebook i mean totally off, Not the dpms The problem is that when i close the lid it stays on and produces to much heat.. It varies from notebook to notebook. For example, on my Satellite 1605, I can find no way to do this through ACPI, DPMS, or any other means. On my Pavilion N5290 running Gentoo, there's a kernel module that handles it by twinking hardware registers. The Inspiron 8500 is a Compal machine if I remember correctly, and there's a very slight possibility that some of the utilities intended for other Compal distributors (Compaq, HP, Toshiba) might work. (The Linux omnibook kernel module works on two of my machines, both Compals, only one an HP.) You might get more information on this from the freebsd-mobile list, also. -Cliff L. Biffle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Need acpi-event-d?
On Monday 16 June 2003 09:09 am, Barney Wolff wrote: man psm Set the HOOKRESUME and INITAFTERSUSPEND flags in /boot/device.hints. Works for me on a Dell I5000. Not here (Toshiba Satellite 1605 -- really a branded Compal). It works if I don't use moused, however. I suspect the problem here is with moused, but haven't had time to tear it open (I suddenly got employed). Not sure if David's seeing the same symptoms, exactly. -Cliff L. Biffle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB port periodically dies, now with complete body text
On Tuesday 04 March 2003 04:46 am, Bernd Walter wrote: I've been having a reliable USB issue on my 5-current box (3 Mar, 23:58:25 MST). It's been happening since I upgraded to -current in the DP2 days, and has happened on two completely independent motherboards. On the more recent of the two (the previous died) I've enabled USB_DEBUG. Here's the deal. I'm aware of problems when disconnecting open usb devices at least on ohci controllers and some devices. This problem arises while the mouse is connected; the interesting debug output only appears once it's disconnected. Not disconnecting it doesn't fix anything. Is there a more specific mailing list I could target this to? -Cliff L. Biffle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
USB port periodically dies
I've been having a reliable USB issue on my 5-current box (3 Mar, 23:58:25 MST). It's been happening since I upgraded to -current in the DP2 days, and has happened on two completely independent motherboards. On the more recent of the two (the previous died) I've enabled USB_DEBUG. Here's the deal. The port periodically dies. Once it dies, a reboot clears it up every time, but nothing short of that will. Once one port has died, any device plugged into another port causes it to quit working as well. (I generally have only my mouse plugged in.) During normal use with hw.usb.ums.debug, hw.usb.uhub.debug, and hw.usb.debug set to 1, I get a lot of lines like: ums_intr: status=13 When the port finally dies, it does so with no fanfare; the mouse simply stops responding. If I unplug the mouse, I get: uhub_explore: C_PORT_ENABLED uhub_explore: device addr=2 disappeared on port 2 ums0: at uhub0 port 1 (addr 2) disconnected To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
USB port periodically dies, now with complete body text
Damn KMail. Full text to follow: --- I've been having a reliable USB issue on my 5-current box (3 Mar, 23:58:25 MST). It's been happening since I upgraded to -current in the DP2 days, and has happened on two completely independent motherboards. On the more recent of the two (the previous died) I've enabled USB_DEBUG. Here's the deal. The port periodically dies. Once it dies, a reboot clears it up every time, but nothing short of that will. Once one port has died, any device plugged into another port causes it to quit working as well. (I generally have only my mouse plugged in.) During normal use with hw.usb.ums.debug, hw.usb.uhub.debug, and hw.usb.debug set to 1, I get a lot of lines like: ums_intr: status=13 When the port finally dies, it does so with no fanfare; the mouse simply stops responding. If I unplug the mouse, I get: uhub_explore: C_PORT_ENABLED uhub_explore: device addr=2 disappeared on port 2 ums0: at uhub0 port 1 (addr 2) disconnected ums0: disconnected ums0: detached uhub_explore: get port status failed, error=TIMEOUT uhub_explore: get port status failed, error=TIMEOUT uhub_explore: get port status failed, error=TIMEOUT If I reconnect the mouse: uhub_explore: C_PORT_ENABLED uhub0: port error, restarting port 1 usbd_new_device bus=0xc261b000 port=1 depth=1 speed=1 usbd_new_device: addr=2, getting first desc failed usbd_remove_device: 0xc2e68a00 uhub_explore: usb_new_device failed, error=TIMEOUT uhub0: device problem, disabling port 1 uhub_explore: get port status failed, error=TIMEOUT [last line repeats every few seconds] ...and disconnect: uhub_explore: C_PORT_ENABLED uhub0: port error, restarting port 1 uhub_explore: status change hub=1 port=1 ...and then the same stuff as above. Repeat ad nauseum The ports work fine under Linux. The earlier motherboard I saw this on worked fine under 4-stable; I have not yet had an opportunity to nuke my machine and install 4.7. :-) (Though I will say that I have very, very similar symptoms on my 4.7 OHCI-based laptop, though it does it starting right from boot, instead of working for a while and then going insane. Again, ports work fine under Linux. I suspect it may be unrelated.) What should I instrument? Any debug flags I can turn on? -Cliff L. Biffle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
APM and ACPI fail on Toshiba Satellite
I've stumbled across a Satellite 1605CDS that I'm trying to beat into shape. ACPI fails as follows: acpi0: PTLTDRSDT on motherboard ACPI-0483: *** Error: GPE0 block (GPE 0 to 15) overlaps the GPE1 block (GPE 0 to 15) acpi0: could not enable ACPI: AE_BAD_VALUE device_probe_and_attach: acpi0 attach returned 6 I sort of expected ACPI to fail after watching everyone else, but the killer here is that APM doesn't seem to work either once ACPI is disabled. Its error messages are less interesting. When compiled into the kernel, there are no error messages, but the /dev/apm device doesn't appear. I then attempted to enable alpm, the power management device for the Aladdin-V chipset, which responded as follows: alpm0: AcerLabs M15x3 Power Management Unit at device 17.0 on pci0 alpm0: Could not allocate Bus space device_probe_and_attach: alpm attach returned 6 APM works great under Knoppix, so I don't think it's a hardware issue. Help! -Cliff L. Biffle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: yet another nvidia post
On Wednesday 25 December 2002 06:54 am, David Holm wrote: I have the nvidia drivers up and running on my current box and 2d-wise they seem to be working great. But whenever I activate glx I can run glxgears two times and it runs accelerated (I even got a higher framerate than in linux), but the third time I ran it it ran for about 5s then the computer froze. 5-10s later it just reboots. This has happened every time I tried it (the last two or three times I updated world, I update approximately after 1-2 weeks). I've managed to reproduce a very similar situation using RC1. Does your kernel have various debugging features in place? If so...try turning them /off/. I kid you not. On the RC1 box here the nVidia drivers were very unstable doing 3D until the kernel was recompiled without debugging. (Chris, the owner of the machine, wanted to do it for 'performance' reasons -- getting the graphics working was an unexpected boon.) I can get you the kernel config, or make it available to the list if anyone's interested in this fleeting heisenbug. -Cliff L. Biffle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0 performance (was: 80386 out of GENERIC)
On Tuesday 17 December 2002 12:19 am, Garance A Drosihn wrote: At 5:58 AM +0100 12/17/02, Cliff Sarginson wrote: Also didn't someone mention that GCC has got slower anyway ? gcc is slower at compiling things. This is very noticeable when you're doing a buildworld. The code which gcc 3.2.1 produces does not seem any slower than the code produced by gcc 2.95.4 (the version in freebsd-stable). Actually, in my benchmarks here, the same code tends to yield much faster executables under gcc3, particularly in C++. But these are limited benchmarks (primarily of KDE and my own applications). I'm willing to trade some time on the compile (which, with any luck, happens only once) in exchange for speed in the application (which I may use every day)! :-) -Cliff L. Biffle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RCng -- docs and whatnot?
Does documentation for the rcng system exist? It sounds like it's still changing, so I wouldn't be surprised if the docs are minimal at the moment. Is there another mailing list where this is more properly asked? I ask because I'm working on a set of KDE tools to administer FreeBSD workstations (running KDE 3.1 on 5.0-DP2 here), and I like the way rcng works and would like to see about integrating a configurator. Thanks! -Cliff L. Biffle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RCng -- docs and whatnot?
On Wednesday 11 December 2002 10:49 pm, Mike Makonnen wrote: man 8 rc man 8 rc.subr I was really hoping for documentation on how the PROVIDES/REQUIRES stuff was handled and calculated. I'm familiar with the rc scripts in general. I suppose I can read the code. :-) -Cliff L. Biffle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATACD issues slowly coming back...
On Sunday 08 December 2002 03:28 pm, Bruce Cran wrote: I've got a A7V-266E motherboard with a KT266A chipset. The solution in my case was to tell the BIOS I didn't have any ATAPI drives. FreeBSD then found everything properly, without any problems - I think the BIOS was maybe configuring the master for UDMA33 and the slave for PIO4, whereas FreeBSD seems to prefer them both as PIO4, That just about makes sense, with the weirdnesses I've seen with this mobo in the past. I'll give that a go and let y'all know what I find. I've got the ATACD on its own channel because I've hit issues in the past with having a DMA and PIO device on the same channel with this controller, but from reading my boot messages this morning my CD drive thinks it supports UDMA 33. Go fig. I should probably also sup the machine past DP2, but it's just been so wonderfully stable...I'm so used to using -stable that this feels like pushing my luck. :-) Thanks! -Cliff L. Biffle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Motherboard choice for 5.0?
I've stumbled across a new 1.4ghz Athlon Thunderbird processor. I need a motherboard to go with it. This system will be running 5.0 exclusively unless it blows up, in which case it will run 4-stable. It's a workstation, but I don't need integrated graphics or sound, and using SDRAM would be nice (since I have 768MB here) but not necessary. Suggestions? (Don't want to repeat the KT133 fiasco. :-) -Cliff L. Biffle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What is the highest 'safe' CPUTYPE for intel?
On Friday 06 December 2002 01:11 pm, leafy wrote: CPUTYPE=pentium4 is know to be broken. What is the known working highest CPUTYPE then? pentium3 or pentium2? Well, I know this isn't quite what you were asking, but I wanted to let the group know that the world and kernel seem quite stable using the athlon-tbird optimizations. Not to mention smokingly fast. Incidentally, I know this is a scary, scary thing, but how do I turn off the various debugging options that are on in GENERIC? I'd like to compile a hotrod kernel/world for testing...is it just a matter of commenting out DEBUG=-g? Thanks! -Cliff L. Biffle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ATACD issues slowly coming back...
I mentioned earlier on the list that the ATA issues I'd been having with 4.7 had disappeared since installing 5.0. They're still much less frequent -- i.e. I can burn CDs now -- but I just got one of the old messages and wanted to submit it for your perusal. cliff50 kernel: acd0: READ_BIG - MEDIUM ERROR asc=0x11 ascq=0x00 error=0x00 I'm not well versed on the ATA command set, but that looks like a command to the drive failing to execute. Is this likely to be the drive, the controller, both, or is it impossible to tell from the data set? This is on the aforementioned potentially-buggy Apollo KT133 chipset, but it's never reported these errors on my hard disk (knock on wood), only the CD drive. They -are- on separate channels. I'll see what information I can collect here, but suggestions on where to look are appreciated. -Cliff L. Biffle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
NVidia binary driver on 5.0-DP2
Hey, for the curious... We've gotten NVidia's binary drivers for the GeForce cards up and running on 5.0-DP2. Once five or so lines in nv-freebsd.h that disabled support on 5.0 were removed...it works beautifully. :-) Patch follows. This is Chris Lee's work, not mine, but he's not on the list, since he's still having trouble admitting to running anything other than Gentoo. :-) (Yes, 5.0-DP2 is bringing in converts from the cold left and right here in Tempe!) -Cliff L. Biffle --- src/nv-freebsd.h Wed Oct 30 07:30:58 2002 +++ src/nv-freebsd.hThu Dec 5 05:09:33 2002 @@ -27,12 +27,6 @@ * active development and also unsupported. */ -#if __FreeBSD_version = 50 -#error This driver does not support FreeBSD 5.0/-CURRENT! -#elif __FreeBSD_version 47 -#error This driver requires FreeBSD 4.7 or later! -#endif - #include sys/systm.h #include sys/types.h #include sys/queue.h To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
USB issues with Apollo KT133A mobo
Hi all. I'm running 5.0-DP2 on a motherboard with the Apollo KT133A chipset. (I believe it's an ASUS, but it doesn't seem to be labelled.) The USB controller (described by dmesg as a VIA 83C572) periodically blows its brains out. More specifically, all USB devices lose power. The device nodes stay in /dev and there are no notices to dmesg about the loss until I unplug and replug them, at which time it says 'port error: restarting port N' where N is generally 0, depending on which controller it is. It then redetects my hardware. This also happened on 4.5 and above, so it might very well be a hardware problem on my end. Since I'm not getting any helpful error messages from my system, my question is this: what debugging switches, if any, should I turn on to see what's going on? Are there any known issues with this controller? Should I just sup to -current? Thanks! -Cliff L. Biffle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB issues with Apollo KT133A mobo
On Wednesday 04 December 2002 05:11 pm, Darryl Okahata wrote: 1. IIRC, USB ports on KT133A motherboards were buggy (???). Could be. The ATA controller was also flaking out under 4.7, but is solid as a rock under 5.0-DP2, which is why I'm sticking with it despite other potential bugs. I can burn CDs now! 2. Drawing too much power from the USB ports can cause the ports to shut down. The absolute maximum limit is 500mA, which isn't much (some 2.5 USB hard disks can draw MUCH more, which violates the spec, and sometimes works, and sometimes doesn't). The behavior persists with just an optical USB mouse, which can't possibly be sucking more than a few dozen mills. (I hope.) In the discussion link you sent me, they discuss the controller disabling the port due to excessive current draw...would it re-enable the port when I simply un/replug the mouse? Normally I'd expect that to require a reboot. (The mouse does come back when I remove it and reinsert it, and generally X doesn't even notice.) The KT133 discussion suggests it's a hardware problem, which wouldn't surprise me...this particular mobo is a very early Athlon board, and the chipset may be buggy. -Cliff L. Biffle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB issues with Apollo KT133A mobo
On Wednesday 04 December 2002 05:40 pm, Josef Karthauser wrote: Is it ohci? If so can you try this patch? Joe Hey Joe -- fancy meeting you here. :-) Nope, the KT133 has two UHCI controllers. What I'm going to do next (which I should have done before) is try the following variables: 1. Does the mouse die if it's the only thing plugged in AND is buffered by a powered hub? (iirc, yes, but needs testing) 2. Does the secondary controller work? (The ports stub out in a header on the board, but I've brought them out and will test.) If (1) is true, that (imho) eliminates the current-draw question. If (2) is true, that points to hardware problems with the primary controller. (Forgot I had two. *grin*) -Cliff L. Biffle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas at all about network problem?
On Monday 02 December 2002 12:09 pm, Craig Reyenga wrote: Right on. I hope that you find something because right now it seems so hopeless. I'd have to say that this is the strangest problem that I've ever had with FreeBSD. Well... My Realtek card in my 5.0 workstation is fully capable of saturating a 100mbps link. It's an 8139; the only thing I did that might have been unusual was forcing the media/mediaopts after bad experiences with rl's autodetect in the past. Perhaps if you give me more information about your setup I could better reproduce it. :-\ -Cliff L. Biffle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas at all about network problem?
On Monday 02 December 2002 10:47 am, Craig Reyenga wrote: Ok, I'm convinced. Clearly I'm the one that has to do the testing because I seem to be the lucky guy with the problem. I'm actually on my way to the office now to set up a test scenario with our 5-current boxen. We've got a whole scad of 8139s, 8129s, 3c905s, and some old Davicom-based cards that gave me endless trouble under 4.x. I'll let you know what I find. For reference, the 8139 in my 5-current box here works at full speed, but I'm on 10mbps; we have more 100baseT equipment at work. -Cliff L. Biffle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas at all about network problem?
On Monday 02 December 2002 03:05 am, Brad Knowles wrote: According to all the source modules I've read regarding RealTek cards, they're about the biggest pieces of hardware garbage that has ever been inflicted on the free/open community. However, a 3Com card should be a little better. Have you tried replacing both RealTek cards with 3Com, to see if that changes things? One thing I've used in the past that improves Realtek throughput is forcing the media type and duplex setting on both ends of the connection. Autodetect in the 8139s seems to be unreliable at times. In my testing here I can get upwards of 1100kBps over 10baseT as long as I set both ends to full-duplex 10baseT/UTP. (This is from a 5.0-DP2 box to a 4.5-RELEASE box, 8139's on both ends; scp and nfs show about the same throughput.) iirc, Craig was seeing closer to 800kBps. I'm trying to find a patch cable (or a crimper) to try 100mbps. -Cliff L. Biffle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
