Re: input/output error @boot

[Toomas Soome]

> On 9. märts 2017, at 8:00, Dexuan Cui  wrote:
> 
> Hi Roberto, 
> Thanks for sending me your memmap and this is a temporary workaround
> patch for you:
> https://github.com/dcui/freebsd/commit/0edd1db55fbbb56352d6024250e4ae7dd8ad31e3.patch
> 
> I put the memmap info here for people who're interested:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746#c26
> 
> We can notice there is a 4MB BootServicesCode range at [12MB, 16MB) .
> loader.efi just writes into this range by force -- this is unsafe anyway!
> 
> To fix this correctly & thoroughly, IMO we need a relocatable kernel, but
> that would require a lot of complicated long term work:
> https://reviews.freebsd.org/D9686?id=25414#inline-56969
> 
> For now, I suggest we should only apply the idea "reduce the size of the
> staging area if necessary" to VM running on Hyper-V, we should restore the
> old behavior on physical machines since that has been working for people
> for a long period of time, though it's  potentially unsafe.
> 
> I think in the loader we can use CPUID to tell if we're running on Hyper-V or 
> not.


IMO there are multiple issues around this problem and workaround.

First of all, to control UEFI memory allocation, the AllocatePages() has 
options:

AllocateAnyPages,
AllocateMaxAddress,
AllocateAddress

On x86, we use:

staging = 1024*1024*1024;
status = BS->AllocatePages(AllocateMaxAddress, EfiLoaderData,
nr_pages, );

Which means:

"Allocation requests of Type AllocateMaxAddress allocate any available range of 
pages whose uppermost address is less than or equal to the address pointed to 
by Memory on input.”

So, we are asking for an amount of memory (64MB), with condition that all the 
pages should be below 1GB.

And we get it. If hyper-v is in fact returning us memory from already occupied 
area - there can be exactly one conclusion - it is bug in hyper-v.

Note, this allocation method does *not* set the starting point for allocation, 
it can return us *any* chunk of memory of given size, below 1GB.

So the attempt to control such allocation by size, is unfortunately flawed - it 
really does not control the allocation.

Note that I have also seen AllocateAddress failures - there was nicely 
available chunk of memory, but the firmware just did not allocate with given 
address (it did happen with OVMF + qemu).

The secondary flaw there is also about firmware. Sure, with UEFI you can have 
“random” allocations and the actual control over memory is actually problem, 
but to plant an “egg”  in 1MB-1GB range, where you have most chances any OS 
will live - IMO this is just stupid.

The only real solution here is to either rise the MaxAddress limit or use 
AllocateAnyPages, get kernel loaded into the memory, and after switching off 
the boot services and before jumping to kernel, relocate the kernel to 
available location below 1GB… 

rgds,
toomas



> 
> Thanks,
> -- Dexuan
> 
>> -Original Message-
>> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
>> curr...@freebsd.org] On Behalf Of Dexuan Cui
>> Sent: Thursday, March 9, 2017 10:44
>> To: Roberto Rodriguez Jr 
>> Cc: FreeBSD Current 
>> Subject: RE: input/output error @boot
>> 
>> [This sender failed our fraud detection checks and may not be who they appear
>> to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
>> 
>> Hmm, Alex did report 314891 worked.
>> 
>> Can you please post the full boot log of the loader?
>> Especially, when you see the “OK” prompt, can you please run the “memmap”
>> command like this link ...
>> 
>> You can take a photo of the screen and send it to me, if it’s too big.
>> 
>> Thanks,
>> -- Dexuan
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: input/output error @boot

[Pete Wright]

On 3/8/17 10:00 PM, Dexuan Cui wrote:



For now, I suggest we should only apply the idea "reduce the size of the
staging area if necessary" to VM running on Hyper-V, we should restore the
old behavior on physical machines since that has been working for people
for a long period of time, though it's  potentially unsafe.


+1

i'd like to see the old behaviour for physical machines to be restored 
as well since this has rendered my drm-next test rig broken :(


thanks!

-pete


--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: LOR on RPi3 r314894

[Gergely Czuczy]

On 2017. 03. 09. 6:59, Benjamin Kaduk wrote:

On Wed, Mar 08, 2017 at 02:06:33PM +0100, Gergely Czuczy wrote:

On 2017. 03. 08. 13:06, Hans Petter Selasky wrote:

You might check the links on this page to see if your LOR is already
listed:

https://wiki.freebsd.org/LOR

Thank you, I wasn't aware of this page. It turns out it's already listed:
http://sources.zabbadoz.net/freebsd/lor/238.html

However, the last reported stamp shouldn't anymore be 2008-09-30 :)

The page is no longer actively maintained, unfortunately.
I couldn't find it among the PRs, should I open one? Or since it was on 
this page, is it already known? I have no idea whether it's a false 
positive, but I'm surely not getting a panic.


-czg


-Ben


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: input/output error @boot

[Dexuan Cui]

Hi Roberto, 
Thanks for sending me your memmap and this is a temporary workaround
patch for you:
https://github.com/dcui/freebsd/commit/0edd1db55fbbb56352d6024250e4ae7dd8ad31e3.patch

I put the memmap info here for people who're interested:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746#c26

We can notice there is a 4MB BootServicesCode range at [12MB, 16MB) .
loader.efi just writes into this range by force -- this is unsafe anyway!

To fix this correctly & thoroughly, IMO we need a relocatable kernel, but
that would require a lot of complicated long term work:
https://reviews.freebsd.org/D9686?id=25414#inline-56969

For now, I suggest we should only apply the idea "reduce the size of the
staging area if necessary" to VM running on Hyper-V, we should restore the
old behavior on physical machines since that has been working for people
for a long period of time, though it's  potentially unsafe.

I think in the loader we can use CPUID to tell if we're running on Hyper-V or 
not.

Thanks,
-- Dexuan

> -Original Message-
> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Dexuan Cui
> Sent: Thursday, March 9, 2017 10:44
> To: Roberto Rodriguez Jr 
> Cc: FreeBSD Current 
> Subject: RE: input/output error @boot
> 
> [This sender failed our fraud detection checks and may not be who they appear
> to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
> 
> Hmm, Alex did report 314891 worked.
> 
> Can you please post the full boot log of the loader?
> Especially, when you see the “OK” prompt, can you please run the “memmap”
> command like this link ...
> 
> You can take a photo of the screen and send it to me, if it’s too big.
> 
> Thanks,
> -- Dexuan
 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: LOR on RPi3 r314894

[Benjamin Kaduk]

On Wed, Mar 08, 2017 at 02:06:33PM +0100, Gergely Czuczy wrote:
> On 2017. 03. 08. 13:06, Hans Petter Selasky wrote:
> > You might check the links on this page to see if your LOR is already 
> > listed:
> >
> > https://wiki.freebsd.org/LOR
> Thank you, I wasn't aware of this page. It turns out it's already listed:
> http://sources.zabbadoz.net/freebsd/lor/238.html
> 
> However, the last reported stamp shouldn't anymore be 2008-09-30 :)

The page is no longer actively maintained, unfortunately.

-Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

r314708: panic: tdsendsignal: ksi on queue

[Bryan Drewery]

I'm on r314708.  I hit ^C while running 'kyua test' in /usr/tests/bin/pwait.

> panic: tdsendsignal: ksi on queue
> cpuid = 10

> #10 kdb_enter (why=0x814488f5 "panic", msg=) at 
> /usr/src/sys/kern/subr_kdb.c:444
> #11 0x80a577f3 in vpanic (fmt=, ap=0xfe35601a3620) 
> at /usr/src/sys/kern/kern_shutdown.c:772
> #12 0x80a5764f in _kassert_panic (fatal=1, fmt=0x81448fd7 
> "%s: ksi on queue") at /usr/src/sys/kern/kern_shutdown.c:669
> #13 0x80a5c843 in tdsendsignal (p=0xf80c39389a80, td=0x0, sig=20, 
> ksi=0xf803888a2bd0) at /usr/src/sys/kern/kern_sig.c:2095
> #14 0x80a13828 in exit1 (td=, rval=, 
> signo=) at /usr/src/sys/kern/kern_exit.c:459
> #15 0x80a5b28c in sigexit (td=0xf802f0bee000, sig=9) at 
> /usr/src/sys/kern/kern_sig.c:3081
> #16 0x80a5b88e in postsig (sig=9) at /usr/src/sys/kern/kern_sig.c:2992
> #17 0x80a5b56b in kern_sigsuspend (td=0xf802f0bee000, mask=...) 
> at /usr/src/sys/kern/kern_sig.c:1515
> #18 0x80a5b441 in sys_sigsuspend (td=0xf802f0bee000, 
> uap=) at /usr/src/sys/kern/kern_sig.c:1479
> #19 0x80ee04da in syscallenter (td=0xf802f0bee000, sa= out>) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135
> #20 amd64_syscall (td=0xf802f0bee000, traced=0) at 
> /usr/src/sys/amd64/amd64/trap.c:902


> (kgdb) frame 18
> #18 0x80a5b441 in sys_sigsuspend (td=0xf802f0bee000, 
> uap=) at /usr/src/sys/kern/kern_sig.c:1479
> 1479return (kern_sigsuspend(td, mask));

> (kgdb) p td->td_proc->p_comm
> $3 = "timeout", '\000' 

> (kgdb) frame 13
> #13 0x80a5c843 in tdsendsignal (p=0xf80c39389a80, td=0x0, sig=20, 
> ksi=0xf803888a2bd0) at /usr/src/sys/kern/kern_sig.c:2095
> 2095KASSERT(ksi == NULL || !KSI_ONQ(ksi), ("%s: ksi on queue", 
> __func__));
> (kgdb) p *ksi
> $4 = {ksi_link = {tqe_next = 0x0, tqe_prev = 0xf80c39389c58}, ksi_info = 
> {si_signo = 20, si_errno = 0, si_code = 2, si_pid = 90903, si_uid = 0, 
> si_status = 9, si_addr = 0x0, si_value = {
>   sival_int = 0, sival_ptr = 0x0, sigval_int = 0, sigval_ptr = 0x0}, 
> _reason = {_fault = {_trapno = 0}, _timer = {_timerid = 0, _overrun = 0}, 
> _mesgq = {_mqd = 0}, _poll = {_band = 0}, __spare__ = {
> __spare1__ = 0, __spare2__ = {0, 0, 0, 0, 0, 0, 0, ksi_flags = 6, 
> ksi_sigq = 0xf80c39389c28}

> (kgdb) p *ksi->ksi_sigq
> $6 = {sq_signals = {__bits = {524288, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 
> 0, 0}}, sq_ptrace = {__bits = {0, 0, 0, 0}}, sq_list = {tqh_first = 
> 0xf803888a2bd0, tqh_last = 0xf803888a2bd0},
>   sq_proc = 0xf80c39389a80, sq_flags = 1}



-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: I/O semantics of pipe and FIFO.

[Alfred Perlstein]

I've seen that bug, but I think our bug was more that dd would exit if it got 
back a short read from input. So if you did something like this (maybe not 
exactly, but close):

dd bs=1m | dd bs=10m > f.out

You might get only 1mb in f.out. This had to do with skipping disklabels and 
other such schenanigans. 

Sent from my iPhone

> On Mar 8, 2017, at 4:09 PM, Devin Teske  wrote:
> 
> Problem we had found was:
> 
> Executing dd with a closed stdout and stderr would cause the summary messages 
> printed at the end to go into the destination output file.
> 
> For example,
> 
> dd if=/dev/zero of=/tmp/foo bs=1m count=1
> 
> Works fine, but the following:
> 
> dd if=/dev/zero of=/tmp/foo bs=1m count=1 >&- 2>&-
> 
> Will cause the summary statistics of dd to appear in /tmp/foo instead of on 
> the console.
> 
> The issue is that the summary statistics are send to fd1, which if you close 
> down stdout and stdin, fd1 is actually the output file since it got the 
> lowest file descriptor available when open(2) was called on the output file.
> 
> This was never fixed because it was deemed “silly developer, don’t close 
> stdout and stderr before invoking dd”.
> 
> The argument has been made by Jilles T. that it is generally a bad idea to 
> close down any of the standard file descriptors because it cannot be 
> predicted how a particular UNIX utility will react (e.g., in the case of dd, 
> causing a simple printf(3) to go to an unexpected location).
> — 
> Devin
> 
> 
>> On Mar 4, 2017, at 8:12 PM, Alfred Perlstein  wrote:
>> 
>> Devin and I found this when we worked together.  I think it was due to some 
>> situation in dd(1) where short reads would exit pre-maturely, however I may 
>> be mis-remembering.  Devin, do you recall the specifics?
>> 
>> 
>>> On 3/4/17 7:44 PM, Julian Elischer wrote:
>>> 
>>> an interesting point to discuss? is our behaviour in this test right?
>>>  from: "austin-group mailng list (posix standard discussion)"
>>> 
>>> -- rest of email is quoted ---
>>> On 5/3/17 5:48 am, Stephane Chazelas wrote:
>>> 
>>> 2017-03-04 13:14:08 +, Danny Niu:
 Hi all.
 
 I couldn't remember where I saw it saying, that when reading
 from a pipe or a FIFO, the read syscall returns the content of
 at most one write call. It's a bit similar to the
 message-nondiscard semantics of dear old STREAM.
 
 Currently, I'm reading through the text to find out a bit
 more, and I appreciate a bit of pointer on this.
>>> [...]
>>> 
>>> (echo x; echo y) | (sleep 1; dd count=1 2> /dev/null)
>>> 
>>> outputs both x and y in all of Linux, FreeBSD and Solaris in my
>>> tests.
>>> 
>>> That a read wouldn't read what's currently in the pipe would be
>>> quite surprising.
>>> 
>>> I also wouldn't expect pipes to store the writes as individual
>>> separate message but use one buffer.
>>> 
>>> In:
>>> 
>>> (
>>> dd bs=4 count=1 if=/dev/zero 2> /dev/null
>>> echo first through >&2
>>> dd bs=4 count=1 if=/dev/zero 2> /dev/null
>>> echo second through >&2
>>> ) | (sleep 1; dd bs=10 count=1 2> /dev/null) | wc -c
>>> 
>>> That is where the second write blocks because the pipe is full,
>>> the reading dd still reads both writes in Linux and Solaris in
>>> my tests (on Solaris (10 on amd64 at least), reduce to 2
>>> instead of 4 or both writes would block).
>>> 
>>> On FreeBSD, I get only the first write (using 8000 followed by
>>> 1 for instance).
>>> 
>>> FreeBSD is also the only one of the three where
>>> 
>>> dd bs=100 count=1 if=/dev/zero | dd bs=100 count=1 | wc -c
>>> 
>>> Doesn't output 100. The others schedule both processes back
>>> and forth during their write() and read() system call while the
>>> pipe is being filled and emptied several times.
>>> 
>> 
> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: input/output error @boot

[Dexuan Cui]

Hmm, Alex did report 314891 worked.

Can you please post the full boot log of the loader?
Especially, when you see the “OK” prompt, can you please run the “memmap” 
command like this link
https://lists.freebsd.org/pipermail/freebsd-current/2017-March/065090.html ?

You can take a photo of the screen and send it to me, if it’s too big.

Thanks,
-- Dexuan

From: Roberto Rodriguez Jr [mailto:rob.rodz@gmail.com]
Sent: Thursday, March 9, 2017 10:34
To: Dexuan Cui 
Cc: FreeBSD Current 
Subject: RE: input/output error @boot

314916 same error :(
input/output
cannot load file
elf64_loadimage read failed
oh well

On Mar 7, 2017 9:58 PM, "Dexuan Cui" 
> wrote:
Hi guys,
Sorry, I had to commit a new patch (r314891) just now to really fix the 
off-by-one bug.
Thank Alex for reporting the issue in my previous patch (r314828).

Hope this issue is finally fixed this time! :-)

Thanks,
-- Dexuan

From: Roberto Rodriguez Jr 
[mailto:rob.rodz@gmail.com]
Sent: Tuesday, March 7, 2017 21:27

To: Dexuan Cui >
Cc: FreeBSD Current 
>
Subject: RE: input/output error @boot

I will test tonight. Thank you very much for your time

On Mar 6, 2017 11:52 PM, "Dexuan Cui" 
> wrote:
> From: Dexuan Cui
> I committed r314770 just now to minimize the impact:
> https://svnweb.freebsd.org/base?view=revision=314770
>
> Please let me know in case this can't solve the issue.
Sorry, r314770  has a bug, so I had to commit r314828:
https://svnweb.freebsd.org/base?view=revision=314828

Please make sure you use the latest code, i.e. >= r314828.

Thanks,
-- Dexuan


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: input/output error @boot

[Roberto Rodriguez Jr]

314916 same error :(
input/output
cannot load file
elf64_loadimage read failed
oh well

On Mar 7, 2017 9:58 PM, "Dexuan Cui"  wrote:

Hi guys,

Sorry, I had to commit a new patch (r314891) just now to really fix the
off-by-one bug.

Thank Alex for reporting the issue in my previous patch (r314828).



Hope this issue is finally fixed this time! :-)



Thanks,

-- Dexuan



*From:* Roberto Rodriguez Jr [mailto:rob.rodz@gmail.com]
*Sent:* Tuesday, March 7, 2017 21:27

*To:* Dexuan Cui 
*Cc:* FreeBSD Current 
*Subject:* RE: input/output error @boot



I will test tonight. Thank you very much for your time



On Mar 6, 2017 11:52 PM, "Dexuan Cui"  wrote:

> From: Dexuan Cui

> I committed r314770 just now to minimize the impact:
> https://svnweb.freebsd.org/base?view=revision=314770

>
> Please let me know in case this can't solve the issue.

Sorry, r314770  has a bug, so I had to commit r314828:
https://svnweb.freebsd.org/base?view=revision=314828


Please make sure you use the latest code, i.e. >= r314828.

Thanks,
-- Dexuan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: invalid bcd xxx

[Oleksandr Tymoshenko]

Eric van Gyzen (vangy...@freebsd.org) wrote:
> On 03/04/2017 11:44, Oleksandr Tymoshenko wrote:
> > Adrian Chadd (adrian.ch...@gmail.com) wrote:
> >> We're not; we need to cope with crappy BIOS emulations and not crash :)
> >>
> >> What's Linux doing instead? Ignoring the RTC?
> >
> > I believe I saw the same problem on either my NUC or Minnowboard.
> > I just hacked around it to work on something else and didn't
> > have time to get back to the device since then. But it's not
> > just emulation BIOS. I think the right way to go is to perform sanity
> > check on RTC data and refuse to use it if it's not valid.
> 
> cem@ posted this patch:
> 
>   http://dpaste.com/1K2W05E
> 
> If someone can test it, I'll gladly commit it.  The real-time clock will 
> likely be wrong, but it won't panic with INVARIANTS.

I can not reproduce crash any more. Probably RTC battery got charged
again. I tested this patch with working RTC - there is no regression
and patch looks OK functional-wise. 

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: I/O semantics of pipe and FIFO.

[Don Lewis]

On  8 Mar, Devin Teske wrote:
> Problem we had found was:
> 
> Executing dd with a closed stdout and stderr would cause the summary
> messages printed at the end to go into the destination output file.
> 
> For example,
> 
> dd if=/dev/zero of=/tmp/foo bs=1m count=1
> 
> Works fine, but the following:
> 
> dd if=/dev/zero of=/tmp/foo bs=1m count=1 >&- 2>&-
> 
> Will cause the summary statistics of dd to appear in /tmp/foo instead
> of on the console.
> 
> The issue is that the summary statistics are send to fd1, which if you
> close down stdout and stdin, fd1 is actually the output file since it
> got the lowest file descriptor available when open(2) was called on
> the output file.
> 
> This was never fixed because it was deemed “silly developer, don’t
> close stdout and stderr before invoking dd”.
> 
> The argument has been made by Jilles T. that it is generally a bad
> idea to close down any of the standard file descriptors because it
> cannot be predicted how a particular UNIX utility will react (e.g., in
> the case of dd, causing a simple printf(3) to go to an unexpected
> location).

Shades of:

- From our Harris VOS system.
   JOBCNTRL ER  2211 : IT'S NOT NICE TO FOOL POP!
   >he 2211
   YOU JUST TRIED TO FAKE-OUT MOTHER NATURE, AND SHE CAUGHT YOU!  SUPER-
   VULCAN NOW HAS YOUR NAME ON HIS ENEMY LIST, AND YOU CAN BE CERTAIN THAT
   FUTURE ATTEMPTS TO RESOURCE LFN 0,3,OR 6 WILL RESULT IN YOUR BEING
   ABORTED, SPINDLED, MANGLED, FOLDED, PUNCHED, DELETED, AND DEALLOCATED.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: I/O semantics of pipe and FIFO.

[Devin Teske]

Problem we had found was:

Executing dd with a closed stdout and stderr would cause the summary messages 
printed at the end to go into the destination output file.

For example,

dd if=/dev/zero of=/tmp/foo bs=1m count=1

Works fine, but the following:

dd if=/dev/zero of=/tmp/foo bs=1m count=1 >&- 2>&-

Will cause the summary statistics of dd to appear in /tmp/foo instead of on the 
console.

The issue is that the summary statistics are send to fd1, which if you close 
down stdout and stdin, fd1 is actually the output file since it got the lowest 
file descriptor available when open(2) was called on the output file.

This was never fixed because it was deemed “silly developer, don’t close stdout 
and stderr before invoking dd”.

The argument has been made by Jilles T. that it is generally a bad idea to 
close down any of the standard file descriptors because it cannot be predicted 
how a particular UNIX utility will react (e.g., in the case of dd, causing a 
simple printf(3) to go to an unexpected location).
— 
Devin


> On Mar 4, 2017, at 8:12 PM, Alfred Perlstein  wrote:
> 
> Devin and I found this when we worked together.  I think it was due to some 
> situation in dd(1) where short reads would exit pre-maturely, however I may 
> be mis-remembering.  Devin, do you recall the specifics?
> 
> 
> On 3/4/17 7:44 PM, Julian Elischer wrote:
>> 
>> an interesting point to discuss? is our behaviour in this test right?
>>   from: "austin-group mailng list (posix standard discussion)"
>> 
>> -- rest of email is quoted ---
>> On 5/3/17 5:48 am, Stephane Chazelas wrote:
>> 
>> 2017-03-04 13:14:08 +, Danny Niu:
>>> Hi all.
>>> 
>>> I couldn't remember where I saw it saying, that when reading
>>> from a pipe or a FIFO, the read syscall returns the content of
>>> at most one write call. It's a bit similar to the
>>> message-nondiscard semantics of dear old STREAM.
>>> 
>>> Currently, I'm reading through the text to find out a bit
>>> more, and I appreciate a bit of pointer on this.
>> [...]
>> 
>> (echo x; echo y) | (sleep 1; dd count=1 2> /dev/null)
>> 
>> outputs both x and y in all of Linux, FreeBSD and Solaris in my
>> tests.
>> 
>> That a read wouldn't read what's currently in the pipe would be
>> quite surprising.
>> 
>> I also wouldn't expect pipes to store the writes as individual
>> separate message but use one buffer.
>> 
>> In:
>> 
>> (
>>  dd bs=4 count=1 if=/dev/zero 2> /dev/null
>>  echo first through >&2
>>  dd bs=4 count=1 if=/dev/zero 2> /dev/null
>>  echo second through >&2
>> ) | (sleep 1; dd bs=10 count=1 2> /dev/null) | wc -c
>> 
>> That is where the second write blocks because the pipe is full,
>> the reading dd still reads both writes in Linux and Solaris in
>> my tests (on Solaris (10 on amd64 at least), reduce to 2
>> instead of 4 or both writes would block).
>> 
>> On FreeBSD, I get only the first write (using 8000 followed by
>> 1 for instance).
>> 
>> FreeBSD is also the only one of the three where
>> 
>> dd bs=100 count=1 if=/dev/zero | dd bs=100 count=1 | wc -c
>> 
>> Doesn't output 100. The others schedule both processes back
>> and forth during their write() and read() system call while the
>> pipe is being filled and emptied several times.
>> 
> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: two recent snapshot installer problems

[Allan Jude]

I wOn 03/08/2017 14:56, Michael W. Lucas wrote:

Thanks for the hint, Toomas. But...

I updated my custom ZFS install/partition script, at:

http://www-old.michaelwlucas.com/zm.sh

I used this script at the command line partitioner in the installer,
then exited and let the installer take over.

The machine installs. After a "sysrc zfs_enable=yes" it boots.

So: bsdinstall doesn't like this box.

If anyone's willing to work on the installer in the next few days, I'm
willing to wait to work on this box. I will have to put it to work
before long, though.

Thanks,
==ml



I wouldn't be able to look at this until Tuesday the 14th. I am in Japan 
until then.


--
Allan Jude
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: start-up failure at SVN r314889

[Michael Butler]

The difference between a kernel that boots and another that won't is ..

imb@toshi:/home/imb> diff -cw /sys/amd64/conf/TOSHI~ /sys/amd64/conf/TOSHI
*** /sys/amd64/conf/TOSHI~  Wed Mar  8 10:05:09 2017
--- /sys/amd64/conf/TOSHI   Wed Mar  8 17:33:25 2017
***
*** 373,379 
  # Enable Linux ABI emulation
  #options  COMPAT_LINUX32
  # Enable Linux KPI
! #options  COMPAT_LINUXKPI

  # Enable the linux-like proc filesystem support (requires COMPAT_LINUX
  # and PSEUDOFS)
--- 373,379 
  # Enable Linux ABI emulation
  #options  COMPAT_LINUX32
  # Enable Linux KPI
! options   COMPAT_LINUXKPI

  # Enable the linux-like proc filesystem support (requires COMPAT_LINUX
  # and PSEUDOFS)

Seems to point at something in SVN r314843 :-(

imb


On 03/08/17 17:10, Eric Camachat wrote:
> I have the same issue on Dell Precision M4800.
> 
> On Wed, Mar 8, 2017 at 6:26 AM, David Wolfskill  wrote:
>> On Wed, Mar 08, 2017 at 07:55:44AM -0500, Michael Butler wrote:
>>> My laptop usually starts like this ..
>>>
>>> FreeBSD 12.0-CURRENT #21 r314812M: Mon Mar  6 19:34:51 EST 2017
>>> i...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI 
>>> amd64
>>> FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM
>>> 4.0.0)
>>> ...
>>>
>>> This morning, I get this :-(
>>>
>>> FreeBSD 12.0-CURRENT #27 r314889M: Tue Mar  7 19:55:25 EST 2017
>>> i...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI
>>> FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM
>>> 4.0.0)
>>> VT(vga): resolution 640x480
>>> panic: kthread_add called too soon
>>>  [ .. ]
>>>
>>> Any thoughts?
>>> 
>>
>> "uname -vp" output from my last several (successful) build/smoke-tests
>> for head:
>>
>> FreeBSD 12.0-CURRENT #274  r314653M/314653:1200023: Sat Mar  4 06:46:18 PST 
>> 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
>>
>> FreeBSD 12.0-CURRENT #275  r314700M/314700:1200023: Sun Mar  5 07:45:20 PST 
>> 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
>>
>> FreeBSD 12.0-CURRENT #276  r314770M/314770:1200023: Mon Mar  6 05:45:44 PST 
>> 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
>>
>> FreeBSD 12.0-CURRENT #277  r314842M/314842:1200023: Tue Mar  7 05:55:58 PST 
>> 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
>>
>> FreeBSD 12.0-CURRENT #278  r314906M/314906:1200024: Wed Mar  8 06:05:49 PST 
>> 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
>>
>> Sorry it's not more help.
>>
>> Peace,
>> david
>> --
>> David H. Wolfskill  da...@catwhisker.org
>> How could one possibly "respect" a misogynist, racist, bullying con-man??!?
>>
>> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
> 
> 
> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: start-up failure at SVN r314889

[Eric Camachat]

I have the same issue on Dell Precision M4800.

On Wed, Mar 8, 2017 at 6:26 AM, David Wolfskill  wrote:
> On Wed, Mar 08, 2017 at 07:55:44AM -0500, Michael Butler wrote:
>> My laptop usually starts like this ..
>>
>> FreeBSD 12.0-CURRENT #21 r314812M: Mon Mar  6 19:34:51 EST 2017
>> i...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI amd64
>> FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM
>> 4.0.0)
>> ...
>>
>> This morning, I get this :-(
>>
>> FreeBSD 12.0-CURRENT #27 r314889M: Tue Mar  7 19:55:25 EST 2017
>> i...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI
>> FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM
>> 4.0.0)
>> VT(vga): resolution 640x480
>> panic: kthread_add called too soon
>>  [ .. ]
>>
>> Any thoughts?
>> 
>
> "uname -vp" output from my last several (successful) build/smoke-tests
> for head:
>
> FreeBSD 12.0-CURRENT #274  r314653M/314653:1200023: Sat Mar  4 06:46:18 PST 
> 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
>
> FreeBSD 12.0-CURRENT #275  r314700M/314700:1200023: Sun Mar  5 07:45:20 PST 
> 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
>
> FreeBSD 12.0-CURRENT #276  r314770M/314770:1200023: Mon Mar  6 05:45:44 PST 
> 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
>
> FreeBSD 12.0-CURRENT #277  r314842M/314842:1200023: Tue Mar  7 05:55:58 PST 
> 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
>
> FreeBSD 12.0-CURRENT #278  r314906M/314906:1200024: Wed Mar  8 06:05:49 PST 
> 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
>
> Sorry it's not more help.
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> How could one possibly "respect" a misogynist, racist, bullying con-man??!?
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.



-- 
☀Eric
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: two recent snapshot installer problems

[Michael W. Lucas]

Thanks for the hint, Toomas. But...

I updated my custom ZFS install/partition script, at:

http://www-old.michaelwlucas.com/zm.sh

I used this script at the command line partitioner in the installer,
then exited and let the installer take over.

The machine installs. After a "sysrc zfs_enable=yes" it boots.

So: bsdinstall doesn't like this box.

If anyone's willing to work on the installer in the next few days, I'm
willing to wait to work on this box. I will have to put it to work
before long, though.

Thanks,
==ml

-- 
Michael W. LucasTwitter @mwlauthor 
nonfiction: https://www.michaelwlucas.com/
fiction: https://www.michaelwarrenlucas.com/
blog: http://blather.michaelwlucas.com/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: How many versions of clang/llvm are currently required to maintain a system

[rb]

Hi,

> On 8 Mar 2017, at 16:40, Mark Linimon  wrote:
> 
> On Mon, Mar 06, 2017 at 03:00:23PM +, r...@gid.co.uk wrote:
>> Let me rephrase that: the link http://purelang.bitbucket.org/
>> quoted on https://wiki.freebsd.org/ObsoleteLLVMVersions doesn’t work,
> 
> That's the URL in lang/pure/Makefile.
> 
>> should be https://bitbucket.org/purelang/
> 
> Hmm.  I looked and it seems like https://purelang.bitbucket.io/ is
> a better choice?  What do you think?

Sure.

> mcl
> 

--
Bob Bishop
r...@gid.co.uk




___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: installworld pwait error

[Roberto Rodriguez Jr]

Just curious though if anybody in the Forum had experienced such an issue
and it obviously they fixed it just curious though.

On Mar 8, 2017 12:51 PM, "David Wolfskill"  wrote:

> On Wed, Mar 08, 2017 at 12:50:18PM -0500, Roberto Rodriguez Jr wrote:
> > Hey,
> >
> > Well thats good because I just updated and am rebuilding again.
> >
> > Thank u
> > 
>
> Happy to help! :-)
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> How could one possibly "respect" a misogynist, racist, bullying con-man??!?
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: installworld pwait error

[Roberto Rodriguez Jr]

Hey,

Well thats good because I just updated and am rebuilding again.

Thank u

On Mar 8, 2017 12:45 PM, "David Wolfskill"  wrote:

> On Wed, Mar 08, 2017 at 12:42:38PM -0500, Roberto Rodriguez Jr wrote:
> > Hi everyone,
> >
> > Sorry I cannot provide the output at this time.
> > Success with buildworld buildkernel installkernel and reboot but
> > installworld breaks saying
> >
> > pwait No such file found.
> >
> > Using 314828.
> > Can anyone confirm?
> >
> > Thanks alld
> > 
>
> I did not see such an issue for either r314842 or r314906.
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> How could one possibly "respect" a misogynist, racist, bullying con-man??!?
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

installworld pwait error

[Roberto Rodriguez Jr]

Hi everyone,

Sorry I cannot provide the output at this time.
Success with buildworld buildkernel installkernel and reboot but
installworld breaks saying

pwait No such file found.

Using 314828.
Can anyone confirm?

Thanks alld
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: How many versions of clang/llvm are currently required to maintain a system

[Mark Linimon]

On Mon, Mar 06, 2017 at 03:00:23PM +, r...@gid.co.uk wrote:
> Let me rephrase that: the link http://purelang.bitbucket.org/
> quoted on https://wiki.freebsd.org/ObsoleteLLVMVersions doesn’t work,

That's the URL in lang/pure/Makefile.

> should be https://bitbucket.org/purelang/

Hmm.  I looked and it seems like https://purelang.bitbucket.io/ is
a better choice?  What do you think?

mcl
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: start-up failure at SVN r314889

[David Wolfskill]

On Wed, Mar 08, 2017 at 07:55:44AM -0500, Michael Butler wrote:
> My laptop usually starts like this ..
> 
> FreeBSD 12.0-CURRENT #21 r314812M: Mon Mar  6 19:34:51 EST 2017
> i...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI amd64
> FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM
> 4.0.0)
> ...
> 
> This morning, I get this :-(
> 
> FreeBSD 12.0-CURRENT #27 r314889M: Tue Mar  7 19:55:25 EST 2017
> i...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI
> FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM
> 4.0.0)
> VT(vga): resolution 640x480
> panic: kthread_add called too soon
>  [ .. ]
> 
> Any thoughts?
> 

"uname -vp" output from my last several (successful) build/smoke-tests
for head:

FreeBSD 12.0-CURRENT #274  r314653M/314653:1200023: Sat Mar  4 06:46:18 PST 
2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

FreeBSD 12.0-CURRENT #275  r314700M/314700:1200023: Sun Mar  5 07:45:20 PST 
2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

FreeBSD 12.0-CURRENT #276  r314770M/314770:1200023: Mon Mar  6 05:45:44 PST 
2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

FreeBSD 12.0-CURRENT #277  r314842M/314842:1200023: Tue Mar  7 05:55:58 PST 
2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

FreeBSD 12.0-CURRENT #278  r314906M/314906:1200024: Wed Mar  8 06:05:49 PST 
2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

Sorry it's not more help.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: start-up failure at SVN r314889

[Michael Butler]

On 03/08/17 08:12, Andriy Gapon wrote:
> On 08/03/2017 14:55, Michael Butler wrote:
>> My laptop usually starts like this ..
>>
>> FreeBSD 12.0-CURRENT #21 r314812M: Mon Mar  6 19:34:51 EST 2017
>> i...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI amd64
>> FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM
>> 4.0.0)
>> VT(vga): resolution 640x480
>> info: [drm] Initialized drm 1.1.0 20060810
>> CPU: Intel(R) Core(TM)2 CPU T7600  @ 2.33GHz (2327.56-MHz
>> K8-class CPU)
>>  [ .. ]
>>
>> This morning, I get this :-(
>>
>> FreeBSD 12.0-CURRENT #27 r314889M: Tue Mar  7 19:55:25 EST 2017
>> i...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI
>> FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM
>> 4.0.0)
>> VT(vga): resolution 640x480
>> panic: kthread_add called too soon
>>  [ .. ]
>>
>> Any thoughts?
> 
> Were messages replaced by the second '[..]' really so useless?

Just the CPU number, then it halts :-(

With no log, I typed what I could remember.

With a verbose start-up, I can see that it gets through parsing the ACPI
tables but fails shortly after. When I get home this evening, I'll take
a screenshot,

imb


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: start-up failure at SVN r314889

[Andriy Gapon]

On 08/03/2017 14:55, Michael Butler wrote:
> My laptop usually starts like this ..
> 
> FreeBSD 12.0-CURRENT #21 r314812M: Mon Mar  6 19:34:51 EST 2017
> i...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI amd64
> FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM
> 4.0.0)
> VT(vga): resolution 640x480
> info: [drm] Initialized drm 1.1.0 20060810
> CPU: Intel(R) Core(TM)2 CPU T7600  @ 2.33GHz (2327.56-MHz
> K8-class CPU)
>  [ .. ]
> 
> This morning, I get this :-(
> 
> FreeBSD 12.0-CURRENT #27 r314889M: Tue Mar  7 19:55:25 EST 2017
> i...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI
> FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM
> 4.0.0)
> VT(vga): resolution 640x480
> panic: kthread_add called too soon
>  [ .. ]
> 
> Any thoughts?

Were messages replaced by the second '[..]' really so useless?


-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: LOR on RPi3 r314894

[Gergely Czuczy]

On 2017. 03. 08. 13:06, Hans Petter Selasky wrote:

On 03/08/17 12:23, Gergely Czuczy wrote:

Hello,

I've built an image for RPi3 from -CURRENT checkout at r314894, and
while booting, I've noticed a LOR message:

http://czg.harmless.hu/aegir/LOR_1_1280.jpg

I don't know whether this one is any concern, if so, I'm just letting
you know.



Hi,

You might check the links on this page to see if your LOR is already 
listed:


https://wiki.freebsd.org/LOR

Thank you, I wasn't aware of this page. It turns out it's already listed:
http://sources.zabbadoz.net/freebsd/lor/238.html

However, the last reported stamp shouldn't anymore be 2008-09-30 :)



--HPS


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

start-up failure at SVN r314889

[Michael Butler]

My laptop usually starts like this ..

FreeBSD 12.0-CURRENT #21 r314812M: Mon Mar  6 19:34:51 EST 2017
i...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI amd64
FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM
4.0.0)
VT(vga): resolution 640x480
info: [drm] Initialized drm 1.1.0 20060810
CPU: Intel(R) Core(TM)2 CPU T7600  @ 2.33GHz (2327.56-MHz
K8-class CPU)
 [ .. ]

This morning, I get this :-(

FreeBSD 12.0-CURRENT #27 r314889M: Tue Mar  7 19:55:25 EST 2017
i...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI
FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM
4.0.0)
VT(vga): resolution 640x480
panic: kthread_add called too soon
 [ .. ]

Any thoughts?

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: LOR on RPi3 r314894

[Hans Petter Selasky]

On 03/08/17 12:23, Gergely Czuczy wrote:

Hello,

I've built an image for RPi3 from -CURRENT checkout at r314894, and
while booting, I've noticed a LOR message:

http://czg.harmless.hu/aegir/LOR_1_1280.jpg

I don't know whether this one is any concern, if so, I'm just letting
you know.



Hi,

You might check the links on this page to see if your LOR is already listed:

https://wiki.freebsd.org/LOR

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

LOR on RPi3 r314894

[Gergely Czuczy]

Hello,

I've built an image for RPi3 from -CURRENT checkout at r314894, and 
while booting, I've noticed a LOR message:


http://czg.harmless.hu/aegir/LOR_1_1280.jpg

I don't know whether this one is any concern, if so, I'm just letting 
you know.


Best regards,
Gergely


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: AMD CPU/APU temperature driver

[Olivier Cochard-Labbé]

On Wed, Mar 8, 2017 at 9:11 AM, Rozhuk Ivan  wrote:

>
> sysctl hw.model
> please.
>

​[root@APU]~# sysctl hw.model
hw.model: AMD G-T40E Processor

[root@apu2]~# sysctl hw.model
hw.model: AMD GX-412TC SOC
​
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: AMD CPU/APU temperature driver

[Rozhuk Ivan]

On Wed, 8 Mar 2017 09:02:05 +0100
Olivier Cochard-Labbé  wrote:

> On Wed, Mar 8, 2017 at 7:29 AM, Rozhuk Ivan 
> wrote:
> 
> >
> > Try now with last version of patch.
> >
> > ​Compile now and works on PC Engine APU1 and APU2:
> 

Thanks!

sysctl hw.model
please.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: AMD CPU/APU temperature driver

[Olivier Cochard-Labbé]

On Wed, Mar 8, 2017 at 7:29 AM, Rozhuk Ivan  wrote:

>
> Try now with last version of patch.
>
> ​Compile now and works on PC Engine APU1 and APU2:

[root@APU]~# kenv smbios.planar.product
APU
[root@APU]~# kldload amdtemp
amdtemp0:  on hostb4
[root@APU]~# sysctl dev.amdtemp
dev.amdtemp.0.rtc.sensor_offset: 0
dev.amdtemp.0.rtc.PerStepTimeUp: 15
dev.amdtemp.0.rtc.PerStepTimeDn: 15
dev.amdtemp.0.rtc.TmpMaxDiffUp: 3
dev.amdtemp.0.rtc.TmpSlewDnEn: 1
dev.amdtemp.0.rtc.CurTmpTjSel: -1.4C
dev.amdtemp.0.rtc.CurTmp: 47.6C
dev.amdtemp.0.htc.PslApicLoEn: 0
dev.amdtemp.0.htc.PslApicHiEn: 0
dev.amdtemp.0.htc.HtcActSts: 0
dev.amdtemp.0.htc.HtcAct: 0
dev.amdtemp.0.htc.HtcPstateLimit: 2
dev.amdtemp.0.htc.HtcSlewSel: 0
dev.amdtemp.0.htc.HtcLock: 0
dev.amdtemp.0.htc.HtcEn: 1
dev.amdtemp.0.htc.HtcHystLmt: 3.1C
dev.amdtemp.0.htc.HtcTmpLmt: 100.1C
dev.amdtemp.0.%parent: hostb4
dev.amdtemp.0.%pnpinfo:
dev.amdtemp.0.%location:
dev.amdtemp.0.%driver: amdtemp
dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors
dev.amdtemp.%parent:

​

[root@apu2]~# kenv smbios.planar.product
apu2
[root@apu2]~# kldload amdtemp
amdtemp0:  on hostb5
[root@apu2]~# sysctl dev.cpu.0.temperature
dev.cpu.0.temperature: 53.9C
[root@apu2]~# sysctl dev.amdtemp
dev.amdtemp.0.rtc.sensor_offset: 0
dev.amdtemp.0.rtc.PerStepTimeUp: 15
dev.amdtemp.0.rtc.PerStepTimeDn: 15
dev.amdtemp.0.rtc.TmpMaxDiffUp: 3
dev.amdtemp.0.rtc.TmpSlewDnEn: 1
dev.amdtemp.0.rtc.CurTmpTjSel: 4.6C
dev.amdtemp.0.rtc.CurTmp: 53.6C
dev.amdtemp.0.htc.PslApicLoEn: 0
dev.amdtemp.0.htc.PslApicHiEn: 0
dev.amdtemp.0.htc.HtcActSts: 1
dev.amdtemp.0.htc.HtcAct: 0
dev.amdtemp.0.htc.HtcPstateLimit: 4
dev.amdtemp.0.htc.HtcSlewSel: 0
dev.amdtemp.0.htc.HtcLock: 0
dev.amdtemp.0.htc.HtcEn: 1
dev.amdtemp.0.htc.HtcHystLmt: 1.1C
dev.amdtemp.0.htc.HtcTmpLmt: 105.1C
dev.amdtemp.0.%parent: hostb5
dev.amdtemp.0.%pnpinfo:
dev.amdtemp.0.%location:
dev.amdtemp.0.%driver: amdtemp
dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors
dev.amdtemp.%parent:
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"