On Wed, Dec 11, 2019 at 10:26:41AM -0600, Eric van Gyzen wrote:
> Since ino64 went in, Coverity complains that the two "ino >= foo"
> comparisons in ffs_fhtovp() compare a 64-bit value to a 32-bit. Is this
> a problem in practice?
I do not think that this a problem, and Coverity could be a bit
Hartmann, O. wrote on 2019/12/11 19:07:
The AMI BIOS is at 2.10.1208 from 4th Nov 2012. There is a newer
firmware available, but I can't install the firmware: while being able
to UEFI USB flahes, it is impossible to boot FreeDOS 1.1 from an USB
flash drive, even having properly set Legacy Boot R
On Wed, 11 Dec 2019 10:48:22 +0100
Gary Jennejohn wrote:
> On Wed, 11 Dec 2019 08:23:59 +0100
> "Hartmann, O." wrote:
>
> > Hello folks,
> >
> > my apology for polluting this list with a non-FreeBSD specific
> > problem, but since Supermicro is a veryy often used vendor in the
> > FreeBSD user
Since ino64 went in, Coverity complains that the two "ino >= foo"
comparisons in ffs_fhtovp() compare a 64-bit value to a 32-bit. Is this
a problem in practice?
Eric
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listi
I wonder if there have been any bug fixes in that area over the past year or so.
Any help and pointers are welcome.
Hi,
A long time ago I fixed an issue for ARM:
http://svnweb.freebsd.org/changeset/base/265913
I've always wondered why x86 does some fixed amount of idle spins before
going to
On 11/12/2019 13:05, Konstantin Belousov wrote:
> On Wed, Dec 11, 2019 at 12:48:36PM +0200, Andriy Gapon wrote:
...
>> tdq_oldswitchcnt = 26, tdq_lowpri = 92 '\\', tdq_ipipending = 0 '\000',
>> tdq_idx
...
> What is the value of tdq_ipipending ?
> See https://reviews.freebsd.org/D22758
It's zero
On 11/12/2019 12:48, Andriy Gapon wrote:
> So, if I am not confused, it appears like possibly a notification from a
> waking
> CPU to the woken CPU (CPU3) was never delivered.
> Potentially, a problem with cpu_idle_wakeup() ?
>
> I wonder if there have been any bug fixes in that area over the pas
On Wed, Dec 11, 2019 at 12:48:36PM +0200, Andriy Gapon wrote:
>
> I am investigating a problem that originally looked like a ZFS I/O hang.
> But it quickly became obvious that the GEOM "up" queue was not being
> processed.
> (kgdb) p g_bio_run_up
> $54 = {bio_queue = {tqh_first = 0xf801d86271
I am investigating a problem that originally looked like a ZFS I/O hang.
But it quickly became obvious that the GEOM "up" queue was not being processed.
(kgdb) p g_bio_run_up
$54 = {bio_queue = {tqh_first = 0xf801d8627178, tqh_last =
0xf80134751658}, bio_queue_lock = {lock_object = {lo_na
On Wed, 11 Dec 2019 08:23:59 +0100
"Hartmann, O." wrote:
> Hello folks,
>
> my apology for polluting this list with a non-FreeBSD specific problem,
> but since Supermicro is a veryy often used vendor in the FreeBSD
> user/developer community I might find help here much fast.
>
> I got hands on
10 matches
Mail list logo
