On Mon, Jul 06, 2020 at 11:17:34AM +0200, Martin Ziemer wrote:
> On Wed, Jul 01, 2020 at 01:47:57PM +1000, Jonathan Gray wrote:
> > On Tue, Jun 30, 2020 at 07:10:10PM +0200, Martin Ziemer wrote:
> > > With this patch (and driver "intel" in /etc/X11/xorg.conf) my system
> > > works.
> > > Tested s
On Mon, Jul 06, 2020 at 06:57:45PM +, Mikolaj Kucharski wrote:
> I today had following panic (caveats, retyped by hand):
>
> wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0
> wsdisplay0: screen 1-5 added (std, vt100 emulation)
> uvm_fault(0xf
Hi all,
On Tue, Jul 07, 2020 at 07:21:10PM +0200, Stefan Sperling wrote:
> That is looking good. The AP is supposed to rotate the group key hourly.
> Since you are able to receive group key updates it follows that the
> pairwise WPA2 crypto for regular data traffic is now working, too.
> Group key
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---
#!
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,
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 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
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
--
Rega
>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
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd6
On Mon, Aug 10, 2020 at 08:34:36PM +, Mikolaj Kucharski wrote:
> >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
>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
dera...@amd64.openbsd.org:/usr/src/sys
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
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:
bLength
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 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
> >
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
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 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
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=55?
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 t
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 +,
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 descrip
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
SD 6.8-beta (GENERIC.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 +, Mikolaj Kucharski wrote:
> >Synopsis:LTE mini-PCIe modem not showing up after reboot
> >Category:kern
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, offeri
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.
>
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 whi
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 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
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 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 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
1.47
> >
> > ***
> >
> > 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.
>
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 c
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 packages snapsh
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 have
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
On Fri, Nov 27, 2020 at 07:42:52PM +0100, Marcus Glocker wrote:
> On Fri, Nov 27, 2020 at 12:57:02PM +0000, Mikolaj Kucharski wrote:
>
> > I think something as simple as below would be okay. If requested I can
> > put in DPRINTFN()s based on current printf()s, like I proposed i
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 of
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: dev/usb/u
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 attempt
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.
> >
> >
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:
https://marc.info/?l=openbsd-bugs&m
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 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&m=160991986510827&w=2
and below sane-backends diff makes my Canon MG3250 USB scanner work
consistenly.
This is awesome, thank you Marcu
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&m=160993335615698&w=2
> diff here:
> https://marc.info/?l=openbsd-tech&m=160992433912265&w=2
Oh, Anton's usecase is exactly the same as min
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 fut
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&m=160991986510827&w
your diff
commited 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 mana
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
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
sc
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 v
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 um
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
wn
umb0: state going up from 'SIM is ready' 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,
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 wor
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 Glocker
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 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
> >>Details
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 Ja
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)
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)
> &
>Synopsis: Xorg crash with can't switch keyboard to raw mode. Enable
>support for it in the kernel
>Category: arm kernel
>Environment:
System : OpenBSD 6.6
Details : OpenBSD 6.6-current (GENERIC.MP) #522: Wed Mar 25
14:03:43 MDT 2020
de
>Synopsis: kernel panic with message _dmamap_sync: ran off map!
>Category: kernel
>Environment:
System : OpenBSD 6.7
Details : OpenBSD 6.7-beta (GENERIC.MP) #546: Mon Apr 6 12:39:22
MDT 2020
dera...@arm64.openbsd.org:/usr/src/sys/arch/a
On Sat, Apr 11, 2020 at 09:06:57AM +, Mikolaj Kucharski wrote:
> >Synopsis:kernel panic with message _dmamap_sync: ran off map!
> >Category:kernel
> >Environment:
> System : OpenBSD 6.7
> Details : OpenBSD 6.7-beta (GENERIC.MP) #546: Mon Apr
On Sat, Apr 11, 2020 at 08:40:09PM +0200, Juan Francisco Cantero Hurtado wrote:
> Thanks for the report. I can't help you with the crash but yesterday I
> updated an amd64 laptop using urtwn and everything worked fine. The
> problem is something related to arm64.
Yeah, I'm trying to reproduce this
On Sat, Apr 11, 2020 at 09:46:49PM +0200, Patrick Wildt wrote:
> > OpenBSD 6.7-beta (GENERIC.MP) #552: Fri Apr 10 20:48:05 MDT 2020
> > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
> >
> > panic: _dmamap_sync: ran off map!
>
> Oh, wow! That means that the DMA sync is
On Sun, Apr 12, 2020 at 10:05:28AM +0200, Patrick Wildt wrote:
> I'm now trying to reproduce it, running this diff. I'm sure the printfs
> will slow the system down, but it's one way to see what's going on.
>
> If you can reproduce it easily, would you mind trying again, with the
> debug printfs?
On Sun, Apr 12, 2020 at 03:22:01PM +0200, Patrick Wildt wrote:
> Maybe, make that printf conditional on something weird, like the
> following. Since, if it runs off the DMA buffers map, maybe actlen
> is broken.
>
> if (xfer->length < xfer->actlen)
> printf("ehci_idon:
Bingo. Kernel p
This seems to be fixed on OpenBSD 6.7-beta.
On Thu, Mar 26, 2020 at 08:05:36PM +, Mikolaj Kucharski wrote:
> >Synopsis:Xorg crash with can't switch keyboard to raw mode. Enable
> >support for it in the kernel
> >Category:arm kernel
> >Environment:
>
On Sun, Apr 12, 2020 at 01:58:18PM +, Mikolaj Kucharski wrote:
> On Sun, Apr 12, 2020 at 03:22:01PM +0200, Patrick Wildt wrote:
> > Maybe, make that printf conditional on something weird, like the
> > following. Since, if it runs off the DMA buffers map, maybe actle
On Mon, Apr 13, 2020 at 12:34:48PM -0600, Theo de Raadt wrote:
> Mikolaj Kucharski wrote:
>
> > Index: sys/dev/usb/ehci.c
> > ===
> > RCS file: /cvs/src/sys/dev/usb/ehci.c,v
> > retrieving revision 1
On Mon, Apr 13, 2020 at 12:44:54PM -0600, Theo de Raadt wrote:
> Then you need to look at why this crazy value is composed here in this
> loop:
>
> actlen = 0;
> for (sqtd = ex->sqtdstart; sqtd != NULL; sqtd = sqtd->nextqtd) {
> usb_syncmem(&sqtd->dma, sqtd->offs, s
On Mon, Apr 13, 2020 at 01:20:27PM -0600, Theo de Raadt wrote:
> Then next step is to figure out why the sqtd is incoherent.
Ok :) If someone has spare time to help me more on this I'm all ears.
Maybe this crash output makes it more clear:
XXX S01: ehci_idone: actlen=0, sqtd_len=8, ehci_qtd_len=
On Tue, Apr 14, 2020 at 11:06:00AM +0200, Patrick Wildt wrote:
> On Mon, Apr 13, 2020 at 09:36:04PM +0200, Mark Kettenis wrote:
> > Can you print the status (full 32 bits) of that particular QTD?
>
> Yeah, I wish I could see the status field for each sqtd in that
> chain.
XXX #1# ehci_idone: len=
>Synopsis: panic: ieee80211_encrypt: key unset for sw crypto: 0
>Category: kernel
>Environment:
System : OpenBSD 6.7
Details : OpenBSD 6.7-current (GENERIC.MP) #217: Sun May 24
21:53:33 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arc
On Tue, May 26, 2020 at 09:56:02AM +0200, Stefan Sperling wrote:
> On Tue, May 26, 2020 at 07:33:07AM +0000, Mikolaj Kucharski wrote:
> > >Synopsis: panic: ieee80211_encrypt: key unset for sw crypto: 0
> > >Category: kernel
> > >Environment:
> > Syste
On Tue, May 26, 2020 at 10:37:09AM +0200, Stefan Sperling wrote:
>
> I don't yet have a definite idea what could cause this.
> I did however notice a problem which may be related. Could you try this diff?
I'm running below diff, with small change:
if (rekeysta == 0) {
print
On Tue, May 26, 2020 at 11:16:30AM +, Mikolaj Kucharski wrote:
> On Tue, May 26, 2020 at 10:37:09AM +0200, Stefan Sperling wrote:
> >
> > I don't yet have a definite idea what could cause this.
> > I did however notice a problem which may be related. Could you tr
On Wed, May 27, 2020 at 09:31:00AM +0200, Stefan Sperling wrote:
> > Uptime of 3h37m with following two entries (from dmesg):
>
> So this uptime is a lot better than what you saw before?
I actually cannot compare is it better or not. This PC Engines machine
runs -current and I upgrade it very reg
On Wed, May 27, 2020 at 07:54:32AM +, Mikolaj Kucharski wrote:
> On Wed, May 27, 2020 at 09:31:00AM +0200, Stefan Sperling wrote:
> > > Uptime of 3h37m with following two entries (from dmesg):
> >
> > So this uptime is a lot better than what you saw before?
>
>
>Synopsis: mta server-cert-check result="failure" - no TLS SNI while
>delivering emails
>Category: user
>Environment:
System : OpenBSD 6.7
Details : OpenBSD 6.7-current (GENERIC.MP) #223: Wed May 27
00:35:01 MDT 2020
dera...@amd64.openb
On Fri, May 29, 2020 at 09:46:09AM +0200, Stefan Sperling wrote:
> > As I cannot repro the panic, I guess for now I don't have anything more
> > to add to this thread, except that your diff works, Stefan.
>
> Thank you, Mikolaj. I have committed the fix.
>
> > I can trigger athn device timeouts,
On Sat, Apr 18, 2020 at 02:01:14PM +0200, Patrick Wildt wrote:
> On Tue, Apr 14, 2020 at 06:42:53PM +0000, Mikolaj Kucharski wrote:
> > On Tue, Apr 14, 2020 at 11:06:00AM +0200, Patrick Wildt wrote:
> > > On Mon, Apr 13, 2020 at 09:36:04PM +0200, Mark Kettenis wrote:
> &g
Hi,
I had finally chance to test this again on:
OpenBSD 6.0-current (GENERIC.MP) #2220: Wed Oct 12 20:06:45 MDT 2016
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
and this problem does not occur anymore. Multiple find(1) commands on
NTFS mount work reliably and doesn't t
Hi all,
Sorry, I didn't include the panic message itself. Again, hand written,
hopefully there is no typos. I can reproduce this every time I run find.
panic: ntfs_ntrele: ino: 9296 usecount: -1
Stopped at Debugger+0x7:leave
...
ddb{0}> show panic
ntfs_ntrele: ino: 9296 usecount: -1
Mark,
I know that below reply is to Alexander's email, but just to be sure, do
you need my dumps again also, as I did send acpidump files in my initial
report.
On Sun, Jul 06, 2014 at 11:19:02PM +0200, Mark Kettenis wrote:
> Thanks, please send me acpidump -o output, and indicate at exactly
> wha
Hi Matthieu,
On Tue, Feb 05, 2019 at 08:13:44AM +0100, Matthieu Herrb wrote:
> On Mon, Feb 04, 2019 at 07:08:25PM +0000, Mikolaj Kucharski wrote:
> > Hi,
> >
> > Sorry for missing subject line in my initial report. I tested git
> > checkout of commit c37c7ee0748ba828
On Thu, Mar 07, 2019 at 08:19:28AM +, Mikolaj Kucharski wrote:
> Hi Matthieu,
>
> On Tue, Feb 05, 2019 at 08:13:44AM +0100, Matthieu Herrb wrote:
> > On Mon, Feb 04, 2019 at 07:08:25PM +, Mikolaj Kucharski wrote:
> > > Hi,
> > >
> > > Sorry for
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: ieee80211_setkeysd
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
:44PM +0100, Stefan Sperling wrote:
> > On Wed, Nov 17, 2021 at 03:25:36PM +, Mikolaj Kucharski wrote:
> > > On Mon, Nov 15, 2021 at 12:33:09PM +, Mikolaj Kucharski wrote:
> > > > I have more panics, with couple of minutes gap between
> > > > ieee80
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,
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 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 into
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 signatur
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 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
>
>Synopsis: boot up kernel panic 6.6-beta #262 around
>acpipci_parse_resources()
>Category: kernel
>Environment:
System : OpenBSD 6.6
Details : OpenBSD 6.6-beta (GENERIC.MP) #247: Sat Aug 24 16:41:52
MDT 2019
dera...@amd64.openbsd.org:/u
On Thu, Aug 29, 2019 at 11:58:16AM +0100, Stuart Henderson wrote:
> On 2019/08/29 10:27, Mikolaj Kucharski wrote:
> > >Synopsis: boot up kernel panic 6.6-beta #262 around
> > >acpipci_parse_resources()
> > >Category: kernel
> > >Environment:
> >
1 - 100 of 140 matches
Mail list logo
