Re: freezes on Powering system off using ACPI
On 12/29/2011 4:32 AM, Edward Martinez wrote: Hello, When I execute shutdown -p now to turn off DragonFLyBSD, it freezes right after syncing disks, done, uptime, on Powering system off using ACPI. I need to hold the power button to turn the system off. I'm using DragonFly v2.13.0.733.gd7f53-DEVELOPMENT. Thanks for your help It's an annoying, long-standing bug that apparently isn't high-visibility enough to get any attention: http://bugs.dragonflybsd.org/issues/2167 http://bugs.dragonflybsd.org/issues/2232 I would fix it if I could. John
Re: freezes on Powering system off using ACPI
On Thu, Dec 29, 2011 at 11:32 AM, Edward Martinez edwar...@live.com wrote: Hello, When I execute shutdown -p now to turn off DragonFLyBSD, it freezes right after syncing disks, done, uptime, on Powering system off using ACPI. I need to hold the power button to Could you check whether your BIOS has legacy usb disk support? If it is on, please try turning it off. Best Regards, sephe -- Tomorrow Will Never Die
Re: freezes on Powering system off using ACPI
On 12/29/11 01:00, John Marino wrote: On 12/29/2011 4:32 AM, Edward Martinez wrote: Hello, When I execute shutdown -p now to turn off DragonFLyBSD, it freezes right after syncing disks, done, uptime, on Powering system off using ACPI. I need to hold the power button to turn the system off. I'm using DragonFly v2.13.0.733.gd7f53-DEVELOPMENT. Thanks for your help It's an annoying, long-standing bug that apparently isn't high-visibility enough to get any attention: http://bugs.dragonflybsd.org/issues/2167 http://bugs.dragonflybsd.org/issues/2232 I would fix it if I could. John Hello, Thanks for the reply:-) I read the bug reports and i added hint.ehci.0.disabled=1 to the /boot/loader.conf, did not work, it still hangs.
Re: freezes on Powering system off using ACPI
On 12/29/11 01:14, Sepherosa Ziehau wrote: On Thu, Dec 29, 2011 at 11:32 AM, Edward Martinezedwar...@live.com wrote: Hello, When I execute shutdown -p now to turn off DragonFLyBSD, it freezes right after syncing disks, done, uptime, on Powering system off using ACPI. I need to hold the power button to Could you check whether your BIOS has legacy usb disk support? If it is on, please try turning it off. Best Regards, sephe Thanks for replying, I disabled legacy usb within the BIOS, my system still hangs. I guess, I will need to continue using the button to turn off the unit, or move the OS to another unit.
freezes on Powering system off using ACPI
Hello, When I execute shutdown -p now to turn off DragonFLyBSD, it freezes right after syncing disks, done, uptime, on Powering system off using ACPI. I need to hold the power button to turn the system off. I'm using DragonFly v2.13.0.733.gd7f53-DEVELOPMENT. Thanks for your help
ACPI SCI interrupt mode
Hi all, I have committed some fixes to the master. By default, SCI is enabled and is configured as edge/high. It is contrary to ACPI standard that SCI is level/low; I have seen some boxes that SCI is level/high. Well, you may think that the value in ACPI MADT's interrupt source override could be used, the answer is no, most of the time they are wrong. So edge/high seems to be the safest options. There are two tunables could be used to set SCI trigger mode and polarity: hw.acpi.sci.trigger (could be level or edge) hw.acpi.sci.polarity (could be high or low) They provides four combination that you could try: level/low (ACPI standard) edge/high level/high edge/low If you have a working I/O APIC, then both tunables will take effect. If you have 8259 and ELCR, then only hw.acpi.sci.trigger will take effect. If you only have 8259, then above two tunables has no effect at all. If after struggling with all of the above tunables, you still do not have a working system, then here comes the last resort tunable: hw.acpi.sci.enabled Set it to 0 will disable SCI (SCI is enabled by default) Best Regards, sephe -- Tomorrow Will Never Die
Re: ACPI based interrupt routing and new ACPI code ready for testing
Sepherosa Ziehau wrote: On Tue, Apr 5, 2011 at 9:08 PM, Max Herrgardherrg...@gmail.com wrote: Sepherosa Ziehau wrote: On Mon, Apr 4, 2011 at 6:02 PM, Max Herrgardherrg...@gmail.comwrote: Nope. Still the same, but they are now on different irqs. I noticed however that my drm0 doesn't get set up with acpi interrupt routing turned on. Hmm, looks like its irq setting up is hosed somewhere else. drm device itself is attached. As far as I understand the drm code, bus_setup_intr is triggered by user space program like Xorg, but there are some precondition check before bus_setup_intr is called. Please set hw.dri.debug=1 (sysctl) and give me the output of vmstat -iv and dmesg, after you started Xorg. Please retest master: 7e89a536e0a53aade79d6001b8477d03245f0be0 I believe it is fixed. Yes. Everything now works as it should :) Cheers, Max
Re: ACPI based interrupt routing and new ACPI code ready for testing
On Mon, Apr 4, 2011 at 6:02 PM, Max Herrgard herrg...@gmail.com wrote: Sepherosa Ziehau wrote: On Fri, Mar 25, 2011 at 7:32 PM, Max Herrgardherrg...@gmail.com wrote: On Fri, Mar 25, 2011 at 2:21 AM, Sepherosa Ziehausepher...@gmail.com wrote: This interrupt sharing may caused by interrupt routing in ACPI code. What's the vmstat -iv on both w/ and w/o ACPI interrupt routing? Yes they are a bit different. OK, please test following commit on master: 40ad81aa20e2ba47db1f04204a60ffd06b513150 Nope. Still the same, but they are now on different irqs. I noticed however that my drm0 doesn't get set up with acpi interrupt routing turned on. Hmm, looks like its irq setting up is hosed somewhere else. drm device itself is attached. As far as I understand the drm code, bus_setup_intr is triggered by user space program like Xorg, but there are some precondition check before bus_setup_intr is called. Please set hw.dri.debug=1 (sysctl) and give me the output of vmstat -iv and dmesg, after you started Xorg. Best Regards, sephe With acpi interrupt routing: interrupt total rate irq0: clk 31844 248 irq4: sio0 0 0 irq7: ppc0 1 0 irq9: acpi0 0 0 irq10: ral0/rl0/vge0/ehci0 7536 58 irq11: fwohci0/pcm0/rl1/atapci0/uhci0/uhci1/uhci2/uhci3 9982 77 irq14: ata0 37 0 irq15: ata1 0 0 irq19 46 0 irq21 6525 50 irq192: swi_siopoll 0 0 irq195: swi_cambio 0 0 irq196: swi_vm 0 0 irq197: swi_taskq/swi_mp_taskq 0 0 Total 55971 437 Without: interrupt total rate irq0: clk 331584 331 irq4: sio0 0 0 irq5: vge0/uhci0/uhci1/drm0 55565 55 irq7: ppc0 0 0 irq9: acpi0 0 0 irq10: ral0/rl0/ehci0 20317 20 irq11: fwohci0/pcm0/rl1/atapci0/uhci2/uhci3 3386 3 irq14: ata0 37 0 irq15: ata1 0 0 irq19 46 0 irq21 3472 3 irq192: swi_siopoll 0 0 irq195: swi_cambio 0 0 irq196: swi_vm 0 0 irq197: swi_taskq/swi_mp_taskq 0 0 Total 414407 413 Max -- Tomorrow Will Never Die
Re: ACPI based interrupt routing and new ACPI code ready for testing
Sepherosa Ziehau wrote: On Mon, Apr 4, 2011 at 6:02 PM, Max Herrgardherrg...@gmail.com wrote: Nope. Still the same, but they are now on different irqs. I noticed however that my drm0 doesn't get set up with acpi interrupt routing turned on. Hmm, looks like its irq setting up is hosed somewhere else. drm device itself is attached. As far as I understand the drm code, bus_setup_intr is triggered by user space program like Xorg, but there are some precondition check before bus_setup_intr is called. Please set hw.dri.debug=1 (sysctl) and give me the output of vmstat -iv and dmesg, after you started Xorg. Hm. I had to kldload radeon.ko to get the dri sysctl tree first. drm0.vgapci0.pci1.pcib1.pci0.pcib0.acpi0.nexus0.root0 drm0: ATI Radeon RV280 9200 [tentative] on vgapci0 vgapci0: Reserved 0x1 bytes for rid 0x18 type 3 at 0xf803 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 drm0: ATI Radeon RV280 9200 [attached!] on vgapci0 then I set hw.dri.0.debug=1 and did startx. http://leaf.dragonflybsd.org/~mh/vdmesg http://leaf.dragonflybsd.org/~mh/vmstat [drm:pid943:drm_open] open_count = 0 [drm:pid943:drm_open_helper] pid = 943, minor = 0 [drm:pid943:radeon_driver_open] [drm:pid943:drm_addmap] offset = 0x, size = 0x2000, type = 2 [drm:pid943:drm_addmap] 8192 13 0xffe01d9d6000 [drm:pid943:drm_addmap] Added map 2 0xffe01d9d6000/0x2000 vgapci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xe800 [drm:pid943:drm_addmap] offset = 0xe800, size = 0x0800, type = 0 [drm:pid943:drm_addmap] Added map 0 0xe800/0x800 [drm:pid943:drm_firstopen] [drm:pid943:drm_ioctl] pid=943, cmd=0xc0406400, nr=0x00, dev 0xffe005daa008, auth=1 [drm:pid943:drm_ioctl] pid=943, cmd=0xc0406400, nr=0x00, dev 0xffe005daa008, auth=1 [drm:pid943:drm_close] open_count = 1 [drm:pid943:drm_close] pid = 943, device = 0xffe005daa008, open_count = 1 [drm:pid943:drm_lastclose] [drm:pid943:radeon_do_cleanup_cp] [drm:pid943:drm_open] open_count = 0 [drm:pid943:drm_open_helper] pid = 943, minor = 0 [drm:pid943:radeon_driver_open] [drm:pid943:drm_addmap] offset = 0x, size = 0x2000, type = 2 [drm:pid943:drm_addmap] 8192 13 0xffe01d9d6000 [drm:pid943:drm_addmap] Added map 2 0xffe01d9d6000/0x2000 [drm:pid943:drm_addmap] offset = 0xe800, size = 0x0800, type = 0 [drm:pid943:drm_addmap] Added map 0 0xe800/0x800 [drm:pid943:drm_firstopen] [drm:pid943:drm_ioctl] pid=943, cmd=0xc0106407, nr=0x07, dev 0xffe005daa008, auth=1 [drm:pid943:drm_ioctl] pid=943, cmd=0xc0106401, nr=0x01, dev 0xffe005daa008, auth=1 [drm:pid943:drm_ioctl] pid=943, cmd=0xc0106401, nr=0x01, dev 0xffe005daa008, auth=1 [drm:pid943:drm_ioctl] pid=943, cmd=0xc0406400, nr=0x00, dev 0xffe005daa008, auth=1 [drm:pid943:drm_ioctl] pid=943, cmd=0xc0406400, nr=0x00, dev 0xffe005daa008, auth=1 [drm:pid943:drm_close] open_count = 1 [drm:pid943:drm_close] pid = 943, device = 0xffe005daa008, open_count = 1 [drm:pid943:drm_lastclose] [drm:pid943:radeon_do_cleanup_cp] [drm:pid943:drm_open] open_count = 0 [drm:pid943:drm_open_helper] pid = 943, minor = 0 [drm:pid943:radeon_driver_open] [drm:pid943:drm_addmap] offset = 0x, size = 0x2000, type = 2 [drm:pid943:drm_addmap] 8192 13 0xffe01d9d6000 [drm:pid943:drm_addmap] Added map 2 0xffe01d9d6000/0x2000 [drm:pid943:drm_addmap] offset = 0xe800, size = 0x0800, type = 0 [drm:pid943:drm_addmap] Added map 0 0xe800/0x800 [drm:pid943:drm_firstopen] [drm:pid943:drm_ioctl] pid=943, cmd=0xc0406400, nr=0x00, dev 0xffe005daa008, auth=1 [drm:pid943:drm_ioctl] pid=943, cmd=0xc0406400, nr=0x00, dev 0xffe005daa008, auth=1 [drm:pid943:drm_close] open_count = 1 [drm:pid943:drm_close] pid = 943, device = 0xffe005daa008, open_count = 1 [drm:pid943:drm_lastclose] [drm:pid943:radeon_do_cleanup_cp] [drm:pid943:drm_open] open_count = 0 [drm:pid943:drm_open_helper] pid = 943, minor = 0 [drm:pid943:radeon_driver_open] [drm:pid943:drm_addmap] offset = 0x, size = 0x2000, type = 2 [drm:pid943:drm_addmap] 8192 13 0xffe01d9d6000 [drm:pid943:drm_addmap] Added map 2 0xffe01d9d6000/0x2000 [drm:pid943:drm_addmap] offset = 0xe800, size = 0x0800, type = 0 [drm:pid943:drm_addmap] Added map 0 0xe800/0x800 [drm:pid943:drm_firstopen] [drm:pid943:drm_ioctl] pid=943, cmd=0xc0406400, nr=0x00, dev 0xffe005daa008, auth=1 [drm:pid943:drm_ioctl] pid=943, cmd=0xc0406400, nr=0x00, dev 0xffe005daa008, auth=1 [drm:pid943:drm_close] open_count = 1 [drm:pid943:drm_close] pid = 943, device = 0xffe005daa008, open_count = 1 [drm:pid943:drm_lastclose] [drm:pid943:radeon_do_cleanup_cp] [drm:pid943:drm_open] open_count = 0 [drm:pid943:drm_open_helper] pid = 943, minor = 0 [drm:pid943:radeon_driver_open] [drm:pid943:drm_addmap] offset = 0x, size = 0x2000, type = 2 [drm:pid943:drm_addmap] 8192 13 0xffe01d9d6000
Re: ACPI based interrupt routing and new ACPI code ready for testing
OK, please test following commit on master: 40ad81aa20e2ba47db1f04204a60ffd06b513150 Great! This dell laptop (latitude d820) now boots v2.9.1.1044.gf7a1ba GENERIC_SMP with: hw.apic_io_enable=1 debug.acpi.enabled=pci pci_link And this time no problems with bge0 timeout reset cycle. And no usb related crash with the cd drive connected. Goetz
Re: ACPI based interrupt routing and new ACPI code ready for testing
Sepherosa Ziehau wrote: On Fri, Mar 25, 2011 at 7:32 PM, Max Herrgardherrg...@gmail.com wrote: On Fri, Mar 25, 2011 at 2:21 AM, Sepherosa Ziehausepher...@gmail.com wrote: This interrupt sharing may caused by interrupt routing in ACPI code. What's the vmstat -iv on both w/ and w/o ACPI interrupt routing? Yes they are a bit different. OK, please test following commit on master: 40ad81aa20e2ba47db1f04204a60ffd06b513150 Nope. Still the same, but they are now on different irqs. I noticed however that my drm0 doesn't get set up with acpi interrupt routing turned on. With acpi interrupt routing: interrupt total rate irq0: clk 31844 248 irq4: sio0 0 0 irq7: ppc0 1 0 irq9: acpi0 0 0 irq10: ral0/rl0/vge0/ehci0 753658 irq11: fwohci0/pcm0/rl1/atapci0/uhci0/uhci1/uhci2/uhci3 998277 irq14: ata0 37 0 irq15: ata1 0 0 irq19 46 0 irq21 652550 irq192: swi_siopoll 0 0 irq195: swi_cambio 0 0 irq196: swi_vm 0 0 irq197: swi_taskq/swi_mp_taskq 0 0 Total 55971 437 Without: interrupt total rate irq0: clk 331584331 irq4: sio0 0 0 irq5: vge0/uhci0/uhci1/drm055565 55 irq7: ppc0 0 0 irq9: acpi00 0 irq10: ral0/rl0/ehci0 20317 20 irq11: fwohci0/pcm0/rl1/atapci0/uhci2/uhci3 3386 3 irq14: ata0 37 0 irq15: ata10 0 irq19 46 0 irq21 3472 3 irq192: swi_siopoll0 0 irq195: swi_cambio 0 0 irq196: swi_vm 0 0 irq197: swi_taskq/swi_mp_taskq 0 0 Total 414407413 Max
Re: ACPI based interrupt routing and new ACPI code ready for testing
On Fri, Mar 25, 2011 at 7:32 PM, Max Herrgard herrg...@gmail.com wrote: On Fri, Mar 25, 2011 at 2:21 AM, Sepherosa Ziehau sepher...@gmail.com wrote: This interrupt sharing may caused by interrupt routing in ACPI code. What's the vmstat -iv on both w/ and w/o ACPI interrupt routing? Yes they are a bit different. OK, please test following commit on master: 40ad81aa20e2ba47db1f04204a60ffd06b513150 Best Regards, sephe With ACPI interrupt routing: interrupt total rate irq0: clk 9239831 278 irq4: sio0 0 0 irq7: ppc0 1 0 irq9: acpi0/vge0/uhci0/uhci1 33423 1 irq10: ral0/rl0/ehci0 842511 25 irq11: fwohci0/pcm0/rl1/atapci0/uhci2/uhci3 1110368 33 irq14: ata0 37 0 irq15: ata1 0 0 irq19 46 0 irq21 1119024 33 irq192: swi_siopoll 0 0 irq195: swi_cambio 0 0 irq196: swi_vm 0 0 irq197: swi_taskq/swi_mp_taskq 0 0 Total 12345241 371 Without: interrupt total rate irq0: clk 151705 466 irq4: sio0 0 0 irq5: vge0/uhci0/uhci1 40002 123 irq7: ppc0 1 0 irq9: acpi0 0 0 irq10: ral0/rl0/ehci0 9093 27 irq11: fwohci0/pcm0/rl1/atapci0/uhci2/uhci3 2253 6 irq14: ata0 37 0 irq15: ata1 0 0 irq19 46 0 irq21 2271 6 irq192: swi_siopoll 0 0 irq195: swi_cambio 0 0 irq196: swi_vm 0 0 irq197: swi_taskq/swi_mp_taskq 0 0 Total 205408 632 Max -- Tomorrow Will Never Die
Re: ACPI based interrupt routing and new ACPI code ready for testing
On Fri, Mar 25, 2011 at 2:21 AM, Sepherosa Ziehau sepher...@gmail.com wrote: This interrupt sharing may caused by interrupt routing in ACPI code. What's the vmstat -iv on both w/ and w/o ACPI interrupt routing? Yes they are a bit different. With ACPI interrupt routing: interrupt total rate irq0: clk9239831278 irq4: sio0 0 0 irq7: ppc0 1 0 irq9: acpi0/vge0/uhci0/uhci1 33423 1 irq10: ral0/rl0/ehci0 842511 25 irq11: fwohci0/pcm0/rl1/atapci0/uhci2/uhci3 1110368 33 irq14: ata0 37 0 irq15: ata10 0 irq19 46 0 irq211119024 33 irq192: swi_siopoll0 0 irq195: swi_cambio 0 0 irq196: swi_vm 0 0 irq197: swi_taskq/swi_mp_taskq 0 0 Total 12345241371 Without: interrupt total rate irq0: clk 151705466 irq4: sio0 0 0 irq5: vge0/uhci0/uhci1 40002123 irq7: ppc0 1 0 irq9: acpi00 0 irq10: ral0/rl0/ehci0 9093 27 irq11: fwohci0/pcm0/rl1/atapci0/uhci2/uhci3 2253 6 irq14: ata0 37 0 irq15: ata10 0 irq19 46 0 irq21 2271 6 irq192: swi_siopoll0 0 irq195: swi_cambio 0 0 irq196: swi_vm 0 0 irq197: swi_taskq/swi_mp_taskq 0 0 Total 205408632 Max
Re: ACPI based interrupt routing and new ACPI code ready for testing
Sepherosa Ziehau wrote: On Tue, Mar 22, 2011 at 7:58 PM, Sepherosa Ziehausepher...@gmail.com wrote: Hi all, Please test ~sephe/acpi_randy branch on leaf It includes: 1) Latest ACPI code (20110211). Thank Magliano Andrea very much for the porting 2) ACPI based interrupt routing To test the code, make sure you are at: ec18ac60f39dd33df5ad41be2c1c7f5714821ff1 Please re-test with the latest master, some I/O APIC APIC ID issue should have been addressed: eab22b0b9e4f3d610dd0d857e9805db77caee017 Hi Sephe. Great work :) Seems to boot fine on my x86_64 UP box. Anything you want tested with it running? Verbose dmesg: http://leaf.dragonflybsd.org/~mh/vdmesg_acpi_randy However, it makes my graphics card (an ati 9200 agp) lose some speed. It usually gets ~1600 fps with glxgears and with 2) enabled it drops to ~20 fps. From what I can see it gives no error about this problem. //Max
Re: ACPI based interrupt routing and new ACPI code ready for testing
:Hi Sephe. Great work :) : :Seems to boot fine on my x86_64 UP box. Anything you want tested with it :running? Verbose dmesg: http://leaf.dragonflybsd.org/~mh/vdmesg_acpi_randy : :However, it makes my graphics card (an ati 9200 agp) lose some speed. It :usually gets ~1600 fps with glxgears and with 2) enabled it drops to ~20 :fps. From what I can see it gives no error about this problem. : ://Max What about the rest of the system? Run some simple cpu benchmarks. If those are slow also this could be an indication of an interrupt storm (and possibly even a SMI storm, similar to ruse39's issue). -Matt Matthew Dillon dil...@backplane.com
Re: ACPI based interrupt routing and new ACPI code ready for testing
Hi Sephe, I've tested it again with latest master + latest acpi_randy branch and it still doesn't work without ioapic enabled. The livelock limit engaged is displayed every few seconds, it's related to irq3. The hard disk can't be initialized and it shows many DMA errors in the mean time until the mountroot prompt appears. If I manage to get a PS/2 keyboard I will send you a verbose dmesg (if needed). See last verbose dmesg with ioapic enabled: http://leaf.dragonflybsd.org/~tuxillo/archive/temp/asus_m2n4_sli_verbose_2.txt Cheers, Antonio Huete 2011/3/23 Sepherosa Ziehau sepher...@gmail.com: On Tue, Mar 22, 2011 at 7:58 PM, Sepherosa Ziehau sepher...@gmail.com wrote: Hi all, Please test ~sephe/acpi_randy branch on leaf It includes: 1) Latest ACPI code (20110211). Thank Magliano Andrea very much for the porting 2) ACPI based interrupt routing To test the code, make sure you are at: ec18ac60f39dd33df5ad41be2c1c7f5714821ff1 Please re-test with the latest master, some I/O APIC APIC ID issue should have been addressed: eab22b0b9e4f3d610dd0d857e9805db77caee017
Re: ACPI based interrupt routing and new ACPI code ready for testing
Matthew Dillon wrote: :However, it makes my graphics card (an ati 9200 agp) lose some speed. It :usually gets ~1600 fps with glxgears and with 2) enabled it drops to ~20 :fps. From what I can see it gives no error about this problem. : ://Max What about the rest of the system? Run some simple cpu benchmarks. If those are slow also this could be an indication of an interrupt storm (and possibly even a SMI storm, similar to ruse39's issue). Do you have a suggestion for such a cpu benchmark? vmstat -i looks okay: # vmstat -i interrupt total rate clk 1500666278 sio0 0 0 ppc0 1 0 acpi0/vge0/uhci0/uhci1 29597 5 ral0/rl0/ehci0145586 27 fwohci0/pcm0/rl1/atapci0/uhci2/uhci3 60096 11 ata0 37 0 ata1 0 0 irq19 46 0 irq21 63376 11 swi_siopoll0 0 swi_cambio 0 0 swi_vm 0 0 swi_taskq/swi_mp_taskq 0 0 Total1799405333 //Max
Re: ACPI based interrupt routing and new ACPI code ready for testing
Matthew Dillon wrote: :However, it makes my graphics card (an ati 9200 agp) lose some speed. It :usually gets ~1600 fps with glxgears and with 2) enabled it drops to ~20 :fps. From what I can see it gives no error about this problem. : ://Max What about the rest of the system? Run some simple cpu benchmarks. If those are slow also this could be an indication of an interrupt storm (and possibly even a SMI storm, similar to ruse39's issue). I did some primes calculation with /usr/bin/time -h primes 1 4242424242 /dev/null and they finished on same time with acpi interrupt routing enabled/disabled. //Max
Re: ACPI based interrupt routing and new ACPI code ready for testing
On Fri, Mar 25, 2011 at 5:00 AM, Max Herrgard herrg...@gmail.com wrote: Matthew Dillon wrote: :However, it makes my graphics card (an ati 9200 agp) lose some speed. It :usually gets ~1600 fps with glxgears and with 2) enabled it drops to ~20 :fps. From what I can see it gives no error about this problem. : ://Max What about the rest of the system? Run some simple cpu benchmarks. If those are slow also this could be an indication of an interrupt storm (and possibly even a SMI storm, similar to ruse39's issue). Do you have a suggestion for such a cpu benchmark? vmstat -i looks okay: # vmstat -i interrupt total rate clk 1500666 278 sio0 0 0 ppc0 1 0 acpi0/vge0/uhci0/uhci1 29597 5 This interrupt sharing may caused by interrupt routing in ACPI code. What's the vmstat -iv on both w/ and w/o ACPI interrupt routing? ral0/rl0/ehci0 145586 27 fwohci0/pcm0/rl1/atapci0/uhci2/uhci3 60096 11 ata0 37 0 ata1 0 0 irq19 46 0 irq21 63376 11 swi_siopoll 0 0 swi_cambio 0 0 swi_vm 0 0 swi_taskq/swi_mp_taskq 0 0 Total 1799405 333 //Max -- Tomorrow Will Never Die
Re: ACPI based interrupt routing and new ACPI code ready for testing
On Tue, Mar 22, 2011 at 7:58 PM, Sepherosa Ziehau sepher...@gmail.com wrote: Hi all, Please test ~sephe/acpi_randy branch on leaf It includes: 1) Latest ACPI code (20110211). Thank Magliano Andrea very much for the porting 2) ACPI based interrupt routing To test the code, make sure you are at: ec18ac60f39dd33df5ad41be2c1c7f5714821ff1 Please re-test with the latest master, some I/O APIC APIC ID issue should have been addressed: eab22b0b9e4f3d610dd0d857e9805db77caee017 To test 1), you just need to recompile the kernel and boot To test 2), in addition to recompile the kernel, you need to put: debug.acpi.enabled=pci pci_link into /boot/loader.conf Or set it on the loader prompt. 1) and 2) are tested on several real boxes, and virtualbox 3.2.12 PLEASE MAKE SURE TO BACK UP YOUR WORKING KERNEL! Best Regards, sephe -- Tomorrow Will Never Die -- Tomorrow Will Never Die
ACPI based interrupt routing and new ACPI code ready for testing
Hi all, Please test ~sephe/acpi_randy branch on leaf It includes: 1) Latest ACPI code (20110211). Thank Magliano Andrea very much for the porting 2) ACPI based interrupt routing To test the code, make sure you are at: ec18ac60f39dd33df5ad41be2c1c7f5714821ff1 To test 1), you just need to recompile the kernel and boot To test 2), in addition to recompile the kernel, you need to put: debug.acpi.enabled=pci pci_link into /boot/loader.conf Or set it on the loader prompt. 1) and 2) are tested on several real boxes, and virtualbox 3.2.12 PLEASE MAKE SURE TO BACK UP YOUR WORKING KERNEL! Best Regards, sephe -- Tomorrow Will Never Die
Re: ACPI based interrupt routing and new ACPI code ready for testing
Hi Sephe, I've tested it in x86_64. I pulled master and then merged your acpi_randy branch on the top of it. Also I've set the setting in the loader.conf file. This machine has never worked before when APIC_IO was enabled; but as of now with these changes: - APIC_IO enabled - Works perfectly so far (http://leaf.dragonflybsd.org/~tuxillo/archive/temp/asus_m2n4_sli_verbose.txt) - APIC_IO disabled - After the hard drive detection, it starts printing livelock limit enganged messages and it doesn't finish booting. I don't have a dmesg for this one, but let me know if you need further information. I will be doing more testing in my other machines. Cheers, Antonio Huete 2011/3/22 Sepherosa Ziehau sepher...@gmail.com: Hi all, Please test ~sephe/acpi_randy branch on leaf It includes: 1) Latest ACPI code (20110211). Thank Magliano Andrea very much for the porting 2) ACPI based interrupt routing To test the code, make sure you are at: ec18ac60f39dd33df5ad41be2c1c7f5714821ff1 To test 1), you just need to recompile the kernel and boot To test 2), in addition to recompile the kernel, you need to put: debug.acpi.enabled=pci pci_link into /boot/loader.conf Or set it on the loader prompt. 1) and 2) are tested on several real boxes, and virtualbox 3.2.12 PLEASE MAKE SURE TO BACK UP YOUR WORKING KERNEL! Best Regards, sephe -- Tomorrow Will Never Die
Re: Firefox still crashes; ACPI
On Tue, Oct 12, 2010 at 08:47:55AM -0700, Matthew Dillon wrote: You could try disabling ACPI subsystems and hopefully it won't crash, and then reenabling one at a time until it crashes. Could someone post all the ACPI keywords / loader.conf line for that? It's explained in acpi(4); you can specify the boot loader variable debug.acpi.disabled as a space-separated list of keywords (or a keyword) from below: ec sysresource cpu cpu_cst cpu_pst video button timer hpet acad cmbat lid thermal bus children all pci pcib pci_link quirks isa - all, bus, or children disable almost everything, so try them at last. - cpu_cst and cpu_pst are subdrivers of acpi_cpu, so specifying ``cpu'' disables both of them. - if it's not a laptop PC, you most likely don't need to bother with acad, cmbat, or lid - if you experience occasional lock-up and either ACPI or HPET is chosen as the cputimer (sysctl kern.cputimer.name), try disabling timer and/or hpet - pci, pcib, and pci_link are disabled by default; you need to explicitly specify them in another variable named ``debug.acpi.enabled'' to use - although listed in acpi(4), I couldn't find where quirks or isa are checked against.
Re: ACPI
On Tuesday 12 October 2010 01:09:27 Sascha Wildner wrote: No, I looks like an older single core CPU. But it has hyperthreading (HTT feature), so it is definitely worth a try. Will try it, but not till tonight at least. I have to bring the laptop to the office. Also, does the box have the latest BIOS available from Dell installed? Don't know. I got it used from a friend. Yes, our handbook lingers in a permanent state of unupdatedness. If you see errors, the best thing is to just be bold and fix them yourself. That would be a great help to us, if more people do it. I'll try, but I don't know what exactly the change was. There's now a /boot/kernel/ directory with both the kernel and the modules; before the kernel was /boot/kernel and the modules were in /boot/modules/? Pierre -- li ze te'a ci vu'u ci bi'e te'a mu du li ci su'i ze te'a mu bi'e vu'u ci
Re: Firefox still crashes; ACPI
You could try disabling ACPI subsystems and hopefully it won't crash, and then reenabling one at a time until it crashes. Could someone post all the ACPI keywords / loader.conf line for that? -Matt Matthew Dillon dil...@backplane.com
Re: Firefox still crashes; ACPI
:On Monday 11 October 2010 20:49:44 Matthew Dillon wrote: : We finally found it, thanks in part to the added assertions and your : reporting of the assertion that occured. The problem should be gone : on the latest master. : :Glad I could help! : :I'm still getting a kernel trap if I boot with ACPI enabled, and I can't get a :dump because it happens before the dump device is set. Can I put some :assertions in the kernel to figure that out? :http://bugs.dragonflybsd.org/issue1559 : :Pierre It looks like a VM86 BIOS call is blowing up. If that is the case it would be nearly impossible to track down. -Matt Matthew Dillon dil...@backplane.com
Re: ACPI
On Tuesday 12 October 2010 01:09:27 Sascha Wildner wrote: No, I looks like an older single core CPU. But it has hyperthreading (HTT feature), so it is definitely worth a try. I turned on SMP and APIC_IO and got a panic during boot. I turned them off, leaving only the 686 CPU enabled, and it boots. I haven't tried SMP without APIC_IO. Pierre -- lo ponse be lo mruli po'o cu ga'ezga roda lo ka dinko
Re: Firefox still crashes; ACPI
On Monday 11 October 2010 20:49:44 Matthew Dillon wrote: We finally found it, thanks in part to the added assertions and your reporting of the assertion that occured. The problem should be gone on the latest master. Glad I could help! I'm still getting a kernel trap if I boot with ACPI enabled, and I can't get a dump because it happens before the dump device is set. Can I put some assertions in the kernel to figure that out? http://bugs.dragonflybsd.org/issue1559 Pierre -- La sal en el mar es más que en la sangre. Le sel dans la mer est plus que dans le sang.
Re: Firefox still crashes; ACPI
On 10/12/2010 3:35, Pierre Abbat wrote: I'm still getting a kernel trap if I boot with ACPI enabled, and I can't get a dump because it happens before the dump device is set. Can I put some assertions in the kernel to figure that out? http://bugs.dragonflybsd.org/issue1559 Can you take a photo or screenshot of it? Sascha
Re: Firefox still crashes; ACPI
On 10/12/2010 4:07, Sascha Wildner wrote: On 10/12/2010 3:35, Pierre Abbat wrote: I'm still getting a kernel trap if I boot with ACPI enabled, and I can't get a dump because it happens before the dump device is set. Can I put some assertions in the kernel to figure that out? http://bugs.dragonflybsd.org/issue1559 Can you take a photo or screenshot of it? Photo/screenshot when booting verbose, I meant. Sascha
Re: ACPI
On Monday 11 October 2010 22:07:42 Sascha Wildner wrote: Can you take a photo or screenshot of it? Here's what it says: cardbus0.cbb0.pci2.pcib2.pci0.pcib0.legacy0.nexus0.root0 cardbus0: CardBus bus [tentative] on cbb0 cardbus0: CardBus bus [attached!] on cbb0 pccard0.cbb0.pci2.pcib2.pci0.pcib0.legacy0.nexus0.root0 pccard0: 16-bit PCCard bus [tentative] on cbb0 pccard0: 16-bit PCCard bus [attached!] on cbb0 $PIR: Found IRQ 11 for link 0x63 from 11 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address 0xb23f supervisor read page not present ip 0x8:c00fc42f sp 10:c09387c8 fp 10:c0938828 cs base 0 limit f type 1b DPL 0 pres 1 def32 1 gran 1 eflags resume IOPL=0 current process 0 (swapper) current thread pri 12 Stopped at c00fc42f: cmpb %cs:0xb23f,%bh Pierre -- Don't buy a French car in Holland. It may be a citroen.
Re: ACPI
On 10/12/2010 4:43, Pierre Abbat wrote: On Monday 11 October 2010 22:07:42 Sascha Wildner wrote: Can you take a photo or screenshot of it? Here's what it says: cardbus0.cbb0.pci2.pcib2.pci0.pcib0.legacy0.nexus0.root0 cardbus0:CardBus bus [tentative] on cbb0 cardbus0:CardBus bus [attached!] on cbb0 pccard0.cbb0.pci2.pcib2.pci0.pcib0.legacy0.nexus0.root0 pccard0:16-bit PCCard bus [tentative] on cbb0 pccard0:16-bit PCCard bus [attached!] on cbb0 $PIR: Found IRQ 11 for link 0x63 from 11 [...] Hmm, is that an SMP kernel? With or without APIC_IO? Have you tried playing with these options? Sascha
Re: ACPI
On Monday 11 October 2010 23:17:00 Sascha Wildner wrote: Hmm, is that an SMP kernel? With or without APIC_IO? Have you tried playing with these options? It's a generic kernel, and I don't know what APIC_IO is. Both of those options are turned off. Pierre -- .i toljundi do .ibabo mi'afra tu'a do .ibabo damba do .ibabo do jinga .icu'u la ma'atman.
Re: ACPI
On 10/12/2010 5:30, Pierre Abbat wrote: On Monday 11 October 2010 23:17:00 Sascha Wildner wrote: Hmm, is that an SMP kernel? With or without APIC_IO? Have you tried playing with these options? It's a generic kernel, and I don't know what APIC_IO is. Both of those options are turned off. OK. Is it a CPU with more than one core? If yes, can you try with a kernel that has SMP option and no APIC_IO option and a kernel that has both options. And see if that makes any difference to the ACPI problem? Sascha
Re: ACPI
On Tuesday 12 October 2010 00:12:57 Sascha Wildner wrote: OK. Is it a CPU with more than one core? CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz (1794.19-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 Features=0xbfebf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x400CNXT-ID Does that mean that there are four CPUs? Or is it impossible to tell without a SMP kernel? If yes, can you try with a kernel that has SMP option and no APIC_IO option and a kernel that has both options. And see if that makes any difference to the ACPI problem? I'll try that in a few days. Btw, it looks like newhandbook/ConfigureKernel hasn't been updated for the latest loader change. Pierre -- Don't buy a French car in Holland. It may be a citroen.
Re: ACPI
On 10/12/2010 6:49, Pierre Abbat wrote: On Tuesday 12 October 2010 00:12:57 Sascha Wildner wrote: OK. Is it a CPU with more than one core? CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz (1794.19-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 Features=0xbfebf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x400CNXT-ID Does that mean that there are four CPUs? Or is it impossible to tell without a SMP kernel? No, I looks like an older single core CPU. But it has hyperthreading (HTT feature), so it is definitely worth a try. Also, does the box have the latest BIOS available from Dell installed? I'll try that in a few days. Btw, it looks like newhandbook/ConfigureKernel hasn't been updated for the latest loader change. Yes, our handbook lingers in a permanent state of unupdatedness. If you see errors, the best thing is to just be bold and fix them yourself. That would be a great help to us, if more people do it. Sascha
Re: HEAD now has powerd for ACPI based cpu frequency adjustment.
Hi, what is the reason for creating powerd instead of using sysutils/estd fr om pkgsrc, which already does ACPI P-states based frequency scaling? Cheers Johannes
Re: HEAD now has powerd for ACPI based cpu frequency adjustment.
Am 03/07/2010 01:13 μμ, schrieb Johannes Hofmann: Hi, what is the reason for creating powerd instead of using sysutils/estd fr om pkgsrc, which already does ACPI P-states based frequency scaling? I think the main reason is Matt couldn't find estd so he just hacked up powerd instead. No idea if the functionality is comparable or which would be a better basis for future improvement. Aggelos
Re: HEAD now has powerd for ACPI based cpu frequency adjustment.
:Am 03/07/2010 01:13 μμ, schrieb Johannes Hofmann: : Hi, : what is the reason for creating powerd instead of using sysutils/estd fr : om pkgsrc, which already does ACPI P-states based frequency scaling? : :I think the main reason is Matt couldn't find estd so he just hacked up :powerd instead. No idea if the functionality is comparable or which :would be a better basis for future improvement. : :Aggelos It took less than 2 hours to write it, but also I want to implement a scheduler integration feature that does not exist in estd at all that will allow us to consolidate processes on fewer cpus when the load is low. Plus, it's kinda like dntpd. Just because someone somewhere wrote something doesn't mean it is going to be the best implementation. -Matt Matthew Dillon dil...@backplane.com
Re: HEAD now has powerd for ACPI based cpu frequency adjustment.
Matthew Dillon dil...@apollo.backplane.com wrote: :Am 03/07/2010 01:13 μμ, schrieb Johannes Hofmann: : Hi, : what is the reason for creating powerd instead of using sysutils/est d fr : om pkgsrc, which already does ACPI P-states based frequency scaling? : :I think the main reason is Matt couldn't find estd so he just hacked u p :powerd instead. No idea if the functionality is comparable or which :would be a better basis for future improvement. : :Aggelos It took less than 2 hours to write it, but also I want to implement a scheduler integration feature that does not exist in estd at all that will allow us to consolidate processes on fewer cpus when the load is low. I'm just asking because I wrote ACPI support for Dragonfly in estd and I 'm the current maintainer of estd. If there is a technical reason to have a proprietary implementation I'm all for it, but the whole power management stuff is quite fragmented alr eady with lots of different implementations that do the same thing slightly different. Cheers Johannes
HEAD now has powerd for ACPI based cpu frequency adjustment.
HEAD now has a /usr/sbin/powerd daemon for systems which support ACPI based cpu frequency adjustment. Your system supports this if it has the hw.acpi.cpu.px_dom* sysctls: sysctl hw.acpi | fgrep dom This is a first attempt from scratch daemon. It takes no arguments and is very generous. Any 1-second load 0.25 will set the cpus to their maximum frequency. When the 10-second load drops down below 0.12 the cpus will be set to their minimum frequency. The power savings is usually around 40%. I'm not sure how well it works for a desktop/X environment as my current workstation has an old BIOS that doesn't support the feature, but it works very nicely on servers. If the 1-second delay to go to max-frequency isn't fast enough for a desktop environment we will probably need a kernel facility that the daemon can block on (so it doesn't have to poll quickly) and have the kernel wake it up when the instantanious load exceeds a certain value. That way the daemon would be able to react within 1/10 to 1/15 of a second or so. Maybe the device event stuff being worked on can be used to support such a facility. -Matt Matthew Dillon dil...@backplane.com
Laptop still doesn't boot with ACPI
http://bugs.dragonflybsd.org/issue1559 I updated the kernel on March 28 (v2.5.1.1080.ga68e0-DEVELOPMENT) and tried booting with ACPI enabled. It still doesn't work. Pierre -- lo ponse be lo mruli po'o cu ga'ezga roda lo ka dinko
RE: Fatal trap 12 during bootup on Dell Cpt with acpi enabled
: I was experimenting with the latest Dragonfly build on a spare Dell Cpt : laptop. If you boot with acpi enabled, you get a kernel fault right : after it outputs ata0: ATA channel 0 on atapci0 Could you please start up without acpi loaded, and then try loading acpi later with kldload and see if that panics, too? If so, try and get a dump by writing 'call dumpsys' at the ddb prompt. Once you have the dump, when you reboot again (without acpi loaded, so it doesn't panic), the dump will be written to /var/crash. If you can then upload that dump somewhere, someone might be able to figure out what the problem is. Cheers, Alex Hornung
Re: Fatal trap 12 during bootup on Dell Cpt with acpi enabled
It says the ACPI driver cannot be loaded after boot in the cases of booting single user and booting multiuser. It always panics after detecting ata0. On 3/11/2010 3:19 AM, Alex Hornung wrote: : I was experimenting with the latest Dragonfly build on a spare Dell Cpt : laptop. If you boot with acpi enabled, you get a kernel fault right : after it outputs ata0:ATA channel 0 on atapci0 Could you please start up without acpi loaded, and then try loading acpi later with kldload and see if that panics, too? If so, try and get a dump by writing 'call dumpsys' at the ddb prompt. Once you have the dump, when you reboot again (without acpi loaded, so it doesn't panic), the dump will be written to /var/crash. If you can then upload that dump somewhere, someone might be able to figure out what the problem is. Cheers, Alex Hornung
Re: Fatal trap 12 during bootup on Dell Cpt with acpi enabled
On Tuesday 09 March 2010 18:50:34 LordYoukai wrote: I was experimenting with the latest Dragonfly build on a spare Dell Cpt laptop. If you boot with acpi enabled, you get a kernel fault right after it outputs ata0: ATA channel 0 on atapci0 I also get a trap page fault which has something to do with ACPI. See http://bugs.dragonflybsd.org/issue1559. The cheese no longer stands alone. Pierre -- lo ponse be lo mruli po'o cu ga'ezga roda lo ka dinko
Re: Fatal trap 12 during bootup on Dell Cpt with acpi enabled
On Tue, Mar 09, 2010 at 03:50:34PM -0800, LordYoukai wrote: current process = Idle current thread = pri 12 kernel: type 12 trap, code = 2 Stopped at AcpiReadBitRegister+0x46: movl %eax,0(%edx) Since the current process is Idle and it's crashing somewhere in AcpiReadBitRegister(), I guess that the caller is probably acpi_cpu_idle(). You can turn off part of ACPI subdrivers by setting boot loader variable (you can find the names of other subdrivers in acpi(4)): set debug.acpi.disabled=cpu_cst and see if it still panics. Alternatively, if you can modify the acpi code and reinstall the driver, the following procedure may or may not fix the issue. $ cd /sys/dev/acpica5 (if you don't have write access on /usr/obj, you need to set an environment variable MAKEOBJDIRPREFIX to somewhere else where you do) $ make obj make depend $ sed -i.bak 's/cpu_quirks;/cpu_quirks = CPU_QUIRK_NO_BM_CTRL;/' acpi_cpu_cstate.c make (see if there's no compilation errors, and ...) $ su root -c 'make install' Cheers.
Re: Fatal trap 12 during bootup on Dell Cpt with acpi enabled
Am 12.03.2010 07:22, schrieb LordYoukai: Disabling cpu_cst seems to have alleviated the panic issue. There is still the issue of a long wait at bootup after the discovery of kbd0 but it did boot. Just a wild guess: Is this a laptop without a battery? If so, disabling cmbat might speed up things. Can you boot verbosely and see if it tells more? Sascha -- http://yoyodyne.ath.cx
Fatal trap 12 during bootup on Dell Cpt with acpi enabled
I was experimenting with the latest Dragonfly build on a spare Dell Cpt laptop. If you boot with acpi enabled, you get a kernel fault right after it outputs ata0: ATA channel 0 on atapci0 The full text is as follows: Fatal trap 12: page fault while in kernel mode fault virtual address = 0 fault code = supervisor write, page not present instruction pointer = 0x8:0xc082d871 stack pointer = 0x10: 0xc6f31d2c frame pointer = 0x10:0xc6f31d38 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = Idle current thread = pri 12 kernel: type 12 trap, code = 2 Stopped at AcpiReadBitRegister+0x46: movl %eax,0(%edx) db --- I am uncertain what else to do - I have left the laptop as is, so if you have any commands for me to input, it is a definite. Ben
ACPI version to set in BIOS
Hi: The BIOS setup utility (v02.58 American Megatrends) provides multiple ACPI versions . ACPI v1.0 . ACPI v2.0 . ACPI v3.0 Currently i've configured ACPI v1.0 while running DragonFly BSD HEAD, but i'd like to know what is the recommended version to setup in BIOS while running DragonFly ? thanks Saifi.
ACPI Exception: AE_NO_HARDWARE_RESPONSE
Hi: On Compaq C301TU laptop, the following lines get dumped on screen everytime there is a change in the power state (on-off, off-on). system power profile changed to 'economy' ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.PCI0.LPCB.EC0_.PCLK] (Node 0xc40694cc), AE_NO_HARDWARE_RESPONSE ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.PCI0.LPCB.EC0_._Q1D] (Node 0xc406956c), AE_NO_HARDWARE_RESPONSE system power profile changed to 'performance' ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.PCI0.LPCB.EC0_.PCLK] (Node 0xc40694cc), AE_NO_HARDWARE_RESPONSE ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.PCI0.LPCB.EC0_._Q1D] (Node 0xc406956c), AE_NO_HARDWARE_RESPONSE system power profile changed to 'economy' ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.PCI0.LPCB.EC0_.PCLK] (Node 0xc40694cc), AE_NO_HARDWARE_RESPONSE ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.PCI0.LPCB.EC0_._Q1D] (Node 0xc406956c), AE_NO_HARDWARE_RESPONSE system power profile changed to 'performance' The power profile change notification is expected, but the ACPI Error|Exception notification is surprising as i don't see this on an identical laptop running FreeBSD-8. The 'dmesg extract' below show information specific to ACPI. Copyright (c) 2003-2009 The DragonFly Project. 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. DragonFly 2.4.1-RELEASE #2: Thu Oct 22 03:37:54 UTC 2009 r...@laptop.datasynergy.org:/usr/obj/usr/src/sys/DF241-P-SZ-RL-OS TSC clock: 1596044328 Hz, i8254 clock: 1193215 Hz CPU: Intel(R) Celeron(R) M CPU420 @ 1.60GHz (1596.01-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6e8 Stepping = 8 Features=0xafe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE Features2=0xc109SSE3,MON,TM2,xTPR,PDCM real memory = 2137522176 (2087424K bytes) avail memory = 2063863808 (2015492K bytes) kbd1 at kbdmux0 Pentium Pro MTRR support enabled fildesc_drvinit() building stdin, stdout, stderr: md0: Malloc disk ACPI: RSDP 0xf6510 00014 (v0 PTLTD ) ACPI: RSDT 0x7f68cbda 0004C (v1 HPQOEM SLIC-MPC 0604 LTP ) ACPI: FACP 0x7f693c86 00074 (v1 HP NISSAN 0604 LOHR 005A) ACPI: DSDT 0x7f68d506 06780 (v1 HP NISSAN 0604 INTL 20060608) ACPI: FACS 0x7f694fc0 00040 ACPI: APIC 0x7f693cfa 00068 (v1 HP NISSAN 0604 LOHR 005A) ACPI: HPET 0x7f693d62 00038 (v1 HP NISSAN 0604 LOHR 005A) ACPI: MCFG 0x7f693d9a 0003C (v1 HP NISSAN 0604 LOHR 005A) ACPI: BOOT 0x7f693fd8 00028 (v1 PTLTD $SBFTBL$ 0604 LTP 0001) ACPI: SLIC 0x7f693e08 00176 (v1 HPQOEM SLIC-MPC 0604 LOHR ) ACPI: APIC 0x7f693f7e 0005A (v1 PTLTDAPIC 0604 LTP ) ACPI: SSDT 0x7f68d2f8 0020A (v1 SataRe SataAhci 1000 INTL 20060217) ACPI: SSDT 0x7f68d11c 001DC (v1 PmRef Cpu0Cst 3001 INTL 20060217) ACPI: SSDT 0x7f68cc26 004F6 (v1 PmRefCpuPm 3000 INTL 20060217) npx0: math processor on motherboard npx0: INT 16 interface Using XMM optimized bcopy/copyin/copyout acpi0: HPQOEM SLIC-MPC on motherboard acpi0: Power Button (fixed) ACPI Error: Could not enable SleepButton event 20090521 evxfevnt-298 ACPI Warning: Could not enable fixed event 3 20090521 evxface-235 acpi0: Sleep Button (fixed) Warning: ACPI is disabling APM's device. You can't run both acpi_ec0: Embedded Controller: GPE 0x19 port 0x66,0x62 on acpi0 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 cpu0: ACPI CPU on acpi0 cpu_cst0: ACPI CPU C-State on cpu0 acpi_tz0: Thermal Zone on acpi0 acpi_tz1: Thermal Zone on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Power Button on acpi0 battery0: ACPI Control Method Battery on acpi0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 How do I fix the ... ACPI Exception: AE_NO_HARDWARE_RESPONSE ... notification lines ? thanks Saifi.
Re: Hunting for missing ACPI interrupt
On Sun 19/8/07 11:54 pm, YONETANI Tomokazu wrote: On Sun, Aug 19, 2007 at 07:55:35PM +0100, David Murray wrote: Anyway, it turns out the power button doesn't work because the ACPI interrupt never appears, at least according to vmstat -i. Does it generate interrupts under FreeBSD? I've just tried the FreeSBIE live CD (based on FreeBSD 6.2) and the power button works as it should. I'll diff Dragonfly's acpica5 dir with FreeBSD's... -- David Murray
Re: Hunting for missing ACPI interrupt
Hi Tomokazu, On Sun 19/8/07 11:54 pm, YONETANI Tomokazu wrote: On Sun, Aug 19, 2007 at 07:55:35PM +0100, David Murray wrote: Anyway, it turns out the power button doesn't work because the ACPI interrupt never appears, at least according to vmstat -i. Does it generate interrupts under FreeBSD? I'm not sure if their ACPI module is compiled with debug supports, though. I don't know, but that sounds like a good thing to try. I will look for a FreeBSD live CD to save digging out another disk drive... I'm assuming the Dragonfly code's still pretty similar similar to that of early FreeBSD 5, with some modifications to compile with newer ACPICA code and some fixes ported over from FreeBSD. I think there are still a lot of things to port from FreeBSD. Okay, thanks for the info. I may try diffing, to see if anything stands out. -- David Murray
Hunting for missing ACPI interrupt
Hi All, I'm wondering if anyone out there can offer any hints for finding a missing interrupt. I've got box here where the front-panel power button has never worked - it doesn't shut the system down. I thought I'd look into it - how hard can it be to make an off switch work, I thought. (People familiar with ACPI will be laughing out loud at this point.) Anyway, it turns out the power button doesn't work because the ACPI interrupt never appears, at least according to vmstat -i. Building the ACPI module with debug shows that it seems to be doing all the right things - it figures out where the registers are in i/o space, enables ACPI, installs a handler and unmasks the power button as an interrupt source. And pressing the button *does* toggle the corresponding status bit, so the hardware really ought to be generating an interrupt at this point. So, either I still have some ACPI (or BIOS or hardware) misconfiguration which means the interrupt isn't being generated as advertised, or I have some sort of interrupt handling misconfiguration which means the interrupt's not getting through to the handler. Can anyone make any suggestions as to how I might diagnose which it is? I did take a look through the FreeBSD ACPI mailing list (I'm assuming the Dragonfly code's still pretty similar) but found only lots of problems with interrupt storms, not interrupt droughts. Thanks in advance! -- David Murray
Re: Hunting for missing ACPI interrupt
David Murray wrote: Hi All, I'm wondering if anyone out there can offer any hints for finding a missing interrupt. I've got box here where the front-panel power button has never worked - it doesn't shut the system down... My BIOS has setable options for how the power switch should behave, e.g. how many seconds I must hold it down before the power actually shuts off. Does your BIOS have something similar?
Re: Hunting for missing ACPI interrupt
Hi Walt, On Sun 19/8/07 11:12 pm, walt wrote: David Murray wrote: I've got box here where the front-panel power button has never worked - it doesn't shut the system down... My BIOS has setable options for how the power switch should behave, e.g. how many seconds I must hold it down before the power actually shuts off. Does your BIOS have something similar? Pressing and holding does turn the power off, without any interaction with Dragonfly. My problem is with pressing and releasing the power button. That should cause the ACPI system to have Dragonfly shut down cleanly. But it seems the interrupt that starts this process never arrives at its handler, and it's that that I'm trying to diagnose. -- David Murray
Re: Hunting for missing ACPI interrupt
On Sun, Aug 19, 2007 at 07:55:35PM +0100, David Murray wrote: Anyway, it turns out the power button doesn't work because the ACPI interrupt never appears, at least according to vmstat -i. Building the ACPI module with debug shows that it seems to be doing all the right things - it figures out where the registers are in i/o space, enables ACPI, installs a handler and unmasks the power button as an interrupt source. And pressing the button *does* toggle the corresponding status bit, so the hardware really ought to be generating an interrupt at this point. Does it generate interrupts under FreeBSD? I'm not sure if their ACPI module is compiled with debug supports, though. I did take a look through the FreeBSD ACPI mailing list (I'm assuming the Dragonfly code's still pretty similar) but found only lots of problems with interrupt storms, not interrupt droughts. similar to that of early FreeBSD 5, with some modifications to compile with newer ACPICA code and some fixes ported over from FreeBSD. I think there are still a lot of things to port from FreeBSD. Cheers.
Re: 1.8.x: ACPI problems
On Thu, Mar 01, 2007 at 02:03:56PM +0200, Tero M?ntyvaara wrote: YONETANI Tomokazu wrote: On Wed, Feb 28, 2007 at 05:48:27AM +0200, Tero M?ntyvaara wrote: When I boot DF normally to ACPI mode and prompt appears, I can't write anything to prompt. prompt means the login prompt (login: or #)? (1) I meant login prompt (login:) So if you enable ACPI and boot, it won't respond to keyboard no matter whether you choose to boot into single- or multi-user mode? But If I boot to non-ACPI-mode, everything works just fine, but I can't get to sigle user mode, because prompt freezes there too... By everything works just fine you mean it manages to boot into multi-user mode in which you see login: prompt, but once you issue # shutdown now command and it goes to single-user mode, it stops responding to your key stroke, right? If so, it sounds like a USB keyboard issue, but I may be wrong... (4) When I issue # shutdown now command in non-ACPI multiuser mode, it outputs the same as in section (3) and after hitting RETURN prompt responds to input normaly. So ... your keyboard does not work when you boot straight into the single user mode, whether with or without ACPI driver enabled, right? If not, I have no idea what this part really means: But If I boot to non-ACPI-mode, everything works just fine, but I can't get to sigle user mode, because prompt freezes there too... My keyboard (Logitech Internet Pro/Y-sZ49) is not USB-version, it is connected to PS/2-port. How should I debug the issue further? If the message buffer(which dmesg command shows you) survives across reboot, I'd like to look at it after you boot with ACPI driver enabled and booted with `boot -v' from the boot loader prompt (did I ask if keyboard works when you go into the boot loader prompt?). Cheers.
Re: 1.8.x: ACPI problems
YONETANI Tomokazu wrote: On Wed, Feb 28, 2007 at 05:48:27AM +0200, Tero M?ntyvaara wrote: When I boot DF normally to ACPI mode and prompt appears, I can't write anything to prompt. prompt means the login prompt (login: or #)? (1) I meant login prompt (login:) Are you using the GENERIC kernel that came with the installer, or a custom kernel? (2) Using default kernel came with installer What happens if you boot into the boot loader(type 6 in the boot menu) and type the following two lines: set debug.acpi.disabled=ec boot -sv (3) I get Enter full pathname of shell or RETURN for /bin/sh: and again I can not write anything to prompt like keyboard is not responding to any input. But If I boot to non-ACPI-mode, everything works just fine, but I can't get to sigle user mode, because prompt freezes there too... By everything works just fine you mean it manages to boot into multi-user mode in which you see login: prompt, but once you issue # shutdown now command and it goes to single-user mode, it stops responding to your key stroke, right? If so, it sounds like a USB keyboard issue, but I may be wrong... (4) When I issue # shutdown now command in non-ACPI multiuser mode, it outputs the same as in section (3) and after hitting RETURN prompt responds to input normaly. My keyboard (Logitech Internet Pro/Y-sZ49) is not USB-version, it is connected to PS/2-port. How should I debug the issue further? My hardware: - Processor: AMD Athlon 64 3000+ (Socket 939) - Mobo: Asus A8R-MVP (ATI CrossFire? Xpress 1600, Marvell 88E8001) - Memory: 512 MB (PC-3200/400 MHz) - Storage: 2 x Samsung SpinPoint P80SD HD080HJ 80 GB SATA2 NCQ - Display adapter: Club 3D 6200LE PCI-E CGNX-L628R Cheers. -- Tero Mäntyvaara
Re: 1.8.x: ACPI problems
On Wed, Feb 28, 2007 at 05:48:27AM +0200, Tero M?ntyvaara wrote: When I boot DF normally to ACPI mode and prompt appears, I can't write anything to prompt. prompt means the login prompt (login: or #)? Are you using the GENERIC kernel that came with the installer, or a custom kernel? What happens if you boot into the boot loader(type 6 in the boot menu) and type the following two lines: set debug.acpi.disabled=ec boot -sv But If I boot to non-ACPI-mode, everything works just fine, but I can't get to sigle user mode, because prompt freezes there too... By everything works just fine you mean it manages to boot into multi-user mode in which you see login: prompt, but once you issue # shutdown now command and it goes to single-user mode, it stops responding to your key stroke, right? If so, it sounds like a USB keyboard issue, but I may be wrong... My hardware: - Processor: AMD Athlon 64 3000+ (Socket 939) - Mobo: Asus A8R-MVP (ATI CrossFire? Xpress 1600, Marvell 88E8001) - Memory: 512 MB (PC-3200/400 MHz) - Storage: 2 x Samsung SpinPoint P80SD HD080HJ 80 GB SATA2 NCQ - Display adapter: Club 3D 6200LE PCI-E CGNX-L628R Cheers.
Re: ACPI: getting front-panel power button to cause shutdown
On Sat, Nov 25, 2006 at 08:04:26PM +, David Murray wrote: I'm trying to get the front-panel power button to shut the system down (cleanly). Currently when I press it, nothing discernible happens (no console messages, nothing logged, and certainly no shutdown). Some of machines around me have this problem too, but I have never cared to investigate :) shutdown -p now, and acpiconf -s 5 both work just fine, which makes me think nothing's fundamentally broken. [looks ok to me too] Can anyone suggest what I might do to diagnose what's going on? I'll happily provide more info, if it helps. Pressing the power button delivers an interrupt to the acpi driver, and it triggers an event handler which winds up to call a function acpi_SetSleepState(), so the first step is to see if an interrupt is delivered to the acpi driver. $ vmstat -i |grep acpi (press power button) $ vmstat -i |grep acpi The number doesn't change on machines with non-working power button here, so I need to find why it's not. But if it does on your machine, try rebuilding the driver with debugging support and see what's happening: % sh $ export MAKEOBJDIRPREFIX=$HOME/obj ACPI_DEBUG=yes $ cd /sys/dev/acpica5 $ make obj make depend $ su (you're asked the root password here) # make install # echo 'debug.acpi.layer=ACPI_EVENTS ACPI_BUTTON'/boot/loader.conf # echo 'debug.acpi.level=ACPI_LV_FUNCTIONS ACPI_LV_INFO'/boot/loader.conf # reboot Cheers.
Re: ACPI: getting front-panel power button to cause shutdown
Hi Tomokazu, On 28/11/06 8:59 am, YONETANI Tomokazu wrote: On Sat, Nov 25, 2006 at 08:04:26PM +, David Murray wrote: I'm trying to get the front-panel power button to shut the system down (cleanly). Pressing the power button delivers an interrupt to the acpi driver... so the first step is to see if an interrupt is delivered to the acpi driver. $ vmstat -i |grep acpi (press power button) $ vmstat -i |grep acpi Thanks for the suggestion. The interrupt count stays firmly at zero, so it looks like I see the same as you do for machines with this problem. I'm not sure what has to be right to cause the interrupt to be generated - presumably there's some sort of interaction between the driver and the ASL. I'll try fiddling with the BIOS settings, but I don't think there's much I can change. I seem to remember that setting PnP OS to yes made things much worse! -- Dave Murray
Re: ACPI: getting front-panel power button to cause shutdown
David Murray [EMAIL PROTECTED] wrote: Would anyone be good enough to help a DragonFly newbie with an ACPI question? I'm trying to get the front-panel power button to shut the system down (cleanly). Currently when I press it, nothing discernible happens (no console messages, nothing logged, and certainly no shutdown). shutdown -p now, and acpiconf -s 5 You might try: sysctl -w hw.acpi.power_button_state=S5 Johannes both work just fine, which makes me think nothing's fundamentally broken. My BIOS offers me either soft off or suspend for the front panel button. I expect I want soft off, but I have tried both. Setting hw.acpi.verbose=1 doesn't seem to tease out any more diagnostics. The acpi module seems to be loading okay at boot time /modules/acpi.ko text=0x47358 data=0x188c+0xb38 syms=[0x4+0x6490+0x4+0x7ebd] and it successfully probes the power button acpi0: Power Button (fixed) Warning: ACPI is disabling APM's device. You can't run both [...] acpi_button0: Power Button on acpi0 Unfortunately the ACPI man pages don't have much to say about the power button, and I can't find anything pertinent in the mailing list archive. Can anyone suggest what I might do to diagnose what's going on? I'll happily provide more info, if it helps. Many thanks in advance!
Re: ACPI: getting front-panel power button to cause shutdown
On 26/11/06 1:29 pm, Johannes Hofmann wrote: David Murray [EMAIL PROTECTED] wrote: I'm trying to get the front-panel power button to shut the system down (cleanly). Currently when I press it, nothing discernible happens shutdown -p now, and acpiconf -s 5 You might try: sysctl -w hw.acpi.power_button_state=S5 Thanks for the suggestion, Johannes. However, it was already set to S5 (I should have said so in my original post). I'm not sure if I've missed some piece of configuration necessary to get the button event acted on, or if I need to turn on debugging in the ACPI code to work out where it's going missing. -- Dave Murray
Re: ACPI: getting front-panel power button to cause shutdown
On Sun, November 26, 2006 9:50 am, David Murray wrote: On 26/11/06 1:29 pm, Johannes Hofmann wrote: Thanks for the suggestion, Johannes. However, it was already set to S5 (I should have said so in my original post). I'm not sure if I've missed some piece of configuration necessary to get the button event acted on, or if I need to turn on debugging in the ACPI code to work out where it's going missing. I realize I'm asking about basic things, but it's always good to be sure: your power button works to turn the system on, correct? And it is wired to the motherboard? Are you holding down the power button for 10 seconds?
Re: ACPI: getting front-panel power button to cause shutdown
On 26/11/06 3:25 pm, Justin C. Sherrill wrote: I realize I'm asking about basic things, but it's always good to be sure: Absolutely! your power button works to turn the system on, correct? Yes, I couldn't start the system otherwise! :-) And it is wired to the motherboard? Yes, and (I mention this only to rule out trivial hardware faults) it worked when this was a Windows box (then to make the system hibernate, so S3 or S4, I think). Are you holding down the power button for 10 seconds? No, just pressing and releasing. If I hold it in (actually for four seconds) then then the BIOS unilaterally powers off, and it's fscks time when the system is restarted. -- Dave Murray
ACPI: getting front-panel power button to cause shutdown
Would anyone be good enough to help a DragonFly newbie with an ACPI question? I'm trying to get the front-panel power button to shut the system down (cleanly). Currently when I press it, nothing discernible happens (no console messages, nothing logged, and certainly no shutdown). shutdown -p now, and acpiconf -s 5 both work just fine, which makes me think nothing's fundamentally broken. My BIOS offers me either soft off or suspend for the front panel button. I expect I want soft off, but I have tried both. Setting hw.acpi.verbose=1 doesn't seem to tease out any more diagnostics. The acpi module seems to be loading okay at boot time /modules/acpi.ko text=0x47358 data=0x188c+0xb38 syms=[0x4+0x6490+0x4+0x7ebd] and it successfully probes the power button acpi0: Power Button (fixed) Warning: ACPI is disabling APM's device. You can't run both [...] acpi_button0: Power Button on acpi0 Unfortunately the ACPI man pages don't have much to say about the power button, and I can't find anything pertinent in the mailing list archive. Can anyone suggest what I might do to diagnose what's going on? I'll happily provide more info, if it helps. Many thanks in advance! -- Dave Murray
ACPI (Re: ICH7 ?)
Kevin L. Kane wrote: ok some more info... using this iso: http://chlamydia.fs.ei.tum.de/pub/DragonFly/snapshots/i386/LATEST-Devel.iso.bz2 it fails with default option at the loader prompt, but if you say load with ACPI disabled it works fine. Our ACPI surely could need an update. Any takers? Sascha -- http://yoyodyne.ath.cx
Re: ACPI (Re: ICH7 ?)
Am Donnerstag, 6. April 2006 19:38 schrieb Sascha Wildner: snip Our ACPI surely could need an update. Any takers? Sascha Hearing that, it can add a bug report: when I boot the DragonFly 1.4 CD on my Asus V6800 notebook with ACPI enabled, the keyboard doesn't work on the login prompt. When I boot without ACPI, it does work. Thomas
Re: boot failure with acpi...
:i updated my src tree then recompiled my kernel earlier but after :rebooting it failed, so what i did was reboot but this time without :acpi mode just to try and evrything's all ok again. i dont know what :to do with it so i just want to report it, hope this helps somehow. :below are the errors that appeared... : :Fatal trap 12: page fault while in kernel mode :fault virtual address# 0x10 :fault code # supervisor read, page not present :instruction poiuter # 0x8:0xc019d4c1 :stack pointer # 0x10:0xc04cbc78 :frame pointer # 0x10:0xc04cbc8c :code segment # base 0x0: limit 0xf, type 0x1b :# DPL 0, pres 1, def32 1 , gran 1 :process eflags # interrupt enabled, resume, IOPL = 0 :current process # 0 (swapper) :current thread# pri 12 : :trap number # 12 :panic: page fault : :ps. im using 1.3.7-HEAD in shuttle xpc ss56g system : :Kirdy Please run 'nm -n /kernel' and extract the addresses both before and after 0xc019d4c1, and post that. If I can't figure it out from that I'll probably need more info, like a DDB backtrace. Make sure that when you recompiled your kernel, you did a full recompile and install of the kernel using the make buildkernel and installkernel targets, rather then just 'make' inside the kernel's object tree. -Matt Matthew Dillon [EMAIL PROTECTED]
Re: ACPI suspend/resume [now working]
:After playing around a little, I found that the following patch makes :suspend/resume work: :.. : : :icu_reinit() has been in previous FreeBSD versions of acpi_wakeup.c. : :I am not sure, whether this is the right way to fix it though. : : Johannes Nice work! It does make sense... interrupts could get stuck while the machine goes to sleep for various reasons and re-initing the 8259 would definitely fix that. I will commit it. I am still going to try to track down the crash you uploaded, as well. -Matt Matthew Dillon [EMAIL PROTECTED]
Re: ACPI suspend/resume
Matthew Dillon [EMAIL PROTECTED] wrote: Hmm. If it popped into the debugger it should have presented some sort of error message. See if you can get a kernel core dump with it in that state. That's what I did. I did a panic in the debugger and it wrote a kernel core dump, which I examined with gdb. That's where the stacktrace comes from. Is there another way to generate a core dump from the debugger? Johannes
ACPI suspend/resume
I am trying to get suspend to RAM working on my Thinkpad. The machine
suspends fine, and even comes up again, but then stops in the kernel
debugger immediately. Here is a stacktrace from gdb:
..
#37 0xc80d4c00 in ?? ()
#38 0xdebf9988 in ?? ()
#39 0xc026ebef in cdevsw_putport (port=0xcce52700, lmsg=0x80045003)
at /usr/src/sys/kern/kern_device.c:100
#40 0xc026ebef in cdevsw_putport (port=0xc05708e0, lmsg=0xdebf99ac)
at /usr/src/sys/kern/kern_device.c:100
#41 0xc0289352 in lwkt_domsg (port=0x0, msg=0xdebf99ac) at msgport2.h:86
#42 0xc026ee5f in dev_dioctl (dev=0xcce52700, cmd=0, data=0x0, fflag=0, td=0x0)
at /usr/src/sys/kern/kern_device.c:222
#43 0xc02d9a24 in spec_ioctl (ap=0x0)
at /usr/src/sys/vfs/specfs/spec_vnops.c:370
#44 0xc02d95b0 in spec_vnoperate (ap=0x0)
at /usr/src/sys/vfs/specfs/spec_vnops.c:125
#45 0xc0405797 in ufs_vnoperatespec (ap=0x0)
at /usr/src/sys/vfs/ufs/ufs_vnops.c:2384
#46 0xc02d449a in vop_ioctl (ops=0x0, vp=0x0, command=0, data=0x0, fflag=0,
cred=0x0, td=0x0) at /usr/src/sys/kern/vfs_vopops.c:555
#47 0xc02d3ffc in vn_ioctl (fp=0xc1744a00, com=2147766275,
data=0xdebf9b50 \003, td=0x0) at /usr/src/sys/kern/vfs_vnops.c:903
#48 0xc029d445 in mapped_ioctl (fd=3, com=2147766275, uspc_data=---Can't read
userspace from dump, or kernel process---
) at file2.h:91
#49 0xc029cf7f in ioctl (uap=0x0) at /usr/src/sys/kern/sys_generic.c:392
#50 0xc0479e24 in syscall2 (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077938180, tf_esi =
-1077937904, tf_ebp = -1077938312, tf_isp = -557867660, tf_ebx = -1077938400,
tf_edx = 2, tf_ecx = 671531072, tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip
= 671847888, tf_cs = 31, tf_eflags = 642, tf_esp = -1077938436, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1338
#51 0xc046690a in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:854
Any ideas how to debug this further?
Johannes
PS: I am running 1.3.5-DEVELOPMENT
