enerated in
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/installboot/util.c?rev=1.11&content-type=text/x-cvsweb-markup
.
Thanks,
Tinker
1
FS type: [4.2BSD]
Rounding size to bsize (32 sectors): 0
>
Tinker
/doc/
Normally OpenBSD man pages link by .Xr and the unbound man pages don't.
Tinker
LSO section also?
https://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/driver/xf86-video-dummy/
https://marc.info/?t=15187399242&r=1&w=2
https://marc.info/?t=15223071333&r=1&w=2
https://marc.info/?l=openbsd-misc&m=152233592922216&w=2
http://man.openbsd.org/void.4
http://man.openbsd.org/xorg.conf.5#SEE_ALSO
Tinker
e that the USB 3 stack separately is unstable, and maybe
also only supports the 1gbps mode, not 5gpbs superspeed.)
Tinker
‐‐‐ Original Message ‐‐‐
On July 27, 2018 5:14 PM, Denis wrote:
> Every time (after 2-3 minutes of work) ASIX Electronics USB-Ethernet
> device reports:
>
&g
to anyone who wants to
have a look!
Second, re superspeed mode:
stsp@ pointed out about a year ago that the XHCI driver only supports,
I think it is, 1gbps aggregate speed per USB hub presently, 5gbps aka
"superspeed".
This might not be a very high priority, maybe except on some chea
On July 28, 2018 1:21 AM, Tinker wrote:
> Hi Marcus,
>
> Thank you for following up.
>
> First re any XHCI bugs:
..
> Second, re superspeed mode:
>
> stsp@ pointed out about a year ago that the XHCI driver only supports,
> I think it is, 1gbps aggregate speed per U
On August 9, 2018 1:39 PM, sc dying wrote:
> Hi,
>
> On Wed, Aug 8, 2018 at 9:24 AM, Denis den...@mindall.org wrote:
>
> > Hi,
> > Using second diff applied to 6.3 sources and rebuilt kernel.
> > The issue is persistent + new kernel error message:
> > checksum err (pkt#1)
> > axen0: usb errors on
egdb doesn't behave like this though.
$ gdb myprogram myprogram.core
[some output]
Reading symbols from
/usr/local/lib/libMYLIBRARY.so.0.0.../usr/src/gnu/usr.bin/binutils/gdb/dwarf2read.c:5447:
internal-error: could not find partial DIE in cache
A problem internal to GDB has been detected,
fu
I set up a bioctl keydisk-encrypted disk (keydisk + encrypted partition
on same physical disk as per previous patch).
Then, I did "fdisk -iy wd0; reboot". On a QEMU-simulated AMD64, this
gave me the output below.
Of course this was "unclean" behavior from my side but nonetheless that
should
bioctl's error message "Invalid metadata" for when you try to use a
non-RAID disklabel partition is too unclear.
Could easily spend a day not figuring out.
Kindly add something like " (is the disklabel partition not of type
RAID?)" to that error message, as the user easily could think that
"m
r argument changes the resolution to
the respective setting.
Thanks,
Tinker
On February 15, 2018 4:57 PM, Tinker wrote:
>Hi,
..
> - Do "bioctl -c C -r 8192 -l /dev/sd0a softraid0", type the password
(And this creates sd2.)
> - Run "/install". When asked about device to install on, choose "sd2".
The specific interaction is:
Avail
to remove the EFI partition and
reallocate that space to use.
This bug applies on OpenBSD 6.2 and I think I saw it in 6.0 or 6.1 also.
Thanks,
Tinker
Hi,
http://man.openbsd.org/dhclient.8 says:
"It does this only when one or both of the options domain-name and
domain-name-servers is present".
To the best of my grammar awareness, it should rather be "are present".
Tinker
Which maybe brings us back to the place where the original wording,
updated with "are", reads better.
"It does this only when one or both of the options domain-name and
domain-name-servers are present"
Someone else decide and update please, these were my only five ce
d be happy to provide any additional infos as needed to help nail
the bug.
Thanks,
Tinker
talled
and newly booted Xeon ECC device.
Find attached JPEG photos of the kernel panic screen from two instances
of the crash, with unlimited storage duration:
http://picpaste.com/First_time-YnkuJoTg.jpg
http://picpaste.com/Second_time-GIGO4Xvh.jpg .
Tinker
After rebooting the machine (now in ordinary softdep mode, and fsck did
its job), I tried to do "rm -rf /home/lost+found", and got "ffs_blkfree:
freeing free block".
Find photo of panic screen attached here, with indefinite storage:
http://picpaste.com/Crash-0Lj3JJ2r.jpg .
I'm not so freaked
On 2017-02-03 21:03, Stefan Sperling wrote:
On Fri, Feb 03, 2017 at 08:03:09PM +0800, Tinker wrote:
Hi,
I have a OpenBSD 6.0 GENERIC.MP system set up as follows:
* sd0 is a physical harddrive. It has a "b" partition for swap, and
an "a"
partition for a softraid. The sof
On 2017-02-03 21:58, Stefan Sperling wrote:
On Fri, Feb 03, 2017 at 09:10:41PM +0800, Tinker wrote:
On 2017-02-03 21:03, Stefan Sperling wrote:
> On Fri, Feb 03, 2017 at 08:03:09PM +0800, Tinker wrote:
> > Hi,
> >
> > I have a OpenBSD 6.0 GENERIC.MP system set up as follows
On 2017-02-04 03:57, Philip Guenther wrote:
On Fri, 3 Feb 2017, Tinker wrote:
After rebooting the machine (now in ordinary softdep mode, and fsck
did
its job), I tried to do "rm -rf /home/lost+found", and got
"ffs_blkfree:
freeing free block".
...
I'm not so fre
mp on swap
drive, would be:
How large should the swap drive be to accomodate any such coredump - the
same size as the physical RAM of the machine, or less, or more?
(Unimportant followup questions to Philip below.)
Thanks,
Tinker
On 2017-02-04 01:10, Sebastien Marie wrote:
[..]
Just comm
lled "Modeling" there, so please add an "o".
(Also why the "###-->" and "<-###" in "* ###--> it is unknown to the
processes generating the input entropy. <-###", though that is probably
intended, even if the meaning not is apparent to me.)
Tinker
The ure(4) man page in current ( http://man.openbsd.org/ure.4 ) says
that its for the "RealTek RTL8152/RTL8153 10/100/Gigabit USB Ethernet
device".
The usb(4) man page in current ( http://man.openbsd.org/usb.4 ) says
"RealTek RTL8152 10/100 USB Ethernet device" however.
This must be a tiny g
;axen: " or alike, to decrease any
risk for user freak-out over it -or, maybe even more relevant would be
to disable it altogether - I guess the other NIC drivers simply silently
ignore any broken-checksum frames they receive?
Thanks,
Tinker
On 2017-04-05 08:48, Stefan Sperling wrote:
..
Yes, some cleanup is due here.
I suggest you send us a patch that makes it a DPRINTF. You could also
add
a line ifp->if_ierrors++;' at the same place so the error is counted
in
netstat -I axen0.
And there are some similar printfs in the same fu
ough.
Any thoughts on how fix would be much appreciated.
If I see this happen again maybe I will be able to go into the kernel
console and force a kernel stack dump.
Thanks,
Tinker
evice, in particular in
combinations of devices (USB controller + axen), so maybe this was just
like the exception that proves the rule.
I didn't see any problems whatsoever with the RTL8153 though.
Thanks,
Tinker
On 2017-04-05 16:40, Tinker wrote:
Hi,
On OpenBSD 6.0 AMD64, I ran this axe
not. (And then the system
froze.)
Is there any way that I could cause a "harder" reset, in that code, or
via command line utilities?
Tinker
On 2017-04-17 01:57, Tinker wrote:
Hi Stefan/bugs@,
(This one is also intended as followup on the
https://marc.info/?t=14913742153&
dex 6 priority 0 llprio 3
media: Ethernet autoselect (10baseT half-duplex)
(The "media:" would eventually automatically switch to "Ethernet
autoselect (1000baseT full-duplex)".)
I haven't really pushed or benchmarked it, but I have seen 130mbps
throughput
Thanks,
Tinker
On 2017-04-17 07:43, Stefan Sperling wrote:
On Mon, Apr 17, 2017 at 02:03:02AM +, Tinker wrote:
And "ifconfig axen0 down" + ".. up" also did not. (And then the system
froze.)
While the system is frozen in X, does the system reboot if you type:
bo re
If you trigger
donate this AXEN to a developer, please let me know postal address
* I/anyone try this AXEN on another device
* I could try to reduce the case further by also removing the CDCE
device (an USB RTL8153 ethernet dongle)
* I/anyone reproduce the freeze and profile it further by doing
trac
.00 addr 4
axen0: AX88179, address 00:11:6b:SNIP
rgephy0 at axen0 phy 3: RTL8169S/8110S/8211 PHY, rev. 5
cdce0 at uhub0 port 17 configuration 2 interface 0 "Linksys Linksys
USB3GIGV1" rev 3.00/30.00 addr 5
cdce0: address 14:91:82:SNIP
I'll give it lots more testing and report b
ocal to my machine. Anyone else's
experience about how AXEN works or not works would be appreciated.
Tinker
On 2017-06-01 00:29, Tinker wrote:
Subsequently I realized that I had had the AXEN plugged in to a USB 2
port (together with an RTL8153 on the same root hub).
Now just minutes ago,
y workaround was to switch over
to use USB2 only. It's still on my TODO to debug the problem further -
mpi@ needed XHCI_DEBUG and/or UHUB_DEBUG debug output data to be able to
get to any conclusions.
Tinker
36 matches
Mail list logo