https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229087
Andriy Gapon changed:
What|Removed |Added
Status|New |Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=163461
Shane changed:
What|Removed |Added
CC||free...@shaneware.biz
--- Comment #3 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106
Bug ID: 229106
Summary: intr_event_handle is unsafe with respect to interrupt
handler list
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229107
Bug ID: 229107
Summary: linprocfs: implement /dev/tty/drivers
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affe
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229107
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|emulat...@freebsd.org
--
You are r
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213501
--- Comment #7 from John Baldwin ---
(In reply to Andriy Gapon from comment #6)
Yes, X with VESA will most likely not work aside from an older BIOS.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106
--- Comment #1 from John Baldwin ---
This is an old race. I have a very old p4 branch that dedicates a spin lock to
protecting the list of handlers (and then uses that as the thread_lock of idle
interrupt threads so that the number of spin
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106
--- Comment #2 from Andriy Gapon ---
Yes, it's an old one.
I think that using a spinlock is perfectly fine.
I also have a work-in-progress that tries to solve the problem with some atomic
magic so that intr_event_handle is completely wait /
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106
Conrad Meyer changed:
What|Removed |Added
CC||c...@freebsd.org
--- Comment #3 fro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106
--- Comment #4 from Conrad Meyer ---
Is this list a good candidate for epoch(9)-based reclamation? :-)
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106
--- Comment #5 from John Baldwin ---
I suspect you cannot use epoch(9) in primary interrupt context (e.g. filters)
just as you can't use regular mutexes there.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106
--- Comment #6 from Andriy Gapon ---
But a similar approach might work.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106
--- Comment #7 from Conrad Meyer ---
Where does epoch(9) take a regular mtx? I may just be missing it, but I see
only spin mutexes.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229120
Bug ID: 229120
Summary: [acpi_ibm] [patch] Add support for newer Thinkpad
models with id LEN0268
Product: Base System
Version: 11.0-STABLE
Hardware: amd64
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229120
Mark Linimon changed:
What|Removed |Added
Keywords||patch
Assignee|b...@freeb
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228755
Mahmoud Al-Qudsi changed:
What|Removed |Added
Keywords||crash, panic
Hardware
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190281
Marie Helene Kvello-Aune changed:
What|Removed |Added
CC||mariehelen...@gmail.com
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190281
--- Comment #4 from Marie Helene Kvello-Aune ---
... And I just realized I didn't see the comment by Eitan Adler before starting
to dig into this. Oops.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106
--- Comment #8 from Andriy Gapon ---
(In reply to Conrad Meyer from comment #7)
I don't know epoch(9) / ck_epoch implementation details, but given the
constraints[*] of interrupt handling, I think that it could be an overkill. I
mean, it p
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106
--- Comment #9 from Conrad Meyer ---
(In reply to Andriy Gapon from comment #8)
Yes, performance of add/remove doesn't matter. But performance of
intr_event_handle() matters very much, and adding a contested spin lock to it
seems like a ba
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106
--- Comment #10 from John Baldwin ---
To be clear, we are not talking about adding a spin mutex. We are talking
about replacing the existing sched_lock mutex used to schedule the ithread
anyway with a dedicated spin mutex that protects the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106
--- Comment #11 from Conrad Meyer ---
Sure. It'd still be a single global spin lock, right?
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.or
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106
--- Comment #12 from John Baldwin ---
No, it is kind of per-IRQ, not global.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
h
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106
--- Comment #13 from Conrad Meyer ---
Oh, that's much better.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.fr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203349
Bug 203349 depends on bug 223806, which changed state.
Bug 223806 Summary: java/openjdk8: [PATCH] arm64 package builds do not allow
enough time for build to complete
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223806
What
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211713
Ali Abdallah changed:
What|Removed |Added
CC||ali...@gmail.com
--- Comment #62 fr
26 matches
Mail list logo
