On Wed, Dec 21, 2022 at 01:08:14PM +0100, Claudio Jeker wrote:
> In general I think finding such errors quickly would be nice.
> Is there a way to make this a compile time error? I guess that requires
> some ugly macro magic.
I agree a compile time check would be better but I don't have
a good ide
We can detect this class of error by redefining the flags to
use the high bits instead of the low ones. This way the malloc()
KMEMSTAT value check triggers because 0x1000 is greater than
the maximum type value.
I tested the following, and it boots fine, and when I moved
M_ZERO to the type fie
Does this make sense?
-m.
Index: ehci.c
===
RCS file: /var/ocvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.118
diff -u -p -r1.118 ehci.c
--- ehci.c 10 Jul 2011 17:34:53 - 1.118
+++ ehci.c 18 Sep 2011 20:11:10 -
On Thu, Sep 08, 2011 at 03:00:27AM +0200, Michael Knudsen wrote:
> if_atu.c includes kthread.h but it doesn't actually have any threads,
> so include timeout.h instead since that's what's needed (usbdi.h pulls
> in struct timeout).
>
> ohci.c uses 0 instead o
if_atu.c includes kthread.h but it doesn't actually have any threads,
so include timeout.h instead since that's what's needed (usbdi.h pulls
in struct timeout).
ohci.c uses 0 instead of NULL in a pointer assignment.
-m.
Index: if_atu.c
On Sat, Jun 11, 2011 at 07:55:25PM +0200, Ingo Schwarze wrote:
> some time ago, mk@ and matthew@ discovered a regression in security(8):
> Our rewrite killed changelist(5) wildcard support.
>
> I think we should put it back, the changelist(5) manual explicitly
> documents the feature.
I've tested
I enabled MSI for the wpi(4) in my X60:
wpi0 at pci2 dev 0 function 0 "Intel PRO/Wireless 3945ABG" rev 0x02: msi, MoW2,
address 00:13:02:9b:f4:89
It didn't blow up right away. Anyone else feel lucky?
Index: if_wpi.c
===
RCS file:
On Wed, Jun 01, 2011 at 11:13:04PM -0400, Kenneth R Westerback wrote:
> Try msi and fallback to old intr mapping. Works on my box where the
> ahci is on a non-msi bus.
Works on my X60 which has ahci on an msi bus:
luggage$ dmesg | grep ^ahci
ahci0 at pci0 dev 31 function 2 "Intel 82801GBM AHCI" r
On Sun, Mar 27, 2011 at 07:26:55PM +, Jacob Meuser wrote:
> USB_PRODUCT_MICROSOFT_LIFECAM: "Microsoft LifeCam"
I think I'm the one who added this entry, and with your diff my camera
still works:
uvideo0 at uhub0 port 5 configuration 1 interface 0 "Microsoft Microsoft
LifeCam" rev 2.00/1.01 ad
On Fri, Oct 08, 2010 at 03:10:35PM -0500, Scot Bontrager wrote:
> A less boneheaded patch. The only caller of uhci_device_setintr simply
> returns the return value upwards and it also returns USBD_NOMEM in several
> cases. So, this seems like the route of least resistance.
Perhaps that change is f
On Fri, Oct 08, 2010 at 08:11:04AM -0500, Scot Bontrager wrote:
> This allows me to use bluetooth again after the assertwaitok() cleanup.
[..]
> upipe->u.intr.npoll = npoll;
> upipe->u.intr.qhs =
> - malloc(npoll * sizeof(uhci_soft_qh_t *), M_USBHC, M_WAITOK);
> + malloc(npoll * sizeof(uhci_sof
Disestablish interrupts if attach fails and bails out. Interrupts
appear to be disabled until we no longer bail out because of errors.
Is this right?
-m.
Index: ehci_pci.c
===
RCS file: /cvs/src/sys/dev/pci/ehci_pci.c,v
retrieving
12 matches
Mail list logo
