Re: USB locks up system -- WAS Re: shutdown or acpi problem
On 2014-11-17 08:58, Dag-Erling Smørgrav wrote: > Dag-Erling Smørgrav writes: >> Steve Kargl writes: >>> I'll try that tomorrow. But, I now know that this is related to using >>> hal from ports. If I comment out both enable_dbus and enable_hal in >>> /etc/rc.conf, the system works as I would expect (ie., usb now works >>> for unplugging devices!). I further suspect that the problems lies in >>> hal_probe_storage, but haven't got too much further. >> HAL: the gift that keeps on giving. It also has this wonderful feature >> where it prevents you from unmounting anything you've ever mounted, >> because it watches for new mountpoints in the system, opens them, and >> keeps the file descriptors open indefinitely. >> >> I know this isn't really germane, but I just couldn't pass up a chance >> to complain about HAL. > > Hold on. It *is* germane: hal_probe_storage auto-mounted your USB stick > and is holding on to it. If this also happens with mice and keyboards > etc., you're probably looking at two different issues. > > DES > I cursed at HAL a lot because it made uC inside r0ket to crap itself partially... this thing can be USB device but apparently didn't like black magic that HAL did. Maybe it tried to read from the beginning or something. It took lot of time to figure out why it doesn't work. Now I have set of ignore files to prevent grabbing for every single device in system. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
Dag-Erling Smørgrav writes: > Steve Kargl writes: > > I'll try that tomorrow. But, I now know that this is related to using > > hal from ports. If I comment out both enable_dbus and enable_hal in > > /etc/rc.conf, the system works as I would expect (ie., usb now works > > for unplugging devices!). I further suspect that the problems lies in > > hal_probe_storage, but haven't got too much further. > HAL: the gift that keeps on giving. It also has this wonderful feature > where it prevents you from unmounting anything you've ever mounted, > because it watches for new mountpoints in the system, opens them, and > keeps the file descriptors open indefinitely. > > I know this isn't really germane, but I just couldn't pass up a chance > to complain about HAL. Hold on. It *is* germane: hal_probe_storage auto-mounted your USB stick and is holding on to it. If this also happens with mice and keyboards etc., you're probably looking at two different issues. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
Steve Kargl writes: > I'll try that tomorrow. But, I now know that this is related to using > hal from ports. If I comment out both enable_dbus and enable_hal in > /etc/rc.conf, the system works as I would expect (ie., usb now works > for unplugging devices!). I further suspect that the problems lies in > hal_probe_storage, but haven't got too much further. HAL: the gift that keeps on giving. It also has this wonderful feature where it prevents you from unmounting anything you've ever mounted, because it watches for new mountpoints in the system, opens them, and keeps the file descriptors open indefinitely. I know this isn't really germane, but I just couldn't pass up a chance to complain about HAL. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Sun, Nov 16, 2014 at 08:33:15PM +0100, Hans Petter Selasky wrote: > > thread apply all bt > > That will give you the backtrace of all threads. Grep for usbconfig, and > figure out which line is causing the problem in the kernel. Then look at > the USB explore threads and see where they are stuck in the detach of umass! > I haven't tried the kgdb approach, yet. I can say that the problem is coming from sg device. If I have 'device sg' in my config file, the problems occur. Removing 'device sg' gives a working kernel. If I do not start hald in /etc/rc.conf, everything works as expected. Now, if hald was started at boot and I then stop hald with '/usr/local/etc/rc.d/hald stop' then the one hald relate process is not stopped. I've wrapped lines to keep this short. % ps axl | grep hald UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 10581 195 20 0 13180 3512 - I - 0:00.05 hald-probe-storage: /dev/sg1 (hald-probe-storage) Using the procstat as suggested by Adrian, I have % procstat -ka 1058 100157 hald-probe-storage hald-probe-stora mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep sgread giant_read devfs_read_f dofileread kern_readv sys_read syscall Xint0x80_syscall -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Sun, Nov 16, 2014 at 04:34:38PM -0800, Adrian Chadd wrote: > ... or since you can ssh into the thing, try as root: > > procstat -ka > I'll try that tomorrow. But, I now know that this is related to using hal from ports. If I comment out both enable_dbus and enable_hal in /etc/rc.conf, the system works as I would expect (ie., usb now works for unplugging devices!). I further suspect that the problems lies in hal_probe_storage, but haven't got too much further. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
... or since you can ssh into the thing, try as root: procstat -ka -adrian On 16 November 2014 11:33, Hans Petter Selasky wrote: > On 11/16/14 20:29, Steve Kargl wrote: >> >> On Sun, Nov 16, 2014 at 08:16:36PM +0100, Hans Petter Selasky wrote: >>> >>> On 11/16/14 20:03, Steve Kargl wrote: On Sun, Nov 16, 2014 at 06:55:53PM +, Mark R V Murray wrote: > > >> On 16 Nov 2014, at 18:51, Steve Kargl >> wrote: >> >> If you have not read the entire thread, once the laptop keyboard and >> video output lock up, I can ssh into the laptop. If I run usbconfig, >> it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* >> devices >> have not been destroyed. > > > Weirder and weirder :-(. > > Something with SX locks? Hmm. I do use those for attach and detach for > RNG sources. Could it be that that stick of yours is somehow getting > involved in the RNG source locks? > It's not limited to a single usb device. Plugging in/Unplugging a logitech mouse dongle, the memstick, a Western Digital MY Passport external usb hard drive, all lead to the locked keyboard and video. I tried adding both RANDOM_DEBUG and USBDEBUG to the kernel, but the mount of output is mind numbing. >>> >>> >>> Can you enter kgdb when the usbconfig is froozen, and backtrace all >>> kernel threads. You should see exactly what locks are the problem. >>> >>> Maybe some lock didn't get properly unlocked! >>> >> >> I haven't tried kgdb. I did try to attach gdb to the usbconfig >> process via its pid, but gdb dumped core. >> >> I haven't looked at locks in kgdb, what command or commands should >> I try. >> >> > > Hi, > > You enter: > > thread apply all bt > > That will give you the backtrace of all threads. Grep for usbconfig, and > figure out which line is causing the problem in the kernel. Then look at the > USB explore threads and see where they are stuck in the detach of umass! > > --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On 11/16/14 20:29, Steve Kargl wrote: On Sun, Nov 16, 2014 at 08:16:36PM +0100, Hans Petter Selasky wrote: On 11/16/14 20:03, Steve Kargl wrote: On Sun, Nov 16, 2014 at 06:55:53PM +, Mark R V Murray wrote: On 16 Nov 2014, at 18:51, Steve Kargl wrote: If you have not read the entire thread, once the laptop keyboard and video output lock up, I can ssh into the laptop. If I run usbconfig, it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices have not been destroyed. Weirder and weirder :-(. Something with SX locks? Hmm. I do use those for attach and detach for RNG sources. Could it be that that stick of yours is somehow getting involved in the RNG source locks? It's not limited to a single usb device. Plugging in/Unplugging a logitech mouse dongle, the memstick, a Western Digital MY Passport external usb hard drive, all lead to the locked keyboard and video. I tried adding both RANDOM_DEBUG and USBDEBUG to the kernel, but the mount of output is mind numbing. Can you enter kgdb when the usbconfig is froozen, and backtrace all kernel threads. You should see exactly what locks are the problem. Maybe some lock didn't get properly unlocked! I haven't tried kgdb. I did try to attach gdb to the usbconfig process via its pid, but gdb dumped core. I haven't looked at locks in kgdb, what command or commands should I try. Hi, You enter: thread apply all bt That will give you the backtrace of all threads. Grep for usbconfig, and figure out which line is causing the problem in the kernel. Then look at the USB explore threads and see where they are stuck in the detach of umass! --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Sun, Nov 16, 2014 at 08:16:36PM +0100, Hans Petter Selasky wrote: > On 11/16/14 20:03, Steve Kargl wrote: > > On Sun, Nov 16, 2014 at 06:55:53PM +, Mark R V Murray wrote: > >> > >>> On 16 Nov 2014, at 18:51, Steve Kargl > >>> wrote: > >>> > >>> If you have not read the entire thread, once the laptop keyboard and > >>> video output lock up, I can ssh into the laptop. If I run usbconfig, > >>> it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices > >>> have not been destroyed. > >> > >> Weirder and weirder :-(. > >> > >> Something with SX locks? Hmm. I do use those for attach and detach for > >> RNG sources. Could it be that that stick of yours is somehow getting > >> involved in the RNG source locks? > >> > > > > It's not limited to a single usb device. Plugging in/Unplugging > > a logitech mouse dongle, the memstick, a Western Digital MY Passport > > external usb hard drive, all lead to the locked keyboard and video. > > > > I tried adding both RANDOM_DEBUG and USBDEBUG to the kernel, but the > > mount of output is mind numbing. > > > > > Can you enter kgdb when the usbconfig is froozen, and backtrace all > kernel threads. You should see exactly what locks are the problem. > > Maybe some lock didn't get properly unlocked! > I haven't tried kgdb. I did try to attach gdb to the usbconfig process via its pid, but gdb dumped core. I haven't looked at locks in kgdb, what command or commands should I try. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On 11/16/14 20:03, Steve Kargl wrote: On Sun, Nov 16, 2014 at 06:55:53PM +, Mark R V Murray wrote: On 16 Nov 2014, at 18:51, Steve Kargl wrote: If you have not read the entire thread, once the laptop keyboard and video output lock up, I can ssh into the laptop. If I run usbconfig, it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices have not been destroyed. Weirder and weirder :-(. Something with SX locks? Hmm. I do use those for attach and detach for RNG sources. Could it be that that stick of yours is somehow getting involved in the RNG source locks? It's not limited to a single usb device. Plugging in/Unplugging a logitech mouse dongle, the memstick, a Western Digital MY Passport external usb hard drive, all lead to the locked keyboard and video. I tried adding both RANDOM_DEBUG and USBDEBUG to the kernel, but the mount of output is mind numbing. Hi, Can you enter kgdb when the usbconfig is froozen, and backtrace all kernel threads. You should see exactly what locks are the problem. Maybe some lock didn't get properly unlocked! Thank you! --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Sun, Nov 16, 2014 at 06:55:53PM +, Mark R V Murray wrote: > > > On 16 Nov 2014, at 18:51, Steve Kargl > > wrote: > > > > If you have not read the entire thread, once the laptop keyboard and > > video output lock up, I can ssh into the laptop. If I run usbconfig, > > it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices > > have not been destroyed. > > Weirder and weirder :-(. > > Something with SX locks? Hmm. I do use those for attach and detach for > RNG sources. Could it be that that stick of yours is somehow getting > involved in the RNG source locks? > It's not limited to a single usb device. Plugging in/Unplugging a logitech mouse dongle, the memstick, a Western Digital MY Passport external usb hard drive, all lead to the locked keyboard and video. I tried adding both RANDOM_DEBUG and USBDEBUG to the kernel, but the mount of output is mind numbing. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
> On 16 Nov 2014, at 18:51, Steve Kargl > wrote: > >> >> I?m sorry my commit caused the problem. >> > > Nothing to be sorry about. This is -current after all. Thanks :-) >> I?m also trying to find out why, but I don?t know enough about USB or >> mass-storage devices to know why, so this may take me a while. In the >> meanwhile, I?ll try to help by pointing out things I do know. > > Yes, I did the bisection to find that r273872 exposes the problem. > What I don't know is if this is hardware specific to a Dell Latitude > D530 laptop, USB specific, or some weird interaction between the > random and USB. > > What I also find odd is that I seem to be the only person seeing > this behavior when it is trivial for me to reproduce: boot laptop, > plug in usb device, wait usb recognizes the device, then unplug > the device. Strange for me too. I’m not exactly being bombarded with bug reports. > If you have not read the entire thread, once the laptop keyboard and > video output lock up, I can ssh into the laptop. If I run usbconfig, > it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices > have not been destroyed. Weirder and weirder :-(. Something with SX locks? Hmm. I do use those for attach and detach for RNG sources. Could it be that that stick of yours is somehow getting involved in the RNG source locks? M -- Mark R V Murray ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Sun, Nov 16, 2014 at 06:34:42PM +, Mark R V Murray wrote: > > > On 16 Nov 2014, at 18:31, Ian Lepore wrote: > > > > The point I'm trying to make here is that you trimmed away the important > > part of the prior messages and replied only to the part where Steve's > > debugging efforts were somewhat speculating. The non-speculative part > > was where he bisected the failure to an exact commit: > > > The problem is caused > by r273872. This is the recent random device patch. I have no > idea why removing a usb device would cause the system to lock > up other than random is probably trying to harvest some entropy. > > I?m sorry my commit caused the problem. > Nothing to be sorry about. This is -current afterall. > I?m also trying to find out why, but I don?t know enough about USB or > mass-storage devices to know why, so this may take me a while. In the > meanwhile, I?ll try to help by pointing out things I do know. Yes, I did the bisection to find that r273872 exposes the problem. What I don't know is if this is hardware specific to a Dell Latitude D530 laptop, USB specific, or some weird interaction between the random and USB. What I also find odd is that I seem to be the only person seeing this behavior when it is trivial for me to reproduce: boot laptop, plug in usb device, wait usb recognizes the device, then unplug the device. If you have not read the entire thread, once the laptop keyboard and video output lock up, I can ssh into the laptop. If I run usbconfig, it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices have not been destroyed. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
> On 16 Nov 2014, at 18:31, Ian Lepore wrote: > > The point I'm trying to make here is that you trimmed away the important > part of the prior messages and replied only to the part where Steve's > debugging efforts were somewhat speculating. The non-speculative part > was where he bisected the failure to an exact commit: > The problem is caused by r273872. This is the recent random device patch. I have no idea why removing a usb device would cause the system to lock up other than random is probably trying to harvest some entropy. I’m sorry my commit caused the problem. I’m also trying to find out why, but I don’t know enough about USB or mass-storage devices to know why, so this may take me a while. In the meanwhile, I’ll try to help by pointing out things I do know. M -- Mark R V Murray ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Sun, 2014-11-16 at 18:23 +, Mark R V Murray wrote: > > On 16 Nov 2014, at 18:21, Ian Lepore wrote: > > > > On Sun, 2014-11-16 at 18:17 +, Mark R V Murray wrote: > >>> On 16 Nov 2014, at 17:51, Steve Kargl > >>> wrote: > >>> > >>> Is there a 'random: device_detach():' missing between the 'umass0' > >>> and 'da0' messages in the last 4 lines. > >> > >> No. At attach time, the RNG grabs some probe entropy. At detach time it > >> does nothing. > >> > >> M > > > > And yet... Steve has gathered evidence that the system bricks when a > > device is detached with the new entropy-gathering code and doesn't do so > > prior to that code. What else is the new code doing around detach time? > > Nothing, except possibly harvesting interrupt entropy. I’ll promise to be > astonished if this is other-than-harmless. > > I’d be more suspicious of the harvester thread, but I still can’t see how > its hurting :-( > > M The point I'm trying to make here is that you trimmed away the important part of the prior messages and replied only to the part where Steve's debugging efforts were somewhat speculating. The non-speculative part was where he bisected the failure to an exact commit: > > > The problem is caused > > > by r273872. This is the recent random device patch. I have no > > > idea why removing a usb device would cause the system to lock > > > up other than random is probably trying to harvest some entropy. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
> On 16 Nov 2014, at 18:21, Ian Lepore wrote: > > On Sun, 2014-11-16 at 18:17 +, Mark R V Murray wrote: >>> On 16 Nov 2014, at 17:51, Steve Kargl >>> wrote: >>> >>> Is there a 'random: device_detach():' missing between the 'umass0' >>> and 'da0' messages in the last 4 lines. >> >> No. At attach time, the RNG grabs some probe entropy. At detach time it does >> nothing. >> >> M > > And yet... Steve has gathered evidence that the system bricks when a > device is detached with the new entropy-gathering code and doesn't do so > prior to that code. What else is the new code doing around detach time? Nothing, except possibly harvesting interrupt entropy. I’ll promise to be astonished if this is other-than-harmless. I’d be more suspicious of the harvester thread, but I still can’t see how its hurting :-( M -- Mark R V Murray ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Sun, 2014-11-16 at 18:17 +, Mark R V Murray wrote: > > On 16 Nov 2014, at 17:51, Steve Kargl > > wrote: > > > > Is there a 'random: device_detach():' missing between the 'umass0' > > and 'da0' messages in the last 4 lines. > > No. At attach time, the RNG grabs some probe entropy. At detach time it does > nothing. > > M And yet... Steve has gathered evidence that the system bricks when a device is detached with the new entropy-gathering code and doesn't do so prior to that code. What else is the new code doing around detach time? -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
> On 16 Nov 2014, at 17:51, Steve Kargl > wrote: > > Is there a 'random: device_detach():' missing between the 'umass0' > and 'da0' messages in the last 4 lines. No. At attach time, the RNG grabs some probe entropy. At detach time it does nothing. M -- Mark R V Murray ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Sat, Nov 15, 2014 at 09:44:18PM -0800, Adrian Chadd wrote: > On 15 November 2014 21:41, Steve Kargl > wrote: > > On Thu, Nov 13, 2014 at 01:22:06PM -0800, Steve Kargl wrote: > >> On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote: > >> > On 11/13/14 19:15, Steve Kargl wrote: > >> > > On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: > >> > >> On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: > >> > >>> On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: > >> > I have a kernel/world from r274273 sources, which is exhibiting a > >> > new > >> > issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r > >> > now' > >> > work. I get to the end of shutdown and see for example > >> > > >> > All buffers synced > >> > Uptime: 4h23m15s > >> > > >> > and then the laptop just sits there. It does not power off with > >> > the -p option nor does it reboot with the -r. Has anyone else > >> > seen this behavior? > >> > > >> > >>> > >> > >>> The problem appears to be related to a recent change in the > >> > >>> USB stack. If I have the following drive plugged into a > >> > >>> usb port, the above behavior is observed on shutdown. > >> > >>> > >> > > > >> > > Adding > >> > > > >> > > hw.usb.no_shutdown_wait: 1 > >> > > > >> > > to /boot/loader.conf appears to work around the 'shutdown -p now' > >> > > and 'shutdown -r now' issue. Unfortunately, the bricking of the > >> > > laptop is not affected by this sysctl. Once a device is plugged > >> > > into a usb, it must remain plugged in. > >> > > > >> > > >> > Hi, > >> > > >> > Is using this sysctl/tunable a suitable solution for you? > >> > > >> > >> The sysctl is a suitable solution for the shutdown issues. > >> It is not suitable solution for the general use of using > >> a memory stick to for example quickly transfer files. Once > >> the memory stick is plugged into the usb port, it must > >> remain there unless one wants to reboot the system. > >> > >> I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled. > >> I need to wade through a rather large /var/log/messages > >> to see if anything appears unusual. > >> > > > > Well, this has been a waste of a day. The problem is caused > > by r273872. This is the recent random device patch. I have no > > idea why removing a usb device would cause the system to lock > > up other than random is probably trying to harvest some entropy. > > + des / markm > > That's a good catch! It's not a waste of a day. Thankyou for digging > into it and finding out what introduced the failure. > > Hopefully between Hans, des and markm a solution can be found. > Shooting into the dark. I added 'options RANDOM_DEBUG' to my kernel. Plugging in a USB device shows kernel: ugen6.2: at usbus6 kernel: umass0: on usbus6 kernel: random: device_attach(): feeding 4 bit(s) of entropy from umass0 kernel: da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 kernel: da0: < 0.00> Removable Direct Access SCSI-2 device kernel: da0: Serial Number 08102201c42413 kernel: da0: 40.000MB/s transfers kernel: da0: 963MB (1974271 512 byte sectors: 64H 32S/T 963C) kernel: da0: quirks=0x2 in /var/log/messages. Now, when I immediately pull the device from the USB port, I get kernel: ugen6.2: at usbus6 (disconnected) kernel: umass0: at uhub6, port 1, addr 2 (disconnected) kernel: da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 kernel: da0: < 0.00> s/n 08102201c42413 detached followed by a bricked laptop, which requires a depression of the power button. Is there a 'random: device_detach():' missing between the 'umass0' and 'da0' messages in the last 4 lines. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Sat, Nov 15, 2014 at 09:44:18PM -0800, Adrian Chadd wrote: > On 15 November 2014 21:41, Steve Kargl > wrote: > > On Thu, Nov 13, 2014 at 01:22:06PM -0800, Steve Kargl wrote: > >> On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote: > >> > On 11/13/14 19:15, Steve Kargl wrote: > >> > > On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: > >> > >> On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: > >> > >>> On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: > >> > I have a kernel/world from r274273 sources, which is exhibiting a > >> > new > >> > issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r > >> > now' > >> > work. I get to the end of shutdown and see for example > >> > > >> > All buffers synced > >> > Uptime: 4h23m15s > >> > > >> > and then the laptop just sits there. It does not power off with > >> > the -p option nor does it reboot with the -r. Has anyone else > >> > seen this behavior? > >> > > >> > >>> > >> > >>> The problem appears to be related to a recent change in the > >> > >>> USB stack. If I have the following drive plugged into a > >> > >>> usb port, the above behavior is observed on shutdown. > >> > >>> > >> > > > >> > > Adding > >> > > > >> > > hw.usb.no_shutdown_wait: 1 > >> > > > >> > > to /boot/loader.conf appears to work around the 'shutdown -p now' > >> > > and 'shutdown -r now' issue. Unfortunately, the bricking of the > >> > > laptop is not affected by this sysctl. Once a device is plugged > >> > > into a usb, it must remain plugged in. > >> > > > >> > > >> > Hi, > >> > > >> > Is using this sysctl/tunable a suitable solution for you? > >> > > >> > >> The sysctl is a suitable solution for the shutdown issues. > >> It is not suitable solution for the general use of using > >> a memory stick to for example quickly transfer files. Once > >> the memory stick is plugged into the usb port, it must > >> remain there unless one wants to reboot the system. > >> > >> I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled. > >> I need to wade through a rather large /var/log/messages > >> to see if anything appears unusual. > >> > > > > Well, this has been a waste of a day. The problem is caused > > by r273872. This is the recent random device patch. I have no > > idea why removing a usb device would cause the system to lock > > up other than random is probably trying to harvest some entropy. > > + des / markm > > That's a good catch! It's not a waste of a day. Thankyou for digging > into it and finding out what introduced the failure. > > Hopefully between Hans, des and markm a solution can be found. > It is a waste in that I was going to spend the day working on powl(). My next window of time for powl() hacking is probably sometime in mid to late December. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On 15 November 2014 21:41, Steve Kargl wrote: > On Thu, Nov 13, 2014 at 01:22:06PM -0800, Steve Kargl wrote: >> On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote: >> > On 11/13/14 19:15, Steve Kargl wrote: >> > > On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: >> > >> On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: >> > >>> On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: >> > I have a kernel/world from r274273 sources, which is exhibiting a new >> > issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r >> > now' >> > work. I get to the end of shutdown and see for example >> > >> > All buffers synced >> > Uptime: 4h23m15s >> > >> > and then the laptop just sits there. It does not power off with >> > the -p option nor does it reboot with the -r. Has anyone else >> > seen this behavior? >> > >> > >>> >> > >>> The problem appears to be related to a recent change in the >> > >>> USB stack. If I have the following drive plugged into a >> > >>> usb port, the above behavior is observed on shutdown. >> > >>> >> > > >> > > Adding >> > > >> > > hw.usb.no_shutdown_wait: 1 >> > > >> > > to /boot/loader.conf appears to work around the 'shutdown -p now' >> > > and 'shutdown -r now' issue. Unfortunately, the bricking of the >> > > laptop is not affected by this sysctl. Once a device is plugged >> > > into a usb, it must remain plugged in. >> > > >> > >> > Hi, >> > >> > Is using this sysctl/tunable a suitable solution for you? >> > >> >> The sysctl is a suitable solution for the shutdown issues. >> It is not suitable solution for the general use of using >> a memory stick to for example quickly transfer files. Once >> the memory stick is plugged into the usb port, it must >> remain there unless one wants to reboot the system. >> >> I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled. >> I need to wade through a rather large /var/log/messages >> to see if anything appears unusual. >> > > Well, this has been a waste of a day. The problem is caused > by r273872. This is the recent random device patch. I have no > idea why removing a usb device would cause the system to lock > up other than random is probably trying to harvest some entropy. + des / markm That's a good catch! It's not a waste of a day. Thankyou for digging into it and finding out what introduced the failure. Hopefully between Hans, des and markm a solution can be found. -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Thu, Nov 13, 2014 at 01:22:06PM -0800, Steve Kargl wrote: > On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote: > > On 11/13/14 19:15, Steve Kargl wrote: > > > On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: > > >> On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: > > >>> On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: > > I have a kernel/world from r274273 sources, which is exhibiting a new > > issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r > > now' > > work. I get to the end of shutdown and see for example > > > > All buffers synced > > Uptime: 4h23m15s > > > > and then the laptop just sits there. It does not power off with > > the -p option nor does it reboot with the -r. Has anyone else > > seen this behavior? > > > > >>> > > >>> The problem appears to be related to a recent change in the > > >>> USB stack. If I have the following drive plugged into a > > >>> usb port, the above behavior is observed on shutdown. > > >>> > > > > > > Adding > > > > > > hw.usb.no_shutdown_wait: 1 > > > > > > to /boot/loader.conf appears to work around the 'shutdown -p now' > > > and 'shutdown -r now' issue. Unfortunately, the bricking of the > > > laptop is not affected by this sysctl. Once a device is plugged > > > into a usb, it must remain plugged in. > > > > > > > Hi, > > > > Is using this sysctl/tunable a suitable solution for you? > > > > The sysctl is a suitable solution for the shutdown issues. > It is not suitable solution for the general use of using > a memory stick to for example quickly transfer files. Once > the memory stick is plugged into the usb port, it must > remain there unless one wants to reboot the system. > > I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled. > I need to wade through a rather large /var/log/messages > to see if anything appears unusual. > Well, this has been a waste of a day. The problem is caused by r273872. This is the recent random device patch. I have no idea why removing a usb device would cause the system to lock up other than random is probably trying to harvest some entropy. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote: > On 11/13/14 19:15, Steve Kargl wrote: > > On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: > >> On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: > >>> On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: > I have a kernel/world from r274273 sources, which is exhibiting a new > issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' > work. I get to the end of shutdown and see for example > > All buffers synced > Uptime: 4h23m15s > > and then the laptop just sits there. It does not power off with > the -p option nor does it reboot with the -r. Has anyone else > seen this behavior? > > >>> > >>> The problem appears to be related to a recent change in the > >>> USB stack. If I have the following drive plugged into a > >>> usb port, the above behavior is observed on shutdown. > >>> > > > > Adding > > > > hw.usb.no_shutdown_wait: 1 > > > > to /boot/loader.conf appears to work around the 'shutdown -p now' > > and 'shutdown -r now' issue. Unfortunately, the bricking of the > > laptop is not affected by this sysctl. Once a device is plugged > > into a usb, it must remain plugged in. > > > > Hi, > > Is using this sysctl/tunable a suitable solution for you? > The sysctl is a suitable solution for the shutdown issues. It is not suitable solution for the general use of using a memory stick to for example quickly transfer files. Once the memory stick is plugged into the usb port, it must remain there unless one wants to reboot the system. I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled. I need to wade through a rather large /var/log/messages to see if anything appears unusual. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On 11/13/14 19:15, Steve Kargl wrote: On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? The problem appears to be related to a recent change in the USB stack. If I have the following drive plugged into a usb port, the above behavior is observed on shutdown. Adding hw.usb.no_shutdown_wait: 1 to /boot/loader.conf appears to work around the 'shutdown -p now' and 'shutdown -r now' issue. Unfortunately, the bricking of the laptop is not affected by this sysctl. Once a device is plugged into a usb, it must remain plugged in. Hi, Is using this sysctl/tunable a suitable solution for you? --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: > On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: > > On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: > > > I have a kernel/world from r274273 sources, which is exhibiting a new > > > issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' > > > work. I get to the end of shutdown and see for example > > > > > > All buffers synced > > > Uptime: 4h23m15s > > > > > > and then the laptop just sits there. It does not power off with > > > the -p option nor does it reboot with the -r. Has anyone else > > > seen this behavior? > > > > > > > The problem appears to be related to a recent change in the > > USB stack. If I have the following drive plugged into a > > usb port, the above behavior is observed on shutdown. > > Adding hw.usb.no_shutdown_wait: 1 to /boot/loader.conf appears to work around the 'shutdown -p now' and 'shutdown -r now' issue. Unfortunately, the bricking of the laptop is not affected by this sysctl. Once a device is plugged into a usb, it must remain plugged in. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: > On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: > > I have a kernel/world from r274273 sources, which is exhibiting a new > > issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' > > work. I get to the end of shutdown and see for example > > > > All buffers synced > > Uptime: 4h23m15s > > > > and then the laptop just sits there. It does not power off with > > the -p option nor does it reboot with the -r. Has anyone else > > seen this behavior? > > > > The problem appears to be related to a recent change in the > USB stack. If I have the following drive plugged into a > usb port, the above behavior is observed on shutdown. > > ugen6.2: at usbus6 > umass0: on usbus6 > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > da0: Fixed Direct Access SCSI-6 device > da0: Serial Number 57584B314537324445595A31 > da0: 40.000MB/s transfers > da0: 1907697MB (3906963456 512 byte sectors: 255H 63S/T 243197C) > da0: quirks=0x2 > ses1 at umass-sim0 bus 0 scbus4 target 0 lun 1 > ses1: Fixed Enclosure Services SCSI-6 device > ses1: Serial Number 57584B314537324445595A31 > ses1: 40.000MB/s transfers > ses1: SCSI-3 ENC Device > The problem is not restricted to hte WD My Passport drive. The memstick ugen6.2: at usbus6 umass0: on usbus6 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: < 0.00> Removable Direct Access SCSI-2 device da0: Serial Number 08102201c42413 da0: 40.000MB/s transfers da0: 963MB (1974271 512 byte sectors: 64H 32S/T 963C) da0: quirks=0x2 will also cause the system to wedge when removed. I failed to report that /dev/da0, /dev/da0s1, /dev/da0s1a, etc were not destroyed when the WD My Passport was removed. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
CCing hps and mav.. > On Nov 13, 2014, at 09:25, Steve Kargl > wrote: > >> On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: >> I have a kernel/world from r274273 sources, which is exhibiting a new >> issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' >> work. I get to the end of shutdown and see for example >> >> All buffers synced >> Uptime: 4h23m15s >> >> and then the laptop just sits there. It does not power off with >> the -p option nor does it reboot with the -r. Has anyone else >> seen this behavior? > > The problem appears to be related to a recent change in the > USB stack. If I have the following drive plugged into a > usb port, the above behavior is observed on shutdown. > > ugen6.2: at usbus6 > umass0: on usbus6 > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > da0: Fixed Direct Access SCSI-6 device > da0: Serial Number 57584B314537324445595A31 > da0: 40.000MB/s transfers > da0: 1907697MB (3906963456 512 byte sectors: 255H 63S/T 243197C) > da0: quirks=0x2 > ses1 at umass-sim0 bus 0 scbus4 target 0 lun 1 > ses1: Fixed Enclosure Services SCSI-6 device > ses1: Serial Number 57584B314537324445595A31 > ses1: 40.000MB/s transfers > ses1: SCSI-3 ENC Device > > If this drive was never plugged into a usb port, 'shutdown -r now' > and 'shutdown -p now' work as expected. > > If drive is plugged into a usb port, and I then unplug the drive the > laptop is turned into a brick. In a vt(4) console, there is no keyboard > and no output is displayed to the console. > > Logging into the laptop with ssh works. With the laptop > in a brick state, issuing 'usbconfig' yields a wedged process > with no output to the terminal and 'usbconfig' is unkillable. > ^T yields > > load: 0.30 cmd: usbconfig 1068 [USB config SX lock] 441.15r 0.00u 0.00s > 1884k. > > Unfortunately, a 'gdb -p 1068' yields a core dump for gdb. :( > > Logging into the laptop again with ssh works. Issuing the command > 'camcontrol rescan all' yields > > Re-scan of bus 4 returned error 0xa > Re-scan of bus 0 was successful > Re-scan of bus 1 was successful > Re-scan of bus 2 was successful > Re-scan of bus 3 was successful > > dmesg follows my sig. > > -- > Steve > > Copyright (c) 1992-2014 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-CURRENT #0 r274456: Thu Nov 13 07:45:01 PST 2014 >ka...@laptop-kargl.apl.washington.edu:/usr/obj/usr/src/sys/MOBILE i386 > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > VT: running with driver "vga". > CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz 686-class > CPU) > Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 > > Features=0xbfebfbff > Features2=0xe3bd > AMD Features=0x2000 > AMD Features2=0x1 > VT-x: (disabled in BIOS) HLT,PAUSE > TSC: P-state invariant, performance statistics > real memory = 3221225472 (3072 MB) > avail memory = 3136098304 (2990 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0: Changing APIC ID to 2 > ioapic0 irqs 0-23 on motherboard > random: entropy device infrastructure driver > random: selecting highest priority adaptor > kbd1 at kbdmux0 > random: SOFT: yarrow init() > random: selecting highest priority adaptor > module_register_init: MOD_LOAD (vesa, 0xc0b3a4e0, 0) error 19 > acpi0: on motherboard > hpet0: iomem 0xfed0-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 450 > Event timer "HPET1" frequency 14318180 Hz quality 440 > Event timer "HPET2" frequency 14318180 Hz quality 440 > acpi0: reservation of 0, 9f000 (3) failed > acpi0: reservation of 10, bf5c0400 (3) failed > cpu0: on acpi0 > cpu1: on acpi0 > atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43,0x50-0x53 irq 2 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > vgapci0: port 0xeff8-0xefff mem > 0xfea0-0xfeaf,0xe000-0xefff irq 16 at device 2.0 on pci0 > vgapci0: Boot video device > vgapci1: mem 0xfeb0-0xfebf at device 2.1 on > pci0 > uhci0: port 0x6f20-0x6f3f irq 20 > at device 26.0 on pci0 > usbus0 on uhci0 > uhci1: port 0x6f00-0x6f1f irq 21 > at device 26.1 on pci0 > usbus1 on uhci1 > ehci0: mem > 0xfed1c400-0xfed1c7ff irq 22 at device 26.7 on pci0 > usbus2: EHCI version 1.0 >
USB locks up system -- WAS Re: shutdown or acpi problem
On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: > I have a kernel/world from r274273 sources, which is exhibiting a new > issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' > work. I get to the end of shutdown and see for example > > All buffers synced > Uptime: 4h23m15s > > and then the laptop just sits there. It does not power off with > the -p option nor does it reboot with the -r. Has anyone else > seen this behavior? > The problem appears to be related to a recent change in the USB stack. If I have the following drive plugged into a usb port, the above behavior is observed on shutdown. ugen6.2: at usbus6 umass0: on usbus6 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Fixed Direct Access SCSI-6 device da0: Serial Number 57584B314537324445595A31 da0: 40.000MB/s transfers da0: 1907697MB (3906963456 512 byte sectors: 255H 63S/T 243197C) da0: quirks=0x2 ses1 at umass-sim0 bus 0 scbus4 target 0 lun 1 ses1: Fixed Enclosure Services SCSI-6 device ses1: Serial Number 57584B314537324445595A31 ses1: 40.000MB/s transfers ses1: SCSI-3 ENC Device If this drive was never plugged into a usb port, 'shutdown -r now' and 'shutdown -p now' work as expected. If drive is plugged into a usb port, and I then unplug the drive the laptop is turned into a brick. In a vt(4) console, there is no keyboard and no output is displayed to the console. Logging into the laptop with ssh works. With the laptop in a brick state, issuing 'usbconfig' yields a wedged process with no output to the terminal and 'usbconfig' is unkillable. ^T yields load: 0.30 cmd: usbconfig 1068 [USB config SX lock] 441.15r 0.00u 0.00s 1884k. Unfortunately, a 'gdb -p 1068' yields a core dump for gdb. :( Logging into the laptop again with ssh works. Issuing the command 'camcontrol rescan all' yields Re-scan of bus 4 returned error 0xa Re-scan of bus 0 was successful Re-scan of bus 1 was successful Re-scan of bus 2 was successful Re-scan of bus 3 was successful dmesg follows my sig. -- Steve Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r274456: Thu Nov 13 07:45:01 PST 2014 ka...@laptop-kargl.apl.washington.edu:/usr/obj/usr/src/sys/MOBILE i386 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 VT: running with driver "vga". CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz 686-class CPU) Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x2000 AMD Features2=0x1 VT-x: (disabled in BIOS) HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 3221225472 (3072 MB) avail memory = 3136098304 (2990 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard random: entropy device infrastructure driver random: selecting highest priority adaptor kbd1 at kbdmux0 random: SOFT: yarrow init() random: selecting highest priority adaptor module_register_init: MOD_LOAD (vesa, 0xc0b3a4e0, 0) error 19 acpi0: on motherboard hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 acpi0: reservation of 0, 9f000 (3) failed acpi0: reservation of 10, bf5c0400 (3) failed cpu0: on acpi0 cpu1: on acpi0 atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 2 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xeff8-0xefff mem 0xfea0-0xfeaf,0xe000-0xefff irq 16 at device 2.0 on pci0 vgapci0: Boot video device vgapci1: mem 0xfeb0-0xfebf at device 2.1 on pci0 uhci0: port 0x6f20-0x6f3f irq 20 at device 26.0 on pci0 usbus0 on uhci0 uhci1: port 0x6f00-0x6f1f irq 21 at device 26.1 on pci0 usbus1 on uhci1 ehci0: mem 0xfed1c400-0xfed1c7ff irq 22 at device 26.7 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci0 hdac0: mem 0xfe9fc000-0xfe9f irq 21 at device 27.0 on pci0 pcib1: at device 28.0 on pci0 pci11: on pcib1 pcib2: at device 28.1 on pci0 pci12: on pcib2 wpi0: mem 0xfe8ff000-0xfe8f irq 17 at device 0.0 on pci12 pcib3: at device 28.5 on pci0 pci9: on pcib3 bge0: mem 0xfe7f000
Re: shutdown or acpi problem
On Wed, Nov 12, 2014 at 06:27:13PM -0800, Chris H wrote: > On Wed, 12 Nov 2014 18:08:52 -0800 Steve Kargl > wrote > > > On Wed, Nov 12, 2014 at 06:03:43PM -0800, Chris H wrote: > > > On Wed, 12 Nov 2014 15:26:55 -0800 Steve Kargl > > > wrote > > > > > > > I run 'make delete-old' and 'make delete-old-libs' after > > > > each installworld. In this case, I was upgrading from > > > > r271492 to r274273. The procedure I use is > > > > > > > > cd /usr/obj > > > Can I throw a > > > > > > chflags -R noschg * > > > > > > here first? Point being, you may well not have gotten > > > everything, otherwise. :) > > > > It's not needed. > How so? It's been necessary for as long > as I can remember. Just to confirm, I looked to see if anything > had changed: > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html > seems not. Do note; I'm not trying to be argumentative. Just > don't see where it's not true (needed). :) It not needed. % su root % script Script started on Wed Nov 12 18:54:16 2014 troutmask:root[201] cd /usr/obj troutmask:root[202] ls usr/ troutmask:root[203] rm -rf usr troutmask:root[204] ls troutmask:root[205] exit exit Script done on Wed Nov 12 18:54:40 2014 QED -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: shutdown or acpi problem
On Wed, Nov 12, 2014 at 6:43 PM, NGie Cooper wrote: > On Wed, Nov 12, 2014 at 6:27 PM, Chris H wrote: > > ... > >> How so? It's been necessary for as long >> as I can remember. Just to confirm, I looked to see if anything >> had changed: >> https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html >> seems not. Do note; I'm not trying to be argumentative. Just >> don't see where it's not true (needed). :) > > It's technically not needed with -DNO_CLEAN (it's handled in > Makefile.inc1), however if you're doing that you might as well not > specify NO_CLEAN: > > http://svnweb.freebsd.org/base/head/Makefile.inc1?view=annotate#l481 My apologies... I was thinking of another build process. Yes, it's very much required according to the process noted in the handbook. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: shutdown or acpi problem
On Wed, Nov 12, 2014 at 6:27 PM, Chris H wrote: ... > How so? It's been necessary for as long > as I can remember. Just to confirm, I looked to see if anything > had changed: > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html > seems not. Do note; I'm not trying to be argumentative. Just > don't see where it's not true (needed). :) It's technically not needed with -DNO_CLEAN (it's handled in Makefile.inc1), however if you're doing that you might as well not specify NO_CLEAN: http://svnweb.freebsd.org/base/head/Makefile.inc1?view=annotate#l481 Cheers! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: shutdown or acpi problem
On Wed, 12 Nov 2014 18:08:52 -0800 Steve Kargl wrote > On Wed, Nov 12, 2014 at 06:03:43PM -0800, Chris H wrote: > > On Wed, 12 Nov 2014 15:26:55 -0800 Steve Kargl > > wrote > > > > > I run 'make delete-old' and 'make delete-old-libs' after > > > each installworld. In this case, I was upgrading from > > > r271492 to r274273. The procedure I use is > > > > > > cd /usr/obj > > Can I throw a > > > > chflags -R noschg * > > > > here first? Point being, you may well not have gotten > > everything, otherwise. :) > > It's not needed. How so? It's been necessary for as long as I can remember. Just to confirm, I looked to see if anything had changed: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html seems not. Do note; I'm not trying to be argumentative. Just don't see where it's not true (needed). :) --Chris > > -- > Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: shutdown or acpi problem
On Wed, Nov 12, 2014 at 06:03:43PM -0800, Chris H wrote: > On Wed, 12 Nov 2014 15:26:55 -0800 Steve Kargl > wrote > > > I run 'make delete-old' and 'make delete-old-libs' after > > each installworld. In this case, I was upgrading from > > r271492 to r274273. The procedure I use is > > > > cd /usr/obj > Can I throw a > > chflags -R noschg * > > here first? Point being, you may well not have gotten > everything, otherwise. :) It's not needed. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: shutdown or acpi problem
On Wed, 12 Nov 2014 15:26:55 -0800 Steve Kargl wrote > On Wed, Nov 12, 2014 at 03:12:46PM -0800, NGie Cooper wrote: > > On Wed, Nov 12, 2014 at 2:42 PM, Steve Kargl > > wrote: > > > I have a kernel/world from r274273 sources, which is exhibiting a new > > > issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' > > > work. I get to the end of shutdown and see for example > > > > > > All buffers synced > > > Uptime: 4h23m15s > > > > > > and then the laptop just sits there. It does not power off with > > > the -p option nor does it reboot with the -r. Has anyone else > > > seen this behavior? > > > > Are you upgrading from a pre-r273872 world, and if so, did you run > > make delete-old first ( > > http://svnweb.freebsd.org/base?view=revision&revision= )? > > Cheers! > > ___ > > I run 'make delete-old' and 'make delete-old-libs' after > each installworld. In this case, I was upgrading from > r271492 to r274273. The procedure I use is > > cd /usr/obj Can I throw a chflags -R noschg * here first? Point being, you may well not have gotten everything, otherwise. :) > rm -rf * > cd /usr/src > svn update > make buildworld > make buildkernel > make installkernel > mergemaster -p > (may or may not boot to single user mode here) > make installworld > mergemaster -iU > make delete-old > make delete-old-libs > shutdown -r +1 > > -- > Steve --Chris > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: shutdown or acpi problem
On Wed, Nov 12, 2014 at 03:12:46PM -0800, NGie Cooper wrote: > On Wed, Nov 12, 2014 at 2:42 PM, Steve Kargl > wrote: > > I have a kernel/world from r274273 sources, which is exhibiting a new > > issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' > > work. I get to the end of shutdown and see for example > > > > All buffers synced > > Uptime: 4h23m15s > > > > and then the laptop just sits there. It does not power off with > > the -p option nor does it reboot with the -r. Has anyone else > > seen this behavior? > > Are you upgrading from a pre-r273872 world, and if so, did you run > make delete-old first ( > http://svnweb.freebsd.org/base?view=revision&revision= )? > Cheers! > ___ I run 'make delete-old' and 'make delete-old-libs' after each installworld. In this case, I was upgrading from r271492 to r274273. The procedure I use is cd /usr/obj rm -rf * cd /usr/src svn update make buildworld make buildkernel make installkernel mergemaster -p (may or may not boot to single user mode here) make installworld mergemaster -iU make delete-old make delete-old-libs shutdown -r +1 -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: shutdown or acpi problem
On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: > I have a kernel/world from r274273 sources, which is exhibiting a new > issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' > work. I get to the end of shutdown and see for example > > All buffers synced > Uptime: 4h23m15s > > and then the laptop just sits there. It does not power off with > the -p option nor does it reboot with the -r. Has anyone else > seen this behavior? > Note booting /boot/kernel.old/kernel and then using 'shutdown -p now' works as expected. The old kernel was bulit from r271492 sources. Any guidance on where to start to debug this issue would be welcomed. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: shutdown or acpi problem
On Wed, Nov 12, 2014 at 2:42 PM, Steve Kargl wrote: > I have a kernel/world from r274273 sources, which is exhibiting a new > issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' > work. I get to the end of shutdown and see for example > > All buffers synced > Uptime: 4h23m15s > > and then the laptop just sits there. It does not power off with > the -p option nor does it reboot with the -r. Has anyone else > seen this behavior? Are you upgrading from a pre-r273872 world, and if so, did you run make delete-old first ( http://svnweb.freebsd.org/base?view=revision&revision= )? Cheers! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
shutdown or acpi problem
I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ACPI problem, my VAIO won't come back from suspension
On Wednesday 03 December 2003 21:57, Nate Lawson wrote: > On Wed, 3 Dec 2003, Melvyn Sopacua wrote: > > On Tuesday 02 December 2003 23:34, Nate Lawson wrote: > > > Try other states (acpiconf -s 1, 2, 4). If one works, use it. If not, > > > try disabling acpi and using apm(4) to suspend and resume. > > > > Normally that would be grand, but now that I've not compiled acpi into > > the kernel, I have no /dev/apm anymore as well. > > If you don't have acpi(4), then you need to add "device apm" to your > kernel to enable apm(4) support. $ grep apm /sys/i386/conf/SAREVOK_NOACPI device apm [EMAIL PROTECTED]~ $ uname -v FreeBSD 5.2-BETA #0: Wed Dec 3 20:13:44 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SAREVOK_NOACPI I noticed in my dmesg.boot: $ grep PNP /var/run/dmesg.boot unknown: can't assign resources (port) unknown: can't assign resources (irq) unknown: can't assign resources (port) unknown: can't assign resources (port) I hope that's not what I think it is :) > > Even with acpi, I never got a /dev/apmctl so apmd never worked. I've read > > through devfs(5)/(8), but as far as I understand, it is the driver's > > responsibility to create the device and even if you could do it in > > userland, than it will just be a non-configured device. > > You can't use apmd with acpi(4). It has /dev/acpictl. Thanx! -- Melvyn === FreeBSD sarevok.idg.nl 5.2-BETA FreeBSD 5.2-BETA #0: Wed Dec 3 20:13:44 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SAREVOK_NOACPI i386 === pgp0.pgp Description: signature
Re: ACPI problem, my VAIO won't come back from suspension
On Wed, 3 Dec 2003, Melvyn Sopacua wrote: > On Tuesday 02 December 2003 23:34, Nate Lawson wrote: > > Try other states (acpiconf -s 1, 2, 4). If one works, use it. If not, > > try disabling acpi and using apm(4) to suspend and resume. > > Normally that would be grand, but now that I've not compiled acpi into the > kernel, I have no /dev/apm anymore as well. If you don't have acpi(4), then you need to add "device apm" to your kernel to enable apm(4) support. > Even with acpi, I never got a /dev/apmctl so apmd never worked. I've read > through devfs(5)/(8), but as far as I understand, it is the driver's > responsibility to create the device and even if you could do it in userland, > than it will just be a non-configured device. You can't use apmd with acpi(4). It has /dev/acpictl. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI problem, my VAIO won't come back from suspension
Hi Nate, On Tuesday 02 December 2003 23:34, Nate Lawson wrote: > Try other states (acpiconf -s 1, 2, 4). If one works, use it. If not, > try disabling acpi and using apm(4) to suspend and resume. Normally that would be grand, but now that I've not compiled acpi into the kernel, I have no /dev/apm anymore as well. Even with acpi, I never got a /dev/apmctl so apmd never worked. I've read through devfs(5)/(8), but as far as I understand, it is the driver's responsibility to create the device and even if you could do it in userland, than it will just be a non-configured device. I've attached my kernel config and dmesg.boot. Is there anything I'm missing? PS: I can live without suspend2disk, but sleep state S1 does not shutdown my display as well, so I'm pretty much out of options. -- Melvyn === FreeBSD sarevok.idg.nl 5.2-BETA FreeBSD 5.2-BETA #0: Wed Dec 3 20:13:44 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SAREVOK_NOACPI i386 === # vim600: tw=78 ts=8 sw=8 ai noet # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.393 2003/11/03 22:48:25 jhb Exp $ machine i386 cpu I686_CPU ident SAREVOK #To statically compile in device wiring instead of /boot/device.hints hints "SAREVOK.hints" #Default places to look for devices. makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols options SCHED_4BSD #4BSD scheduler options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options MD_ROOT #MD is a potential root device options NFSCLIENT #Network Filesystem Client options NFSSERVER #Network Filesystem Server options NFS_ROOT#NFS usable as /, requires NFSCLIENT options NTFS#NT File System options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PSEUDOFS#Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~215k to driver. # Debugging for use in -current options DDB #Enable the kernel debugger options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS options WITNESS #Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN#Don't run witness on spinlocks for speed # To make an SMP kernel, the next two are needed #optionsSMP # Symmetric MultiProcessor Kernel #device apic# I/O APIC # deviceacpi device isa device eisa device pci # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd
Re: ACPI problem, my VAIO won't come back from suspension
Try other states (acpiconf -s 1, 2, 4). If one works, use it. If not, try disabling acpi and using apm(4) to suspend and resume. Suspend/resume is far down my list of things to troubleshoot and most of the problems are very hw-specific. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ACPI problem, my VAIO won't come back from suspension
Hello, I have a Sony VAIO PCG-GRX626P, and I'm using a two days old FreeBSD current, and pretty much everything works, except that when I move into sleep mode 3 (acpiconf -s 3) I cannot bring my lap back. :-( The fan starts again, but nothing else happens, after a while I just power off the machine. I might be missing something, please point me to the right docs. TIA, --Francisco ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ACPI problem reports
If you are currently having ACPI problems, please submit a PR through the send-pr mechanism. After you have been assigned a number, please report it to [EMAIL PROTECTED] Information to include is a full dmesg of your system and links to the output of: acpidump -t -d -o my.dsdt > my.asl In preparation for 5.2R, PRs will be prioritized in the following order: 1. Panics/system crashes that are unavoidable 2. Same but avoidable (i.e. by disabling certain subsystems) 3. Features not working (battery, powerdown, but not suspend) 4. Feature requests and suspend/resume problems Thanks, -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI problem?
On Fri, 18 Jul 2003, Danny Braniss wrote: > > On Thu, 17 Jul 2003, Danny Braniss wrote: > > > > Your asl seems bogus since there are a lot of unexpected values (i.e. for > > > > TZ and EC port values). Since it worked in 4.8R, follow the instructions > > > > for disabling ACPI. > > > > > > > > -Nate > > > > > > thanks, that did it, but now, is there anyway i can help fix this so > > > acpi will work? i have several of this boxes and booting them diskless > > > will be a problem. > > > > Try man acpi: > > sorry, i guess i was not clear, i did 'unset acpi_load', and got the system > up, i was offering to help in fixing the acpi (actually debugging, since > my head hurts from reading the acpi stuff :-) Unfortunately your ASL appears to be the problem, not ACPI. The best thing you can do is try a BIOS update for your motherboard. If that doesn't help, use acpidump to get your DSDT and then start working on things according to: http://www.cpqlinux.com/acpi-howto.html This is not for the faint of heart so that's why I just suggested disabling acpi on your box. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI problem?
> On Thu, 17 Jul 2003, Danny Braniss wrote: > > > Your asl seems bogus since there are a lot of unexpected values (i.e. for > > > TZ and EC port values). Since it worked in 4.8R, follow the instructions > > > for disabling ACPI. > > > > > > -Nate > > > > thanks, that did it, but now, is there anyway i can help fix this so > > acpi will work? i have several of this boxes and booting them diskless > > will be a problem. > > Try man acpi: > To disable the acpi driver completely, set the kernel environment vari- > able hint.acpi.0.disabled to 1. Some i386 machines totally fail to oper- > ate with some or all of ACPI disabled. Other i386 machines fail with > ACPI enabled. Non-i386 platforms do not support operating systems which > do not use ACPI. Disabling all or part of ACPI on non-i386 platforms may > result in a non-functional system. > > Hints can go in /boot/loader.conf. Later, after the system is working for > you, you can go back and install a new BIOS and see if that fixes the > problem with ACPI enabled. > > -Nate sorry, i guess i was not clear, i did 'unset acpi_load', and got the system up, i was offering to help in fixing the acpi (actually debugging, since my head hurts from reading the acpi stuff :-) thanks, danny ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI problem?
On Thu, 17 Jul 2003, Danny Braniss wrote: > > Your asl seems bogus since there are a lot of unexpected values (i.e. for > > TZ and EC port values). Since it worked in 4.8R, follow the instructions > > for disabling ACPI. > > > > -Nate > > thanks, that did it, but now, is there anyway i can help fix this so > acpi will work? i have several of this boxes and booting them diskless > will be a problem. Try man acpi: To disable the acpi driver completely, set the kernel environment vari- able hint.acpi.0.disabled to 1. Some i386 machines totally fail to oper- ate with some or all of ACPI disabled. Other i386 machines fail with ACPI enabled. Non-i386 platforms do not support operating systems which do not use ACPI. Disabling all or part of ACPI on non-i386 platforms may result in a non-functional system. Hints can go in /boot/loader.conf. Later, after the system is working for you, you can go back and install a new BIOS and see if that fixes the problem with ACPI enabled. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI problem?
> Your asl seems bogus since there are a lot of unexpected values (i.e. for > TZ and EC port values). Since it worked in 4.8R, follow the instructions > for disabling ACPI. > > -Nate thanks, that did it, but now, is there anyway i can help fix this so acpi will work? i have several of this boxes and booting them diskless will be a problem. danny ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI problem?
Your asl seems bogus since there are a lot of unexpected values (i.e. for TZ and EC port values). Since it worked in 4.8R, follow the instructions for disabling ACPI. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ACPI problem?
hi, the motherboard is Intel STL2, which works fine with 4.8-stable. just tried 5.1-current and it hangs on boot: BIOS drive A: is disk0 BIOS drive C: is disk1 PXE version 2.1, real mode entry point @9d3a:0106 BIOS 637kB/785344kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Tue Jul 15 17:13:47 IDT 2003) pxe_open: server addr: 132.65.16.23 pxe_open: server path: /roots/FreeBSD/i386-5.1 pxe_open: gateway ip: 132.65.16.1 Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x42d0f4 data=0x78094+0x829e0 syms=[0x4+0x56520+0x4+0x65c75] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... /boot/kernel/acpi.ko text=0x39c14 data=0x1638+0xf68 syms=[0x4+0x5990+0x4+0x75d9] Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #2: Tue Jun 24 15:51:59 IDT 2003 [EMAIL PROTECTED]:/r+d/obj/r+d/src/sys/HUJI Preloaded elf kernel "/boot/kernel/kernel" at 0xc073. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0730244. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 933074142 Hz CPU: Intel Pentium III (933.07-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383fbff real memory = 805240832 (767 MB) avail memory = 774459392 (738 MB) Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pcibios: BIOS version 2.10 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-safe" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x404-0x407 on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_tz0: on acpi0 acpi_tz0: _CRT value is absurd, ignored (-217.-7C) acpi_tz0: _ACx value is absurd, ignored (-247.-7C) acpi_tz1: on acpi0 acpi_tz1: _CRT value is absurd, ignored (-217.-7C) acpi_tz1: _ACx value is absurd, ignored (-247.-7C) acpi_tz2: on acpi0 acpi_tz2: _CRT value is absurd, ignored (-217.-7C) acpi_tz2: _ACx value is absurd, ignored (-247.-7C) acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib0: slot 2 INTA is routed to irq 11 pcib0: slot 3 INTA is routed to irq 9 pcib0: slot 6 INTA is routed to irq 5 pcib0: slot 15 INTA is routed to irq 9 pci0: at device 2.0 (no driver attached) fxp0: port 0x1400-0x143f mem 0xf910-0xf91f,0xf9001000-0xf9001fff irq 9 at device 3.0 on pci0 fxp0: Ethernet address 00:d0:b7:b6:90:53 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto em0: port 0x1440-0x145f mem 0xf902-0xf903,0xf904-0xf905 irq 5 at device 6.0 on pci0 em0: Speed:N/A Duplex:N/A isab0: port 0x580-0x58f at device 15.0 on pci0 isa0: on isab0 atapci0: port 0x1460-0x146f,0x374-0x377,0x170-0x177 at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ohci0: mem 0xf9002000-0xf9002fff irq 9 at device 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered pcib1: on acpi0 pci1: on pcib1 pcib1: slot 4 INTA is routed to irq 9 pcib1: slot 4 INTB is routed to irq 10 ahc0: port 0x1800-0x18ff mem 0xfb00-0xfb000fff irq 9 at device 4.0 on pci1 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: port 0x2000-0x20ff mem 0xfb001000-0xfb001fff irq 10 at device 4.1 on pci1 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 acpi_ec0: port 0xca7,0xca6 on acpi0 ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER ACPI-0340: *** Error:
Re: ACPI problem: sio ports improperly attached with ACPI on IntelL440GX+
On Sun, 23 Mar 2003, Robert Watson wrote: > When I boot with ACPI, the following appears in dmesg: > > Mar 23 14:14:31 none kernel: sio0: configured irq 4 not in bitmap of probed irqs 0 > Mar 23 14:14:31 none kernel: sio0: port may not be enabled > Mar 23 14:14:31 none kernel: sio0 port 0x3f8-0x3ff irq 4 on acpi0 > Mar 23 14:14:31 none kernel: sio0: type 16550A > ... > > And sure enough, when using ACPI, interrupts don't work properly with the > serial ports, resulting in them essentially being unusable (stuff goes > out, but not in, except once in a while when the silo overflows). I > notice that, unlike my other 5.x boxes, sio0 and sio1 seem to attach to > acpi0, rather than isa0 as one would expect, so I guess it's not entirely > surprising that the interrupts aren't working right. > > Any suggestions about how I might go about diagnosing and remedying this > problem? Maybe something else steals their interrupts (it could be unconfigured ports sio[2-3]). I think the ports get probed again later with isa hints (ISTR seeing this for isa-pnp) but their "successful" attachment to acpi prevents this doing anything. The "configured irq N not in bitmap" warning used to be an error and this would have prevented attachment. You could try making it an error again. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ACPI problem: sio ports improperly attached with ACPI on Intel L440GX+
I'm attempting to use an Intel L440GX+ motherboard with 5.x, and am running into the following problem: when I boot without ACPI, the serial ports probe, attach, and work fine: Mar 23 14:21:56 none kernel: sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 Mar 23 14:21:56 none kernel: sio0: type 16550A Mar 23 14:21:56 none kernel: sio1 at port 0x2f8-0x2ff irq 3 on isa0 Mar 23 14:21:56 none kernel: sio1: type 16550A When I boot with ACPI, the following appears in dmesg: Mar 23 14:14:31 none kernel: sio0: configured irq 4 not in bitmap of probed irqs 0 Mar 23 14:14:31 none kernel: sio0: port may not be enabled Mar 23 14:14:31 none kernel: sio0 port 0x3f8-0x3ff irq 4 on acpi0 Mar 23 14:14:31 none kernel: sio0: type 16550A Mar 23 14:14:31 none kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Mar 23 14:14:31 none kernel: sio1: port may not be enabled Mar 23 14:14:31 none kernel: sio1 port 0x2f8-0x2ff irq 3 on acpi0 Mar 23 14:14:31 none kernel: sio1: type 16550A And sure enough, when using ACPI, interrupts don't work properly with the serial ports, resulting in them essentially being unusable (stuff goes out, but not in, except once in a while when the silo overflows). I notice that, unlike my other 5.x boxes, sio0 and sio1 seem to attach to acpi0, rather than isa0 as one would expect, so I guess it's not entirely surprising that the interrupts aren't working right. Any suggestions about how I might go about diagnosing and remedying this problem? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: acpi problem ???
On Fri, 24 Jan 2003, Nate Lawson wrote: > On Thu, 23 Jan 2003, Bryan Liesner wrote: > > On Thu, 23 Jan 2003, Nate Lawson wrote: > > > > > On Thu, 23 Jan 2003, Bryan Liesner wrote: > > > > I just upgraded my 4.7 system to 5.0-current via sources. Everything > > > > went smoothly, and I was up and running quickly, but with an acpi related > > > > problem. > > > > > > > > When booting, the kernel loads, detects the devices, then hangs right > > > > here: > > > > > > > > Mounting root from ufs:/dev/ad0s1a > > > > pid 84 (fsck_ufs), uid 0: exited on signal 8 > > > > > > > > No panic, just a hang. > > > > > > One thing you have wrong is that you have both acpi and apm enabled. Nix > > > apm and try again. > > > > > > Also, try without the usb drive plugged in. > > > > I took out the apm and the usb drive, same issue. > > Thanks... > > Boot single user, run fsck manually on each partition, then go multiuser. > No dice. I'm still getting the FPE on fsck_ufs. I'm kind of puzzled here. One possible clue - I forgot to unset the acpi_load, booted single user, and got the same hang when mounting root. The difference was that I didn't see fsck_ufs exit, the machine just sat there. The system isn't locked up in either case. I can hit ctrl-alt-delete and the system will reboot properly... -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: acpi problem ???
On Thu, 23 Jan 2003, Bryan Liesner wrote: > On Thu, 23 Jan 2003, Nate Lawson wrote: > > > On Thu, 23 Jan 2003, Bryan Liesner wrote: > > > I just upgraded my 4.7 system to 5.0-current via sources. Everything > > > went smoothly, and I was up and running quickly, but with an acpi related > > > problem. > > > > > > When booting, the kernel loads, detects the devices, then hangs right > > > here: > > > > > > Mounting root from ufs:/dev/ad0s1a > > > pid 84 (fsck_ufs), uid 0: exited on signal 8 > > > > > > No panic, just a hang. > > > > One thing you have wrong is that you have both acpi and apm enabled. Nix > > apm and try again. > > > > Also, try without the usb drive plugged in. > > I took out the apm and the usb drive, same issue. > Thanks... Boot single user, run fsck manually on each partition, then go multiuser. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: acpi problem ???
On Thu, 23 Jan 2003, Nate Lawson wrote: > On Thu, 23 Jan 2003, Bryan Liesner wrote: > > I just upgraded my 4.7 system to 5.0-current via sources. Everything > > went smoothly, and I was up and running quickly, but with an acpi related > > problem. > > > > When booting, the kernel loads, detects the devices, then hangs right > > here: > > > > Mounting root from ufs:/dev/ad0s1a > > pid 84 (fsck_ufs), uid 0: exited on signal 8 > > > > No panic, just a hang. > > One thing you have wrong is that you have both acpi and apm enabled. Nix > apm and try again. > > Also, try without the usb drive plugged in. > I took out the apm and the usb drive, same issue. Thanks... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: acpi problem ???
On Thu, 23 Jan 2003, Bryan Liesner wrote: > I just upgraded my 4.7 system to 5.0-current via sources. Everything > went smoothly, and I was up and running quickly, but with an acpi related > problem. > > When booting, the kernel loads, detects the devices, then hangs right > here: > > Mounting root from ufs:/dev/ad0s1a > pid 84 (fsck_ufs), uid 0: exited on signal 8 > > No panic, just a hang. One thing you have wrong is that you have both acpi and apm enabled. Nix apm and try again. Also, try without the usb drive plugged in. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
acpi problem ???
I just upgraded my 4.7 system to 5.0-current via sources. Everything went smoothly, and I was up and running quickly, but with an acpi related problem. When booting, the kernel loads, detects the devices, then hangs right here: Mounting root from ufs:/dev/ad0s1a pid 84 (fsck_ufs), uid 0: exited on signal 8 No panic, just a hang. Disabling acpi takes the hang away. The system is up to date as of the 22nd, running on an ASUS A7V266. The rest of the details are attached in an acpi-less dmesg. Also included is the output from fdisk. -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == *** Working on device /dev/ad0 *** parameters extracted from in-core disklabel are: cylinders=116336 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=116336 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 117266625 (57259 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 130/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Thu Jan 23 18:58:33 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GRAVY Preloaded elf kernel "/boot/kernel/kernel" at 0xc0495000. Preloaded elf module "/boot/kernel/radeon.ko" at 0xc04950b4. Calibrating clock(s) ... TSC clock: 1544533484 Hz, i8254 clock: 1193206 Hz Timecounter "i8254" frequency 1193206 Hz TSC initialization skipped: APM enabled. CPU: AMD Athlon(TM) XP1800+ (1544.53-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383f9ff AMD Features=0xc048 Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 536788992 (511 MB) Physical memory chunk(s): 0x1000 - 0x0009dfff, 643072 bytes (157 pages) 0x004bc000 - 0x1ffe3fff, 531791872 bytes (129832 pages) avail memory = 516505600 (492 MB) bios32: Found BIOS32 Service Directory header at 0xc00f1470 bios32: Entry = 0xf0bf0 (c00f0bf0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xdf0 pnpbios: Found PnP BIOS data at 0xc00fbd80 pnpbios: Entry = f:bdb0 Rev = 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: Initializing GEOMetry subsystem netsmb_dev: loaded null: mem: Pentium Pro MTRR support enabled VESA: information block 56 45 53 41 00 02 00 01 00 01 01 00 00 00 22 00 00 01 00 04 00 01 0e 01 00 01 24 01 00 01 29 01 00 01 6a 00 02 01 04 01 82 01 0d 01 0e 01 0f 01 20 01 92 01 93 01 94 01 95 01 96 01 a2 01 a3 01 VESA: 56 mode(s) found VESA: v2.0, 65536k memory, flags:0x1, mode table:0xc03fb2c2 (122) VESA: ATI RADEON VE VESA: ATI Technologies Inc. R100 01.00 random: npx0: on motherboard npx0: INT 16 interface pci_open(1):mode 1 addr port (0x0cf8) is 0x80010014 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=30991106) Using $PIR table, 10 entries at 0xc00f13a0 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded05A 0x02 3 4 5 7 9 10 11 12 embedded05B 0x03 3 4 5 7 9 10 11 12 embedded06A 0x05 3 4 5 7 9 10 11 12 slot 1 0 12A 0x05 3 4 5 7 9 10 11 12 slot 1 0 12B 0x01 3 4 5 7 9 10 11 12 slot 1 0 12C 0x02 3 4 5 7 9 10 11 12 slot 1 0 12D 0x03 3 4 5 7 9 10 11 12 slot 2 0 13A 0x01 3 4 5 7 9 10 11 12 slot 2 0 13B 0x02 3 4 5 7 9 10 11 12 slot 2 0 13C 0x03 3 4 5 7 9 10 11 12 slot 2 0 13D 0x05 3 4 5 7 9 10 11 12 slot 3 0 14A 0x02 3 4 5 7 9 10 11 12 slot 3 0 14B 0x03 3 4 5 7 9 10 11 12 slot 3 0 14C 0x05 3 4 5 7 9 10 11 12 slot 3 0 14D 0x01 3 4 5 7 9 10 11 12 slot 4 0 15A 0x03 3 4 5 7 9 10 11 12 slot 4 0 15B 0x05 3 4 5 7 9 10 11 12 slot 4 0 15C 0x01 3 4 5 7 9 10 11 12 slot 4 0 15D 0x02 3 4 5 7 9 10 11 12 slot 5 0 16
Re: ACPI problem with laptop?
> > Then you'll get thermal operation messages, something like: > > Nov 26 19:34:13 mybox kernel: acpi_tz0: _AC0: temperature 60.0 >= > > setpoint 60.0 > > Nov 26 19:34:13 mybox kernel: acpi_tz0: switched from NONE to _AC0: 60.0C > > > > We need the messages like this, acpidump output, and sysctl hw.acpi > output > > to track this down. [snip] > Patch added. > acpidump adds this (except for the log): acpidump: DSDT is corrupt To get acpidump properly, I recommend not loading acpi.ko. # Maybe other kernel modules also. acpidump is a very simple utility, doesn't require acpi modules. Running it in single user mode is better, I think. > There were no thermal info in /var/log/messages or anywhere else for > that matter I'm afraid that your ACPI BIOS don't have ThermalZone definitions... If so, ACPI cannot help to control thermal of your system. Anyway, I'm waiting for your acpidump output. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI problem with laptop?
Mitsuru IWASAKI wrote:
> Hi,
>
> Hmm, we need further info. on this.
> Please add the following lines into your /boor/loader.conf:
>
> hw.acpi.verbose=1
> debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_BUS"
> debug.acpi.level="ACPI_LV_WARN ACPI_LV_ERROR ACPI_LV_OBJECTS"
>
>
> Then you'll get thermal operation messages, something like:
> Nov 26 19:34:13 mybox kernel: acpi_tz0: _AC0: temperature 60.0 >=
> setpoint 60.0
> Nov 26 19:34:13 mybox kernel: acpi_tz0: switched from NONE to _AC0: 60.0C
>
> We need the messages like this, acpidump output, and sysctl hw.acpi
output
> to track this down.
>
> BTW, does new acpica patches give any effects for your?
>
http://people.freebsd.org/~iwasaki/acpi/acpica-20021002-20021118-test20021121.diff
>
> Thanks
Patch added.
acpidump adds this (except for the log): acpidump: DSDT is corrupt
-su-2.05b# sysctl hw.acpi
hw.acpi.power_button_state: S5
hw.acpi.sleep_button_state: S1
hw.acpi.lid_switch_state: S1
hw.acpi.standby_state: S1
hw.acpi.suspend_state: S3
hw.acpi.sleep_delay: 0
hw.acpi.s4bios: 1
hw.acpi.verbose: 1
hw.acpi.cpu.max_speed: 16
hw.acpi.cpu.current_speed: 16
hw.acpi.cpu.performance_speed: 16
hw.acpi.cpu.economy_speed: 8
hw.acpi.acline: 1
hw.acpi.battery.life: 99
hw.acpi.battery.time: -1
hw.acpi.battery.state: 2
hw.acpi.battery.units: 1
hw.acpi.battery.info_expire: 5
There were no thermal info in /var/log/messages or anywhere else for
that matter
/John
/*
RSD PTR: Checksum=142, OEMID=PTLTD, RsdtAddress=0x0eefb5f9
*/
/*
RSDT: Length=44, Revision=1, Checksum=229,
OEMID=PTLTD, OEM Table ID= RSDT, OEM Revision=0x604,
Creator ID= LTP, Creator Revision=0x0
*/
/*
Entries={ 0x0eefee74, 0x0eefeee8 }
*/
/*
DSDT=0xeefb625
INT_MODEL=PIC
SCI_INT=10
SMI_CMD=0x802f, ACPI_ENABLE=0xf0, ACPI_DISABLE=0xf1, S4BIOS_REQ=0xf2
PM1a_EVT_BLK=0x8000-0x8003
PM1a_CNT_BLK=0x8004-0x8005
PM2_TMR_BLK=0x8008-0x800b
PM2_GPE0_BLK=0x8020-0x8023
P_LVL2_LAT=90ms, P_LVL3_LAT=900ms
FLUSH_SIZE=0, FLUSH_STRIDE=0
DUTY_OFFSET=0, DUTY_WIDTH=4
DAY_ALRM=125, MON_ALRM=126, CENTURY=127
Flags={WBINVD,PROC_C1,SLP_BUTTON}
*/
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #0: Tue Nov 26 16:13:19 CET 2002
root@Sleeper:/usr/obj/usr/src/sys/Sleeper
Preloaded elf kernel "/boot/kernel/kernel" at 0xc05bb000.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc05bb0a8.
Timecounter "i8254" frequency 1193182 Hz
Timecounter "TSC" frequency 1295518645 Hz
CPU: mobile AMD Athlon(tm) 4 1500+ (1295.52-MHz 686-class CPU)
Origin = "AuthenticAMD" Id = 0x662 Stepping = 2
Features=0x383f9ff
AMD Features=0xc040
real memory = 251658240 (240 MB)
avail memory = 238227456 (227 MB)
Initializing GEOMetry subsystem
Pentium Pro MTRR support enabled
npx0: on motherboard
npx0: INT 16 interface
acpi0: on motherboard
ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15
Using $PIR table, 7 entries at 0xc00fdf50
acpi0: power button is handled as a fixed feature programming model.
Timecounter "ACPI-safe" frequency 3579545 Hz
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0
acpi_cpu0: on acpi0
acpi_button0: on acpi0
acpi_button1: on acpi0
acpi_lid0: on acpi0
acpi_acad0: on acpi0
acpi_cmbat0: on acpi0
pcib0: port 0xcf8-0xcff on acpi0
initial configuration
\\_SB_.PCI0.PIB_.LNKC irq 5: [ 5] low,level,sharable 0.1.0
\\_SB_.PCI0.PIB_.LNKA irq 4: [ 4] low,level,sharable 0.7.0
\\_SB_.PCI0.PIB_.LNKB irq 11: [ 11] low,level,sharable 0.7.1
\\_SB_.PCI0.PIB_.LNKC irq 5: [ 5] low,level,sharable 0.7.2
\\_SB_.PCI0.PIB_.LNKD irq 9: [ 9] low,level,sharable 0.7.3
\\_SB_.PCI0.PIB_.LNKA irq 4: [ 4] low,level,sharable 0.9.0
\\_SB_.PCI0.PIB_.LNKD irq 9: [ 9] low,level,sharable 0.9.1
\\_SB_.PCI0.PIB_.LNKB irq 11: [ 11] low,level,sharable 0.10.0
\\_SB_.PCI0.PIB_.LNKB irq 11: [ 11] low,level,sharable 0.11.0
\\_SB_.PCI0.PIB_.LNKA irq 4: [ 4] low,level,sharable 0.19.0
before setting priority for links
before fixup boot-disabled links -
after fixup boot-disabled links --
arbitrated configuration -
\\_SB_.PCI0.PIB_.LNKC irq 5: [ 5] low,level,sharable 0.1.0
\\_SB_.PCI0.PIB_.LNKA irq 4: [ 4] low,level,sharable 0.7.0
\\_SB_.PCI0.PIB_.LNKB irq 11: [ 11] low,level,sharable 0.7.1
\\_SB_.PCI0.PIB_.LNKC irq 5: [ 5] low,level,sharable 0.7.2
\\_SB_.PCI0.PIB_.LNKD irq 9: [ 9] low,level,sharable 0.7.3
\\_SB_.PCI0.PIB_.LNKA irq 4: [ 4] low,level,sharable 0.9.0
\\_SB_.PCI0.PIB_.LNKD irq 9: [ 9] low,level,sharable 0.9.1
\\_SB_.PCI0.PIB_.LNKB irq 11: [ 11] low,level,sharable 0.10.0
\\_SB_.PCI0.PIB_.LNKB irq 11: [ 11] low,level,sharable 0.11.0
\\_SB_.PCI0.PIB_.LNKA irq
Re: ACPI problem with laptop?
Terry Lambert wrote: > Have you applied the most recent ACPI patches, and turned on > debugging output (at least "hw.acpi.verbose=1") to see if it > fixes the problem (and if it doesn't, at least report what's > going on)? It looks like the author of the ACPI code has already replied to your post; apply the patch he suggests, and turn on the debugging he suggests. He knows far mor about ACPI than the rest of us. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI problem with laptop?
John Angelmo wrote: > Terry Lambert wrote: > > Is this a Dell Lattitude? They are known to have heat problems. > > > > There's also the possibility that the CPU is a desktop CPU in > > the laptop; people aren't supposed to do that, either, but it > > can crank up the heat. > > No it's a Evo N114 with an Athlon 4 in it, I think that this is a mobile CPU It may be that Windows ensures that the computer runs cooler by down-clocking it. Have you applied the most recent ACPI patches, and turned on debugging output (at least "hw.acpi.verbose=1") to see if it fixes the problem (and if it doesn't, at least report what's going on)? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI problem with laptop?
Terry Lambert wrote: Is this a Dell Lattitude? They are known to have heat problems. There's also the possibility that the CPU is a desktop CPU in the laptop; people aren't supposed to do that, either, but it can crank up the heat. -- Terry Hello No it's a Evo N114 with an Athlon 4 in it, I think that this is a mobile CPU /John -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI problem with laptop?
Hi, > If I choose to make world under -CURRENT the laptop gets hotter (well > the processor/hd and so on gets used and causes heat) now, the fan > starts to spin faster and so on, but the computer never gets cooler even > a day after a build it still is hot and the fan never stops spinning, is > there a way to let my processor know how to calm down? > This problem dosn't occur when I'm running Windows (XP) Hmm, we need further info. on this. Please add the following lines into your /boor/loader.conf: hw.acpi.verbose=1 debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_BUS" debug.acpi.level="ACPI_LV_WARN ACPI_LV_ERROR ACPI_LV_OBJECTS" Then you'll get thermal operation messages, something like: Nov 26 19:34:13 mybox kernel: acpi_tz0: _AC0: temperature 60.0 >= setpoint 60.0 Nov 26 19:34:13 mybox kernel: acpi_tz0: switched from NONE to _AC0: 60.0C We need the messages like this, acpidump output, and sysctl hw.acpi output to track this down. BTW, does new acpica patches give any effects for your? http://people.freebsd.org/~iwasaki/acpi/acpica-20021002-20021118-test20021121.diff Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ACPI problem with laptop?
Hello If I choose to make world under -CURRENT the laptop gets hotter (well the processor/hd and so on gets used and causes heat) now, the fan starts to spin faster and so on, but the computer never gets cooler even a day after a build it still is hot and the fan never stops spinning, is there a way to let my processor know how to calm down? This problem dosn't occur when I'm running Windows (XP) /John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI problem
On Sat, 23 Nov 2002, Ertan Kucukoglu wrote: > First of all, I do not know much about backtracing, debugging etc. First advice: we shipped DP2 with two different kernels, the normal kernel without high debugging features, and then a special debugging kernel called DEBUG. My first advice when starting to debug problems of this sort is to boot the debug kernel rather than the regular kernel, since it will allow you to exercise debugging features more easily. > I want to use the power key to shutdown the system. It is compaq evo > 300, P4 1.6ghz, 368MB RAM > > Yesterday OS was 5.0DP2. I can not power it off. It comes to a point > when it should cut the power off 'System is shutting down using ACPI' > like message is displayed and after a while. It just panics at free(). In general, if you get a panic and drop to ddb, you can type in "trace" to get a backtrace -- this is usually the single must useful piece of information for debugging a panic. The print-out can often be 20 lines long, and is full of hex numbers. If you have access to a second machine, you can use a serial console to make it easier to copy and paste the ddb output. If you don't, and are concerned about typographical errors, you can skip the function "arguments", but make sure you do get the function+0xoffset bits right. Serial console is really best because we can look at the argument pointers and make sure they make sense. Also, when reporting panics, please do include the exactly language of the panic message. > This morning I cvsuped and buildworld the machine. This time it do not > panic, but 'Timeout' error message comes and system reset itself leading > a new boot.' Is this problem because of my hardware or something else? Not clear. We really need the exact messages here, if you can arrange it. Given the problems that you're experiencing, if a serial console is available, it would probably make a big different in debugging the problems, and save you a lot of hand-typing. You can set up a serial console by linking it and an adjacent machine using a null modem cable on the first serial port, and then using a terminal program on the adjacent box at 9600bps -- all console I/O can be sent to the box by typing: set console="comconsole" in the boot loader. When you're using the debug kernel, you'll also be able to interact with the debugger using the serial console. > > My dmesg output is below. My hand written uname -a is: > test# uname -a > FreeBSD test.ozlerplastik.com 5.0-CURRENT FreeBSD > 5.0-CURRENT #3: Sat > Nov 23 10:57:36 EET 2002 > [EMAIL PROTECTED]:/usr/src/sys/i386/compile/OPTIMIZED_KERNEL > i386 > > Regards, > > --Ertan > > P.S. Unproper dismount messages are because I wanted to > test the system background filesystem check. I just pluged > the cable of when the X is running. There seems to be no > problem at all. > > dmesg: > Copyright (c) 1992-2002 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, > 1992, 1993, 1994 > The Regents of the University of California. All > rights reserved. > FreeBSD 5.0-CURRENT #3: Sat Nov 23 10:57:36 EET 2002 > [EMAIL PROTECTED]:/usr/src/sys/i386/compile/OPTIMIZED_KERNEL > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0415000. > Timecounter "i8254" frequency 1193182 Hz > Timecounter "TSC" frequency 1594833756 Hz > CPU: Pentium 4 (1594.83-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf12 Stepping = 2 > >Features=0x3febfbff > real memory = 402653184 (384 MB) > avail memory = 386703360 (368 MB) > Initializing GEOMetry subsystem > Pentium Pro MTRR support enabled > acpi0: on motherboard > Using $PIR table, 9 entries at 0xc00ebfd0 > acpi0: power button is handled as a fixed feature > programming model. > Timecounter "ACPI-fast" frequency 3579545 Hz > acpi_timer0: <24-bit timer at 3.579545MHz> port > 0xf808-0xf80b on acpi0 > acpi_cpu0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > initial configuration > \\_SB_.LNKA irq 0: [ 3 4 5 6 7 10 11 14 15] > low,level,sharable 0.31.0 > \\_SB_.LNKB irq 10: [ 3 4 5 6 7 10 11 14 15] > low,level,sharable 0.31.1 > \\_SB_.LNKH irq 0: [ 3 4 5 6 7 10 11 14 15] > low,level,sharable 0.31.2 > \\_SB_.LNKD irq 11: [ 3 4 5 6 7 10 11 14 15] > low,level,sharable 0.31.3 > \\_SB_.LNKC irq 10: [ 3 4 5 6 7 10 11 14 15] > low,level,sharable 0.1.0 > \\_SB_.LNKD irq 11: [ 3 4 5 6 7 10 11 14 15] > low,level,sharable 0.1.1 > before setting priority for links > \\_SB_.LNKA: > interrupts: 3 4 5 6 7 >10111415 > penalty: 1220 1220 220 1220 1220 > 420 420 10220 10220 > references: 1 > priority: 0 > \\_SB_.LNKH: > interrupts: 3 4 5 6 7 >10111415 > penalty: 1220 1220 220 1220 1220 > 420 420 10220 10220 > references: 1 > pri
Re: ACPI problem
Ertan Kucukoglu wrote: > I want to use the power key to shutdown the system. It is > compaq evo 300, P4 1.6ghz, 368MB RAM > > Yesterday OS was 5.0DP2. I can not power it off. It comes > to a point when it should cut the power off 'System is > shutting down using ACPI' like message is displayed and > after a while. It just panics at free(). > > This morning I cvsuped and buildworld the machine. This > time it do not panic, but 'Timeout' error message comes and > system reset itself leading a new boot.' Is this problem > because of my hardware or something else? You will most likely need to dump your ACPI table and file a bug report, assigning it to the ACPI code owner, who will then tell you what is wrong with your BIOS, an ha yuned to do to fix it (or give you a patch to th ACPI code in FreeBSD, to make it tolerate your BIOS). The first step will be a bug report. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ACPI problem
Hello, First of all, I do not know much about backtracing, debugging etc. I want to use the power key to shutdown the system. It is compaq evo 300, P4 1.6ghz, 368MB RAM Yesterday OS was 5.0DP2. I can not power it off. It comes to a point when it should cut the power off 'System is shutting down using ACPI' like message is displayed and after a while. It just panics at free(). This morning I cvsuped and buildworld the machine. This time it do not panic, but 'Timeout' error message comes and system reset itself leading a new boot.' Is this problem because of my hardware or something else? My dmesg output is below. My hand written uname -a is: test# uname -a FreeBSD test.ozlerplastik.com 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Sat Nov 23 10:57:36 EET 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/OPTIMIZED_KERNEL i386 Regards, --Ertan P.S. Unproper dismount messages are because I wanted to test the system background filesystem check. I just pluged the cable of when the X is running. There seems to be no problem at all. dmesg: Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #3: Sat Nov 23 10:57:36 EET 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/OPTIMIZED_KERNEL Preloaded elf kernel "/boot/kernel/kernel" at 0xc0415000. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 1594833756 Hz CPU: Pentium 4 (1594.83-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf12 Stepping = 2 Features=0x3febfbff real memory = 402653184 (384 MB) avail memory = 386703360 (368 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled acpi0: on motherboard Using $PIR table, 9 entries at 0xc00ebfd0 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xf808-0xf80b on acpi0 acpi_cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 initial configuration \\_SB_.LNKA irq 0: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.31.0 \\_SB_.LNKB irq 10: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.31.1 \\_SB_.LNKH irq 0: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.31.2 \\_SB_.LNKD irq 11: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.31.3 \\_SB_.LNKC irq 10: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.1.0 \\_SB_.LNKD irq 11: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.1.1 before setting priority for links \\_SB_.LNKA: interrupts: 3 4 5 6 7 10111415 penalty: 1220 1220 220 1220 1220 420 420 10220 10220 references: 1 priority: 0 \\_SB_.LNKH: interrupts: 3 4 5 6 7 10111415 penalty: 1220 1220 220 1220 1220 420 420 10220 10220 references: 1 priority: 0 before fixup boot-disabled links - \\_SB_.LNKA: interrupts: 3 4 5 6 7 10111415 penalty: 1220 1220 220 1220 1220 420 420 10220 10220 references: 1 priority: 2931 \\_SB_.LNKH: interrupts: 3 4 5 6 7 10111415 penalty: 1220 1220 220 1220 1220 420 420 10220 10220 references: 1 priority: 2931 after fixup boot-disabled links -- arbitrated configuration - \\_SB_.LNKA irq 5: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.31.0 \\_SB_.LNKB irq 10: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.31.1 \\_SB_.LNKH irq 5: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.31.2 \\_SB_.LNKD irq 11: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.31.3 \\_SB_.LNKC irq 10: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.1.0 \\_SB_.LNKD irq 11: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.1.1 pci0: on pcib0 agp0: mem 0xf800-0xfbff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pcib2: at device 30.0 on pci0 initial configuration \\_SB_.LNKA irq 5: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 2.4.0 \\_SB_.LNKC irq 10: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 2.4.1 \\_SB_.LNKF irq 0: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 2.4.2 \\_SB_.LNKG irq 0: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 2.4.3 \\_SB_.LNKC irq 10: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 2.9.0 \\_SB_.LNKF irq 0: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 2.9.1 \\_SB_.LNKG irq 0: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 2.9.2 \\_SB_.LNKA irq 5: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 2.9.3 \\_SB_.LNKF ir
Kernel won't boot - ACPI Problem ?
Hi Folks, I was unable to boot the kernel for sometime, so I tried doing an "unset acpi_load" and the kernel booted fine. The kernel would hang after reaching "Timecounter" as show below. --- Sep 13 18:20:09 calvin kernel: unknown: can't assign resources (port) Sep 13 18:20:09 calvin kernel: unknown: can't assign resources (port) Sep 13 18:20:09 calvin kernel: unknown: can't assign resources (port) Sep 13 18:20:09 calvin kernel: Timecounters tick every 10.000 msec --- My System Info --- Sep 13 18:20:09 calvin kernel: Timecounter "i8254" frequency 1193182 Hz Sep 13 18:20:09 calvin kernel: Timecounter "TSC" frequency 996769445 Hz Sep 13 18:20:09 calvin kernel: CPU: Pentium III/Pentium III Xeon/Celeron (996.77-MHz 686-class CPU) Sep 13 18:20:09 calvin kernel: Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Sep 13 18:20:09 calvin kernel: Features=0x383fbff Sep 13 18:20:09 calvin kernel: real memory = 267255808 (260992K bytes) Sep 13 18:20:09 calvin kernel: avail memory = 253181952 (247248K bytes) --- uname - 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Sep 19 17:11:41 IST 2002 root@calvin:/usr/obj/usr/src/sys/GENERIC i386 My Kernel boots fine, if I disable acpi. Is there something wrong with ACPI and kernel right now ? Is there a fix to this ? i.e. apart from disabling acpi. TIA Regards Sid -- What is worth doing is worth the trouble of asking somebody to do. Sid Carter - http://symonds.net/~sidcarter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1371] Re: ACPI: problem with fdc resource allocation
# Congratulations, Maxim! > On Thu, Oct 25, 2001 at 05:13:56PM +0300, Maxim Sobolev wrote: > > > > 6. And finally I've put back corrected ACPI table back into > > BIOS image using CBROM.EXE, flashed resulting BIOS image and > > voila - the ACPI problem gone. :) > > > > Way cool. :) Yeah, Maxim is maniac :) Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: problem with fdc resource allocation
Maxim Sobolev wrote: > I know several local guys with exactly the same > bug (some time ago I've convinced some them to swith to -current > and test/report any problems) and it is very sad to see my efforts > vanished, especially considering that the source of the problem is > located and as you said it is a "trivial" one. FWIW, "trivial" usually refers to the complexity of the problem, not the amount of work required to fix it (if it's trivial, then that means the work to fix it is "grunt work", i.e. it is not intellectually challenging, and therefore not attractive to work on or spend your effort on). The other use of "trivial" is "concerned with trivia"; it means that while the problem is known, so is the workaround, and so it is not a critical problem, just an annoying one. The most commonly cited workaround for this case is to delete or rename "acpi.ko" to prevent it being loaded. The first definition is the one used by mathematicians; the second one is used by the other sciences to describe things like the value of the constant of integration, when all they are concerned with is a line fit for the curve (i.e. set it to whatever displaces the curve sufficiently for it to fit the data). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1371] Re: ACPI: problem with fdc resource allocation
On Thu, Oct 25, 2001 at 05:13:56PM +0300, Maxim Sobolev wrote: > > 6. And finally I've put back corrected ACPI table back into > BIOS image using CBROM.EXE, flashed resulting BIOS image and > voila - the ACPI problem gone. :) > Way cool. :) Joe msg32007/pgp0.pgp Description: PGP signature
Re: [acpi-jp 1363] Re: ACPI: problem with fdc resource allocation
Mitsuru IWASAKI wrote:
>
> Hi, Maxim. Thanks for reporting and reminding us.
>
> I think this is very difficult to fix, because;
> 1. Basically, this is a bug in BIOS, should be reported to vendor.
> 2. ACPI CA is developed by Intel. We'd like to have less local
> workaround changes as possible.
> 3. I'm not sure whether suggested patches (buffer size dynamicaly expanding)
> in [acpi-jp 1315] is correct fix, maybe not. Probably another approach
> can be considered (e.g. just ignore AE_AML_BUFFER_LIMIT and continue
> interpreter execution).
Thank you very much for pointing me into the right
direction! Finally I've properly fixed the bug, though I
took slightly different approach, which I will describe
below in the case when somebody else has the same or similar
problem:
1. First of all, I dumped the ASL DSDT code using
acpidump(8) utility available from ports/devel/acpicatools.
For some reason output of the similar utility in the base
system (fresh 5-CURRENT) appears to be incompatible with
iasl compiler, so if anybody else will follow these steps
please make sure that you are using a right acpidump(8).
2. After that I have compiled ASL code back into AML using
iasl and saved resulting AML under different name DSDT_old.
3. Then I've patched ASL file to fix the problem - as Mike
suggested changed 0x19 to 0x11 and 0x1c to 0x14 and compiled
fixed ASL into DSDT_new file. With this message I am
attaching appropriate patch, perhaps it is a good idea to
put it somehow into the repository.
4. Next I've compared output of `hexdump -C' of both files
(DSDT_old and DSDT_new), noted the differencies - as I
expected only three bytes were different - checksum in the
header and two bytes in the code itself.
5. Then I've extracted ACPI table from BIOS image using
AWARD's CBROM.EXE utility, fired my favourite hex editor,
found those two bytes in the extracted file and changed them
accordingly (0x19-->0x11, 0x1c-->0x14). Also I've increased
checksum in the DSDT header by the difference of the
checksums in the DSDT_old and DSDT_new (0x10 in this
particular case).
6. And finally I've put back corrected ACPI table back into
BIOS image using CBROM.EXE, flashed resulting BIOS image and
voila - the ACPI problem gone. :)
If anybody else needs it, I could provide "fixed" BIOS image
for Tyan-S1590 (Trinity 100AT) mobo, just drop me a note.
Thanks to all who helped!
-Maxim
>
> I'll describe again the problem. This method is like this;
> Method(_CRS) {
> Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
>0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0,
>0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79, 0x0 })
> CreateByteField(BUF0, 0x2, IOLO)
> CreateByteField(BUF0, 0x3, IOHI)
> CreateByteField(BUF0, 0x4, IORL)
> CreateByteField(BUF0, 0x5, IORH)
> CreateByteField(BUF0, 0x19, IRQL)
> CreateByteField(BUF0, 0x1c, DMAV)
> Return(BUF0)
> }
>
> The problem is that this AML is trying to create a field at exceeded
> position (0x19) of the Buffer (size is 0x18).
> And strangely, this method just return the buffer w/o any changes
> after CreateByteField operations. I guess that BIOS writer forgotten to
> delete CreateByteField statements, or change the buffer size.
>
> Now that we have DSDT override patches;
> http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1347
> or
> http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1349
>
> and AML disassembler (acpidump), and ASL compiler (iasl) in
> ports/devel/acpicatools/.
>
> Maxim, could you apply the following patches and try DSDT overriding?
>
> Thanks
>
> --- Tyan-S1590.asl.org Wed Oct 24 22:00:44 2001
> +++ Tyan-S1590.asl Wed Oct 24 22:02:09 2001
> @@ -884,12 +884,14 @@
> }
> Method(_CRS) {
> Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3, 0x0,
>0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0, 0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0,
>0x79, 0x0 })
> +/*
> CreateByteField(BUF0, 0x2, IOLO)
> CreateByteField(BUF0, 0x3, IOHI)
> CreateByteField(BUF0, 0x4, IORL)
> CreateByteField(BUF0, 0x5, IORH)
> CreateByteField(BUF0, 0x19, IRQL)
> CreateByteField(BUF0, 0x1c, DMAV)
> +*/
> Return(BUF0)
> }
> Name(_PRS, Buffer(0x1a) {0x30, 0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
>0x0, 0x4, 0x47, 0x1,
Re: [acpi-jp 1363] Re: ACPI: problem with fdc resource allocation
Mitsuru IWASAKI wrote:
>
> Hi, Maxim. Thanks for reporting and reminding us.
>
> I think this is very difficult to fix, because;
> 1. Basically, this is a bug in BIOS, should be reported to vendor.
I understood that, but it is a discontinued model, so it is
unlikely that they will bother to provide updated BIOS just
to satisfy those strange that want to run FreeBSD on it. :((
> 2. ACPI CA is developed by Intel. We'd like to have less local
> workaround changes as possible.
Ok, I see.
> 3. I'm not sure whether suggested patches (buffer size dynamicaly expanding)
> in [acpi-jp 1315] is correct fix, maybe not. Probably another approach
> can be considered (e.g. just ignore AE_AML_BUFFER_LIMIT and continue
> interpreter execution).
>
> I'll describe again the problem. This method is like this;
> Method(_CRS) {
> Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
>0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0,
>0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79, 0x0 })
> CreateByteField(BUF0, 0x2, IOLO)
> CreateByteField(BUF0, 0x3, IOHI)
> CreateByteField(BUF0, 0x4, IORL)
> CreateByteField(BUF0, 0x5, IORH)
> CreateByteField(BUF0, 0x19, IRQL)
> CreateByteField(BUF0, 0x1c, DMAV)
> Return(BUF0)
> }
>
> The problem is that this AML is trying to create a field at exceeded
> position (0x19) of the Buffer (size is 0x18).
> And strangely, this method just return the buffer w/o any changes
> after CreateByteField operations. I guess that BIOS writer forgotten to
> delete CreateByteField statements, or change the buffer size.
>
> Now that we have DSDT override patches;
> http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1347
> or
> http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1349
>
> and AML disassembler (acpidump), and ASL compiler (iasl) in
> ports/devel/acpicatools/.
>
> Maxim, could you apply the following patches and try DSDT overriding?
Looks like a way to go. I'll test them tomorrow and let you
know then.
Big thanks!
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1363] Re: ACPI: problem with fdc resource allocation
Hi, Maxim. Thanks for reporting and reminding us.
I think this is very difficult to fix, because;
1. Basically, this is a bug in BIOS, should be reported to vendor.
2. ACPI CA is developed by Intel. We'd like to have less local
workaround changes as possible.
3. I'm not sure whether suggested patches (buffer size dynamicaly expanding)
in [acpi-jp 1315] is correct fix, maybe not. Probably another approach
can be considered (e.g. just ignore AE_AML_BUFFER_LIMIT and continue
interpreter execution).
I'll describe again the problem. This method is like this;
Method(_CRS) {
Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0,
0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79, 0x0 })
CreateByteField(BUF0, 0x2, IOLO)
CreateByteField(BUF0, 0x3, IOHI)
CreateByteField(BUF0, 0x4, IORL)
CreateByteField(BUF0, 0x5, IORH)
CreateByteField(BUF0, 0x19, IRQL)
CreateByteField(BUF0, 0x1c, DMAV)
Return(BUF0)
}
The problem is that this AML is trying to create a field at exceeded
position (0x19) of the Buffer (size is 0x18).
And strangely, this method just return the buffer w/o any changes
after CreateByteField operations. I guess that BIOS writer forgotten to
delete CreateByteField statements, or change the buffer size.
Now that we have DSDT override patches;
http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1347
or
http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1349
and AML disassembler (acpidump), and ASL compiler (iasl) in
ports/devel/acpicatools/.
Maxim, could you apply the following patches and try DSDT overriding?
Thanks
--- Tyan-S1590.asl.org Wed Oct 24 22:00:44 2001
+++ Tyan-S1590.asl Wed Oct 24 22:02:09 2001
@@ -884,12 +884,14 @@
}
Method(_CRS) {
Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3, 0x0,
0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0, 0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79,
0x0 })
+/*
CreateByteField(BUF0, 0x2, IOLO)
CreateByteField(BUF0, 0x3, IOHI)
CreateByteField(BUF0, 0x4, IORL)
CreateByteField(BUF0, 0x5, IORH)
CreateByteField(BUF0, 0x19, IRQL)
CreateByteField(BUF0, 0x1c, DMAV)
+*/
Return(BUF0)
}
Name(_PRS, Buffer(0x1a) {0x30, 0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3, 0x0,
0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0, 0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x38,
0x79, 0x0 })
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: problem with fdc resource allocation
> > > > The problem is still here as of today's kernel. Please do > > > something about it. > > > > Should I reapeat how sad it is that this longstanding > > problem is being completely ignored by the acpi > > maintainer(s)? > > No, I'd prefer that you found something constructive to do with your time. > I'm not interested in being bitched out over something as trivial as this > when I have so much on my plate already; if you can't contribute, do me > the least favour and save me the angst. What you expect me to do "constructive" about this? I've submitted detailed report, tested some patches proposed by the Japanese ACPI developers and so on. I do not see what else I could do to get this problem resolved apart from bugging you from time to time. Perhaps you have any better ideas, then please let me know. Also if the problem is as trivial as you are describing, then it is highly unclear why it is not fixed yet (some 6 weeks are passed since initial report). I know several local guys with exactly the same bug (some time ago I've convinced some them to swith to -current and test/report any problems) and it is very sad to see my efforts vanished, especially considering that the source of the problem is located and as you said it is a "trivial" one. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: problem with fdc resource allocation
> > The problem is still here as of today's kernel. Please do > > something about it. > > Should I reapeat how sad it is that this longstanding > problem is being completely ignored by the acpi > maintainer(s)? No, I'd prefer that you found something constructive to do with your time. I'm not interested in being bitched out over something as trivial as this when I have so much on my plate already; if you can't contribute, do me the least favour and save me the angst. Thanks. Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: problem with fdc resource allocation
Maxim Sobolev wrote: > > Maxim Sobolev wrote: > > > > Mike Smith wrote: > > > > > This just isn't going to work. The _CRS data stream stops at byte 0x17, > > > and these extra items are simply mis-aimed. > > > > > > The 0x19 should really be 0x11, and the 0x1c should really be 0x14, ie. > > > this is a BIOS bug, and should be reported to the vendor. (It should > > > also have failed the Microsoft ACPI validation suite...) > > > > > > The correct action should probably be to silently discard the write > > > operations outside of a defined buffer, and return Zeroes or Ones for a > > > read outside a buffer. > > > > Do you have a patch to test this approach? While I understand that the best way to > > resolve the problem is to convince vendors to fix their ACPI implementations, but > > obviously this isn't going to happen any time soon, so appropriate workarround is > > really a must. > > The problem is still here as of today's kernel. Please do > something about it. Should I reapeat how sad it is that this longstanding problem is being completely ignored by the acpi maintainer(s)? -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: problem with fdc resource allocation
Maxim Sobolev wrote: > > Mike Smith wrote: > > > This just isn't going to work. The _CRS data stream stops at byte 0x17, > > and these extra items are simply mis-aimed. > > > > The 0x19 should really be 0x11, and the 0x1c should really be 0x14, ie. > > this is a BIOS bug, and should be reported to the vendor. (It should > > also have failed the Microsoft ACPI validation suite...) > > > > The correct action should probably be to silently discard the write > > operations outside of a defined buffer, and return Zeroes or Ones for a > > read outside a buffer. > > Do you have a patch to test this approach? While I understand that the best way to > resolve the problem is to convince vendors to fix their ACPI implementations, but > obviously this isn't going to happen any time soon, so appropriate workarround is > really a must. The problem is still here as of today's kernel. Please do something about it. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: problem with fdc resource allocation
Mike Smith wrote:
> This just isn't going to work. The _CRS data stream stops at byte 0x17,
> and these extra items are simply mis-aimed.
>
> The 0x19 should really be 0x11, and the 0x1c should really be 0x14, ie.
> this is a BIOS bug, and should be reported to the vendor. (It should
> also have failed the Microsoft ACPI validation suite...)
>
> The correct action should probably be to silently discard the write
> operations outside of a defined buffer, and return Zeroes or Ones for a
> read outside a buffer.
Do you have a patch to test this approach? While I understand that the best way to
resolve the problem is to convince vendors to fix their ACPI implementations, but
obviously this isn't going to happen any time soon, so appropriate workarround is
really a must.
-Maxim
> > Hi, I've just made a workaround for this. Intel folks, could you review
> > it as always?
> >
> > > The problem is here, right?
> > > > can't fetch resources for \\_SB_.PCI0.ISA_.FDC0 - AE_AML_BUFFER_LIMIT
> > >
> > > I'm sure _SB_.PCI0.ISA_.FDC0._CRS (Current Resource Settings) have some
> > > problems (not sure in BIOS or ACPICA yet). I could reproduce the problem
> > > which you reported. Trace attached in this mail.
> > [snip]
> > > dsopcode-0677 [09] DsEvalBufferFieldOpera: Field size 208 exceeds Buffer si
> > ze 192 (bits)
> > > PsExecute: method failed - \_SB_.PCI0.ISA_.FDC0._CRS (0x8098fa8)
> > > Execution of \_SB_.PCI0.ISA_.FDC0._CRS failed with status AE_AML_BUFFER_LIM
> > IT
> >
> > This method is like this;
> > Method(_CRS) {
> > Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
> > 0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0,
> > 0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79, 0x0
> > })
> > CreateByteField(BUF0, 0x2, IOLO)
> > CreateByteField(BUF0, 0x3, IOHI)
> > CreateByteField(BUF0, 0x4, IORL)
> > CreateByteField(BUF0, 0x5, IORH)
> > CreateByteField(BUF0, 0x19, IRQL)
> > CreateByteField(BUF0, 0x1c, DMAV)
> > Return(BUF0)
> > }
> >
> > The problem is that this AML is trying to create a field at exceeded
> > position (0x19) of the Buffer (size is 0x18).
> > I couldn't find how AML interprepter treat this in ACPI Spec. so I'm
> > not sure wether AWRDACPI violates the Spec. or ACPICA can have a workaround
> > for this.
> > Anyway, I made a patch to reallocate a large enough buffer for the
> > requested operation.
> >
> > Thanks
> >
> > Index: dsopcode.c
> > ===
> > RCS file: /home/ncvs/src/sys/contrib/dev/acpica/dsopcode.c,v
> > retrieving revision 1.1.1.10
> > diff -u -r1.1.1.10 dsopcode.c
> > --- dsopcode.c7 Sep 2001 01:22:24 - 1.1.1.10
> > +++ dsopcode.c1 Oct 2001 18:58:41 -
> > @@ -615,11 +615,24 @@
> > if ((BitOffset + BitCount) >
> > (8 * (UINT32) SrcDesc->Buffer.Length))
> > {
> > +UINT32 Length;
> > +UINT8 *Pointer;
> > +
> > ACPI_DEBUG_PRINT ((ACPI_DB_ERROR,
> > "Field size %d exceeds Buffer size %d (bits)\n",
> > BitOffset + BitCount, 8 * (UINT32) SrcDesc->Buffer.Length))
> > ;
> > -Status = AE_AML_BUFFER_LIMIT;
> > -goto Cleanup;
> > +Length = ((BitOffset + BitCount) / 8) +
> > + (((BitOffset + BitCount) % 8) ? 1 : 0);
> > +Pointer = ACPI_MEM_CALLOCATE (Length);
> > +if (!Pointer)
> > +{
> > +Status = AE_NO_MEMORY;
> > +goto Cleanup;
> > +}
> > +MEMCPY (Pointer, SrcDesc->Buffer.Pointer, SrcDesc->Buffer.Length
> > );
> > +ACPI_MEM_FREE (SrcDesc->Buffer.Pointer);
> > +SrcDesc->Buffer.Pointer = Pointer;
> > +SrcDesc->Buffer.Length = Length;
> > }
> >
> >
>
> --
> ... every activity meets with opposition, everyone who acts has his
> rivals and unfortunately opponents also. But not because people want
> to be opponents, rather because the tasks and relationships force
> people to take different points of view. [Dr. Fritz Todt]
>V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: problem with fdc resource allocation
This just isn't going to work. The _CRS data stream stops at byte 0x17,
and these extra items are simply mis-aimed.
The 0x19 should really be 0x11, and the 0x1c should really be 0x14, ie.
this is a BIOS bug, and should be reported to the vendor. (It should
also have failed the Microsoft ACPI validation suite...)
The correct action should probably be to silently discard the write
operations outside of a defined buffer, and return Zeroes or Ones for a
read outside a buffer.
> Hi, I've just made a workaround for this. Intel folks, could you review
> it as always?
>
> > The problem is here, right?
> > > can't fetch resources for \\_SB_.PCI0.ISA_.FDC0 - AE_AML_BUFFER_LIMIT
> >
> > I'm sure _SB_.PCI0.ISA_.FDC0._CRS (Current Resource Settings) have some
> > problems (not sure in BIOS or ACPICA yet). I could reproduce the problem
> > which you reported. Trace attached in this mail.
> [snip]
> > dsopcode-0677 [09] DsEvalBufferFieldOpera: Field size 208 exceeds Buffer si
> ze 192 (bits)
> > PsExecute: method failed - \_SB_.PCI0.ISA_.FDC0._CRS (0x8098fa8)
> > Execution of \_SB_.PCI0.ISA_.FDC0._CRS failed with status AE_AML_BUFFER_LIM
> IT
>
> This method is like this;
> Method(_CRS) {
> Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
> 0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0,
> 0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79, 0x0
> })
> CreateByteField(BUF0, 0x2, IOLO)
> CreateByteField(BUF0, 0x3, IOHI)
> CreateByteField(BUF0, 0x4, IORL)
> CreateByteField(BUF0, 0x5, IORH)
> CreateByteField(BUF0, 0x19, IRQL)
> CreateByteField(BUF0, 0x1c, DMAV)
> Return(BUF0)
> }
>
> The problem is that this AML is trying to create a field at exceeded
> position (0x19) of the Buffer (size is 0x18).
> I couldn't find how AML interprepter treat this in ACPI Spec. so I'm
> not sure wether AWRDACPI violates the Spec. or ACPICA can have a workaround
> for this.
> Anyway, I made a patch to reallocate a large enough buffer for the
> requested operation.
>
> Thanks
>
> Index: dsopcode.c
> ===
> RCS file: /home/ncvs/src/sys/contrib/dev/acpica/dsopcode.c,v
> retrieving revision 1.1.1.10
> diff -u -r1.1.1.10 dsopcode.c
> --- dsopcode.c7 Sep 2001 01:22:24 - 1.1.1.10
> +++ dsopcode.c1 Oct 2001 18:58:41 -
> @@ -615,11 +615,24 @@
> if ((BitOffset + BitCount) >
> (8 * (UINT32) SrcDesc->Buffer.Length))
> {
> +UINT32 Length;
> +UINT8 *Pointer;
> +
> ACPI_DEBUG_PRINT ((ACPI_DB_ERROR,
> "Field size %d exceeds Buffer size %d (bits)\n",
> BitOffset + BitCount, 8 * (UINT32) SrcDesc->Buffer.Length))
> ;
> -Status = AE_AML_BUFFER_LIMIT;
> -goto Cleanup;
> +Length = ((BitOffset + BitCount) / 8) +
> + (((BitOffset + BitCount) % 8) ? 1 : 0);
> +Pointer = ACPI_MEM_CALLOCATE (Length);
> +if (!Pointer)
> +{
> +Status = AE_NO_MEMORY;
> +goto Cleanup;
> +}
> +MEMCPY (Pointer, SrcDesc->Buffer.Pointer, SrcDesc->Buffer.Length
> );
> +ACPI_MEM_FREE (SrcDesc->Buffer.Pointer);
> +SrcDesc->Buffer.Pointer = Pointer;
> +SrcDesc->Buffer.Length = Length;
> }
>
>
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: problem with fdc resource allocation
>
> Hi, I've just made a workaround for this. Intel folks, could you review
> it as always?
>
> > The problem is here, right?
> > > can't fetch resources for \\_SB_.PCI0.ISA_.FDC0 - AE_AML_BUFFER_LIMIT
> >
> > I'm sure _SB_.PCI0.ISA_.FDC0._CRS (Current Resource Settings) have some
> > problems (not sure in BIOS or ACPICA yet). I could reproduce the problem
> > which you reported. Trace attached in this mail.
> [snip]
> > dsopcode-0677 [09] DsEvalBufferFieldOpera: Field size 208 exceeds Buffer size 192
>(bits)
> > PsExecute: method failed - \_SB_.PCI0.ISA_.FDC0._CRS (0x8098fa8)
> > Execution of \_SB_.PCI0.ISA_.FDC0._CRS failed with status AE_AML_BUFFER_LIMIT
>
> This method is like this;
> Method(_CRS) {
> Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
> 0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0,
> 0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79, 0x0 })
> CreateByteField(BUF0, 0x2, IOLO)
> CreateByteField(BUF0, 0x3, IOHI)
> CreateByteField(BUF0, 0x4, IORL)
> CreateByteField(BUF0, 0x5, IORH)
> CreateByteField(BUF0, 0x19, IRQL)
> CreateByteField(BUF0, 0x1c, DMAV)
> Return(BUF0)
> }
>
> The problem is that this AML is trying to create a field at exceeded
> position (0x19) of the Buffer (size is 0x18).
> I couldn't find how AML interprepter treat this in ACPI Spec. so I'm
> not sure wether AWRDACPI violates the Spec. or ACPICA can have a workaround
> for this.
> Anyway, I made a patch to reallocate a large enough buffer for the
> requested operation.
Yes, that patch fixed the problem, thank you!
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: problem with fdc resource allocation
Hi, I've just made a workaround for this. Intel folks, could you review
it as always?
> The problem is here, right?
> > can't fetch resources for \\_SB_.PCI0.ISA_.FDC0 - AE_AML_BUFFER_LIMIT
>
> I'm sure _SB_.PCI0.ISA_.FDC0._CRS (Current Resource Settings) have some
> problems (not sure in BIOS or ACPICA yet). I could reproduce the problem
> which you reported. Trace attached in this mail.
[snip]
> dsopcode-0677 [09] DsEvalBufferFieldOpera: Field size 208 exceeds Buffer size 192
>(bits)
> PsExecute: method failed - \_SB_.PCI0.ISA_.FDC0._CRS (0x8098fa8)
> Execution of \_SB_.PCI0.ISA_.FDC0._CRS failed with status AE_AML_BUFFER_LIMIT
This method is like this;
Method(_CRS) {
Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0,
0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79, 0x0 })
CreateByteField(BUF0, 0x2, IOLO)
CreateByteField(BUF0, 0x3, IOHI)
CreateByteField(BUF0, 0x4, IORL)
CreateByteField(BUF0, 0x5, IORH)
CreateByteField(BUF0, 0x19, IRQL)
CreateByteField(BUF0, 0x1c, DMAV)
Return(BUF0)
}
The problem is that this AML is trying to create a field at exceeded
position (0x19) of the Buffer (size is 0x18).
I couldn't find how AML interprepter treat this in ACPI Spec. so I'm
not sure wether AWRDACPI violates the Spec. or ACPICA can have a workaround
for this.
Anyway, I made a patch to reallocate a large enough buffer for the
requested operation.
Thanks
Index: dsopcode.c
===
RCS file: /home/ncvs/src/sys/contrib/dev/acpica/dsopcode.c,v
retrieving revision 1.1.1.10
diff -u -r1.1.1.10 dsopcode.c
--- dsopcode.c 7 Sep 2001 01:22:24 - 1.1.1.10
+++ dsopcode.c 1 Oct 2001 18:58:41 -
@@ -615,11 +615,24 @@
if ((BitOffset + BitCount) >
(8 * (UINT32) SrcDesc->Buffer.Length))
{
+UINT32 Length;
+UINT8 *Pointer;
+
ACPI_DEBUG_PRINT ((ACPI_DB_ERROR,
"Field size %d exceeds Buffer size %d (bits)\n",
BitOffset + BitCount, 8 * (UINT32) SrcDesc->Buffer.Length));
-Status = AE_AML_BUFFER_LIMIT;
-goto Cleanup;
+Length = ((BitOffset + BitCount) / 8) +
+ (((BitOffset + BitCount) % 8) ? 1 : 0);
+Pointer = ACPI_MEM_CALLOCATE (Length);
+if (!Pointer)
+{
+Status = AE_NO_MEMORY;
+goto Cleanup;
+}
+MEMCPY (Pointer, SrcDesc->Buffer.Pointer, SrcDesc->Buffer.Length);
+ACPI_MEM_FREE (SrcDesc->Buffer.Pointer);
+SrcDesc->Buffer.Pointer = Pointer;
+SrcDesc->Buffer.Length = Length;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: problem with fdc resource allocation
Hi, > > I'm not sure exactly what's the problem you are having, but it's too > > little information to track it down... > > Could you send [EMAIL PROTECTED] ; > > - acpidump output; like > ># acpidump -o your_machine_name.dsdt > your_machine_name.dsdt.asl > > I'll add them to > > http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/?cvsroot=freebsd-jp > > - dmesg output of kernel boot -v > > Just sent it to you privately. After hiting sed button I've realised that >machine_name that > you have requested != host_name. Since it isn't a brandname model you can identify >it after > the mainboard name - Tyan-S1590. Thanks, I've just add them to http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Tyan-S1590.asl?cvsroot=freebsd-jp The problem is here, right? > can't fetch resources for \\_SB_.PCI0.ISA_.FDC0 - AE_AML_BUFFER_LIMIT I'm sure _SB_.PCI0.ISA_.FDC0._CRS (Current Resource Settings) have some problems (not sure in BIOS or ACPICA yet). I could reproduce the problem which you reported. Trace attached in this mail. I'll try to make a workaround tomorrow or next, sorry. # Here in Japan, it's midnight... Thanks % acpicadb Tyan-S1590.dsdt Parsing Methods:... 55 Control Methods found and parsed (259 nodes total) ACPI Namespace successfully loaded at root 0x8087414 - f FDC0 \_SB_.PCI0.ISA_.FDC0 (0x8098da8) - Device - debug _SB_.PCI0.ISA_.FDC0._CRS Executing \_SB_.PCI0.ISA_.FDC0._CRS 0 #0008 [00] Name BUF0 (Path \) [00] ( 5 #0011 [01] Buffer [01] ( 7 #000A [02] (UINT8) 0x18, 9 #0033 [02] ByteList (Length 0x0018) [02] } [01] } % ArgObj:0x80acfa8 Integer 0018 00021 #008C [00] CreateByteField [00] ( 00022 #002D [01] BUF0, (Path 00026 #000A [01] (UINT8) 0x02, 00028 #002D [01] IOLO (Path [01] } % ArgObj:0x80acf28 Name BUF0 Type-Buffer ArgObj:0x80af1a8 Integer 0002 ArgObj:0x80af0a8 Name IOLO Type-BuffField 0002C #008C [00] CreateByteField [00] ( 0002D #002D [01] BUF0, (Path 00031 #000A [01] (UINT8) 0x03, 00033 #002D [01] IOHI (Path [01] } % ArgObj:0x80acf28 Name BUF0 Type-Buffer ArgObj:0x80af328 Integer 0003 ArgObj:0x80af228 Name IOHI Type-BuffField 00037 #008C [00] CreateByteField [00] ( 00038 #002D [01] BUF0, (Path 0003C #000A [01] (UINT8) 0x04, 0003E #002D [01] IORL (Path [01] } % ArgObj:0x80acf28 Name BUF0 Type-Buffer ArgObj:0x80af4a8 Integer 0004 ArgObj:0x80af3a8 Name IORL Type-BuffField 00042 #008C [00] CreateByteField [00] ( 00043 #002D [01] BUF0, (Path 00047 #000A [01] (UINT8) 0x05, 00049 #002D [01] IORH (Path [01] } % ArgObj:0x80acf28 Name BUF0 Type-Buffer ArgObj:0x80af628 Integer 0005 ArgObj:0x80af528 Name IORH Type-BuffField 0004D #008C [00] CreateByteField [00] ( 0004E #002D [01] BUF0, (Path 00052 #000A [01] (UINT8) 0x19, 00054 #002D [01] IRQL (Path [01] } % ArgObj:0x80acf28 Name BUF0 Type-Buffer ArgObj:0x80af7a8 Integer 0019 ArgObj:0x80af6a8 Name IRQL Type-BuffField dsopcode-0677 [09] DsEvalBufferFieldOpera: Field size 208 exceeds Buffer size 192 (bits) PsExecute: method failed - \_SB_.PCI0.ISA_.FDC0._CRS (0x8098fa8) Execution of \_SB_.PCI0.ISA_.FDC0._CRS failed with status AE_AML_BUFFER_LIMIT To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: problem with fdc resource allocation
Mitsuru IWASAKI wrote: > Hi, > > > Maxim Sobolev wrote: > > > > > Maxim Sobolev wrote: > > > > > > > "Andrey A. Chernov" wrote: > > > > > > > > > On Mon, Sep 17, 2001 at 16:26:20 +0300, Maxim Sobolev wrote: > > > > > > Hi, > > > > > > > > > > > > Finally decided to upgrade my current box to the post-ACPI/KSE and found > > > > > > that I'm having problem with resource allocation for floppy disk >controller. > > > > > > I'm sure somebody already reported this some time ago, but the problems >seems > > > > > > still here, so I would like to see it resolved. > > > > > > > > > > > fdc0: cannot reserve I/O port range (1 ports) > > > > > > > > > > It seems that here is conflict with your device.hints, try to remove fdc > > > > > from the hints. > > > > > > > > > > As I already write, it is very bad thing that ACPI is in conflicts with > > > > > default hints file correctly describing devices used. ACPI must ignore > > > > > duplicate devices from the hints. > > > > > > > > > > The problem with floppy is harder, because floppy controller present in > > > > > ACPI but the floppy itself not present (on my motherboard at least), so > > > > > in current situation fdc0 must not be in hints, but fd0 must be, it makes > > > > > whole thing even more cryptic. > > > > > > > > Doesn't work, exactly the same problem - see attached device.hints. > > > > > > Knock, knock... Is anybody home? > > > > Hmm, it is very sad to see that acpi code is totally unsupported, especially in the > > spite of recent "how to attract people to test -current" thread. The problem is >still > > here, as of today's kernel. > > I'm not sure exactly what's the problem you are having, but it's too > little information to track it down... > Could you send [EMAIL PROTECTED] ; > - acpidump output; like ># acpidump -o your_machine_name.dsdt > your_machine_name.dsdt.asl > I'll add them to > http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/?cvsroot=freebsd-jp > - dmesg output of kernel boot -v Just sent it to you privately. After hiting sed button I've realised that machine_name that you have requested != host_name. Since it isn't a brandname model you can identify it after the mainboard name - Tyan-S1590. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: problem with fdc resource allocation
Hi, > Maxim Sobolev wrote: > > > Maxim Sobolev wrote: > > > > > "Andrey A. Chernov" wrote: > > > > > > > On Mon, Sep 17, 2001 at 16:26:20 +0300, Maxim Sobolev wrote: > > > > > Hi, > > > > > > > > > > Finally decided to upgrade my current box to the post-ACPI/KSE and found > > > > > that I'm having problem with resource allocation for floppy disk controller. > > > > > I'm sure somebody already reported this some time ago, but the problems seems > > > > > still here, so I would like to see it resolved. > > > > > > > > > fdc0: cannot reserve I/O port range (1 ports) > > > > > > > > It seems that here is conflict with your device.hints, try to remove fdc > > > > from the hints. > > > > > > > > As I already write, it is very bad thing that ACPI is in conflicts with > > > > default hints file correctly describing devices used. ACPI must ignore > > > > duplicate devices from the hints. > > > > > > > > The problem with floppy is harder, because floppy controller present in > > > > ACPI but the floppy itself not present (on my motherboard at least), so > > > > in current situation fdc0 must not be in hints, but fd0 must be, it makes > > > > whole thing even more cryptic. > > > > > > Doesn't work, exactly the same problem - see attached device.hints. > > > > Knock, knock... Is anybody home? > > Hmm, it is very sad to see that acpi code is totally unsupported, especially in the > spite of recent "how to attract people to test -current" thread. The problem is still > here, as of today's kernel. I'm not sure exactly what's the problem you are having, but it's too little information to track it down... Could you send [EMAIL PROTECTED] ; - acpidump output; like # acpidump -o your_machine_name.dsdt > your_machine_name.dsdt.asl I'll add them to http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/?cvsroot=freebsd-jp - dmesg output of kernel boot -v Mike, anything add to this? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: problem with fdc resource allocation
Maxim Sobolev wrote: > Maxim Sobolev wrote: > > > "Andrey A. Chernov" wrote: > > > > > On Mon, Sep 17, 2001 at 16:26:20 +0300, Maxim Sobolev wrote: > > > > Hi, > > > > > > > > Finally decided to upgrade my current box to the post-ACPI/KSE and found > > > > that I'm having problem with resource allocation for floppy disk controller. > > > > I'm sure somebody already reported this some time ago, but the problems seems > > > > still here, so I would like to see it resolved. > > > > > > > fdc0: cannot reserve I/O port range (1 ports) > > > > > > It seems that here is conflict with your device.hints, try to remove fdc > > > from the hints. > > > > > > As I already write, it is very bad thing that ACPI is in conflicts with > > > default hints file correctly describing devices used. ACPI must ignore > > > duplicate devices from the hints. > > > > > > The problem with floppy is harder, because floppy controller present in > > > ACPI but the floppy itself not present (on my motherboard at least), so > > > in current situation fdc0 must not be in hints, but fd0 must be, it makes > > > whole thing even more cryptic. > > > > Doesn't work, exactly the same problem - see attached device.hints. > > Knock, knock... Is anybody home? Hmm, it is very sad to see that acpi code is totally unsupported, especially in the spite of recent "how to attract people to test -current" thread. The problem is still here, as of today's kernel. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: problem with fdc resource allocation
"Andrey A. Chernov" wrote: > On Mon, Sep 17, 2001 at 16:26:20 +0300, Maxim Sobolev wrote: > > Hi, > > > > Finally decided to upgrade my current box to the post-ACPI/KSE and found > > that I'm having problem with resource allocation for floppy disk controller. > > I'm sure somebody already reported this some time ago, but the problems seems > > still here, so I would like to see it resolved. > > > fdc0: cannot reserve I/O port range (1 ports) > > It seems that here is conflict with your device.hints, try to remove fdc > from the hints. > > As I already write, it is very bad thing that ACPI is in conflicts with > default hints file correctly describing devices used. ACPI must ignore > duplicate devices from the hints. > > The problem with floppy is harder, because floppy controller present in > ACPI but the floppy itself not present (on my motherboard at least), so > in current situation fdc0 must not be in hints, but fd0 must be, it makes > whole thing even more cryptic. Doesn't work, exactly the same problem - see attached device.hints. -Maxim #hint.fdc.0.at="isa" #hint.fdc.0.port="0x3F0" #hint.fdc.0.irq="6" #hint.fdc.0.drq="2" hint.fd.0.at="fdc0" hint.fd.0.drive="0" hint.atkbdc.0.at="isa" hint.atkbdc.0.port="0x060" hint.atkbd.0.at="atkbdc" hint.atkbd.0.irq="1" hint.vga.0.at="isa" hint.sc.0.at="isa" hint.sc.0.flags="0x6" hint.npx.0.at="nexus" hint.npx.0.port="0x0F0" hint.npx.0.irq="13" hint.sio.0.at="isa" hint.sio.0.port="0x3F8" hint.sio.0.flags="0x10" hint.sio.0.irq="4" hint.sio.1.at="isa" hint.sio.1.port="0x2F8" hint.sio.1.irq="3" hint.ppc.0.at="isa" hint.ppc.0.flags="0x8" hint.ppc.0.irq="7" hint.plip.0.at="ppbus" hint.psm.0.at="atkbdc" hint.psm.0.irq="12"
Re: ACPI: problem with fdc resource allocation
On Mon, Sep 17, 2001 at 16:26:20 +0300, Maxim Sobolev wrote: > Hi, > > Finally decided to upgrade my current box to the post-ACPI/KSE and found > that I'm having problem with resource allocation for floppy disk controller. > I'm sure somebody already reported this some time ago, but the problems seems > still here, so I would like to see it resolved. > fdc0: cannot reserve I/O port range (1 ports) It seems that here is conflict with your device.hints, try to remove fdc from the hints. As I already write, it is very bad thing that ACPI is in conflicts with default hints file correctly describing devices used. ACPI must ignore duplicate devices from the hints. The problem with floppy is harder, because floppy controller present in ACPI but the floppy itself not present (on my motherboard at least), so in current situation fdc0 must not be in hints, but fd0 must be, it makes whole thing even more cryptic. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ACPI: problem with fdc resource allocation
Hi, Finally decided to upgrade my current box to the post-ACPI/KSE and found that I'm having problem with resource allocation for floppy disk controller. I'm sure somebody already reported this some time ago, but the problems seems still here, so I would like to see it resolved. Thanks! -Maxim Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #23: Mon Sep 17 16:03:59 EEST 2001 root@big_brother:/usr/src/sys/i386/compile/MBSD Timecounter "i8254" frequency 1193025 Hz CPU: AMD-K6(tm) 3D processor (501.07-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x58c Stepping = 12 Features=0x8021bf AMD Features=0x8800 real memory = 167706624 (163776K bytes) avail memory = 159588352 (155848K bytes) Preloaded elf kernel "/boot/kernel/kernel" at 0xc0346000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc03460a8. K6-family MTRR support enabled (2 registers) Using $PIR table, 6 entries at 0xc00fddf0 apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI" frequency 3579545 Hz can't fetch resources for \\_SB_.PCI0.ISA_.FDC0 - AE_AML_BUFFER_LIMIT acpi_timer0: <24-bit timer at 3.579545MHz> port 0x5008-0x500b on acpi0 acpi_button0: on acpi0 acpi_pcib0: port 0x5080-0x50ff,0x5000-0x507f,0xcf8-0xcff on acpi0 pci0: on acpi_pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xe000-0xe00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 7.2 (no driver attached) ed0: port 0xe800-0xe81f irq 9 at device 9.0 on pci0 ed0: address 00:40:05:5b:69:33, type NE2000 (16 bit) fdc0: cannot reserve I/O port range (1 ports) sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x778-0x77b,0x378-0x37f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: IEEE1284 device found /NIBBLE/ECP Probing for PnP devices on ppbus0: ppbus0: PRINTER MLC,PCL,PJL lpt0: on ppbus0 lpt0: Interrupt-driven port atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 fdc0: cannot reserve I/O port range (1 ports) psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 orm0: at iomem 0xc-0xc7fff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 fdc0: cannot reserve I/O port range (6 ports) ppc1: cannot reserve I/O port range ata2: at port 0x168-0x16f,0x36e-0x36f irq 10 on isa0 ad0: 4110MB [14848/9/63] at ata0-master UDMA33 ad1: 2014MB [4092/16/63] at ata1-master UDMA33 acd0: CDROM at ata1-slave PIO3 Mounting root from ufs:/dev/ad1s1a
ACPI problem?
After enabling ACPI in my kernel I get these messages in dmesg: ---snip--- VESA: v2.0, 2496k memory, flags:0x0, mode table:0xc03b82e2 (122) VESA: MagicGraph 256 AV 44K PRELIMINARY ACPI-0299: *** Warning: Invalid table signature found ACPI-0170: *** Error: AcpiLoadTables: Could not load RSDT: AE_BAD_SIGNATURE ACPI-0202: *** Error: AcpiLoadTables: Could not load tables: AE_BAD_SIGNATURE ACPI: table load failed: AE_BAD_SIGNATURE Using $PIR table, 6 entries at 0xc00f0f80 apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 ---snip--- (Of course the VESA and apm messages were there before...) I have a Toshiba Tecra8000 as hardware and acpidump gives me: ---snip--- RSD PTR: Checksum=18, OEMID=TOSHIB, RsdtAddress=0x07ff acpidump: RSDT is corrupted ---snip--- Drop me a line if you want me to dig deeper at stuff. DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
