Hi Alexander,
thank you for quick response. I confirm that r354923 fixes this issue in
12-STABLE.
# dmesg | grep ^ses
ses0 at ahciem0 bus 0 scbus6 target 0 lun 0
ses0: SEMB S-E-S 2.00 device
ses0: SEMB SES Device
ses0: pass0,ada0 in 'Slot 00', SATA Slot: scbus0 target 0
ses0: pass1,ada1 in
On Wed, Nov 20, 2019 at 08:18:52PM -0800, Pete Wright wrote:
>
>
> On 11/20/19 8:13 PM, Glen Barber wrote:
> > On Wed, Nov 20, 2019 at 07:57:57PM -0800, Pete Wright wrote:
> > > Hello,
> > > looks like some of the recent commits to usr.sbin/jail/Makefile has broken
> > > CURRENT. I am getting
On 11/20/19 8:13 PM, Glen Barber wrote:
On Wed, Nov 20, 2019 at 07:57:57PM -0800, Pete Wright wrote:
Hello,
looks like some of the recent commits to usr.sbin/jail/Makefile has broken
CURRENT. I am getting this error when attempting a buildworld:
===> usr.sbin/jail (cleandir)
make[4]:
On Wed, Nov 20, 2019 at 07:57:57PM -0800, Pete Wright wrote:
> Hello,
> looks like some of the recent commits to usr.sbin/jail/Makefile has broken
> CURRENT. I am getting this error when attempting a buildworld:
>
> ===> usr.sbin/jail (cleandir)
> make[4]:
Hello,
looks like some of the recent commits to usr.sbin/jail/Makefile has
broken CURRENT. I am getting this error when attempting a buildworld:
===> usr.sbin/jail (cleandir)
make[4]: "/usr/home/pete/git/freebsd/usr.sbin/jail/Makefile" line 21:
Malformed conditional (${LINKER_TYPE} == "bfd"
Hi Michael,
I'm sorry, I've forgot to merge it after Warner merged his r351356.
Please try the fresh stable/12 and tell if you still have a problem.
On 20.11.2019 17:34, Michal Vančo wrote:
> Hi,
>
> I have an issue with SES not working with AHCI. After some digging I found a
> thread on
On Wed, Nov 20, 2019 at 02:52:22PM -0800, Mark Millard wrote:
>
> Unfortunately for Bob P., no suggestion can meet his full criteria. So
> he has several suggestions to potentially pick from or to use in
> combination.
>
This is a most gracious way of saying my expectations are
unreasonable.
On Wed, Nov 20, 2019 at 04:41:46PM -0600, Kyle Evans wrote:
>
> The revisions noted are a good data point, thanks! Can you try
> upgrading the kernel past r354875 before I revert the most likely
> candidate up to that point? Perhaps with this patch applied, to make
> sure you're not hitting an
On 11/20/19 12:02 PM, bob prohaska wrote:
On Wed, Nov 20, 2019 at 11:18:41AM -0700, Warner Losh wrote:
On Wed, Nov 20, 2019 at 10:39 AM bob prohaska wrote:
From time to time it would be handy to revert freebsd-current to
an older, well-behaved revision.
Is there a mechanism for identifying
On 11/20/19 2:37 PM, bob prohaska wrote:
While compiling a kernel at r354909 using a system at
r354845 the serial console flooded with messages of the
form
g_vfs_done():ufs/rootfs[WRITE(offset=266534912, length=32768)]error = 5
occasionally interspersed with
mmcsd0: Error indicated: 1 Timeout
On 2019-Nov-20, at 14:28, Julian Elischer wrote:
> On 11/20/19 1:51 PM, Mark Millard wrote:
>> Bob P. wrote for an aarch64 context:
>>
>>> From time to time it would be handy to revert freebsd-current to
>>> an older, well-behaved revision.
>>>
>>> Is there a mechanism for identifying
On Wed, Nov 20, 2019 at 4:37 PM bob prohaska wrote:
>
> While compiling a kernel at r354909 using a system at
> r354845 the serial console flooded with messages of the
> form
> g_vfs_done():ufs/rootfs[WRITE(offset=266534912, length=32768)]error = 5
>
> occasionally interspersed with
>
> mmcsd0:
While compiling a kernel at r354909 using a system at
r354845 the serial console flooded with messages of the
form
g_vfs_done():ufs/rootfs[WRITE(offset=266534912, length=32768)]error = 5
occasionally interspersed with
mmcsd0: Error indicated: 1 Timeout
Hi,
I have an issue with SES not working with AHCI. After some digging I found a
thread on freebsd-current
(https://lists.freebsd.org/pipermail/freebsd-current/2019-August/074176.html)
where exactly the same issue was described and finally fixed in r351589. My
question is, will this fix be
On 11/20/19 1:51 PM, Mark Millard wrote:
Bob P. wrote for an aarch64 context:
From time to time it would be handy to revert freebsd-current to
an older, well-behaved revision.
Is there a mechanism for identifying revision numbers that
will at least compile and boot, by date?
In my case
Bob P. wrote for an aarch64 context:
> From time to time it would be handy to revert freebsd-current to
> an older, well-behaved revision.
>
> Is there a mechanism for identifying revision numbers that
> will at least compile and boot, by date?
>
> In my case buildworld seems to be markedly
On Wed, Nov 20, 2019 at 11:18:41AM -0700, Warner Losh wrote:
> On Wed, Nov 20, 2019 at 10:39 AM bob prohaska wrote:
>
> > From time to time it would be handy to revert freebsd-current to
> > an older, well-behaved revision.
> >
> > Is there a mechanism for identifying revision numbers that
> >
On Wed, Nov 20, 2019 at 10:39 AM bob prohaska wrote:
> From time to time it would be handy to revert freebsd-current to
> an older, well-behaved revision.
>
> Is there a mechanism for identifying revision numbers that
> will at least compile and boot, by date?
>
Almost all of them will compile.
On Wed, 2019-11-20 at 09:38 -0800, bob prohaska wrote:
> From time to time it would be handy to revert freebsd-current to
> an older, well-behaved revision.
>
> Is there a mechanism for identifying revision numbers that
> will at least compile and boot, by date?
>
> In my case buildworld seems
On Wed, Nov 20, 2019 at 09:38:53AM -0800, bob prohaska wrote:
> >From time to time it would be handy to revert freebsd-current to
> an older, well-behaved revision.
>
> Is there a mechanism for identifying revision numbers that
> will at least compile and boot, by date?
>
> In my case
On Thu, Nov 21, 2019 at 1:39 AM bob prohaska wrote:
>
> From time to time it would be handy to revert freebsd-current to
> an older, well-behaved revision.
>
> Is there a mechanism for identifying revision numbers that
> will at least compile and boot, by date?
>
> In my case buildworld seems to
>From time to time it would be handy to revert freebsd-current to
an older, well-behaved revision.
Is there a mechanism for identifying revision numbers that
will at least compile and boot, by date?
In my case buildworld seems to be markedly slower than, say,
six months ago. Maybe it's
On Thu, Nov 21, 2019 at 12:39 AM Michael Butler
wrote:
>
> The no-relax flag can't be used on all architectures ..
>
> Building /usr/obj/usr/src/amd64.amd64/usr.sbin/jail/jail
> --- jail ---
> ld: error: unknown argument '--no-relax'
> cc: error: linker command failed with exit code 1 (use -v to
The no-relax flag can't be used on all architectures ..
Building /usr/obj/usr/src/amd64.amd64/usr.sbin/jail/jail
--- jail ---
ld: error: unknown argument '--no-relax'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
--- all_subdir_usr.sbin/portsnap ---
---
Claude:
Another video from Juan Brown about an issue with an flight from Atlanta
to New York. It is another 'fly by wire' type of aircraft and Juan goes
into great detail on the hardware and software issue. Not quite a
737-Max issue, but similar.
https://www.youtube.com/watch?v=vV_o9kTRXUY
25 matches
Mail list logo
