Re: recent apm changes (FYI)
On Thu, Sep 02, 1999 at 10:21:14PM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Oscar Bonilla writes: : Sep 2 08:43:28 voyager pccardd[24601]: No free configuration for card 3Com : : Then I kill pccardd and restart it and I get: : : ep0: No connectors or MII. : ep0: [*UTP*] address 00:60:08:b6:36:fb : Sep 2 08:47:51 voyager pccardd[31164]: pccardd started : : and from now on everything works fine. : : I could kill it and restart it from /etc/rc.resume, but I thought that : maybe you'd want me to look into something... How new is your userland? There have been some bugs in that area fixed in pccardd of late. Maybe we missed one? I have a 3C589D that I saw this problem with once or twice, but haven't seen it lately. Aug. 27th. Want me to make world again? I also have a 3C589D and it happens with it too. Regards, -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes (FYI)
In message [EMAIL PROTECTED] Oscar Bonilla writes: : Aug. 27th. Want me to make world again? I also have a 3C589D and it happens : with it too. No. Aug 27 is new enough to be good. I'm swamped right now with a dozen other things at the moment, but if you could write me in about a week I'd be able to help you out more. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes (FYI)
On Fri, Sep 03, 1999 at 09:33:29AM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Oscar Bonilla writes: : Aug. 27th. Want me to make world again? I also have a 3C589D and it happens : with it too. No. Aug 27 is new enough to be good. I'm swamped right now with a dozen other things at the moment, but if you could write me in about a week I'd be able to help you out more. sure, i'll talk back in a week... regards, -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
recent apm changes (FYI)
I have a Vaio PCG-505FX, and first of all let me tell you guys that the recent apm changes are working great. I can use both the suspend and hibernate functions without a problem. There's just one weird thing going on that I'd like you to know about, if someone gives me instructions on how to debug it I can help find the problem. If I hibernate the laptop, at resume time i need to kill the pccardd daemon and restart it in order to be able to use my 3Com Fast Etherlink XL PCMCIA card. Here's the log from the console... Called APM sound suspend hook for unit 0 ep0: unload Return IRQ=10 Card disabled, slot 0 Called APM sound resume hook for unit 0 Card inserted, slot 0 Sep 2 08:43:23 voyager /kernel: resumed from suspended mode (slept 13:11:45) Sep 2 08:43:28 voyager pccardd[24601]: No free configuration for card 3Com Then I kill pccardd and restart it and I get: ep0: No connectors or MII. ep0: [*UTP*] address 00:60:08:b6:36:fb Sep 2 08:47:51 voyager pccardd[31164]: pccardd started and from now on everything works fine. I could kill it and restart it from /etc/rc.resume, but I thought that maybe you'd want me to look into something... thanks and regards, -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
plm If I use 'zzz', I have to do the known 'sleep 1; zzz' trick. This is plm the difference. I'll commit the patch for `key release event prevent suspend' problem if no objections. Thanks a lot! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
Sorry to late...
plm Now suspend works. However still the disks keep spinning until they
plm reach their BIOS timeout. In Linux Windows, there is some hook when
plm going to suspend mode that spins down the (IDE) disks. This is nice,
plm since it is well possible that you go to suspend but do not set a disk
plm spindown timeout.
I read linux source code closely again, I found their hack in
IDE device driver. Does anyone know this could make differences on
suspending?
From linux/drivers/block/ide.c Version 6.18 August 16, 1998:
void ide_intr (int irq, void *dev_id, struct pt_regs *regs)
{
unsigned long flags;
ide_hwgroup_t *hwgroup = (ide_hwgroup_t *)dev_id;
ide_hwif_t *hwif;
ide_drive_t *drive;
ide_handler_t *handler;
__cli();/* local CPU only */
spin_lock_irqsave(hwgroup-spinlock, flags);
hwif = hwgroup-hwif;
if ((handler = hwgroup-handler) == NULL || hwgroup-poll_timeout != 0) {
/*
* Not expecting an interrupt from this drive.
* That means this could be:
* (1) an interrupt from another PCI device
* sharing the same PCI INT# as us.
* or (2) a drive just entered sleep or standby mode,
* and is interrupting to let us know.
* or (3) a spurious interrupt of unknown origin.
*
* For PCI, we cannot tell the difference,
* so in that case we just ignore it and hope it goes away.
*/
#ifdef CONFIG_BLK_DEV_IDEPCI
if (IDE_PCI_DEVID_EQ(hwif-pci_devid, IDE_PCI_DEVID_NULL))
#endif /* CONFIG_BLK_DEV_IDEPCI */
{
/*
* Probably not a shared PCI interrupt,
* so we can safely try to do something about it:
*/
(void)ide_ack_intr(hwif-io_ports[IDE_STATUS_OFFSET],
hwif-io_ports[IDE_IRQ_OFFSET]);
unexpected_intr(irq, hwgroup);
}
spin_unlock_irqrestore(hwgroup-spinlock, flags);
return;
}
... but I've seen this kind of hack in wd device driver before.
How about spin down from userland (apmd) using camcontrol(8) like tool?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
"MI" == Mitsuru IWASAKI [EMAIL PROTECTED] writes: MI Hi, MI I got ASUS P2B M/B ATX case and assembled new box yesterday. With MI my patch, new box successfully transit into suspend state. There is MI no sounds from CPU fun, chassis fun and IDE HDD spin (powered down by MI BIOS setting, Power management setup - PM Timers - HDD Power Down: MI 1 Min.). The power led keeps flashing during suspending. MI Without the patch, suspending system is never successful (standby MI also), message `slept 00:00:00' comes up :-( MI The key release event seems prevent suspend, so some sort of delay MI mechanism would be necessary such as my patch. MI Now I'm wondering why your PC doesn't get quite. I suspect that MI hardware configuration different from yours (I have no SCSI HD on new MI box). Any suggestions? After a new cvsup I tried your patch again. Same result. Here is my dmesg output. It is about the same at boot, but the APM debug output when suspend is tried is completely different. Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #9: Mon Aug 16 20:56:59 MET DST 1999 plm@muon:/var/arch/fbsd/src/sys/compile/PLM Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (350.80-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x651 Stepping = 1 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 268423168 (262132K bytes) avail memory = 257990656 (251944K bytes) Pentium Pro MTRR support enabled Probing for PnP devices: CSN 1 Vendor ID: CTL00e4 [0xe4008c0e] Serial 0x1f5ceca5 Comp ID: PNPb02f [0x2fb0d041] Add hook "pcm resume handler" Add hook "pcm suspend handler" pcm1 (SB16pnp SB16 PnP sn 0x1f5ceca5) at 0x220-0x22f irq 5 drq 1 flags 0x15 on isa npx0: math processor on motherboard npx0: INT 16 interface apm0: APM BIOS on motherboard apm: APM BIOS version 0102 apm: Code16 0xc00f, Data 0xc00fdbd0 apm: Code entry 0x7770, Idling CPU disabled, Management enabled apm: CS_limit=0x, DS_limit=0x apm: Engaged control enabled apm: found APM BIOS v1.2, connected at v1.2 apm: Slow Idling CPU disabled Add hook "default suspend" Add hook "default resume" pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 vga-pci0: Matrox model 0521 graphics accelerator irq 11 at device 0.0 on pci1 isab0: Intel 82371AB PCI to ISA bridge at device 4.0 on pci0 ata-pci0: Intel PIIX4 IDE controller at device 4.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 chip1: UHCI USB controller at device 4.2 on pci0 chip2: Intel 82371AB Power management controller at device 4.3 on pci0 ahc0: Adaptec 2910/15/20/30C SCSI adapter irq 9 at device 9.0 on pci0 ahc0: aic7850 Single Channel A, SCSI Id=7, 3/255 SCBs ed0: NE2000 PCI Ethernet (ProLAN) irq 10 at device 11.0 on pci0 ed0: address 00:40:95:00:57:83, type NE2000 (16 bit) isa0: ISA bus on motherboard fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio2 at port 0x3e8-0x3ef irq 4 on isa0 sio2: type 16550A sio3 at port 0x2e8-0x2ef irq 3 on isa0 sio3: type 16550A ppc0 at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppb0: IEEE1284 device found /NIBBLE/ECP Probing for PnP devices on ppbus0: ppbus0: Hewlett-Packard OfficeJet Series 700.4.00c MLC,PCL,PML lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ata0: master: setting up UDMA2 mode on PIIX4 chip OK ad0: Maxtor 90680D4/PAS23B15 ATA-4 disk at ata0 as master ad0: 6485MB (13281408 sectors), 13176 cyls, 16 heads, 63 S/T, 512 B/S ad0: piomode=4, dmamode=2, udmamode=2 ad0: 16 secs/int, 0 depth queue, DMA mode ata0: slave: setting up UDMA2 mode on PIIX4 chip OK ad1: Maxtor 91000D8/SASX1B18 ATA-4 disk at ata0 as slave ad1: 9543MB (19545120 sectors), 19390 cyls, 16 heads, 63 S/T, 512 B/S ad1: piomode=4, dmamode=2, udmamode=2 ad1: 16 secs/int, 0 depth queue, DMA mode ata1: master: setting up UDMA2 mode on PIIX4 chip OK ad2: ST39140A/841260 ATA-3 disk at ata1 as master ad2: 8693MB (17803440 sectors), 17662 cyls, 16 heads, 63 S/T, 512 B/S ad2: piomode=4, dmamode=2, udmamode=2 ad2: 16 secs/int, 0 depth queue, DMA mode Waiting 5 seconds for SCSI devices to settle sa0 at ahc0 bus 0 target 6 lun 0
Re: recent apm changes
Followup: I decided to upgrade my P2B BIOS version. I had 1005, went to 1010. This made a difference! Now suspend works. However still the disks keep spinning until they reach their BIOS timeout. In Linux Windows, there is some hook when going to suspend mode that spins down the (IDE) disks. This is nice, since it is well possible that you go to suspend but do not set a disk spindown timeout. Weird that 1005 did not, but 1010 does suspend with FreeBSD ( your patch, I didn't try without it again), while 1005 did work with Linux Windows. That's why I didn't think of upgrading before. I'll report what happens with the original (non patched) kernel later. "MI" == Mitsuru IWASAKI [EMAIL PROTECTED] writes: MI Hi, MI I got ASUS P2B M/B ATX case and assembled new box yesterday. With MI my patch, new box successfully transit into suspend state. There is MI no sounds from CPU fun, chassis fun and IDE HDD spin (powered down by MI BIOS setting, Power management setup - PM Timers - HDD Power Down: MI 1 Min.). The power led keeps flashing during suspending. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
"MS" == Mike Smith [EMAIL PROTECTED] writes: "MS" == Mike Smith [EMAIL PROTECTED] writes: Then after 5 seconds the screen blanks, the power light starts flashing (indicating suspend mode), but when I hit a key, the console says (slept 00:00:02) only, and programs in fact continued running (thus it didn't go or remain in suspend mode at all). MS I think you'll find that programs didn't, in fact, continue MS running; rather they paused and then resumed when you came out MS of suspend. I'm running seti@home, and it really continued while my computer was 'suspended'. Also a little test program continued running. MS What you're failing to offer here, and thus why I remain MS skeptical, is any evidence that suggests that these programs MS were "running" while the system believed itself to be MS suspended. I can see that after one hour of 'suspend' mode, the program has done for one hour worth of calculations. Really, I am not insane and know when my programs have run and done work and when not. -- Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know [EMAIL PROTECTED] | the Netherlands| what I'm doing. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
"MS" == Mike Smith [EMAIL PROTECTED] writes: Then after 5 seconds the screen blanks, the power light starts flashing (indicating suspend mode), but when I hit a key, the console says (slept 00:00:02) only, and programs in fact continued running (thus it didn't go or remain in suspend mode at all). MS I think you'll find that programs didn't, in fact, continue MS running; rather they paused and then resumed when you came out MS of suspend. I'm running seti@home, and it really continued while my computer was 'suspended'. Also a little test program continued running. -- Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know [EMAIL PROTECTED] | the Netherlands| what I'm doing. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
"MS" == Mike Smith [EMAIL PROTECTED] writes: Then after 5 seconds the screen blanks, the power light starts flashing (indicating suspend mode), but when I hit a key, the console says (slept 00:00:02) only, and programs in fact continued running (thus it didn't go or remain in suspend mode at all). MS I think you'll find that programs didn't, in fact, continue MS running; rather they paused and then resumed when you came out MS of suspend. I'm running seti@home, and it really continued while my computer was 'suspended'. Also a little test program continued running. What you're failing to offer here, and thus why I remain skeptical, is any evidence that suggests that these programs were "running" while the system believed itself to be suspended. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
"MI" == Mitsuru IWASAKI [EMAIL PROTECTED] writes: MI Please try this patch. MI If it still fails, it's worth to try increasing APM_SUSPEND_DELAY, MI something like: MI #define APM_SUSPEND_DELAY 3 Alas, it doesn't make a difference. I tried too with APM_SUSPEND_DELAY 5. What I see when I issue 'zzz', is a delay of 5 seconds, but in between programs keep running (and thus keep generating interrupts I guess). Then after 5 seconds the screen blanks, the power light starts flashing (indicating suspend mode), but when I hit a key, the console says (slept 00:00:02) only, and programs in fact continued running (thus it didn't go or remain in suspend mode at all). Anyway thanks for you efforts so far. -- Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know [EMAIL PROTECTED] | the Netherlands| what I'm doing. ---+-+-- Powered by FreeBSD (-current). See http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
Hi, MI Please try this patch. MI If it still fails, it's worth to try increasing APM_SUSPEND_DELAY, MI something like: MI #define APM_SUSPEND_DELAY 3 Alas, it doesn't make a difference. H. OK, I'll buy new mather board same one as yours and investigate what's happend on it. Could you tell me which M/B are you using? And I'd like to have your dmesg output from kernel with APM_DEBUG option. # In your kernel config file: # options APM_DEBUG Also, I'll send you few more patches before I purchase new one if I get new ideas. Anyway thanks for you efforts so far. Not at all. I never give up :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
Hi, Oh, do you have suspend button on your box? Cool. On my poor experience, suspeding by hot-keys easier to success than by zzz(8). On this point I can report the oppposite experience, on my machine (a no name special) the trackpad tends to lock up if touched between power on and resume finishing. The best indicator of safety is apm -z returning, if I use the button I have to guess. Ahh, I've seen this kind of behavior on some laptops. I guess this is related with some sort of time limits on communication with APM BIOS. APM Spec. v1.2 Appendix D - APM Driver Considerations - When an APM connection exists, the APM BIOS transitions into System Standby and System Suspend states only when directed to do so by a call from the APM Driver. The calls to change system states are invoked by the APM Driver only after the APM BIOS indicates that the state transition should be made, and the APM Driver has checked with all APM-aware applications to make sure that it is an appropriate time to change system states. However, there are three cases where the APM BIOS may make the system state transition itself. The first case is if the APM Driver does not pick up a posted Standby Request, Suspend Request or Critical Suspend Notification event within the 2 second ~~~ (one second plus one second grace period) time limit. The second is when the APM Driver, after picking up the event, does not respond to a Standby Request, Suspend Request or Critical Suspend Notification event with an appropriate Set Power State call within 5 seconds of receiving the event. The last situation is when the APM Driver has responded to an event with a Request Processing Set Power call and does not reply again within another 5 seconds.The CPU is power managed according to CPU Idle and CPU Busy calls made by the APM Driver to the APM BIOS. Last time, we didn't have `Last Request Processing Notification' to APM BIOS at all for the second case. After adding this hack in PAO, we saw greate improvements about system suspending transition (standby also) on a lot of laptops :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
Hi, Nate.
I'm sorry if my poor english troubled you.
We should have no problems responding in this amount of time in FreeBSD,
since we don't (didn't used to?) have any code that should cause
significant delay in responding.
My understanding on system suspend code in FreeBSD is that once APM
driver get a system suspend request event from the BIOS, the driver is
hurry to put system into suspend state (execute suspend hooks and call
set power state function for suspend) as soon as possible without any
responses to the BIOS.
I think that this style is cool, I like, and no response to the BIOS
is not violating the APM specification at all, but there are many
BIOSes expecting response from driver. In Linux and NetBSD, they have
last request processing notification to the BIOS before transition into
suspend state. I guess they obtained the same conclusion to support
various BIOS implementations including buggy and bogus BIOSes.
That's why `suspending on Linux is OK, but on FreeBSD' like phenomenon
is there I'd like solve this if possible and need your help or
support.
From Linux code:
static void do_apm_timer(unsigned long unused)
{
int err;
static int pending_count = 0;
if (((standbys_pending 0) || (suspends_pending 0))
(apm_bios_info.version 0x100)
(pending_count-- = 0)) {
pending_count = 4;
err = apm_set_power_state(APM_STATE_BUSY);
if (err)
apm_error("busy", err);
}
From NetBSD code:
static void
apm_event_handle(sc, regs)
struct apm_softc *sc;
struct bioscallregs *regs;
{
int error;
struct bioscallregs nregs;
switch(regs-bx) {
case APM_USER_STANDBY_REQ:
DPRINTF(APMDEBUG_EVENTS, ("apmev: user standby request\n"));
if (apm_do_standby) {
if (apm_record_event(sc, regs-bx))
apm_userstandbys++;
apm_op_inprog++;
(void)apm_set_powstate(APM_DEV_ALLDEVS,
APM_LASTREQ_INPROG);
} else {
(void)apm_set_powstate(APM_DEV_ALLDEVS,
APM_LASTREQ_REJECTED);
/* in case BIOS hates being spurned */
apm_powmgt_enable(1);
}
break;
Last time, we didn't have `Last Request Processing Notification' to
APM BIOS at all for the second case.
Huh? I don't see any mention of 'last request processing notification'
anywhere above. Also, I don't believe the APM driver responds with a
Ah, details are described in `4. Advanced Power Managerment Software
Interface - 4.6.8 Set Power State'. `an appropriate Set Power State
call' includes 'last request processing notification' too.
They say:
Set Power State entry codes of CX=0004h and CX=0005h are used by the
APM Driver to respond to requests from the system BIOS for the
global Standby and Suspend states. The APM Driver uses the Last
Request Processing Notification (0004h) to indicate that it is
currently in the process of determining whether or not to reject the
request. This notification must be sent at least once every five
seconds after the APM driver receives the request by calling Get
Power Management Event. The APM driver must eventually end this
"busy" state by accepting the request, (calling Set Power State with
the appropriate state) or by rejecting the request using CX=0005h.
Thanks.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
In message [EMAIL PROTECTED] Mitsuru IWASAKI writes:
: + error = DEVICE_SUSPEND(root_bus);
: + /*
: + * XXX Shouldn't ignore the error like this, but should
: + * instead fix the newbus code. Until that happens,
: + * I'm doing this to get suspend working again.
: + */
: + if (error)
: + printf("DEVICE_SUSPEND error %d, ignored\n", error);
I think that it is now safe to make this warning an error...
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
plm In contract, if I suspend in Linux of Windows, the computer shuts up plm immediateley and is quiet. Only sometimes there is a (not too loud) plm little fan (I think it is the CPU fan) running for a few more minutes. I've read Linux code (v2.2.9) closely, noticed they put cli before APM BIOS call and save restore segment registers. I suspect these two (or only cli?) affect the suspending state. To clarify, could you try attached patches (for sys/i386/i386/bioscall.s) one by one? # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # bioscall-1 # bioscall-2 # bioscall-3 # echo x - bioscall-1 sed 's/^X//' bioscall-1 'END-of-bioscall-1' X--- i386/i386/bioscall.s.org Mon Aug 9 17:51:31 1999 X+++ i386/i386/bioscall.s Mon Aug 9 17:53:07 1999 X@@ -64,9 +64,16 @@ X movl12(%ebp),%edx X movl16(%ebp),%esi X movl20(%ebp),%edi X+#if 1 /* cli hack */ X+ pushfl X+ cli X+#endif X pushl %ebp X lcall _bioscall_vector X popl%ebp X+#if 1 /* cli hack */ X+ popfl X+#endif X movl%eax,0(%ebp) X movl%ebx,4(%ebp) X movl%ecx,8(%ebp) END-of-bioscall-1 echo x - bioscall-2 sed 's/^X//' bioscall-2 'END-of-bioscall-2' X--- i386/i386/bioscall.s.org Mon Aug 9 17:51:31 1999 X+++ i386/i386/bioscall.s Mon Aug 9 18:01:36 1999 X@@ -64,9 +64,17 @@ X movl12(%ebp),%edx X movl16(%ebp),%esi X movl20(%ebp),%edi X+#if 1 /* segment regs hack */ X+ pushl %fs X+ pushl %gs X+#endif X pushl %ebp X lcall _bioscall_vector X popl%ebp X+#if 1 /* segment regs hack */ X+ popl%gs X+ popl%fs X+#endif X movl%eax,0(%ebp) X movl%ebx,4(%ebp) X movl%ecx,8(%ebp) END-of-bioscall-2 echo x - bioscall-3 sed 's/^X//' bioscall-3 'END-of-bioscall-3' X--- i386/i386/bioscall.s.org Mon Aug 9 17:51:31 1999 X+++ i386/i386/bioscall.s Mon Aug 9 18:00:07 1999 X@@ -64,9 +64,20 @@ X movl12(%ebp),%edx X movl16(%ebp),%esi X movl20(%ebp),%edi X+#if 1 /* cli + segment regs hack */ X+ pushfl X+ cli X+ pushl %fs X+ pushl %gs X+#endif X pushl %ebp X lcall _bioscall_vector X popl%ebp X+#if 1 /* cli + segment regs hack */ X+ popl%gs X+ popl%fs X+ popfl X+#endif X movl%eax,0(%ebp) X movl%ebx,4(%ebp) X movl%ecx,8(%ebp) END-of-bioscall-3 exit To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
plm In contract, if I suspend in Linux of Windows, the computer shuts up plm immediateley and is quiet. Only sometimes there is a (not too loud) plm little fan (I think it is the CPU fan) running for a few more minutes. I've read Linux code (v2.2.9) closely, noticed they put cli before APM BIOS call and save restore segment registers. The CLI call is bogus. I note a commit I *just* made: revision 1.49.2.4 date: 1999/07/10 18:36:59; author: nate; state: Exp; lines: +1 -2 - Remove un-necessary CLI statement from apm_int, which casues suspend/resume to fail on at least some IBM Thinkpads. [ FWIW, the cli call is also missing from -current ] Submitted by: "Kenton A. Hoover" [EMAIL PROTECTED] If the CLI is there, my box refuses to suspend. Apparently it was removed from linux a while back, and like many software projects that don't have usable history, the bug is now being re-introduced into Linux again. :( As far as the segment registers, we do an explicit save of them already when we switch into VM86 mode, so it should be necessary to save them twice. I suspect these two (or only cli?) affect the suspending state. To clarify, could you try attached patches (for sys/i386/i386/bioscall.s) one by one? I'd be interested to know if either of the patches did anything... Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
As far as the segment registers, we do an explicit save of them already when we switch into VM86 mode, so it should be necessary to save them twice. VM86 mode is only used to enable APM; after that we are using the 32-bit protected mode interface. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
As far as the segment registers, we do an explicit save of them already when we switch into VM86 mode, so it should be necessary to save them twice. VM86 mode is only used to enable APM; after that we are using the 32-bit protected mode interface. Ahh... In the old code, we used to explicitly push/pop all of the registers. Do we still do that? Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
"MI" == Mitsuru IWASAKI [EMAIL PROTECTED] writes: plm In contract, if I suspend in Linux of Windows, the computer shuts up plm immediateley and is quiet. Only sometimes there is a (not too loud) plm little fan (I think it is the CPU fan) running for a few more minutes. MI I've read Linux code (v2.2.9) closely, noticed they put cli MI before APM BIOS call and save restore segment registers. I MI suspect these two (or only cli?) affect the suspending state. MI To clarify, could you try attached patches (for MI sys/i386/i386/bioscall.s) one by one? I've tried them all. They don't make a difference alas. In doing so, to my surprise I found out that when I suspend my computer in FreeBSD, it isn't suspended at all! I have an ATX case with an Asus P2B motherboard. When I suspend my computer, the power led starts flashing (and keeps doing so). When I suspend my computer in Linux or Windows, as mentioned, the computer gets quiet (HDD spins down etc). The led flashes. Now I found out that when I suspend it in FreeBSD (either with sleep 1; zzz or with the suspend button or through the BIOS timer), the led starts flashing, but processes just keep running! I never paid attention to it, but I got suspicious because I'm running setiathome which accesses the harddrive occasionally, and even during suspend mode I heard the typical HDD sound sometimes. So the problem is not an incomplete suspend, but no suspend at all. It seems to suspend at first, the led starts flashing, the screen is blanked, but somehow the computer keeps running. -- Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know [EMAIL PROTECTED] | the Netherlands| what I'm doing. ---+-+-- Powered by FreeBSD (-current). See http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
Hi, MI I've read Linux code (v2.2.9) closely, noticed they put cli MI before APM BIOS call and save restore segment registers. I MI suspect these two (or only cli?) affect the suspending state. MI To clarify, could you try attached patches (for MI sys/i386/i386/bioscall.s) one by one? I've tried them all. They don't make a difference alas. In doing so, to my surprise I found out that when I suspend my computer in FreeBSD, it isn't suspended at all! I have an ATX case with an Asus P2B motherboard. When I suspend my computer, the power led starts flashing (and keeps doing so). When I suspend my computer in Linux or Windows, as mentioned, the computer gets quiet (HDD spins down etc). The led flashes. Hmmm, the CLI call is not useful in this case... I also had another kind of problem about CLI, my box froze sometimes when suspending. It shouldn't be put CLI in here as Nate mentioned. Segment regisers also wasn't related with the problem. I watched %fs before after BIOS call using ddb, the value didn't change on my box. I guess Linux code only expects some BIOSes manipulate segment registers. Another possibility is *delay mechanism* on suspend (and standby). AFAIK, Linux, NetBSD and PAO has this but CURRENT. I'll make patch tonight based on PAO APM code. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
"MI" == Mitsuru IWASAKI [EMAIL PROTECTED] writes: PAO has a small sleep in the apm driver, while -current didn't the last time I looked. MI OK, I'll work on this. MI To Peter Mutsaers: MI Could you try following command to suspend and see any improvements? MI % sleep 3 apm -z I have done this before, and it does bring the computer into suspend indeed (light flashes). But for my real problem, noise reduction, this doesn't help of course. The disks keep spinning, and so do all fans (CPU or whatever). In contract, if I suspend in Linux of Windows, the computer shuts up immediateley and is quiet. Only sometimes there is a (not too loud) little fan (I think it is the CPU fan) running for a few more minutes. regards, -- Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know [EMAIL PROTECTED] | the Netherlands| what I'm doing. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write:
In FreeBSD, when I activate suspend mode, I see the light on my
computer blinking, indicating it has gone into suspend mode, but still
there is no reduction in noise whatsoever. The disks keep spinning,
the CPU fan (or whatever) too. I could activate the BIOS spindown
timer on the HDD's, but I'd rather not (since then I also get
spindowns while I'm normally working with the computer) but still the
other fan will always continue to run.
What can I do to change this behaviour? Can anyone explain what Linux
(or Win95 for that matter) are doing to make it 100% quiet in suspend
mode? Then I could give it a try to have FreeBSD do the
same. Currently this prevents me from using FreeBSD alas.
FreeBSD's APM suspend works by sending the BIOS a suspend event
for all BIOS managed devices, and the BIOS is supposed to put
all devices under it's control into the "low-power suspend" state.
I'd guess that this isn't the same as "off". You can't tell the
BIOS to turn off all devices, you need to specify which devices
to turn off.
You could play around with adding something like this to
apm_suspend_system (for your hdd:):
sc-bios.r.eax = (APM_BIOS 8) | APM_SETPWSTATE;
sc-bios.r.ebx = 0x02ff;
sc-bios.r.ecx = state ? PMST_APMENABLED : PMST_OFF;
sc-bios.r.edx = 0;
if (apm_bioscall())
printf("Failed to turn off HDD: errcode = %d\n",
0xff (sc-bios.r.eax 8));
Of course, you'd probably also need a corresponding "turn on", call
somewhere. As for your fan, I'm not sure what the deviceid for the
fan would be, the "0x02ff" above means "all 2ndary storage devices".
Perhaps "0x80FF", for all OEM devices.
At the moment, there isn't the ability to control individual devices,
but at some point, I can see this being added to the new-bus architecture;
each device can register callbacks for various power management events.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
Peter Mutsaers wrote: Hello, After Linux I gave FreeBSD a try again, when I saw some improvements to APM had been committed. I hoped for a real suspend mode, but alas. Now I'm wondering what makes the difference, and whether I could do it myself. Let me explain: I run my (desktop) computer in the living room. I don't want to shut it down all the time, but it must be 100% quiet when I'm not using it. In Linux, when suspend mode is activated (either through a short press on the power button or by the (BIOS) timer ), the disks also spin down (immediately, not waiting for their timer, which I disabled) and also the CPU fan and/or the FAN of the box switches off. In FreeBSD, when I activate suspend mode, I see the light on my computer blinking, indicating it has gone into suspend mode, but still there is no reduction in noise whatsoever. The disks keep spinning, the CPU fan (or whatever) too. I could activate the BIOS spindown timer on the HDD's, but I'd rather not (since then I also get spindowns while I'm normally working with the computer) but still the other fan will always continue to run. What can I do to change this behaviour? Can anyone explain what Linux (or Win95 for that matter) are doing to make it 100% quiet in suspend mode? Then I could give it a try to have FreeBSD do the same. Currently this prevents me from using FreeBSD alas. Have you looked at PAO at all? http://www.jp.freebsd.org/PAO/ I've got a -current machine (no cvsups in a few months) that wakes up immediately after suspending. (sleeps 0 seconds) -- Eric Hodel [EMAIL PROTECTED] "They cook your gonies" -Terry Lambert's uncle on why he doesn't have a microwave To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
