https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246626
Bug ID: 246626
Summary: netstat -g IPv4 Virtual Interface Table data wrong
Product: Base System
Version: 12.1-STABLE
Hardware: Any
OS: Any
Status: New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246552
Dan Kotowski changed:
What|Removed |Added
CC||dan.kotowski@a9development.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246629
Bug ID: 246629
Summary: Multicast stack problem - MRT_ADD_VIF Address already
in use
Product: Base System
Version: 12.1-STABLE
Hardware: Any
OS: Any
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246630
Bug ID: 246630
Summary: stable/11 regression: base.txz reproducibility depends
on number of cpu cores
Product: Base System
Version: Unspecified
Hardware: amd64
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246630
Conrad Meyer changed:
What|Removed |Added
CC||c...@freebsd.org,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246327
--- Comment #2 from Andrey P. ---
Retried with FreeBSD-13.0-CURRENT-amd64-20200514-r361019-memstick.img
The laptop is set to Legacy BIOS mode in both cases.
Two drives are attached to the laptop:
ada0 - with UFS (successful) installation
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521
--- Comment #52 from Jesper Schmitz Mouridsen ---
looking hard at the linux driver dyndbg output I have managed to read the short
data and getting bus witdh 4 from the SCR :-)
I will add a patch as soon as my code formatting is fixed..
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246638
Bug ID: 246638
Summary: panic on boot: "cannot find a large enough size"
Product: Base System
Version: CURRENT
Hardware: amd64
OS: Any
Status: New
S
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246614
Kyle Evans changed:
What|Removed |Added
CC||b...@freebsd.org,
|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246638
Conrad Meyer changed:
What|Removed |Added
CC||c...@freebsd.org,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521
--- Comment #53 from Jesper Schmitz Mouridsen ---
Created attachment 214731
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=214731&action=edit
can read scr
This was the minimal changes I could make in order to read the scr.
The s
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246638
--- Comment #2 from Rafael Kitover ---
Just tried booting a 12.1-STABLE stick, and that booted fine!
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@fr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521
--- Comment #54 from Gary Jennejohn ---
(In reply to Jesper Schmitz Mouridsen from comment #53)
Thanks! I'll look at it. Note that your rtsx_pci_send_cmd() is basically the
same as rtsx_send_cmd() already in the code. The main difference
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246638
--- Comment #3 from Mark Johnston ---
(In reply to Conrad Meyer from comment #1)
Hmm. In the one place where this function is used, we are allocating memory to
back the vm page array. The selected domain is that of the corresponding page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245807
--- Comment #4 from Bertrand Petit ---
(In reply to andrew from comment #3)
Indeed, a major POLA violation is it, but also it is still a bug since this
"magic behavior" should only select an /usr/obj subdirectory as an objdir only
when that
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245348
--- Comment #6 from Bertrand Petit ---
How could I help to solve this issue?
--
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=204521
--- Comment #55 from Jesper Schmitz Mouridsen ---
Created attachment 214733
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=214733&action=edit
dyndbg output of linux kernel driver
--
You are receiving this mail because:
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521
--- Comment #56 from Jesper Schmitz Mouridsen ---
(In reply to Gary Jennejohn from comment #54)
Yep rtsx_pci_send_cmd should be merged, note that it does not have mmc_cmd cmd
as argument. The dmesg output is now attahced.
--
You are recei
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246638
--- Comment #4 from Conrad Meyer ---
(In reply to Mark Johnston from comment #3)
Might be the e820 or EFI metadata is somewhat erroneous? Just speculating at
this point. phys_segs should help.
@Rafael, bootverbose mode should print out t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246638
--- Comment #5 from Rafael Kitover ---
Here you go:
vm.phys_segs:
SEGMENT 0:
start: 0x1
end: 0x9f000
domain:1
free list: 0x81f0a170
SEGMENT 1:
start: 0x10
end: 0x20
domain:1
free list: 0x
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246638
--- Comment #6 from Conrad Meyer ---
So yep, we have 5 domains but only 4 DIMMS.
Domain 2 has exactly 32GB, domain 4 ditto. Domain 7's got ~28GB, and domain 1
has ~32 GB.
Domain 0 has only ~34 MB. That one seems problematic.
--
You ar
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246614
--- Comment #1 from Kyle Evans ---
Created attachment 214734
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=214734&action=edit
git(1) diff against base
Here's a tentative diff; there's some other WIP that I've already created on
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246638
--- Comment #7 from Rafael Kitover ---
Just a guess, but could the 34MB be the video memory of the crappy video chip
on my server motherboard? Or something like that anyway.
Here is a photo of the panic by the way:
https://photos.app.goo.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246614
--- Comment #2 from Michael Osipov ---
There are several issues with the patch:
* The term "serial" is already taken: by the serial number embedded in the cert
as well as serialNumber as part of the DN. c_rehash talks about decimal digit.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246638
--- Comment #8 from Conrad Meyer ---
(In reply to Rafael Kitover from comment #7)
Probably the 34MB is wrongly carved from some other domain to not have an
unpopulated domain 0. Is it possible the DIMMS are installed in an order not
recomm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246614
--- Comment #3 from Kyle Evans ---
(In reply to Michael Osipov from comment #2)
Acknowledged- I'll fix the patch after WIP lands and wrangle you into a formal
review on Phabricator. Thanks for the review. =-)
--
You are receiving this ma
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246638
--- Comment #9 from Rafael Kitover ---
Created attachment 214737
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=214737&action=edit
12.1-STABLE /var/run/dmesg.boot
--
You are receiving this mail because:
You are the assignee for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246638
--- Comment #10 from Rafael Kitover ---
I set this variable at the loader prompt, and my full dmesg.boot for
12.1-STABLE is attached.
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233101
Ed Maste changed:
What|Removed |Added
CC||ema...@freebsd.org
--- Comment #1 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246191
Ed Maste changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246494
Ed Maste changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246191
--- Comment #1 from Ed Maste ---
Even worse, I tried using the i386 installer on a machine with an existing GELI
encrypted ZFS root. The installer didn't work at first due to PR246494. After
working around that issue I was prompted for the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246494
--- Comment #1 from Ed Maste ---
I observed a failure on a Lenovo X220 while attempting to use
FreeBSD-13.0-CURRENT-i386-20200521-r361307-mini-memstick.img.xz due to this
issue; the system reported
Non-system disk
Press any key to reboot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246494
--- Comment #2 from Ed Maste ---
It looks like this was probably introduced by r342283 which added a 2nd
partition to the i386 memstick. That change was actually a mistake for i386
though, as we do not have any EFI boot support for i386, so
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234775
--- Comment #2 from Conrad Meyer ---
Still 2048 on all x86, probably still disfunctional.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org m
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244149
Conrad Meyer changed:
What|Removed |Added
Keywords||patch
URL|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246638
--- Comment #11 from Conrad Meyer ---
Hm, so this must be us synthesizing a bogus 0-domain:
SRAT: Found memory domain 1 addr 0x0 len 0xa: enabled
SRAT: Found memory domain 1 addr 0x10 len 0xbff0: enabled
SRAT: Found memory doma
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246638
Mark Linimon changed:
What|Removed |Added
Keywords||panic, regression
--
You are recei
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246638
--- Comment #12 from Mark Johnston ---
(In reply to Conrad Meyer from comment #11)
Ah, it'll be the code which registers vm_phys segments for preloaded data and
the kernel page tables. It hard-codes domain 0. Maybe we can defer the
regist
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219075
--- Comment #5 from commit-h...@freebsd.org ---
A commit references this bug:
Author: rgrimes
Date: Fri May 22 03:13:29 UTC 2020
New revision: 361355
URL: https://svnweb.freebsd.org/changeset/base/361355
Log:
Include all currently presen
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246552
--- Comment #3 from Mark Millard ---
(In reply to Dan Kotowski from comment #2)
Does boot -v at the loader prompt print any
extra messages during the boot? Or is it just
the ACPI messages for which none of the printf
happen?
If there are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246649
Bug ID: 246649
Summary: The manual page describing tmpfs doesn't mention
either the ro mount option or the rw mount option.
Product: Documentation
Version: Latest
Har
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521
--- Comment #57 from Gary Jennejohn ---
(In reply to Jesper Schmitz Mouridsen from comment #56)
The mmc cmd is used to report an error to the MMC stack, if one occurs, so
rtsx_send_cmd() would be the better choice in general.
Thanks for loo
43 matches
Mail list logo
