https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278311
--- Comment #5 from Joel Bodenmann ---
Does not seem to work yet. Still not getting any temperatures (via sysctl or
sysutils/hwstat).
Looking through /var/log/messages I see:
7306 Apr 12 00:37:15 hedt1 kernel: amdtemp0:
on hostb24
7307
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278311
--- Comment #4 from Xin LI ---
Created attachment 249918
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249918=edit
Add support for F19 M10 (0x10..0x1f)
Could you please try this patch?
--
You are receiving this mail because:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278316
--- Comment #6 from Henrich Hartzer ---
Pull request on Github: https://github.com/freebsd/freebsd-src/pull/1164
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278316
--- Comment #5 from Henrich Hartzer ---
I got it working! Patch is attached.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278316
--- Comment #4 from Henrich Hartzer ---
Created attachment 249917
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249917=edit
Atom S1200 UART support
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278311
--- Comment #3 from Joel Bodenmann ---
Created attachment 249916
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249916=edit
dmesg.boot
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278311
--- Comment #2 from Joel Bodenmann ---
Created attachment 249915
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249915=edit
pciconf
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278316
--- Comment #3 from Henrich Hartzer ---
>From FreeBSD, dmesg also shows IRQ 16. But sysctl -a seems to say that IRQ 32
is in use for the uart. I've had no luck forcing it to use IRQ 16.
But... with debug.uart_force_poll = 1, it works!
So
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278311
Xin LI changed:
What|Removed |Added
CC||delp...@freebsd.org
--- Comment #1 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265884
Xin LI changed:
What|Removed |Added
CC||delp...@freebsd.org
--- Comment #1 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278316
--- Comment #2 from Henrich Hartzer ---
I tried to force IRQ 16 (FreeBSD uses 32) with device.hints, but it stays at
IRQ 32. I'm not sure if this is a problem or not.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278316
--- Comment #1 from Henrich Hartzer ---
I just verified that this is working on a hardware level by booting Linux Mint
and testing the port.
dmesg (from Linux) said: "ttyS4 at I/O 0xf000 (irq = 16, base_baud = 115200) is
a 16550A"
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278316
Bug ID: 278316
Summary: Intel Atom S1200 (Centerton) serial UART not working
Product: Base System
Version: 14.0-RELEASE
Hardware: amd64
OS: Any
Status: New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
--- Comment #12 from Alan Somers ---
(In reply to Rick Macklem from comment #11)
fuse_vnop_read or fuse_vnop_write might return EINTR if:
* uiomove(9) returns ERESTART or EINTR
* getblk returns NULL
* bwrite returns EINTR
* If a signal is
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
Rick Macklem changed:
What|Removed |Added
CC||asom...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276961
Dimitry Andric changed:
What|Removed |Added
Status|New |Open
CC|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278311
Joel Bodenmann changed:
What|Removed |Added
Severity|Affects Only Me |Affects Some People
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278311
Bug ID: 278311
Summary: amdtemp: Does not recognize AMD Threadripper 7960X
Product: Base System
Version: Unspecified
Hardware: Any
OS: Any
Status: New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278295
Mark Linimon changed:
What|Removed |Added
Keywords||regression
--
You are receiving
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277450
--- Comment #16 from Thomas Dreibholz ---
FreeBSD is the guest system in VirtualBox. It does not have any VirtualBox
guest utilities port installed when the issue occurs. I only tried Linux as
VirtualBox host, yet.
I useful place for some
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277450
--- Comment #15 from Oleksandr Kryvulia ---
(In reply to Thomas Dreibholz from comment #14)
I think port's pkg-message is a right place.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278305
Yuri Victorovich changed:
What|Removed |Added
CC||d...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278305
Bug ID: 278305
Summary: clang crashes: fatal error: error in backend: Cannot
select: t71: v32bf16 = insert_subvector t67, t64,
Constant:i32<16> (on the port misc/ncnn)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234576
Trenton Hensley changed:
What|Removed |Added
CC||childrenlopside...@gmail.co
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271259
Neil Phillips changed:
What|Removed |Added
CC||tensepeb...@gmail.com
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
--- Comment #10 from Rick Macklem ---
I believe the EINTR would be coming from the I/O
operation done by sshfs. For the NFS mounts, it
occurs for "soft" mounts when the NFS server takes
too long to reply to an RPC.
- It was returned by the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277677
--- Comment #1 from Henrich Hartzer ---
Opened a pull request for this:
https://github.com/freebsd/freebsd-src/pull/1161
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278295
Bug ID: 278295
Summary: add net 128.0.0.0: gateway 10.8.1.1 fib 1: Invalid
argument
Product: Base System
Version: 14.0-RELEASE
Hardware: Any
OS: Any
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235136
Michael Osipov changed:
What|Removed |Added
CC||micha...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
--- Comment #9 from Ivan Rozhuk ---
I suspect that more correct is ignore EINTR error limited times and only then
fallback to generic copy.
So IMHO usage pattern must be one of:
size_t ntry;
const size_t max_ntry = 5;
for (ntry = 0;
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
--- Comment #8 from Ivan Rozhuk ---
(In reply to Mark Johnston from comment #7)
According to man copy_file_range [1] EINTR also may happen "for files on some
NFS mounts.", so it is not new problem, it is documented behavior.
You may ask
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
--- Comment #7 from Mark Johnston ---
(In reply to Ivan Rozhuk from comment #6)
Well, I'm not going to commit a patch that works around an unknown problem in
just one utility that happens to use copy_file_range().
I'm not asking you to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
--- Comment #6 from Ivan Rozhuk ---
(In reply to Mark Johnston from comment #5)
I have no idea why this happen.
I do not try to run cp under ktrace and have no plans to debug whole kernel fs
stack.
My investigation was: "what happen with
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985
--- Comment #8 from Vlad Biley ---
(In reply to feh from comment #7)
Hi Erwin,
Thanks for your reply. Here's my story in detail:
https://www.reddit.com/r/freebsd/comments/1b80lpi/gpu_has_fallen_off_the_bus_a_sad_story_about_my/
I wrote
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985
--- Comment #7 from f...@fehcom.de ---
Hi Vlad,
thanks for your comment. On my side, there is a bit more history:
a) Before I used the current MiniPC with AMD Ryzen 5, I had a similar device
with Ryzen 7, a Gigabyte BRR7-4800.
b) Here,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985
--- Comment #6 from Vlad Biley ---
(In reply to feh from comment #4)
>finally, there is a pattern: The crash happens moving objects (files) by means
>of Gnome's nemo on the desktop (copy/move files).
Unfortunately (or fortunately?), I
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985
--- Comment #5 from Vlad Biley ---
Created attachment 249875
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249875=edit
core.txt
Hi. This is a follow-up to my comment #3. On my previous RX 560 GPU, crashes
happened frequently
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985
f...@fehcom.de changed:
What|Removed |Added
Severity|Affects Only Me |Affects Some People
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278286
Bug ID: 278286
Summary: file(1) man page fixes
Product: Documentation
Version: Latest
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278283
--- Comment #1 from w...@psr.com ---
typo: I meant "now in the calendar-data port"
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278283
Bug ID: 278283
Summary: /usr/bin/calendar: 11 bugs fixed, major improvements
[tarball]
Product: Base System
Version: Unspecified
Hardware: Any
OS:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275965
--- Comment #2 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=493908c4b45c7b75e4a6b4aea3b5b63ea5c268d5
commit 493908c4b45c7b75e4a6b4aea3b5b63ea5c268d5
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278281
Bug ID: 278281
Summary: /usr/sbin/fstyp potential read through wild pointer
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=27810
--- Comment #2 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/ports/commit/?id=6e5c3c7067c582416bead63f34ce07e06a86
commit 6e5c3c7067c582416bead63f34ce07e06a86
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=82881
Zhenlei Huang changed:
What|Removed |Added
Status|Open|Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195407
Mark Johnston changed:
What|Removed |Added
CC||ma...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278265
--- Comment #1 from Oleg Streejak ---
Created attachment 249853
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249853=edit
adds stdout flush to generic output function
the proposed patch. I've compiled and tested route - now it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
--- Comment #5 from Mark Johnston ---
But why is copy_file_range() returning EINTR? What happens if you run cp under
ktrace (so that signals are logged as well)?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277992
--- Comment #7 from m...@sentex.net ---
I let the job continue over night and it continues to get slower on writes. i.e
after doing a trim -f /dev/da[disk in pool]/p1 one by one, the tests start out
fast (~ 300MB of files in the zfs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277992
--- Comment #7 from m...@sentex.net ---
I let the job continue over night and it continues to get slower on writes. i.e
after doing a trim -f /dev/da[disk in pool]/p1 one by one, the tests start out
fast (~ 300MB of files in the zfs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278271
Yuri Victorovich changed:
What|Removed |Added
URL||https://gcc.gnu.org/bugzill
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278271
Bug ID: 278271
Summary: Bug in LLVM's libc++ breaks g++13 (build of
math/ceres-solver is broken on armv7)
Product: Base System
Version: 14.0-STABLE
Hardware: arm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277992
--- Comment #6 from m...@sentex.net ---
OK, as suspected. I stopped the test, reset the TRIM method to ATA_TRIM,
offlined the disk one by one and did a trim -f /dev/da[disk]p1 one by one and
resilvered the pool. After that, I got normal
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276770
--- Comment #8 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=9fc935855951ff8277c669b2aa248fde63a10175
commit 9fc935855951ff8277c669b2aa248fde63a10175
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278265
Bug ID: 278265
Summary: `route -n monitor' is quiet when redirecting its
output
Product: Base System
Version: 14.0-STABLE
Hardware: amd64
OS: Any
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276770
--- Comment #7 from commit-h...@freebsd.org ---
A commit in branch stable/14 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=7d763eadd36e9b9419379756add71f5383f40af0
commit 7d763eadd36e9b9419379756add71f5383f40af0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278245
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|virtualizat...@freebsd.org
--
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278234
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|emulat...@freebsd.org
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278232
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|j...@freebsd.org
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278220
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=130238
Dag-Erling Smørgrav changed:
What|Removed |Added
Severity|Affects Only Me |Affects Some People
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278234
--- Comment #3 from Zeev Zilberman ---
This seems like a good reference for sysfs:
https://cromwell-intl.com/open-source/sysfs.html
For reference, on a Linux system with 2 domains, a switch connected to each
domain and 2 devices behind
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274538
Alex S changed:
What|Removed |Added
CC||iwt...@gmail.com
--- Comment #3 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277538
--- Comment #5 from Mark Johnston ---
I believe that this commit will prevent that particular panic, but indeed,
we're not going to recover well from a swap device being removed.
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277538
--- Comment #4 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=4696650782e2e5cf7ae5823f1de04550c05b5b75
commit 4696650782e2e5cf7ae5823f1de04550c05b5b75
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277992
--- Comment #5 from m...@sentex.net ---
Created attachment 249831
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249831=edit
charting write throughput (90 second pauses between tests)
Good news / bad news. The test continued
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278232
Michael Osipov changed:
What|Removed |Added
CC||cperc...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278232
--- Comment #2 from Dirk Meyer ---
FreeBSD-13.3 was not tested.
My Workaround is to use pf NAT on the HOST.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278232
--- Comment #1 from Michael Osipov ---
Did you try 13.3 actually?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278245
Bug ID: 278245
Summary: sendfile to bhyve VM on same host fails with MEXTPG
Product: Base System
Version: 14.0-RELEASE
Hardware: amd64
OS: Any
Status: New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=130238
Jamie Landeg-Jones changed:
What|Removed |Added
CC||ja...@catflap.org
---
To view an individual PR, use:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277992
--- Comment #4 from m...@sentex.net ---
With max trim set to 1/4 of the default value, I still get random errors. In
this case, I set all 4 drives to
sysctl -w kern.cam.da.7.delete_max=4294901760
kern.cam.da.7.delete_max: 17179607040 ->
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278234
--- Comment #2 from Konstantin Belousov ---
Created attachment 249811
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249811=edit
Fix for the panic, but the layout does not match Linux
This is the patch I have. As noted, the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278234
Konstantin Belousov changed:
What|Removed |Added
CC||k...@freebsd.org
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272965
--- Comment #14 from ludwigp-fbsdb...@chip-web.com ---
I saw the same panic (except on tcp_input) on FreeBSD 13.x, FreeBSD 14 and
FreeBSD 15 snapshots from 20240404, just from receiving an IPv4 SSH connection
over the "ure" network
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278220
Marek Zarychta changed:
What|Removed |Added
CC||zarych...@plan-b.pwste.edu.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278234
Bug ID: 278234
Summary: linsysfs assumes pci domain
Product: Base System
Version: 15.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278230
--- Comment #5 from Aleksei Sukhoguzov ---
(In reply to Andrey Korobkov from comment #4)
Yeah, now I understand. Glad you solved the problem :)
Cheers
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278230
--- Comment #4 from Andrey Korobkov ---
Sorry, I wasn't clear enough: the issue I had with history in tcsh(1) was
syncing the history after each issued command between multiple terminal session
in gnome-terminal(1) tabs.
The solution was
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278230
--- Comment #3 from Andrey Korobkov ---
I have these in my ~/.cshrc:
set history = 1
set savehist = ($history merge lock)
And it doesn't work for me. What I may be doing wrong? What to check some more
times?
--
You are receiving
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278232
Dirk Meyer changed:
What|Removed |Added
Keywords||regression
--
You are receiving
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278232
Bug ID: 278232
Summary: Jail IPv4 source address selection inside a jail not
working
Product: Base System
Version: 14.0-RELEASE
Hardware: amd64
OS:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278230
--- Comment #2 from Aleksei Sukhoguzov ---
(In reply to Andrey Korobkov from comment #1)
I don't use tcsh(1) myself, but it does have a 'merge' option in the 'savehist'
variable that seems to do exactly this, or am I missing something?
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278230
Andrey Korobkov changed:
What|Removed |Added
CC||als...@vinterdalen.se
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278230
Bug ID: 278230
Summary: sh: Multiple instances overwrite each other's history
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278229
Bug ID: 278229
Summary: iconv mapping tables for ISO 8859-2 and 8859-3 contain
garbage
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278220
Dirk Meyer changed:
What|Removed |Added
Keywords||regression
--- Comment #1 from Dirk
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278220
Bug ID: 278220
Summary: gre: route add -iface invalid argument
Product: Base System
Version: 14.0-RELEASE
Hardware: Any
OS: Any
Status: New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277886
Warner Losh changed:
What|Removed |Added
CC||i...@freebsd.org
--- Comment #4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277886
--- Comment #3 from Tomoaki AOKI ---
(In reply to Xin LI from comment #2)
> I think the ask is simply make check_feature() and check_mos_features()
> (/stand/libsa/zfs/zfsimpl.c) to always return 0 instead of EIO even if
> the feature is
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=130238
Vick Khera changed:
What|Removed |Added
CC||vi...@khera.org
--- Comment #3 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278195
Mark Linimon changed:
What|Removed |Added
Keywords||regression
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278195
Bug ID: 278195
Summary: daemon is exiting without informing that it failed to
execute
Product: Base System
Version: 13.3-RELEASE
Hardware: amd64
OS:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277886
Xin LI changed:
What|Removed |Added
CC||delp...@freebsd.org,
|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=130238
Chris Davidson changed:
What|Removed |Added
CC||Christopher.davidson@gmail.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277886
Tomoaki AOKI changed:
What|Removed |Added
CC||junch...@dec.sakura.ne.jp
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277992
--- Comment #3 from m...@sentex.net ---
(In reply to Warner Losh from comment #2)
Thanks for looking Warner! The disks are in the same server, either in the SAS
enclosure/expander or off the motherboard. Pretty sure power is ok as the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277655
--- Comment #10 from Henrich Hartzer ---
Might it be possible for you or someone else to review my patch?
If I should submit it through another avenue, please let me know!
--
You are receiving this mail because:
You are the assignee for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277992
--- Comment #2 from Warner Losh ---
"Power on reset" sense code means that the drive dropped off the bus
(typically). Usually if you can eliminate flakey power (either bad connectors,
or inadequate power to cope with maximum power draw),
701 - 800 of 62190 matches
Mail list logo
