acing the same issue).
The "normal" way of doing this is using overlays
https://mail-index.netbsd.org/port-arm/2018/12/12/msg005320.html
https://www.raspberrypi.com/documentation/computers/configuration.html#part2
Should help here.
Nick
;ll take a look.
Thanks,
Nick
Any objections / improvements to this diff to add MI boot option helper
functions?
Thanks,
Nickdiff --git a/sys/kern/subr_optstr.c b/sys/kern/subr_optstr.c
index c557dc71e341..0e7cf76d27ef 100644
--- a/sys/kern/subr_optstr.c
+++ b/sys/kern/subr_optstr.c
@@ -43,13 +43,15 @@ __KERNEL_RCSID(0, "$Ne
achdep.c
that sets and clears PSL_SE in md_flags could also be removed.
l_md is already zeroed by the memset(&l2->l_startzero, 0, ... ) calls
https://nxr.netbsd.org/search?q=l_startzero&project=src&defs=&refs=&path=&hist=
I've taken to just asserts that md_astpending is zero.
Nick
This patch adds the missing boot options.
Why not use BOOT_FLAG (as well as the get_bootconf_option for the long
format)?
Nick
On 23/04/2022 15:25, Tobias Nygren wrote:
On Sat, 23 Apr 2022 14:17:09 - (UTC)
Michael van Elst wrote:
nick.hud...@gmx.co.uk (Nick Hudson) writes:
To enable efiboot to work from Apple M1 nvme I had to apply this diff so
that libsa picks up the fs_fshift based FFS_FSBTODB.
Is this
Hi,
To enable efiboot to work from Apple M1 nvme I had to apply this diff so
that libsa picks up the fs_fshift based FFS_FSBTODB.
Is this correct or does it mean the FS has an incorrect fs_fsbtodb? (and
there's a bug in mkfs somewhere)
Thanks,
Nick
Index: sys/ufs/ffs
, &dev);
I think yes.
I have tested uhid(4) and ukbd(4). I haven't tested ucycom(4), which
uses uhidev(9) in a way that nothing else does -- to do async xfers on
the output pipe. Can anyone review and/or test ucycom(4)?
ucycom(4) works as well as it did before the change.
Nick
mistakenly
enables it thinking it will help them scan things when in reality
enabling the driver will just break scanning.
Fine by me.
Nick
d)
277 {
278 struct lwp *l = curlwp;
279
280 KERNEL_UNLOCK_ALL(l, &l->l_biglocks);
281 lwp_lock(l);
lwp_lock will raise the IPL to IPL_SCHED. spc_{lock,mutex} are used by
lwp_lock (maybe others)
HTH,
Nick
caused the mixup.
The change I referred to was
Revision 1.254.2.76 / (download) - annotate - [select for diffs], Mon
May 30 06:46:50 2016 UTC (4 years, 5 months ago) by skrll
Branch: nick-nhusb
Changes since 1.254.2.75: +181 -48 lines
Diff to previous 1.254.2.75 (colored) to branchpoint 1.254 (colored)
cular and enter
ddb / dump usbhist when it does...
I had a fix on my nick-nhusb branch that might help here, but other
updates broke it and I've not looked as to why.
Nick
hed is an MI variable for the scheduler which is
why its use in vax cpu_need_resched got removed.
End of ramblings...
Nick
, permitting braces to be consistently used:
| - Adds to clarity of intent.
| - Aids code review.
| - Avoids gotofail:
https://en.wikipedia.org/wiki/Unreachable_code#goto_fail_bug
|
| regards,
| Luke.
I was asked to CC this thread to tech-kern@, so I'm doing that.
yes please
Nick
On 16/05/2020 12:45, Kamil Rytarowski wrote:
On 16.05.2020 07:48, Nick Hudson wrote:
On 15/05/2020 17:35, Kamil Rytarowski wrote:
I propose the following patch:
http://netbsd.org/~kamil/patch-00253-refactor-vmspace-refcnt.txt
Does it look good?
Nick, does it fix the hppa locking problem
On 15/05/2020 17:35, Kamil Rytarowski wrote:
I propose the following patch:
http://netbsd.org/~kamil/patch-00253-refactor-vmspace-refcnt.txt
Does it look good?
Nick, does it fix the hppa locking problem?
Thanks for working on this.
Unfortunately, it doesn't fix all the pro
ng in xhci_endpoint.
Committed.
Thanks,
Nick
ed the LW_RUNNING flag on softclk/0 between where it is
> set (unlocked) at line 884 of kern_softint.c and callout_softclock().
Isn't it the case that softclk/0 is the victim/interrupted LWP for a
soft{serial,net,bio}.
That's certainly how I read the FP values.
the callout handler blocked and softclk/0 became a victim as well maybe?
http://src.illumos.org/source/xref/netbsd-src/sys/kern/kern_synch.c#687
a soft{serial,net,bio} happends before curlwp is changed away from the blocking
softint thread
Nick
ese diffs caused the issue. I have some
changes to ohci aborting on nhusb which I'll try and fixup when this
diff goes in.
Thanks,
Nick
you if dwc_gmac interrupts are being distributed to
both cpus? I think we need to prevent or protect against this.
Nick
ling the spin lock, and it looks
like it's itself waiting for a mutex.
Now I have to find why "mach cpu 1" hangs, and how to avoid it ...
The kdb_trap code is racey and needs to look more like the mips version.
Feel free to beat me to fixing it.
Nick
1:
db{0}> mach cpu 1
kdb_trap: switching to cpu1
Stopped in pid 26110.1 (gcc) at netbsd:_kernel_lock+0xc4:
Maybe you can get it by looking for the lwp on the other cpu using ps/l
and using bt/a?
Nick
On 15/02/2019 13:44, Rin Okuyama wrote:
On 2019/02/15 21:57, Jonathan A. Kollasch wrote:
On Wed, Feb 13, 2019 at 06:35:14PM +0900, Rin Okuyama wrote:
Hi,
On 2019/02/13 3:54, Nick Hudson wrote:
On 12/02/2019 16:02, Rin Okuyama wrote:
Hi,
The system freezes indefinitely with xhci(4) or ehci
te loop in
usbd_ar_pipe(); xfers with USBD_NOT_STARTED remain in a queue forever
because upm_abort [= xhci_device_bulk_abort() etc.] cannot remove them.
Why not the attached patch instead?
Nick
? sys/dev/usb/cscope.out
Index: sys/dev/u
7;s a bug). An ECHI_DEBUG/ehcidebug=1
log when it happens would be interesting.
Thanks,
Nick
Index: sys/dev/usb/ehci.c
===
RCS file: /cvsroot/src/sys/dev/usb/ehci.c,v
retrieving revision 1.265
diff -u -p -r1.265 ehci.c
--- sys
)
}
}
- if (ic != NULL)
+ if (ic == NULL)
panic("%s: interrupt handle not valid", __func__);
return ic->ic_funcs->disestablish(ic->ic_dev, cookie);
Fixed.
Thanks,
Nick
usbd_probe_and_attach#2@1: port 5, set config at addr 2 failed, er
ror=4
Any hint?
Can you make the trace available somewhere, please?
Nick
ion in usbd_get_desc() and inject
fake descriptors (see below), the device is correctly attached
on reboot, and it works again. Is it an acceptable workaround?
[snip]
Isn't there a way to reset it?
Doesn't the hub power the port down? The bug is probably in uhub.c
christos
Nick
;locking against myself");
546
2. owned by a different owner, which is NOT running
Is this still a possibility given the above?
Nick
On 12/19/17 08:21, Ryota Ozaki wrote:
On Tue, Dec 19, 2017 at 4:52 PM, Nick Hudson wrote:
On 19/12/2017 03:43, Ryota Ozaki wrote:
BTW I committed a change that disables IFEF_MPSAFE by default on
all interfaces because it seems that IFEF_MPSAFE requires additional
changes to work safely with
On 12/20/17 12:18, Sprow wrote:
In article <3ef1728a-54fb-6c89-5634-e39ca9808...@netbsd.org>,
Nick Hudson wrote:
How so?
It used to read
#define IS_TTHUB(dd) \
((dd)->bDeviceProtocol == UDPROTO_HSHUBSTT || \
(dd)->bDeviceProtocol == UDPROTO_HSHUBMTT)
th
On 12/19/17 20:32, Sprow wrote:
In article <5fc73ccd-26a2-7919-17e3-8098ccb3f...@netbsd.org>,
Nick Hudson wrote:
On 12/17/17 10:40, Nick Hudson wrote:
On 12/08/17 18:25, Sprow wrote:
I've been having a look on a USB analyser at a class of hubs that
don't seem to work on a
On 12/17/17 10:40, Nick Hudson wrote:
On 12/08/17 18:25, Sprow wrote:
Hi,
I've been having a look on a USB analyser at a class of hubs that
don't seem
to work on a driver based on
src/sys/dev/usb/xhci.c
Comparing the dialogue for a non XHCI controller I see the issue is
that t
additional changes?
Thanks,
Nick
ecking the
adjacent hub (5 in my example). As a result the expression evaluates to false
and the ttportnum & tthubslot are 0, which blocks the controller from routing
the GetDescriptor properly.
I didn't look too closely yet, but I'm pretty sure the upstream HS hub
is required here as you stated.
Nick
On 14/12/2017 10:48, Ryota Ozaki wrote:
On Fri, Dec 8, 2017 at 7:53 PM, Nick Hudson wrote:
Not sure I follow this. I think we agree that the driver should not use
if_flags in the rx/tx path (anymore).
Yes. Drivers should provide their own method.
Great.
Anyway I updated the document
On 12/06/17 11:11, Ryota Ozaki wrote:
On Tue, Nov 28, 2017 at 6:40 PM, Ryota Ozaki wrote:
On Mon, Nov 27, 2017 at 12:24 AM, Nick Hudson wrote:
On 11/17/17 07:44, Ryota Ozaki wrote:
[snip]
Hi,
(Sorry for late replying. I was sick in bed for days...)
Can you document the protection
On 12/08/17 09:04, Nick Hudson wrote:
On 12/08/17 03:26, Mouse wrote:
[Brian Buhrow]
1. [...]. Mutexes that use spin locks can't be used in interrupt
context.
Sure you don't have that backwards? I _think_ mutex(9) says that spin
mutexes are the only ones that _can_ be us
kwards. To quote mutex(9)...
IPL_VM, IPL_SCHED, IPL_HIGH
A spin mutex will be returned. Spin mutexes provide
mutual
exclusion between LWPs, and between LWPs and interrupt
handlers.
Nick
macros:
http://www.netbsd.org/~ozaki-r/if_ioctl-no-KERNEL_LOCK.revised.diff
ozaki-r
Hi,
Can you document the protection requirements of the struct ifnet
members, e.g. if_flags.
Ideally by annotating it like struct proc
http://src.illumos.org/source/xref/netbsd-src/sys/sys/proc.h#230
Thanks,
Nick
, uintptr_t, uintptr_t *);
int kobj_reloc(kobj_t, uintptr_t, const void *, bool, bool);
int kobj_machdep(kobj_t, void *, size_t, bool);
This broke the arm builds
Why uintptr_t * and not Elf_Addr *?
Nick
going on like cvs
updates and compiling.
Does anyone who might know what's been fixed know if the changes are
going to be pulled in to -8?
There are no changes in sys/dev/usb worth note. Maybe git bisect to find
out what fixed it?
Nick
On 12/12/16 09:55, J. Hannken-Illjes wrote:
On 11 Dec 2016, at 22:33, Nick Hudson wrote:
On 12/11/16 21:05, J. Hannken-Illjes wrote:
On 11 Dec 2016, at 21:01, David Holland wrote:
On a low-memory machine Nick ran into the following deadlock:
(a) rename -> vrele on child -> in
On 12/11/16 21:05, J. Hannken-Illjes wrote:
On 11 Dec 2016, at 21:01, David Holland wrote:
On a low-memory machine Nick ran into the following deadlock:
(a) rename -> vrele on child -> inactive -> truncate -> getblk ->
no memory in buffer pool -> wait for syncer
On 09/28/16 16:13, Rin Okuyama wrote:
On 2016/09/28 20:40, Nick Hudson wrote:
[snip]
if the mapping changes PA then the resident_count gets reduced by
pmap_{,pte_}remove, but not increased again.
I'm working on a fix.
Thank you very much for your analysis. I'm looking
ges PA then the resident_count gets reduced by
pmap_{,pte_}remove, but not increased again.
I'm working on a fix.
Nick
ot;, line 628
kernel: breakpoint trap
Stopped in pid 2328.1 (sed) at netbsd:cpu_Debugger+0x4: jr ra
bdslot: nop
Matt fixed it with src/sys/uvm/pmap/pmap.c:1.22
Nick
On 08/09/16 11:09, Takahiro Hayashi wrote:
Hello,
I'll post xhci patches for HEAD.
x-addrendian.diff
+ Fix endian issue of device address.
x-linktrb2.diff
+ Put Link TRB always at the end of ring.
Should fix ctrl xfer problem on Intel xHC.
Thanks,
Committed.
Thanks,
Nick
).
src/sys/arch/mips/mips/spl.S:1.11 helps in most places.
My cobalt (real hw) still has a problem here.
Martin
Nick
ll rights reserved.
NetBSD 7.99.34 (GENERIC) #8: Thu Jul 14 06:19:34 BST 2016
nick@
16K page kernel, the problem
will go away -- though I'll lose a little bit of efficiency?
yes.
That said, I think the pmap deals with virtual cache aliasing correctly now.
Thor
Nick
On 05/11/16 11:52, Kimihiro Nonaka wrote:
2016-05-11 15:41 GMT+09:00 Nick Hudson:
I'd be happy (as a tegra owner/user) to move hdmicec to 206. I don't think
hdmicec is use anywhere else yet.
char 206 is already used by seeprom.
- sys/conf/majors
device-major seeprom char 2
char 260com
-
Regards,
I'd be happy (as a tegra owner/user) to move hdmicec to 206. I don't
think hdmicec is use anywhere else yet.
Anyone else have an opinion?
NIck
nected
every
several minutes repeatedly.
ENOHARDWARE
regards,
--
t-hash
Thanks,
Nick
On 04/13/16 11:58, Dave Tyson wrote:
On Wednesday 13 Apr 2016 07:59:20 Nick Hudson wrote:
Hi,
I think the first phase of nick-nhusb is in a state ready to be
merged. I'd like to merge it in the next few days, but in the meantime
I've put some kernels for testing here:
On 04/13/16 08:15, Paul Goyette wrote:
On Wed, 13 Apr 2016, Nick Hudson wrote:
Hi,
I think the first phase of nick-nhusb is in a state ready to be
merged. I'd like to merge it in the next few days, but in the meantime
I've put some kernels for testing here:
http://www.netbsd.
On 04/13/16 08:05, Taylor R Campbell wrote:
Date: Wed, 13 Apr 2016 07:59:20 +0100
From: Nick Hudson
I think the first phase of nick-nhusb is in a state ready to be
merged. I'd like to merge it in the next few days, but in the meantime
I've put some kernels for te
Hi,
I think the first phase of nick-nhusb is in a state ready to be
merged. I'd like to merge it in the next few days, but in the meantime
I've put some kernels for testing here:
http://www.netbsd.org/~skrll/nick-nhusb
Please test and report success or failure.
I can provide
On 04/04/16 08:45, Nick Hudson wrote:
On 04/04/16 05:25, Brian Buhrow wrote:
hello. I did a lot of work on this under NetBSD-5 to allow the
libimobiledevice tools to work with iOS based Apple devices. I have
some
simple patches for libusb1 and a re-working of the ugen(4) driver to
nks
-Brian
Thanks,
Nick
27;t know how to get level. Is there API?).
There isn't an API afaik.
ozaki-r
Nick
little guidance on what's going on. I'll
continue to poke at it as well, but another set of eyes looking at the
issue would be much appreciated.
I see the bug(s) and will try and cook up diffs soon. They'll be against
-current, though
-thanks
-Brian
Nick
On 01/20/16 16:16, Frank Zerangue wrote:
Thanks Nick,
Here are the pertinent options in my kernel config:
options CPU_ARM1136 # Support the ARM1136 core
options CPU_ARM11 # Support the ARM11 core
options FPU_VFP
callbacks to run at IPL_SOFTSERIAL really means that the
USB callbacks should be re-checked that they provide the right protection
when calling into the subsystems they access.
Let me know if the patch fixes things for you.
Thanks,
Nick
On 27/12/2015 20:00, Brian Buhrow wrote:
hello Nick. I've been doing this work under NetBSD-5 and the ehci(4)
driver definitely doesn't behave well when sent a zero-length packet under
that branch.
Define "doesn't behave well"
I also checked out your U
ally, the chain allocators get
confused about the fact that the lengths of the xfer are zero.
send-pr please.
Hopefully I've fixed these on my branch.
Nick
On 12/06/15 16:01, Taylor R Campbell wrote:
Date: Sun, 6 Dec 2015 09:22:05 +
From: Nick Hudson
It seems to me that nd6_timer is either expecting too much of
the USB stack by expecting a synchronous interface to changing
multicast filters that doesn't sleep; or th
m CPU N
and schedules softint process (at IPL_SOFTNET) which never runs as the lwp
is blocked in step 3)
Maybe
290 #define IPL_SOFTUSB IPL_SOFTNET
http://nxr.netbsd.org/xref/src/sys/dev/usb/usbdi.h#290
should be changed to IPL_SOFTBIO?
Thoughts?
Nick
ers to be 16384 bytes in length. Our USB
system seems to prefer breaking these down into 1024 byte transfers. My
question is this:
USB transfers can be greater than 1024.
http://nxr.netbsd.org/search?q=UGEN_BBSIZE&project=src
I think we should look to other ugen drivers to make sure we behave
similarly
Nick
zero length packets. Re-reading what Nick wrote on this thread about
USB writes consisting of USB transactions on the bus, I think this means you
just initiate a transfer to the device in question with no payload. I
believe I know how to do this from within the ugen(4) driver itself, and I
ha
k for you?
There are almost certainly other KASSERTs that need adapting to polling.
Nick
drivers are a little inconsistent in their handling
of the
USBD_SHORT_XFER flag, but without it a short transfer will always
result in a callback status of USBD_SHORT_XFER
http://nxr.netbsd.org/xref/src/sys/dev/usb/usbdi.c#883
Nick
´m not an USB guy so I don´t really understand what this all is. I
hope someone can fix this.
cvs update and try again. The locking is not required when polling.
Nick
On 09/24/15 15:52, Brian Buhrow wrote:
On Sep 24, 12:00pm, Nick Hudson wrote:
} Are you sure about this? I'm not sure why ugen_bulkra_intr doesn't start
} a new transfer, but see below.
}
} I wonder if
}
} http://nxr.netbsd.org/xref/src/sys/dev/usb/ugen.c#697
}
n.c#697
http://nxr.netbsd.org/xref/src/sys/dev/usb/ugen.c#1221
needs USBD_SHORT_XFER_OK adding to the flags arg.
UGEN_DEBUG output will help?
Nick
On 09/11/15 11:07, Takahiro Hayashi wrote:
Hello,
Here is xhci patches for nick-nhusb branch.
nhusb-xhci-lock.diff
+ Fix lock error. Same as
https://mail-index.netbsd.org/tech-kern/2015/07/15/msg019170.html
nhusb-xhci-evh.diff
+ Split xhci_handle_event() into 3 functions
On 09/11/15 11:07, Takahiro Hayashi wrote:
Hello,
Here is xhci patches for nick-nhusb branch.
I'll look into this.
nhusb-xhci-lock.diff
+ Fix lock error. Same as
https://mail-index.netbsd.org/tech-kern/2015/07/15/msg019170.html
iirc, I wanted to do this differently
nhusb
is a regression in WAPBL. Can you tell me
how I can extract a kernel for the Pi using objdump, so I can conduct some
experimentation?
What do you want to do with objdump?
Nick
is causing this misbehavior. And a freeze is
rather annoying for a node that is mainly supposed to be administrated
from remote...
TIA,
Can you try netbsd-7 or better still -current?
Thanks,
Nick
can be useful, sometime you get a computer model where
it crashes. The only workaround I see is to build with
MEMORY_DISK_RBFLAGS=0x1000 # RB_AUTOBOOT | RB_MD1
This is how you're supposed to do it, I believe. The boot loader helps
as well.
Nick
On 06/23/15 07:43, takahiro hayashi wrote:
Hello,
Here is xhci patch for nick-nhusb branch.
nh-xhci-check.diff
+ Add port range check in xhci_rhpsc().
+ Add sanity check if xfer->ux_pipe != NULL in xhci_handle_event().
nh-xhci-prc.diff
+ Remove SET_FEATURE C_PORT_RESET(
On 06/07/15 14:33, takahiro hayashi wrote:
Hi,
On 2015/06/07 19:50, Nick Hudson wrote:
On 06/06/15 05:39, takahiro hayashi wrote:
Hello,
On nick-nhusb branch kernel panics in usbd_transfer() when the
zero-length request gets stalled.
This happens when the uhidev driver issues usbd_set_idle
On 06/06/15 05:39, takahiro hayashi wrote:
Hello,
On nick-nhusb branch kernel panics in usbd_transfer() when the
zero-length request gets stalled.
This happens when the uhidev driver issues usbd_set_idle to my
USB keyboard, one of its uhidevs returns stall for SET_IDLE request.
While
On 06/06/15 18:51, takahiro hayashi wrote:
On 2015/06/07 01:51, takahiro hayashi wrote:
On 2015/06/07 01:39, Nick Hudson wrote:
I don't think XHCI_* defines should appear in usb.h.
Oh that's my fault.
I'll fix it...
New diff of usb.h attached.
Thanks.
All committed now.
Nick
FTOUT(x,
__BITS(31,16))
} UPACKED usb_devcap_ssp_descriptor_t;
#define USB_DEVCAP_SSP_DESCRIPTOR_SIZE 12 /* variable length */
I don't think XHCI_* defines should appear in usb.h.
Nick
On 04/06/15 00:15, Takahiro HAYASHI wrote:
Hello,
On 2015/04/02 21:10, Nick Hudson wrote:
On 03/24/15 13:30, Robert Sprowson wrote:
b) some experimental USB 3 work that might break it for some people,
this
should probably be on a private branch
I'm happy to do this on my nick-
On 04/04/15 16:15, Nick Hudson wrote:
On 04/04/15 10:12, Maxime Villard wrote:
Hi,
here is a new list of 11 potential bugs:
http://m00nbsd.net/ae123a9bae03f7dde5c6d654412daf5a.html#Report-5
Please carefully test/investigate these bugs before fixing them. Also,
please include the keyword
essages so that I
can easily keep track of what is/isn't fixed - or send me a mail directly.
The sys/dev/usb/umass_isdata.c report looks like a false +ve to me.
Found by The Brainy Code Scanner.
Regards,
Maxime
Nick
e people, this
should probably be on a private branch
I'm happy to do this on my nick-nhusb branch, but maybe this isn't what
you want.
c) some port specific tweaks for Intel chipsets, which should probably be
compile time bracketed or taken out with quirks on other ports
On 10/31/14 03:59, Takahiro HAYASHI wrote:
hello,
This patch tries to support 3.0 hubs for xhci.
still xhci is at best experimental.
Thanks for working on this. Are you tracking other BSDs?
Can you update the diff to -current?
Thanks,
Nick
side of this is that build uses more disk space. I mean to
compensate that by making kernel build share objects in the long run,
but it will take Long Time...
Another downside is that you're going to break quite a few kernels that
rely on linker scripts.
Nick
On 08/12/14 17:20, Takahiro HAYASHI wrote:
On 08/12/14 23:07, Nick Hudson wrote:
On 08/12/14 10:42, Takahiro HAYASHI wrote:
On 08/12/14 07:45, Takahiro HAYASHI wrote:
Please send diff :)
Wait for a while plz.
lessprf.diff
replaces most of device_printf.
I define new macros DPRINTD and
Hello,
I am new to NetBSD and would like to see if there is any chance that I
could find something related to file system to work on (I am working on
networking/platform SW full-time)
Are these two projects already complete or been taken care of by people?
Those look like a good entry point to th
On 08/12/14 15:07, Nick Hudson wrote:
On 08/12/14 10:42, Takahiro HAYASHI wrote:
I'll dump my local misc patches too.
usb3.diff
tries to make usb stack recognize super speed and
make usbdevs(8) print super speed.
This patch also adds XHCI_DEBUG flag to opt_usb.h.
I committed mo
evice.
http://mail-index.netbsd.org/source-changes/2013/03/20/msg042367.html
Committed.
Thanks,
Nick
On 08/10/14 12:54, Takahiro HAYASHI wrote:
Hi,
Hi,
On 08/10/14 17:06, Nick Hudson wrote:
Some comments...
@@ -2889,6 +3028,7 @@ xhci_timeout(void *addr)
struct xhci_softc * const sc =
xfer->pipe->device->bus->hci_private;
if (sc->sc_dying) {
+xhci_
t xhci_softc * const sc = xfer->pipe->device->bus->hci_private;
if (sc->sc_dying) {
+ xhci_abort_xfer(xfer, USBD_TIMEOUT);
return;
}
This looks very strange.
The driver makes far too much use of device_printf and all USB should
move to KERNHIST.
Nick
uctures
is detected. These checks can decrease performance up to 15%.
I'd guess that KMEM_REDZONE add much less than 15%.
Nick
oesn't look like that usb_frag_freelist isn't
protected correctly. I looks more like random corruption. What was the
value of %edx?
Thanks,
Nick
dump -d or nm -n or gdb or whatever to find the code
that's at 0x8031162f in your kernel, you'll probably get a
fairly good idea of what broke.
backtrace is always useful as well.
Nick
1 - 100 of 106 matches
Mail list logo
