>Synopsis: Randomly during bootup, ugold(4) doesn't attach
>Category: kernel
>Environment:
System : OpenBSD 7.4
Details : OpenBSD 7.4-current (GENERIC.MP) #1656: Sun Feb 4
20:17:35 MST 2024
Hi,
I found one of my PC Engines APU3 in kernel panic. What changed recently
on this machine, I started node.js on it about two days ago.
- it runs local installation of Zigbee2MQTT
- nodejs / Zigbee2MQTT opens /dev/cuaU0
- cuaU0 is ITEAD SONOFF Zigbee 3.0 USB Dongle Plus V2
This is very new
Mark,
On Sat, Jan 27, 2024 at 03:05:10PM +0100, Mark Kettenis wrote:
> > Date: Sat, 27 Jan 2024 22:47:05 +0900
> > From: stephane Tranchemer
> >
> > Hello Jonathan,
> >
> > made a kernel with the patch and here is what I get on dmesg:
> >
> > puc0 at pci0 dev 26 function 0 "Intel C3000 UART"
Hi,
Below patch makes ugold(4) work with TEMPerGold v3.5.
Sorry for lack of man page diff, but I don't know how to categorise
those USB sticks. This is random USB stick from AliExpress.
Before:
uhidev0 at uhub0 port 3 configuration 1 interface 0 "PCsensor TEMPerGold" rev
1.10/0.00 addr 2
On Mon, Apr 17, 2023 at 08:23:27PM +, Mikolaj Kucharski wrote:
> On Thu, Apr 13, 2023 at 04:43:39PM +0000, Mikolaj Kucharski wrote:
> > Hi,
> >
> > I have an amd64 based cheap laptop, which has extremly slow I/O and even
> > slower I/O in the installer. The result i
the timeouts ridiculously long does not serve
> those people
>
Make sense.
>
> Mikolaj Kucharski wrote:
>
> > Hi,
> >
> > I have an amd64 based cheap laptop, which has extremly slow I/O and even
> > slower I/O in the installer. The result is, that fsck
On Thu, Apr 13, 2023 at 05:18:15PM +, Klemens Nanni wrote:
> On Thu, Apr 13, 2023 at 04:43:39PM +0000, Mikolaj Kucharski wrote:
> > I have an amd64 based cheap laptop, which has extremly slow I/O and even
> > slower I/O in the installer. The result is, that fsck during upgrade
On Thu, Apr 13, 2023 at 04:43:39PM +, Mikolaj Kucharski wrote:
> Hi,
>
> I have an amd64 based cheap laptop, which has extremly slow I/O and even
> slower I/O in the installer. The result is, that fsck during upgrade,
> triggered via sysupgrade -s, takes ages. Basically make
Hi,
I have an amd64 based cheap laptop, which has extremly slow I/O and even
slower I/O in the installer. The result is, that fsck during upgrade,
triggered via sysupgrade -s, takes ages. Basically makes upgrade
non-usable. I need to follow manual upgrade or I edit via the
gzip, rdsetroot -x,
Hi,
I'm not sure does this belong to bugs@
However what I used in the past was Yaifo and I still use it every few
years, but it takes too much effort to rebase it to -current, so I
didn't touch it for few years now, but for me it worked really nicely.
https://github.com/jedisct1/yaifo
On Thu,
On Thu, Nov 03, 2022 at 07:06:48AM +, Mikolaj Kucharski wrote:
> Hi,
>
> I'm using below type of config for few years now. Today I've upgraded to:
>
>
> OpenBSD 7.2-current (GENERIC.MP) #823: Wed Nov 2 11:56:37 MDT 2022
> dera...@amd64.openbsd.org:/usr/src/s
Hi,
I'm using below type of config for few years now. Today I've upgraded to:
OpenBSD 7.2-current (GENERIC.MP) #823: Wed Nov 2 11:56:37 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
and see following problem:
$ ssh -vv pce-0035
OpenSSH_9.1, LibreSSL
On Sun, Apr 03, 2022 at 09:20:12PM +, Mikolaj Kucharski wrote:
> >Synopsis:random panic
> >Category:kernel
> >Environment:
> System : OpenBSD 7.1
> Details : OpenBSD 7.1 (GENERIC.MP) #457: Sun Apr 3 00:33:57 MDT
> 2022
>
I see this problem too on both of mine APU3 access points with:
athn0 at pci4 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 5 int 16
athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:34:e4:23
I had it on my long waiting todo list to open a bug report for this
problem, but real life..
On Sat, Jan 15, 2022 at 12:36:06PM -0800, Mike Larkin wrote:
> On Sat, Jan 15, 2022 at 07:50:34PM +0100, Stefan Sperling wrote:
> > On Sat, Jan 15, 2022 at 10:03:07AM -0700, Theo de Raadt wrote:
> > > Additionally, the /boot code must be able to see that the disk contains
> > > a hibernate
On Sat, Jan 15, 2022 at 09:50:04AM -0800, Mike Larkin wrote:
> On Sat, Jan 15, 2022 at 10:03:07AM -0700, Theo de Raadt wrote:
> > Additionally, the /boot code must be able to see that the disk contains
> > a hibernate signature, and this may not work if your swap partition
> > is at such a far
On Sat, Jan 15, 2022 at 01:50:50AM -0700, Theo de Raadt wrote:
> Mikolaj Kucharski wrote:
>
> > On Sat, Jan 15, 2022 at 08:23:07AM +0000, Mikolaj Kucharski wrote:
> > >
> > > Thanks. I found and enabled "Linux S3" option in BIOS, now I see S3
> &
On Sat, Jan 15, 2022 at 08:23:07AM +, Mikolaj Kucharski wrote:
>
> Thanks. I found and enabled "Linux S3" option in BIOS, now I see S3
> available in dmesg:
>
> acpi0: sleep states S0 S3 S4 S5
>
I forgot to mention, above BIOS option makes suspend work,
+0100, Stefan Sperling wrote:
> > On Wed, Nov 17, 2021 at 03:25:36PM +0000, Mikolaj Kucharski wrote:
> > > On Mon, Nov 15, 2021 at 12:33:09PM +0000, Mikolaj Kucharski wrote:
> > > > I have more panics, with couple of minutes gap between
> > > > ieee80211_s
On Wed, Nov 17, 2021 at 03:25:36PM +, Mikolaj Kucharski wrote:
> What is strange, I would imagine, that address of they key is one
> between those two:
>
>
> $ grep -w ic_def_txkey panic.txt | cut -f3- -d: | tail
> ieee80211_setkeysdone() [ieee80211_proto.c|480] c
I have more panics, with couple of minutes gap between
ieee80211_setkeysdone() from ieee80211_proto.c and panic
in ieee80211_encrypt() from ieee80211_crypto.c.
Sorry for wrapped lines, but I added Time::HiRes in a rush,
the console grabbing script.
2025.100422.505898Z: MMM:
On Mon, Sep 27, 2021 at 08:39:48AM +, Mikolaj Kucharski wrote:
> On Sat, Sep 25, 2021 at 10:25:12AM +0200, Stefan Sperling wrote:
> > On Sat, Sep 25, 2021 at 02:03:40AM +, Mikolaj Kucharski wrote:
> > > I've added more info, probably mainly for myself. I'm not sure
On Sat, Sep 25, 2021 at 10:25:12AM +0200, Stefan Sperling wrote:
> On Sat, Sep 25, 2021 at 02:03:40AM +0000, Mikolaj Kucharski wrote:
> > I've added more info, probably mainly for myself. I'm not sure where to
> > go with this information yet.
>
> We need to figure out wha
I've added more info, probably mainly for myself. I'm not sure where to
go with this information yet.
On Sat, Sep 25, 2021 at 01:31:33AM +, Mikolaj Kucharski wrote:
> On Wed, Sep 22, 2021 at 03:00:37PM +0000, Mikolaj Kucharski wrote:
> > Another one, it happened with below dif
On Wed, Sep 22, 2021 at 03:00:37PM +, Mikolaj Kucharski wrote:
> Another one, it happened with below diff applied. Didn't had time yet to
> dive into this.
I have limited time in recent months, so I'm trying to put anything what
I have in spare moment. This should be more clear, f
Another one, it happened with below diff applied. Didn't had time yet to
dive into this.
---
commit 94d934f45b45bd87293428425164d8120ec10255 (main)
from: Mikolaj Kucharski
date: Mon Sep 20 08:35:49 2021 UTC
ignore the SWBA interrupt while we're
On Tue, Apr 27, 2021 at 11:32:49PM +0200, Stefan Sperling wrote:
> On Tue, Apr 27, 2021 at 06:36:32PM +0000, Mikolaj Kucharski wrote:
> > I got it again, but had official snapshot, so I don't have more info
> > than I had in the past, but I would like to share it anyway..
>
>
Ok, manual upgrade fixed the problem.
On Fri, Jun 11, 2021 at 12:36:12PM +, Mikolaj Kucharski wrote:
> Hi,
>
> I sysupgraded today one of my machines and it didn't come back up
> properly. It's stuck after executing init(8) with following message
> every couple of seconds:
&
Hi,
I sysupgraded today one of my machines and it didn't come back up
properly. It's stuck after executing init(8) with following message
every couple of seconds:
init: can't open /dev/console: No such file or directory
I was upgrading to (based on the source location, where sysupgrade
fetched
Hi,
I've noticed this initially with sysupgrade(8) on armd64:
OpenBSD 6.9-current (GENERIC.MP) #1194: Tue Jun 8 12:50:22 MDT 2021
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
but I also see this on amd64:
OpenBSD 6.9-current (GENERIC.MP) #58: Tue Jun 8 10:24:26
On Wed, May 19, 2021 at 12:30:27PM +0100, Stuart Henderson wrote:
> Understood why, but I think wireguard is a special case, normally
> maintaining a nat mapping across a change of address doesn't help as the
> system at the other side won't associate it with the same "connection". The
> ()
t would be convenient for the user but would I think be delicate work,
> especially regarding MP locking.
>
> --
> Sent from a phone, apologies for poor formatting.
> On 19 May 2021 01:16:06 Mikolaj Kucharski wrote:
>
> > Forgot to also show PF rules:
> >
> > pce-0035#
Forgot to also show PF rules:
pce-0035# grep -ve '^$' -e '^#' /etc/pf.conf
set skip on lo
set limit states 25000
queue q_umb0 on umb0 flows 1024 qlimit 50 quantum 300 default
queue q_athn0 on athn0 flows 1024 qlimit 100 quantum 300 default
match out on umb0 inet from !(umb0) nat-to (umb0:0)
match
On Tue, May 11, 2021 at 10:28:21AM +0200, Stefan Sperling wrote:
> On Sun, May 09, 2021 at 08:28:14PM +0000, Mikolaj Kucharski wrote:
> > ..and in case timestamps may give a bit more clue, here is example from
> > one of the accesspoints:
>
> Yes, this is insight
..and in case timestamps may give a bit more clue, here is example from
one of the accesspoints:
# grep -F ieee80211_encap /var/log/messages
2021-05-09T11:35:31.155Z pce-0041 /bsd: ieee80211_encap: data frame for node
c0:ee:fb:33:f0:11 in state 4
2021-05-09T11:36:07.957Z pce-0041 /bsd:
On Sat, May 08, 2021 at 10:06:08AM +0200, Stefan Sperling wrote:
>
> Fixed patch, with the condition ni != ic->ic_bss added:
>
> diff b412d6f4250f42e50e0333dbcedab9189b4b19e2 /usr/src
> blob - 58f654273f7ea0cc3c04e0a60d5e5e6a33296dc0
> file + sys/net80211/ieee80211_output.c
> ---
On Sat, May 08, 2021 at 10:06:08AM +0200, Stefan Sperling wrote:
> On Fri, May 07, 2021 at 10:27:36PM +0000, Mikolaj Kucharski wrote:
> > Yes, I see ieee80211_encap: data frame for node... messages in
> > dmesg. Two dmesgs, from two PC Engines machines, in two different
> > lo
On Sat, May 08, 2021 at 09:51:06AM +0200, Stefan Sperling wrote:
> >
> > Do you think above could be committed to HEAD?
>
> Yes, I will commit it.
>
Cool, thanks!
> > Wrong place, wong time.. but could `got rebase` return dedicated
> > exit code for below situation?
> >
> > $ got rebase main
On Wed, Apr 28, 2021 at 12:52:36AM +0200, Stefan Sperling wrote:
>
> Here is another shot in the dark.
> The patch below ensures that we don't attempt to send data frames
> to nodes that aren't in associated state anymore. The node's crypto
> keys would already have been cleared which would
On Wed, Apr 28, 2021 at 12:52:36AM +0200, Stefan Sperling wrote:
> On Tue, Apr 27, 2021 at 11:32:49PM +0200, Stefan Sperling wrote:
> > On Tue, Apr 27, 2021 at 06:36:32PM +, Mikolaj Kucharski wrote:
> > > I got it again, but had official snapshot, so I don't have more inf
On Tue, Apr 27, 2021 at 11:32:49PM +0200, Stefan Sperling wrote:
> On Tue, Apr 27, 2021 at 06:36:32PM +0000, Mikolaj Kucharski wrote:
> > I got it again, but had official snapshot, so I don't have more info
> > than I had in the past, but I would like to share it anyway..
>
>
On Mon, Nov 16, 2020 at 01:57:06PM +, Mikolaj Kucharski wrote:
> On Mon, Nov 16, 2020 at 12:53:14PM +0100, Stefan Sperling wrote:
> > On Mon, Nov 16, 2020 at 10:59:45AM +, Mikolaj Kucharski wrote:
> > > It happened again. This time on current. I was on Android phone
On Sat, Mar 06, 2021 at 09:39:08AM -0700, Theo de Raadt wrote:
>
> The ifconfig man page says "inet autoconf" sets a flag. It does not say
> "sets the flag and brings the interface up". You want to argue against
> the documented behaviour?
>
I think there is some inconsistency in the
RIC.MP
Thank you!
>
> On Thu, Feb 25, 2021 at 11:38:03AM +0000, Mikolaj Kucharski wrote:
> > Hi,
> >
> > After recent snapshot upgrade tmux output change for C-b w. With newest
> > snapshot it looks as:
> >
> > (0) - 0: 2 windows (attached)
> &
Hi,
After recent snapshot upgrade tmux output change for C-b w. With newest
snapshot it looks as:
(0) - 0: 2 windows (attached)
(1) ├─> 0: 2 windows (attached)
(2) └─> 1: 2 windows (attached)
Before it looked something like (taken from OpenBSD 6.8 stable):
(0) - 0: 2 windows (attached)
(1)
On Thu, Feb 25, 2021 at 10:07:32AM +0100, stef...@fritz.wtf wrote:
> >Synopsis: After installing OpenBSD 6.8 errata 014 pf allows no connections
> >and knows no tables
> >Category: kernel
> >Environment:
> System : OpenBSD 6.8
> Details : OpenBSD 6.8 (GENERIC) #4: Mon
On Wed, Feb 17, 2021 at 01:26:05PM +0100, Stephen Bosch wrote:
> Am 17.02.21 um 11:24 schrieb Stefan Sperling:
> > On Tue, Feb 16, 2021 at 09:50:23PM +0100, Stephen wrote:
> >>> Synopsis: panic in athn driver
> >>> Category: amd64
> >>> Environment:
> >>System : OpenBSD 6.8
> >>
A question below..
On Wed, Feb 03, 2021 at 11:22:16AM +, Mikolaj Kucharski wrote:
> On Wed, Feb 03, 2021 at 11:10:45AM +, Edd Barrett wrote:
> > Hi,
> >
> > CCing ratchov@ and kettenis@ with some context.
> >
> > In short: my change broke ugen, which
On Wed, Feb 03, 2021 at 11:10:45AM +, Edd Barrett wrote:
> Hi,
>
> CCing ratchov@ and kettenis@ with some context.
>
> In short: my change broke ugen, which expects to scan up the interface
> range until an interface doesn't exist.
>
> On Wed, Feb 03, 2021 at 06:25:48AM +0100, Marcus
On Tue, Feb 02, 2021 at 10:02:57AM +, Edd Barrett wrote:
> Hi,
>
> Apologies for breaking stuff.
No worries.
> On Tue, Feb 02, 2021 at 07:24:34AM +0100, Marcus Glocker wrote:
> > Edd:
> > Can you please also double check if this still works with your
> > uaudio(4) device?
>
> My device
y' to 'attached'
umb0: connecting ...
umb0: connection activating
umb0: connection activated
umb0: state going up from 'attached' to 'connected'
umb0: IPv4 addr 100.109.48.67, mask 255.255.255.248, gateway 100.109.48.68
umb0: IPv4 nameserver 89.108.202.20
umb0: IPv
On Mon, Feb 01, 2021 at 10:16:37PM +, Mikolaj Kucharski wrote:
> On Mon, Feb 01, 2021 at 10:57:43PM +0100, Marcus Glocker wrote:
> > Ok. Then it was the usbd_device2interface_handle() change.
> > Fixed one device (uaudio), broke the other device (umb) :-|
> > Now le
On Mon, Feb 01, 2021 at 10:57:43PM +0100, Marcus Glocker wrote:
> Ok. Then it was the usbd_device2interface_handle() change.
> Fixed one device (uaudio), broke the other device (umb) :-|
> Now lets see if we can find something common to make both
> work. Can you please send an lsusb -v of your
Bingo!
After applying your revert diff, umb0 works as expected:
# ifconfig umb0
umb0: flags=8855 mtu 1500
index 7 priority 6 llprio 3
roaming disabled registration home network
state up cell-class LTE rssi -99dBm speed 47.7Mbps up 286Mbps down
SIM initialized PIN
Here dmesg when umb0 works:
OpenBSD 6.8-current (GENERIC.MP) #157: Sat Jan 23 22:27:44 UTC 2021
r...@pc1.home.local:/home/mkucharski/openbsd/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4259872768 (4062MB)
avail mem = 4115431424 (3924MB)
random: good seed from bootblocks
mpath0 at root
On Mon, Jan 25, 2021 at 08:36:13PM +0100, Marcus Glocker wrote:
> On Thu, Jan 21, 2021 at 05:02:02PM +0100, Marcus Glocker wrote:
>
> > On Thu, 21 Jan 2021 15:51:58 +
> > Mikolaj Kucharski wrote:
> >
> > > I've also tested scanning on:
> &g
to CVS?
On Wed, Jan 13, 2021 at 08:03:07PM +, Mikolaj Kucharski wrote:
> Marcus,
>
> On Sat, Jan 09, 2021 at 11:55:38PM +, Mikolaj Kucharski wrote:
> > Marcus,
> >
> > I was suspecting there is more than one issue, but didn't manage to dive
> > in
Marcus,
On Sat, Jan 09, 2021 at 11:55:38PM +, Mikolaj Kucharski wrote:
> Marcus,
>
> I was suspecting there is more than one issue, but didn't manage to dive
> into it. With your last kernel diff:
>
> https://marc.info/?l=openbsd-bugs=160991986510827=2
>
>
On Sun, Jan 10, 2021 at 10:00:50AM +0100, Theo Buehler wrote:
> > > To get coredump and backtrace in such a situation, read up on
> > > kern.nouidcoredump=3 in sysctl(8)
> >
> > I imagine this is a typo and you meant kern.nosuidcoredump in
> > sysctl(2). Anyway, thanks, that is helpful for the
On Sat, Jan 09, 2021 at 01:27:33PM +0100, Theo Buehler wrote:
> This is very likely to be fixed in -current by this commit:
> https://marc.info/?l=openbsd-cvs=160993335615698=2
> diff here:
> https://marc.info/?l=openbsd-tech=160992433912265=2
Oh, Anton's usecase is exactly the same as mine. I've
Marcus,
I was suspecting there is more than one issue, but didn't manage to dive
into it. With your last kernel diff:
https://marc.info/?l=openbsd-bugs=160991986510827=2
and below sane-backends diff makes my Canon MG3250 USB scanner work
consistenly.
This is awesome, thank you Marcus!
Marcus,
Below diff works, in similar way like previous diff. With the diff
opening and closing ugen(4) results in consistent behaviour.
Setting SANE_CUSTOM_LIBUSB_TIMEOUT between 6 and 10 seconds makes my
scanner work. I'm gonna test your diff, which you sent for sane
backends.
On Wed, Jan 06,
Marcus,
I'm just catching up here. I know you posted newer diff, but I would
like to comment what I've seen with your below diff.
I'm running sane-backends with my SANE_CUSTOM_LIBUSB_TIMEOUT diff, as
shown in one of my eariler emails in this thread at:
On Sat, Jan 02, 2021 at 09:34:56AM +0100, Marcus Glocker wrote:
> On Fri, Jan 01, 2021 at 07:15:53PM +, Natasha Kerensikova wrote:
>
> > Hello,
> >
> > I'm only catching up with the thread now, but thanks a lot for including
> > me, I am indeed interested in how this topic is evolve.
> >
>
On Fri, Jan 01, 2021 at 06:56:21PM +0100, Marcus Glocker wrote:
> It looks like with xhci(4) for some reason the bulk endpoints are
> stalling after some operations, which isn't happening with ehci(4). I
> currently can't see why this happens only with xhci(4). That's why
> on your second
On Tue, Dec 29, 2020 at 03:03:06PM +0100, Marcus Glocker wrote:
> On Mon, 28 Dec 2020 20:55:33 +
> miko...@kucharski.name wrote:
...
> > >Fix:
> > Per email threads on tech@ from above marc.info links below is
> > not proper solution, but a workaround:
> >
> > --8<--
> > Index:
On Mon, Dec 28, 2020 at 08:55:33PM +, miko...@kucharski.name wrote:
>
> I've started adding printfs to xhci_device_generic_transfer() but that
> slowed code path to the point that problem disappeared and scanner
> started to work reliably, but (obviously) scan got really slow, from
> couple
len;
- }
-#endif
+
/* the length must be a multiple of the max size */
curlen -= curlen % mps;
DPRINTFN(1,("ehci_alloc_sqtd_chain: multiple QTDs, "
On Sun, Nov 22, 2020 at 01:36:10AM +, Mikolaj Kuch
Hi,
Whould below diff be okay, or just simple:
if (curlen > len)
curlen = len;
be more appropriate here?
On Wed, Nov 11, 2020 at 09:02:49AM +0000, Mikolaj Kucharski wrote:
> On Sat, Oct 24, 2020 at 09:08:45AM +0200, Marcus Glocker wrote:
> > Now you ha
On Mon, Nov 16, 2020 at 12:53:14PM +0100, Stefan Sperling wrote:
> On Mon, Nov 16, 2020 at 10:59:45AM +0000, Mikolaj Kucharski wrote:
> > It happened again. This time on current. I was on Android phone using
> > Signal and other laptop on urwn(4) was fetching newest pa
It happened again. This time on current. I was on Android phone using
Signal and other laptop on urwn(4) was fetching newest packages snapshot.
In this email thread it's different physical hardware, but I think
it's same Wi-Fi card like on the other PC Engines board.
This email thread which I'm
> > ***
> >
> > While the DIAGNOSTIC code to panic at curlen == 0 was introduced with
> > the first commit of ehci.c. I think the revision 1.57 should have
> > removed that DIAGNOSTIC code already, since we obviously can cope
> > with curlen = 0.
> >
> >
On Sat, Oct 24, 2020 at 09:08:45AM +0200, Marcus Glocker wrote:
> Now you have on M less in your tree checkout :-)
> Thanks for tracking this down.
Awesome, thank you! One down, more to go...
--
Regards,
Mikolaj
On Sat, Sep 26, 2020 at 11:00:46PM +, Mikolaj Kucharski wrote:
> On Wed, Sep 16, 2020 at 09:19:37PM +0000, Mikolaj Kucharski wrote:
> > So time of the crash varies and I guess probably there is no pattern
> > there. Here is new panic report, with some kernel printf()s added.
&
On Wed, Sep 16, 2020 at 09:19:37PM +, Mikolaj Kucharski wrote:
> So time of the crash varies and I guess probably there is no pattern
> there. Here is new panic report, with some kernel printf()s added.
>
> Problem seems to be related that dataphyspage is greater than
> d
On Thu, Sep 17, 2020 at 12:31:16PM +0200, Stefan Sperling wrote:
> On Wed, Sep 16, 2020 at 08:39:19PM +0000, Mikolaj Kucharski wrote:
> > This one seems random, on that machine I see it first time. CVS checkout
> > is basically the build time as I first do cvs up and then make.
&g
This one seems random, on that machine I see it first time. CVS checkout
is basically the build time as I first do cvs up and then make.
OpenBSD 6.8-beta (GENERIC.MP) #73: Sun Sep 13 15:23:23 UTC 2020
r...@pc1.home.local:/home/mkucharski/openbsd/src/sys/arch/amd64/compile/GENERIC.MP
# ls -1
On Wed, Sep 09, 2020 at 09:32:42PM +, Mikolaj Kucharski wrote:
> I tested my other non-graphical OpenBSD machines, which are
> running exactly the same 6.8-beta and curl works fine there.
>
> I couldn't find anything obvious which is different between those
> machines which ha
On Wed, Sep 09, 2020 at 09:35:34PM +0100, Stuart Henderson wrote:
> On 2020/09/09 20:31, Mikolaj Kucharski wrote:
> > Hi,
> >
> > I see this problem with curl on two machines and firefox and chromium on
> > one as that's the only X11 environment which I have.
> >
Hi,
I see this problem with curl on two machines and firefox and chromium on
one as that's the only X11 environment which I have.
# curl -vs https://www.mail-archive.com/
* Trying 72.52.77.8:443...
* Connected to www.mail-archive.com (72.52.77.8) port 443 (#0)
* ALPN, offering h2
* ALPN,
.MP) #64: Sun Sep 6 18:19:41 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
On Mon, Aug 10, 2020 at 08:34:36PM +0000, Mikolaj Kucharski wrote:
> >Synopsis:LTE mini-PCIe modem not showing up after reboot
> >Category:kernel
> >Environm
On Sat, Aug 29, 2020 at 10:46:27PM -0400, James Hastings wrote:
> On Mon, Aug 10, 2020 at 08:34:36PM +0000, Mikolaj Kucharski wrote:
> > >Synopsis: LTE mini-PCIe modem not showing up after reboot
> > >Category: kernel
> > >Environment:
> > Syste
Marcus,
On Fri, Aug 28, 2020 at 10:06:17AM +0200, Marcus Glocker wrote:
> One other ask.
>
> Since we have fixed the free panic with the last commit now, I'm
> wondering whether tools like scanimage are smart enough to handle
> things like that the device returns a too short configuration
On Wed, Aug 26, 2020 at 11:27:21PM +0200, Marcus Glocker wrote:
> On Wed, 26 Aug 2020 19:20:26 +
> Mikolaj Kucharski wrote:
>
> > On Wed, Aug 26, 2020 at 06:54:59PM +, Mikolaj Kucharski wrote:
> > > On Wed, Aug 26, 2020 at 06:45:28PM +,
On Tue, Aug 25, 2020 at 10:16:50PM +0200, Mark Kettenis wrote:
> > >
> > > What I am doing wrong here?
> > >
> >
> > Any kind soul is willing to help me and push me in the correct
> > direction? As you can see I don't have experience in kernel space
> > development and I imagine one would need
On Wed, Aug 26, 2020 at 06:54:59PM +, Mikolaj Kucharski wrote:
> On Wed, Aug 26, 2020 at 06:45:28PM +0000, Mikolaj Kucharski wrote:
...
> >
> > Do you have any theory why first control request is returning
> > wTotalLength=32 and second is returning wTotalLength
On Wed, Aug 26, 2020 at 06:45:28PM +, Mikolaj Kucharski wrote:
> Marcus,
>
> On Wed, Aug 26, 2020 at 01:40:02PM +0200, Marcus Glocker wrote:
> > On Tue, 25 Aug 2020 10:30:50 +0000
> > Mikolaj Kucharski wrote:
> >
> ...
> > > # lsusb -v
> &g
Marcus,
On Wed, Aug 26, 2020 at 01:40:02PM +0200, Marcus Glocker wrote:
> On Tue, 25 Aug 2020 10:30:50 +
> Mikolaj Kucharski wrote:
>
...
> > # lsusb -v
>
> Thanks.
>
> So there is no other configuration descriptor with wTotalLength=32.
> I read through
On Sun, Aug 16, 2020 at 01:23:54PM +, Mikolaj Kucharski wrote:
> On Mon, Aug 10, 2020 at 08:34:36PM +0000, Mikolaj Kucharski wrote:
> > >Synopsis: LTE mini-PCIe modem not showing up after reboot
> > >Category: kernel
> > >Environment:
> > Syste
On Tue, Aug 25, 2020 at 12:24:56PM +0200, Marcus Glocker wrote:
> On Mon, 24 Aug 2020 16:46:22 +
> Mikolaj Kucharski wrote:
>
> >
> > # scanimage -L
> > device `xerox_mfp:libusb:000:002' is a Samsung M2070 Series
> > multi-function peripheral
> >
&g
On Fri, Aug 21, 2020 at 01:21:28PM +0200, Marcus Glocker wrote:
> On Tue, 18 Aug 2020 15:46:03 +
> Mikolaj Kucharski wrote:
>
> > On Tue, Aug 18, 2020 at 06:41:13AM +0200, Marcus Glocker wrote:
> > > Could you please also send an lsusb -v of the device?
&
On Tue, Aug 18, 2020 at 06:41:13AM +0200, Marcus Glocker wrote:
> Could you please also send an lsusb -v of the device?
Sure, no problem.
> pkg_add usbutils
> lsusb
> lsusb -d : -v
# lsusb -v -d 04e8:3469
Bus 000 Device 002: ID 04e8:3469 Samsung Electronics Co., Ltd
Device Descriptor:
On Sun, Aug 16, 2020 at 06:41:18PM +, Mikolaj Kucharski wrote:
> >Synopsis:scanimage -L triggers panic, free: size too large 55 > 32
> >Category:kernel
> >Environment:
> System : OpenBSD 6.7
> Details : OpenBSD 6.7-current (GENERIC.M
>Synopsis: scanimage -L triggers panic, free: size too large 55 > 32
>Category: kernel
>Environment:
System : OpenBSD 6.7
Details : OpenBSD 6.7-current (GENERIC.MP) #28: Sun Aug 16 10:19:11
MDT 2020
>Synopsis: LTE mini-PCIe modem not showing up after reboot
>Category: kernel
>Environment:
System : OpenBSD 6.7
Details : OpenBSD 6.7-current (GENERIC.MP) #15: Sun Aug 9 17:48:40
MDT 2020
On Mon, Aug 03, 2020 at 12:47:22PM +0200, Theo Buehler wrote:
>
> I will commit a cleaned-up version of that diff soon.
Thanks. It works now with:
OpenBSD 6.7-current (GENERIC.MP) #13: Sat Aug 8 01:11:49 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
--
On Mon, Aug 03, 2020 at 12:47:22PM +0200, Theo Buehler wrote:
> I will commit a cleaned-up version of that diff soon.
I see. Thanks for clarification.
--
Regards,
Mikolaj
Hi,
I'm unable to openssl s_client, wget, curl or ftp the domain
k8sapi.prod.chorus1.net. Here is example session with ftp command:
$ ftp -o /dev/null https://k8sapi.prod.chorus1.net/
Trying 34.102.178.128...
TLS handshake failure: handshake failed: error:1404B09F:SSL
routines:ST_CONNECT:length
On Sun, Jul 26, 2020 at 11:08:04PM +, Mikolaj Kucharski wrote:
> Hi,
>
> Not sure should I start new thread for this, but while experimenting
> with easy repro of this issue, I ended up reliably freezing kernel, but
> without even any ddb or panic output. Hard freeze.
>
&g
Hi,
Not sure should I start new thread for this, but while experimenting
with easy repro of this issue, I ended up reliably freezing kernel, but
without even any ddb or panic output. Hard freeze.
# hostname.ure0
inet6 autoconf
dhcp
File hostname.wg1 generated with following script:
--->8---
1 - 100 of 137 matches
Mail list logo
