https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233430
lbartoletti changed:
What|Removed |Added
Resolution|--- |Unable to Reproduce
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232313
Mateusz Kwiatkowski changed:
What|Removed |Added
CC||kwia...@panic.pl
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234413
topical changed:
What|Removed |Added
CC||topi...@gmx.net
--- Comment #9 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234741
--- Comment #7 from David Chisnall ---
(In reply to Andriy Gapon from comment #6)
No, and the size reported in loader appears to be wrong. In dmesg, it shows
as:
da1: 524288MB (1073741824 512 byte sectors
I wonder if this is part of
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234741
--- Comment #8 from Toomas Soome ---
(In reply to David Chisnall from comment #7)
Ok, so your second disk is not partitioned and the size is misreported, that is
bad.
The update in stable and current will ignore unpartitioned disks, but
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234741
--- Comment #9 from Andriy Gapon ---
(In reply to David Chisnall from comment #7)
I think that the incorrect size is the problem.
We use a size reported by BIOS or in a partition table as the size.
In this case, most of the second disk
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234741
David Chisnall changed:
What|Removed |Added
CC||dex...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234413
--- Comment #10 from Mark Johnston ---
(In reply to topical from comment #9)
I don't think it makes sense to return EOPNOTSUPP when Q_GETQUOTA fails because
no quota is configured. UFS already uses EINVAL in this case, and it is in
fact
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234741
--- Comment #10 from Toomas Soome ---
(In reply to Andriy Gapon from comment #9)
Woops, but in that case we are indeed in trouble, because we do not probe the
partitionless disks.
So in this case, we have few options:
1. can we install
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234741
--- Comment #12 from Toomas Soome ---
(In reply to David Chisnall from comment #11)
The problem with disk sizes, BIOS, and kernel is that kernel has its own
drivers to read the disk size - whatever type of disk is there, we do have
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233989
Robert Clausecker changed:
What|Removed |Added
CC||f...@fuz.su
--- Comment #5
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198030
Gerald Aryeetey changed:
What|Removed |Added
CC||gndar...@uwaterloo.ca
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234296
Mark Johnston changed:
What|Removed |Added
Assignee|b...@freebsd.org|ma...@freebsd.org
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234296
--- Comment #7 from Mark Johnston ---
I looked at the kernel dumps. In all three cases, we crashed while processing
a callout that had been mostly zeroed out. However, in all cases, at offset
0x10 into the callout there is a pointer in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234296
--- Comment #8 from Mark Johnston ---
sizeof(struct vnode) == 480, so it looks like this is a use-after-free in the
512 byte malloc zone. The callout is at offset 0xb8 into the structure. Based
on some skimming of the CTF type graph,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234042
Mark Johnston changed:
What|Removed |Added
CC||ma...@freebsd.org
--- Comment #6
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234567
Mark Johnston changed:
What|Removed |Added
CC||ma...@freebsd.org
--- Comment #7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234413
Mark Linimon changed:
What|Removed |Added
Keywords||patch
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234413
--- Comment #12 from Mark Johnston ---
(In reply to Sean Eric Fagan from comment #11)
LGTM, thanks.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231457
--- Comment #10 from di...@dz.dn.ua ---
I experimented with a stable/11 branch on 2GB RAM and 8GB swap space with
r320475 "world" used, looking for the moment of kernel problems begins.
Swap on ZFS is unstable from revision r321453
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234838
--- Comment #2 from Leif Pedersen ---
Of course! Thanks for looking!
It's our standby MySQL database, so there's a light but steady stream of
network IO for the DB replication. Its filesystems are ZFS. Once an hour, six
other machines
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234042
--- Comment #10 from Mark Johnston ---
(In reply to Mike Andrews from comment #9)
Would you be willing to share the vmcores with me, along with a copy of the
corresponding /boot/kernel and /usr/lib/debug/boot/kernel?
--
You are receiving
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234042
--- Comment #7 from Greg Rivers ---
For me the panic occurs at boot time during kernel probing and device
enumeration. It's possible that the panic happens right at the hand-off to
init, but there's no indication that /etc/rc ever gets
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234413
--- Comment #11 from Sean Eric Fagan ---
Created attachment 201007
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=201007=edit
Return EINVAL if no quotas are present
Obviously I have no objection to this ;).
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234042
--- Comment #8 from Mark Johnston ---
(In reply to Greg Rivers from comment #7)
I suspect that the boot-time panic is unrelated. Would you be willing to file
a separate PR and CC me? Could you also include a verbose dmesg (boot -v at
the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181131
Vincenzo Maffione changed:
What|Removed |Added
Resolution|--- |Overcome By Events
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234838
--- Comment #1 from Colin Percival ---
Thanks for reporting this. Can you tell me anything about the workload this
instance is seeing? Amount of bandwidth, TCP vs UDP, large packets vs small
packets, anything else which seems like it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234413
Sean Eric Fagan changed:
What|Removed |Added
Resolution|--- |FIXED
Status|New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234042
--- Comment #9 from Mike Andrews ---
All of my systems are dual-stack v4/v6, and the panics happen after a few days
of uptime. Not boot-time. If it was boot-time I wouldn't have finished
upgrading the whole rack. :)
There shouldn't be
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230722
Warner Losh changed:
What|Removed |Added
Priority|--- |Normal
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230722
--- Comment #13 from Warner Losh ---
I understand what I must do next, but haven't had the time to do the changes
for the next round of testing because of time off around the holidays, travel,
etc.
--
You are receiving this mail because:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230465
--- Comment #4 from Vincenzo Maffione ---
The compilation problems have been fixed.
Which FreeBSD version are you using? We need to understand if your ixl driver
is backed by iflib or not.
--
You are receiving this mail because:
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234838
Bug ID: 234838
Summary: ena drop-outs on 12.0-RELEASE
Product: Base System
Version: 12.0-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity:
33 matches
Mail list logo
