I think this was fixed by otto@ with the commit below:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/llvm/libunwind/src/UnwindCursor.hpp.diff?r1=1.2&r2=1.3
Hi,
First of all thank you for the report!
I looked at this last night when you sent it. Nothing obvious pops up. I
will try to try it on an OpenBSD machine soon. Currently away.
Not sure caching is the culprit, but will definitely investigate this
when I get back. If you don't mind asking,
În 11 iulie 2020 00:10:23 EEST, Paul Irofti a scris:
>On Fri, Jul 10, 2020 at 10:08:25PM +0200, Mark Kettenis wrote:
>> > Date: Fri, 10 Jul 2020 17:47:21 +0300 (EEST)
>> > From: p...@irofti.net
>> >
>> > >Synopsis: Default X configuration with Firef
On Fri, Jul 10, 2020 at 10:08:25PM +0200, Mark Kettenis wrote:
> > Date: Fri, 10 Jul 2020 17:47:21 +0300 (EEST)
> > From: p...@irofti.net
> >
> > >Synopsis: Default X configuration with Firefox temporarily locks up x250
> > >with Firefox
> > >Category: kernel
> > >Environment:
> > System
Hi,
Can you guys test this diff for me and let me know what happens or if it
fixes your issue?
This is supposed to be applied on top of a clean current source tree.
Thank you,
Paul
Index: arch/amd64/amd64/tsc.c
===
RCS file: /cvs
> I am attaching two dmesges - one from good, one from bad session.
> The main differences seem to be:
>
> < cpu0: AMD FX(tm)-8350 Eight-Core Processor, 4000.80 MHz, 15-02-00
> > cpu0: AMD FX(tm)-8350 Eight-Core Processor, 4001.94 MHz, 15-02-00
>
> < TSC skew=73
> < cpu1: AMD FX(tm)-8350 Eight-Co
Hi,
Thank you for the report!
I will send you a diff to test later today. In the meantime you can go back to
-current as the diff will be on top of what's in the tree.
So revert the revert :)
Paul
e
> > -* off at this point.
> > -*/
> > - wbinvd();
> > ci->ci_flags |= CPUF_PRESENT;
> > - ci->ci_tsc_skew = 0;/* reset on resume */
> > - tsc_sync_ap(ci);
> >
> > lapic_enable();
> > lapic_startclock();
lease(8), step 2) and test if the problem persists?
> >
>
> No tested the patch yet, but some more information gathered thanks to
> @phessler
Hi,
Could you please let us know once you tested the patch?
Reverting will probably fix your machine as acpihpet0 fixes your issue,
and reverting the diff will make it the default choice. So, could you
please also try forcing tsc as default with the reverted diff
(just like you are doing now in sysctl.conf for acpihpet0) and let us
know if that also breaks the machine?
Thank you,
Paul Irofti
On Wed, May 02, 2018 at 02:23:06PM +0200, Sebastien Marie wrote:
> Hi,
>
> I recently received a pine64 board for doing Rust work on it (thanks
> danj@) and I have some problems with it.
>
> One of them is random crash or dead-lock when running rustc, which is a
> multi-threaded program.
>
> I d
T470 :)
commit 19e33011e1fb5ea1671e43366f5ac2a762b2642f
Author: Paul Irofti
Date: Wed Feb 21 15:20:03 2018 +0200
Fix connection mutex locking.
diff --git sys/dev/pci/drm/drm_probe_helper.c sys/dev/pci/drm/drm_probe_helper.c
index 936c0c1d3a7..84a0e585d32 100644
--- sys/dev/pci/drm/drm_probe_hel
Great news! I am working on fixing the locking warning but from my
understanding of the code it is benign.
Unfortunately, the diff will probably not go in any time soon due to politics.
I bet this will fix it.
https://marc.info/?l=openbsd-tech&m=151695604403648&w=2
On Wed, Feb 14, 2018 at 12:37:45PM -0500, Jiri B wrote:
> Hello,
>
> Lenovo T470s hangs when being plugged into docking station - ThinkPad
> Ultra Dock (40A20)[1][2] - just hangs, no output, nothing.
>
> When it d
On Fri, Jul 21, 2017 at 10:45:01AM +0300, p...@irofti.net wrote:
> >Synopsis:Booting OpenBSD with external keyboard randomly panics in xhci
> >Category:kernel
> >Environment:
> System : OpenBSD 6.1
> Details : OpenBSD 6.1-current (GENERIC.MP) #6: Fri Jul 21 10:29:44
>
> >Fix:
> Unknown.
Here is a potential fix.
Index: dev/pci/drm/i915/i915_drv.h
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_drv.h,v
retrieving revision 1.77
diff -u -p -u -p -r1.77 i915_drv.h
--- dev/pci/drm/i915/i915_drv.
> I will now update to a more recent snapshot and see if I can still
> reproduce.
Yup, got a freeze with the snapshot from 19.07, but this time I also got a
trace. Pics here: http://irofti.net/tmp/x250/.
> 0:6:0: Cirrus Logic CS4610 SoundFusion
> 0x: Vendor ID: 1013 Product ID: 6001
> 0x0004: Command: 0106 Status: 0200
> 0x0008: Class: 04 Subclass: 01 Interface: 00 Revision: 01
This says you do have clcs(4) hardware on your laptop. What is the exact
error you are seeing when
On Fri, Apr 28, 2017 at 10:22:04PM -0500, Rafeiro, Humberto wrote:
>Attached I'm sending the ACPIDUMP files. Hope that it will help.
Can you show me the dmesg output with this diff? It should show the AML
trace that leads to the acpivout(4) panic.
Index: dsdt.c
==
Do you happen to be multi-booting on this machine? I think I found a
reliable way to reproduce this...
Yes I guess it's related because I stopped cheating on^W^W multi-booting
and I've never had the problem again.
I am pretty sure the bug has to do with power management and Wake on Lan
(Wo
On 12/5/2016 12:16 PM, danj+o...@chown.me wrote:
Synopsis:
Category:
Environment:
System : OpenBSD 6.0
Details : OpenBSD 6.0-current (GENERIC.MP) #0: Wed Nov 30 09:19:28
MST 2016
bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/com
Most likely related to the PHY power being turned off. X540
got a fix for that. You might want to look through FreeBSD's
e1000 driver looking for the phy power bits relevant to your
model (determine MAC and PHY ids and chip family and then
follow the code). I've looked briefly some time ago but
On 20.12.2016 17:45, Mike Belopuhov wrote:
On 5 December 2016 at 11:16, wrote:
Synopsis:
Category:
Environment:
System : OpenBSD 6.0
Details : OpenBSD 6.0-current (GENERIC.MP) #0: Wed Nov 30 09:19:28
MST 2016
bu...@amd64.openbsd.org:/usr/src
Can you also send the acpidump? There is not much we can do without it.
If unsure how, use sendbug.
On Thu, Dec 01, 2016 at 08:46:58PM +0100, Mark Kettenis wrote:
> > Date: Thu, 1 Dec 2016 19:03:35 +0200
> > From: Paul Irofti
> >
> > > see what responses you get. It would be nice to have WiFi on/off
> > > working from a key if that is possible.
> >
&
> see what responses you get. It would be nice to have WiFi on/off
> working from a key if that is possible.
The wi-fi on-off button on the x250 and x260 disables ugen1 device
0x0a2a and 0x0a2b respectively. Of course that is not enough. I will try
to look into it soon.
ugen1 detached
ugen1 at uh
> Ah, there are only two ports in use. I guess one of them is the
> management port and the other is connected to the built-in switch.
> Maybe the attach routine should just skip ports that lack a PHY mapping,
> for now.
This is better: no panic!
--
> > Not really. I also just committed a diff that fixes the build. Were
> > you able to build before?
>
> Yes, from a clean tree. Did you notice that you hard-wired the PCI code
> to PCI Express mode? If you don't care, why did you "fix" it, then?
No I did not notice. I thought I was building in
> > Is it okay if I revert this for now until we find a proper fix?
>
> No, because this will cause the whole random data passed to the kernel
> to be zeroed.
Honestly, who cares on this architecture? It is not production ready.
Disabling all supported D-Link models for this seems like an
exagger
It seems rev 1.2 broke booting on the DSR machines.
Revision 1.2, Tue Sep 22 16:16:08 2015 UTC (12 months, 4 weeks ago) by
miod
Branch: MAIN
CVS Tags: OPENBSD_5_9_BASE, OPENBSD_5_9
Changes since 1.1: +2 -0 lines
Ma
On Thu, Oct 20, 2016 at 03:51:50PM +, Visa Hankala wrote:
> On Thu, Oct 20, 2016 at 04:53:32PM +0300, Paul Irofti wrote:
> > cn30xxgmx0 at iobus0 base 0x118000800
> > port are disable
> > cn30xxgmx1 at iobus0 base 0x118001000
> > panic: : don't know
Hi,
The gmx diff from June panics my Octeon II CN6120 model.
Author: visa
Date: Wed Jun 22 13:09:35 2016 +
Add support for the second GMX interface on Octeon II. This enables
ports eth[0-3] on 8-port
> I will sprinkle more printfs and get back to your questions.
ffs_sync freezes after printing 2 (never gets to 3).
This time it was /usr/src if it matters.
if (waitfor != MNT_LAZY) {
+ printf("2");
vfs_mount_foreach_vnode(mp, ffs_sync_vnode, &fsa);
On Thu, Aug 11, 2016 at 02:36:06PM +0200, Mike Belopuhov wrote:
> VFS_SYNC calls ffs_sync for ffs. Where does it hang inside ffs_sync?
> Do you have softdeps enabled for these filesystems?
I have the defaults for every filesystem. At install I used auto.
97210743c9376e49.b none swap sw
97210743c
I sprinkled some printfs to narrow down the problem, but that had the
unfortunate effect of making the bug dissapear.
I am no expert here, but I wonder if a delay() is needed somewhere or if
my printfs are just stopping a race.
Here's the diff I used.
Index: kern/vfs_subr.c
=
On Wed, Mar 16, 2016 at 10:16:45PM +, Kári Tristan Helgason wrote:
> This is very similar to the patch I had come up with for this issue.
>
> What is the reason for not using the local variable b in the trylock
> in barrier_destroy()?
I want that assignment to happen once we are holding the l
> What do you think?
I think this diff is even safer: it checks for threads entering and
exiting the barrier while holding the mutex, and if both values are 0 it
proceeds to destroy the barrier.
I also renamed sofar to in so that the relationship between threads is
more obvious.
Index: rthread.
On Tue, Mar 15, 2016 at 02:30:26AM +0100, Tobias Ulmer wrote:
> On Tue, Mar 15, 2016 at 12:51:45AM +0100, Tobias Ulmer wrote:
> > On Thu, Mar 10, 2016 at 10:23:17PM +, Kári Tristan Helgason wrote:
> > > I think I may have come across a race in the implementation of
> > > `pthread_barrier_wait`
> I will try your patch and post back here.
I discussed the patch with Tobias and it is not enough. The barrier
pointer could become NULL during _destroy.
I'm currently working on a better diff which I'll post once I'm confident
it's good enough.
>
> > On 15 Mar 2016, at 01:30, Tobias Ulmer w
On Wed, Jul 15, 2015 at 12:21:02PM -0400, Adam Van Ymeren wrote:
>
>
> On 15 July 2015 12:18:16 GMT-04:00, Paul Irofti wrote:
> >> After a cold boot the output is as follows.
> >>
> >> 1) Pressing brightness up
> >>
> >> acpithinkpad0: ha
> After a cold boot the output is as follows.
>
> 1) Pressing brightness up
>
> acpithinkpad0: handling event 0x1011
> acpithinkpad0: handling event 0x000
>
> 2) Pressing brightess down
>
> acpithinkpad0: handling event 0x1011
> acpithinkpad0: handling event 0x000
>
>
> Then I suspend zzz,
Can you apply the following diff and tell me what the debug printf says
when you push the brightness buttons before and after suspend?
Index: acpithinkpad.c
===
RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v
retrieving revision 1.4
On Thu, Feb 05, 2015 at 06:54:57AM +, Raf Czlonka wrote:
> On Tue, Feb 03, 2015 at 09:08:38PM GMT, Paul Irofti wrote:
>
> > If it fails, please be kind enough to also apply the following debug
> > diff and supply the output on your dmesg when you press the volume
> &g
On Tue, Feb 03, 2015 at 10:54:07PM +0200, Paul Irofti wrote:
> On Wed, Jan 28, 2015 at 12:54:15AM +, Raf Czlonka wrote:
> > >Synopsis: Volume buttons stop working after suspend/resume cycle
> > >Category: kernel
> > >Environment:
> > Syste
On Wed, Jan 28, 2015 at 12:54:15AM +, Raf Czlonka wrote:
> >Synopsis:Volume buttons stop working after suspend/resume cycle
> >Category:kernel
> >Environment:
> System : OpenBSD 5.6
> Details : OpenBSD 5.6-stable (GENERIC) #0: Tue Jan 27 00:09:23 GMT
> 2015
>
On Fri, Jul 11, 2014 at 08:15:47AM +0200, Alexander Schrijver wrote:
> On Thu, Jul 10, 2014 at 05:42:54AM +0100, Mikolaj Kucharski wrote:
> > Looking at the lines printed, my impression was that acpiasus0 at acpi0
> > is the last line before screen goes blank, so I've disabled acpiasus and
> > it d
This is the important part of the trace:
> 4e10 Store
> 4e11 \\_SB_.PCI0.LPCB.H_EC.CTMP
> locking
> field: aml_rwgas bitpos 1536 bpos 0 blen 8,flags 0x11
> read 03 00c0 0008 [\\_SB_.PCI0.LPCB.H_EC.ECR_]
> gasio rd: 3 0xc0 1 1 851728760
> aml_bufcpy: 0x90
> unlocking
> 4e28 Local0
> 4e29 If
>
On Fri, Apr 18, 2014 at 12:34:44PM +0300, Paul Irofti wrote:
> Closing in... what does this button do?
In case someone wants to chime in and have a look at the issue:
The diff consists of 3 parts:
- acpiec clear events on resume
Closing in... what does this button do?
Index: dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.205
diff -u -p -r1.205 dsdt.c
--- dsdt.c 12 Dec 2013 20:56:01 - 1.205
+++ dsdt.c 18 Apr 2014
Thanks for testing!
I need a bit more info, could you tell me what the output is when
applying the following diff on top of -current?
Index: dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.205
diff -u -p -r
> I applied the previous patch to a fresh checked out source tree which didn't
> contain below changes. Should I have applied several patches together?
Nope. The way you applyed and tested is correct. Thanks!
In general I don't send diffs on top of other diffs as it just makes it
confusing for all
> I'll send a tracing diff your way soon because I'm curious what the
> AML path is inside _TMP once your machine resumes.
Here it is. Careful it might be really noisy and further tweaks might be
needed. Let me know what the output is and I'll see what needs to be
done next.
Note, I'm interested
Very strange...
I'm still investigating the issue and glancing at your acpidump.
I'll send a tracing diff your way soon because I'm curious what the
AML path is inside _TMP once your machine resumes.
Until then I wanted to ask you if you're also testing with the glk diff
when you're testing my ac
Hi Remi,
thank you for the detailed report and for your patience.
I was wondering if you could test the following diff and let me know
what happens.
Thanks,
Paul
Index: dev/acpi/acpiec.c
===
RCS file: /cvs/src/sys/dev/acpi/acpiec.c
On Mon, Feb 03, 2014 at 02:52:57PM +0200, Manolis Tzanidakis wrote:
> Hello,
> I' m getting random crashes on resume from suspend on my ASUS Eeeepc
> 1000H. It runs GENERIC.MP i386 -current as of 20140202 snapshot.
> I've let memtest86+ run over night without problems to eliminate bad
> RAM issues.
On Tue, Feb 04, 2014 at 04:11:08PM +0200, Paul Irofti wrote:
> On Mon, Feb 03, 2014 at 02:52:57PM +0200, Manolis Tzanidakis wrote:
> > Hello,
> > I' m getting random crashes on resume from suspend on my ASUS Eeeepc
> > 1000H. It runs GENERIC.MP i386 -current as of 20140
On Mon, Feb 11, 2013 at 10:33:21PM +0100, Mark Kettenis wrote:
> >
> > On Mon, Feb 11, 2013 at 12:33:17PM +0100, Charles Rapenne wrote:
> > > >Synopsis: Boot hang on laptop with acpi enabled
> > > >Category: i386
> > > >Environment:
> > > System : OpenBSD 5.3
> > > D
On Mon, Feb 11, 2013 at 04:08:47PM +0200, Paul Irofti wrote:
> On Mon, Feb 11, 2013 at 12:13:29AM +0100, frantisek holop wrote:
> > hmm, on Sun, Feb 10, 2013 at 12:04:37PM +0200, Paul Irofti said that
> > > Can you reproduce this consitently?
> >
> > i wouldn&#
On Mon, Feb 11, 2013 at 12:33:17PM +0100, Charles Rapenne wrote:
> >Synopsis: Boot hang on laptop with acpi enabled
> >Category: i386
> >Environment:
> System : OpenBSD 5.3
> Details : OpenBSD 5.3-beta (GENERIC.MP) #27: Mon Feb 4
> 01:27:42 MST 2013
>
> t...@i38
On Mon, Feb 11, 2013 at 12:13:29AM +0100, frantisek holop wrote:
> hmm, on Sun, Feb 10, 2013 at 12:04:37PM +0200, Paul Irofti said that
> > Can you reproduce this consitently?
>
> i wouldn't say consistently but oftenish.
> it just happened again right after i started
Can you reproduce this consitently?
It would make it easier to debug for me.
> vga1 at pci0 dev 1 function 0 vendor "ATI", unknown product 0x980a rev 0x00
Is this the Wrestler [Radeon HD 7290]? Can you try with a recent
snapshot?
On Thu, Sep 13, 2012 at 08:50:06AM -0500, joshua stein wrote:
> On Thu, 13 Sep 2012 at 13:21:54 +0300, Paul Irofti wrote:
> > On Wed, Sep 12, 2012 at 09:12:20PM -0500, joshua stein wrote:
> > > asus ux31a running amd64 sept 11 snapshot, newest bios (happened
> > >
On Wed, Sep 12, 2012 at 09:12:20PM -0500, joshua stein wrote:
> asus ux31a running amd64 sept 11 snapshot, newest bios (happened
> with older one too), panics during acpi configuration.
Does this help?
Index: dev/acpi/acpicpu.c
===
R
On Mon, Sep 10, 2012 at 03:30:38PM +0200, mwanamut...@gmail.com wrote:
> >Synopsis:LCD brigtness on Thinkpad T61 can not be adjusted without
> >rebooting
> >Category:Thinkpad t61 hotkey
> >Environment:
> System : OpenBSD 5.2
> Details : OpenBSD 5.2-current (GENERIC.MP
On Wed, May 30, 2012 at 09:33:38PM -0700, Philip Guenther wrote:
> The problem was in the handling of munlock(addr, 0). The zero length case
> wasn't detected, resulting in an iterator being started after its end
> point. :-/
>
> The diff below fixes the code to have munlock() return success w
On Mon, Feb 06, 2012 at 10:40:17AM +, Stuart Henderson wrote:
> Bleh. Why would you post a patch with an invalid sender address?!
Spam I guess. At least that's what the signature says...
And yes, I know it was probably a rethorical question.
This is from an older snapshot but I thought it might still interest
somebody, dmesg at the end.
ddb> trace
Debugger(d08d3b58,da72ad88,d08b3020,da72ad88,d580ae58) at Debugger+0x4
panic(d08b3020,d08bcc60,da79d000,da79d2cc,dc) at panic+0x5d
pool_do_get(d0a2f320,a,da72adfc,d03d88b3,d54245ac) at pool_
On Sun, Nov 27, 2011 at 03:09:38PM -0500, Ted Unangst wrote:
> On Sun, Nov 27, 2011, Paul Irofti wrote:
> > $ pwd
> > /var
> > $ sudo du -sh .
> > 2.1G.
> > $ df -h | grep var
> > /dev/wd1e 3.9G3.8G -7.3M 100%/var
> > $ mount | g
$ pwd
/var
$ sudo du -sh .
2.1G.
$ df -h | grep var
/dev/wd1e 3.9G3.8G -7.3M 100%/var
$ mount | grep var
/dev/wd1e on /var type ffs (local, nodev, nosuid)
$ grep var /etc/fstab
/dev/wd1e /var ffs rw,nodev,nosuid 1 2
The issue never went away until I rebooted the machine. Great
What happens when you run with this diff?
Index: acpivout.c
===
RCS file: /cvs/src/sys/dev/acpi/acpivout.c,v
retrieving revision 1.9
diff -u -p -r1.9 acpivout.c
--- acpivout.c 23 May 2011 11:58:03 - 1.9
+++ acpivout.c 21 Oc
On Tue, Oct 18, 2011 at 07:38:49PM -0500, joshua stein wrote:
> acpi panic on an asus ux21 with the latest amd64 snapshot installed
> a few minutes ago. disabling acpivout lets it boot.
>
> acpidump at http://jcs.org/tmp/asusux21.tar.gz
Yet another one... I'll look into it asap.
On Tue, Aug 09, 2011 at 09:59:09PM -0400, Kenneth R Westerback wrote:
> On Tue, Aug 09, 2011 at 04:21:10PM -0400, Andre Inglis wrote:
> > Hi OpenBSD team,
> >
> > Sorry but I could not use any built in services to send this report but I
> > have included what I could. If you need any more informati
On Sat, Jun 11, 2011 at 10:03:12PM +0200, Javier Vazquez wrote:
> Hello Paul,
Hello
> First, thanks for taking your time coaching me :D, I really
> appreciate that.
You're welcomed.
> I send you the required patch files. Also I added another
> Toshiba models such as L
Good progress! This is almost commitable :-)
Some nits: use `cvs diff -uNp` and be careful about spacing.
Going to comment more on the diff inline.
diff -p -u5 -r -N /usr/src.orig/sys/arch/i386/conf/GENERIC
/usr/src/sys/arch/i386/conf/GENERIC
--- /usr/src.orig/sys/arch/i386/conf/GENERICFri
Tricked by gnats@ again...
Okay, what happens when you try only this diff:
Index: dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.185
diff -u -p -r1.185 dsdt.c
--- dsdt.c 22 Apr 2011 18:22:01 -
Sending to bugs@ as well -- don't know what gnats@ is doing...
Okay, the ASUS AML for _BCL is a total bust. It might need a separate
driver. Out of curiosity, can you tell me if with this patch your system
boots and brightness works?
Index: acpivout.c
=
On Mon, Apr 04, 2011 at 06:32:48AM -0400, Kenneth R Westerback wrote:
> On Mon, Apr 04, 2011 at 11:43:24AM +0200, Mark Kettenis wrote:
> > > Date: Mon, 4 Apr 2011 09:53:10 +0100
> > > From: Stuart Henderson
> > >
> > > On 2011/04/03 21:42, Sha'ul wrote:
> > > > I install, reboot, and get kernal p
On Tue, Mar 15, 2011 at 12:24:24PM +0100, Vladim?r Kotal wrote:
> I am now running 4.9-current kernel (from 12th March, ohci.c still at
> version 1.103) and userland bits from 4.8-release. The uow device is
Userland from 4.8-release with a 4.9-current kernel, any reason for
choosing this particula
78 matches
Mail list logo
