Re: regression (crash) in sysmon/acpiacad
On Fri, 5 Feb 2010, Matthias Drochner wrote: p...@whooppee.com said: Regarding the earlier comment about your battery charge level not changing... Is this still true? Just checked again and found that the charge level is updated now, but only every 30s. (The code in acpibat_refresh() suggests that cached values are kept only for 5s, and I believe that is how it did behave formerly.) The 30-second timer is the default poll interval for sysmon_envsys, so we're calling the refresh routine on that basis. I'm not totally up to speed on the acpibat internal stuff, so I don't know if it should be getting updated more frequently. I definitely watched the battery state for a couple of minutes yesterday, so something else must have happened. Looking at acpibat_refresh()... the 5-seconds check uses microtime() which is not necessarily monotonic. And, iirc, I had booted Windows before, which sets the RTC to GMT+1, so I had to force the clock back by a manual ntpdate. This might have killed status updating. Well, just a hypothesis, but I'd suggest to use getmicrouptime() for these checks. Yeah, good point. - | Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Kernel loadable modules and missing symbols
Hi, A kernel loadable module suggestion from me: It would be nice if missing symbols could be printed to dmesg when loading modules under NetBSD 5.x. This helps debugging problems. --HPS
Re: uticom(4)
On Fri, Feb 05, 2010 at 12:13:01AM +0200, Yorick Hardy wrote: I think uticom(4) is now ready for comment. The source for uticom(4) is available at ftp://ftp.NetBSD.org/pub/NetBSD/misc/yhardy/uticom20100204.tar.bz2 (extract in src/) and the additional changes to src at ftp://ftp.NetBSD.org/pub/NetBSD/misc/yhardy/uticom.diff This is not a port of OpenBSD uticom(4), nor of the Linux driver. This driver uses different firmware from the OpenBSD and Linux drivers. *NICE*, our own firmware, and sufficent docs (and compilers) to modify it are public it looks like. Where do i get one of these devices? (Says the person with 5+ uplcom(4)s he doesn't use.) The driver uses a header file (src/sys/dev/microcode/uticom/tusb3410fw.h) for the firmware. The firmware is about 5KB. firmload(9) will be used if UTICOM_TUSB3410FW_H is undefined in src/sys/dev/usb/uticom.h (line 68). There's not much point in putting the firmware in the kernel by default until we have console-on-ucom(4) support. I encountered a problem with uhci_open (probably also ehci). uhci_open sets nexttoggle to zero (src/sys/dev/usb/uhci.c line 3186) on every pipe open. However, the device endpoint toggle will not reset to zero. Since ucomopen seems to open the pipes for the bulk endpoints, this means the device bulk endpoint toggle may differ from the pipe's nexttoggle on every open. I worked around the problem by clearing the halt feature on the bulk endpoints which resets the data toggle to zero, but this should not be necessary. Oh, that must be the problem I was having with my AVRISP mkII. It should be fixed where appropriate (in the host controller driver). Jonathan Kollasch
Re: Interrupt problems on NetBSD/i386 5.0.1
hello. What happens if you boot without acpi? (boot -2)
This looks like a problem similar to one I had with my Dell laptop. I
filed a pr about it. See below.
Does this help?
-Brian
Hello. Well, it turns out that there isn't a fix in the BIOS for this
problem, but I was able to whip up a quick patch which I've submitted as
kern/37538, which allows me to use both the sound and wireless cards at
full speed with ACPI enabled.
The problem is that while the BIOS properly routes the interrupt for
these two devices, it doesn't actually report that the interrupt is valid
for these devices in its table. So, when NetBSD tries to verify the
verasity of the interrupts, it can't, and so it tries to reroute the
interrupts to other irq's, with less than satisfactory results. With this
patch, you can add
options ACPI_BELIEVE_BIOS
to your kernel config, and the kernel will just assume that what the BIOS
says is true is accurate with respect to irq assignments.
I am by no means an ACPI expert, so if there's abetter way to achieve
this result, I'm all for it. However, if not, then I'd like to see this
patch incorporated into the tree for NetBSD-4 and beyond, sinceI've
verified that the problem persists all the way through today's -current
sources.
The complete bug report is available on the bug query web page, but
I'll include the patch below, since it's so short.
Comments?
-thanks
-Brian
Index: acpi_pci_link.c
===
RCS file: /cvsroot/src/sys/dev/acpi/acpi_pci_link.c,v
retrieving revision 1.7
diff -u -r1.7 acpi_pci_link.c
--- acpi_pci_link.c 24 Sep 2006 06:03:20 - 1.7
+++ acpi_pci_link.c 14 Dec 2007 06:03:25 -
@@ -369,6 +369,17 @@
{
int i;
+#ifdef ACPI_BELIEVE_BIOS
+ /*
+*Some BIOS's route the interrupts correctly for the devices
+*they configure, but don't report that those interrupts are valid in
+*their interrupt table. If this option is true, assume the BIOS
+*did the right thing, and always return valid.
+*Fixes interrupt problems with ACPI and the Dell D400 laptop
+*/
+ return(TRUE);
+#endif
+
/* Invalid interrupts are never valid. */
if (!PCI_INTERRUPT_VALID(irq))
return (FALSE);
