On 2016/07/17 20:41, Nick Hudson wrote:
On 17-Jul-16 10:01 AM, Takahiro Hayashi wrote:
Hi,
The patch is generally good, but I'm confused by this part...
@@ -3483,12 +3606,7 @@ xhci_device_ctrl_start(struct usbd_xfer
XHCI_TRB_2_BYTES_SET(len);
control = (i
Hi,
On 2016/07/08 00:44, co...@sdf.org wrote:
hi,
my urtwn (EW-7811Un) is failing with xhci.
it still works if I use another machine which has USB2 ports on a recent
kernel (i.e. it is not a urtwn(4) problem).
in dmesg I see:
urtwn0: could not load firmware page 0
Can you try attached patch?
Hi,
On 2016/07/08 00:44, co...@sdf.org wrote:
hi,
my urtwn (EW-7811Un) is failing with xhci.
it still works if I use another machine which has USB2 ports on a recent
kernel (i.e. it is not a urtwn(4) problem).
in dmesg I see:
urtwn0: could not load firmware page 0
what's the way to get the mos
On 2016/06/30 19:45, Paul Goyette wrote:
On Thu, 30 Jun 2016, Takahiro Hayashi wrote:
Can you add these kernel options:
options DIAGNOSTIC
options USB_DEBUG
options XHCI_DEBUG
I am starting a rebuild now. I will be able to install the new kernel tomorrow.
and, set this sysctl
, set this sysctl?
hw.xhci.debug=14
however, I have no idea to see the logs without kbd.
On Mon, 27 Jun 2016, Paul Goyette wrote:
On Mon, 27 Jun 2016, Takahiro Hayashi wrote:
Hi,
On 2016/06/27 09:22, Paul Goyette wrote:
Hmmm, my system was totally idle (just running xlockmore's &qu
Hi,
On 2016/06/27 20:10, Paul Goyette wrote:
On Mon, 27 Jun 2016, Takahiro Hayashi wrote:
ddb.commandonenter may help you (a little).
What command would you like me to execute?
Ah, never mind please, you seems already have "trace".
Does syslogd write anything to /var/lo
Hi,
On 2016/06/27 19:22, Paul Goyette wrote:
On Mon, 27 Jun 2016, Takahiro Hayashi wrote:
Hi,
On 2016/06/27 09:22, Paul Goyette wrote:
Hmmm, my system was totally idle (just running xlockmore's "maze" screen
saver!), and suddenly panic()d.
Here's the traceback (
Hi,
On 2016/06/27 09:22, Paul Goyette wrote:
Hmmm, my system was totally idle (just running xlockmore's "maze" screen
saver!), and suddenly panic()d.
Here's the traceback (manually transcribed):
vpanic + 0x140
cd_play_msf
xhci_new_device + 0x821
usbd_new_device + 0x3e
uhub
Hi,
On 2016/06/04 09:34, Paul Goyette wrote:
With a kernel built from sources dated 2016-05-29 at 23:57:35 UTC, when
attaching my external hard drive (near-line backup device), I get the following
messages:
uhub0 at usb0: vendor 8086 xHCI Root Hub, class 9/0, rev 1.00/1.00, addr 0
...
Jun 4
On 2016/04/14 18:29, Takahiro Hayashi wrote:
On 2016/04/14 17:40, Nick Hudson wrote:
I summarise known problems:
+ KASSERT(sc->sc_command_addr == 0) in xhci_do_command() may fail.
+ My ASM1042 card does not work at all. No interrupts.
It works on FreeBSD and OpenBSD.
h
On 2016/04/14 17:40, Nick Hudson wrote:
I summarise known problems:
+ KASSERT(sc->sc_command_addr == 0) in xhci_do_command() may fail.
+ My ASM1042 card does not work at all. No interrupts.
It works on FreeBSD and OpenBSD.
http://nxr.netbsd.org/xref/src-freebsd/sys/dev/usb/controller/xhci.
ch has come with the patches from Takahiro
HAYASHI.
xhci(4) still needs quite a bit of love to be fully ready.
xhci(4) is still imcomplete and experimental.
It needs more work.
I summarise known problems:
+ KASSERT(sc->sc_command_addr == 0) in xhci_do_command() may fail.
+ My ASM1042 card do
2015 at 4:10 PM, Takahiro Hayashi wrote:
Hello,
Kernel panics in arptimer after detaching network interface.
See dmesg below please.
It happened on NetBSD/amd64 on GENERIC.201510182130Z from nyftp.
I think this problem looks like kern/50186.
BTW I think this problem is different from PR kern/50186.
Re
Hello,
Kernel panics in arptimer after detaching network interface.
See dmesg below please.
It happened on NetBSD/amd64 on GENERIC.201510182130Z from nyftp.
I think this problem looks like kern/50186.
How-To-Repeat:
1. Boot kernel into single user mode with "boot netbsd -s".
2. sysctl -w net.ine
Anyone interested in the patch of adding show kernhist to crash(8)?
--- src/sys/sys/kernhist.h.orig 2014-03-31 16:25:43.0 +0900
+++ src/sys/sys/kernhist.h 2015-05-09 22:32:06.0 +0900
@@ -86,7 +86,7 @@ LIST_HEAD(kern_history_head, kern_histor
#defineKERNHIST_UVMUBCH
hi,
Add tech-net@ to To:.
On 2015/04/09 21:39, Justin Cormack wrote:
On 9 April 2015 at 12:10, Kengo NAKAHARA wrote:
Hi,
On 2015/04/03 16:14, Takahiro HAYASHI wrote:
It seems that IFF_POINTTOPOINT interfaces like tun and gif cannot
receive ipv6 packets.
This occurs on NetBSD/amd64 -current
Hello,
It seems that IFF_POINTTOPOINT interfaces like tun and gif cannot
receive ipv6 packets.
This occurs on NetBSD/amd64 -current since Feb 27 2015.
For example, establishing gif tunnnel between 2 hosts.
[host1] <---> [host2]
192.168.0.1 192.168.0.2 ipv4 address of real interface
fd00::1
Hello,
I think 3.0 hub should work with this patch, but
either HS hub or SS hub in 3.0 hub may not be recognised.
still xhci is at best experimental.
Fixes:
- Fix incorrect route string was set.
Correct route string does not contain root hub port.
- Fix FS and LS devices were not recognised
On 10/12/14 12:34, I wrote:
- 3.0 hub should work, but either HS hub or SS hub in 3.0 hub
may not be recognised.
It looks one of these simultaneous interrupts is lost.
uhub_intr() drops latter interrupt while uhub is exploring
(sc_explorepending=1) for devices of former interrupt.
I trie
hi,
On 09/15/14 23:46, Ryo ONODERA wrote:
Hi,
Our xHCI USB 3.0 driver with Intel Lynx Point/Lynx Point-LP, Renesas uPD70202
and Fresco Logic 0x1b73/0x1100 xHCI chips does not support non-root hub
as following.
I believe our xHCI driver have no non-root hub support.
I have tested some USB 1.1/2
gcc points out two uninitialized variables while building current
amd64 kernel with makeoptions COPTS="-O1 -fno-omit-frame-pointer",
but does not complain about these with "-O2 -fno-omit-frame-pointer".
BTW we should check if initial values are correct.
Index: src/sys/arch/x86/x86/sys_machdep.c
(03/30/14 07:46), Hisashi T Fujinaka wrote:
On Sun, 30 Mar 2014, Takahiro HAYASHI wrote:
(03/30/14 07:21), NetBSD Test Fixture wrote:
--- task.pico ---
cc1: warnings being treated as errors
/tmp/bracket/build/2014.03.29.20.53.55-i386/src/external/bsd/bind/dist/lib/isc/task.c
(03/30/14 07:21), NetBSD Test Fixture wrote:
--- task.pico ---
cc1: warnings being treated as errors
/tmp/bracket/build/2014.03.29.20.53.55-i386/src/external/bsd/bind/dist/lib/isc/task.c:1643:1:
error: no previous prototype for 'isc__taskmgr_resume'
*** [task.pico] Error cod
(03/29/14 21:58), I wrote:
"#else" is missing in bind/dist/lib/isc/task_p.h.
I need this to run named on i486 that does not have CX8.
Thank you for fix.
--
t-hash
Hello,
"#else" is missing in bind/dist/lib/isc/task_p.h.
I need this to run named on i486 that does not have CX8.
Index: src/external/bsd/bind/dist/lib/isc/task_p.h
===
RCS file: /cvsroot/src/external/bsd/bind/dist/lib/isc/task_p.h,
Thank you for quick fix.
(03/28/14 05:19), I wrote:
files.drmkms should be fixed like following diff, or
build will fail if there are no other devices that require
i2cexec and i2c_bitbang, e.g. tl or cxdtv.
--
t-hash
files.drmkms should be fixed like following diff, or
build will fail if there are no other devices that require
i2cexec and i2c_bitbang, e.g. tl or cxdtv.
Index: src/sys/external/bsd/drm2/drm/files.drmkms
===
RCS file: /cvsroot/src/s
Hello,
On Tue, 26 Nov 2013 21:20:45 +
Mindaugas Rasiukevicius wrote:
> Thomas Klausner wrote:
> > On Tue, Nov 26, 2013 at 08:34:15PM +, Mindaugas Rasiukevicius wrote:
> > > Thomas, Takahiro: can you try with the following change?
> > >
> > > http://mail-index.netbsd.org/source-changes/
Hello,
On Tue, 5 Nov 2013 10:07:49 +
David Brownlee wrote:
> I've noticed a recent netbsd-6 xen DOM0 hanging on similar big
> compiles (firefox24/25) if run while the DOMUs are active. Possibly
> unrelated, but just as a data point.
I saw NetBSD/amd64 6.1_STABLE dom0 panics once while insta
Hello,
Thank you for your kindly explanation.
I will post ddb log in other mail as it gets quite large.
Regards,
--
t-hash
Hello,
Today I met hangup on 2 logical cpu box.
This box runs -current 2013.11.15.16.06.06 UTC with LOCKDEBUG.
I was doing ./build release for amd64 from HEAD tree
and running systat on console.
There are no network traffics other than ntp and incoming bcast/mcast.
There are no processes waiting
I happened unfortunately to meet this problem, but fortunately
entered ddb.
I was doing ./build release for amd64 on amd64 HEAD around Nov 9.
Does this give any help?
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip 80153995 cs 8 rflags 202 cr2 7f7ff7b2 ilevel
8 rsp f
Hello,
If there are Path MTU discovery blackhole router(s) between web server
and your client, such packets can be seen; server does not send
large packets but does small ones and client replies ack with SACK.
On Thu, 10 Oct 2013 14:10:13 +0200
Reinoud Zandijk wrote:
> Hi folks,
>
> i'm experi
33 matches
Mail list logo