FreeBSD_HEAD_i386 - Build #570 - Fixed

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #570 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/570/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/570/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/570/console

Change summaries:

285524 by adrian:
Populate hw.model with the CPU model information.

Now you see something like:

# sysctl hw.model
hw.model: Atheros AR9330 rev 1

Tested:

* Carambola 2, AR9331 SoC

285523 by jmg:
cryptodev is not needed for TCP_SIGNATURE...

Comment that cryptodev shouldn't be used unless you know what you're
doing...

The various arm/mips and one powerpc configs that have cryptodev in
them need to be addressed, audited if they provide benefit and removed
if they don't...

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

FreeBSD_HEAD-tests - Build #1182 - Unstable

[jenkins-admin]

FreeBSD_HEAD-tests - Build #1182 - Unstable:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1182/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1182/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1182/console

Change summaries:

No changes


The end of the build log:

[...truncated 4416 lines...]
[192.168.10.2] out: bin/sh/expansion/functional_test:plus_minus4  ->  passed  
[0.312s]
[192.168.10.2] out: bin/sh/expansion/functional_test:plus_minus5  ->  passed  
[0.274s]
[192.168.10.2] out: bin/sh/expansion/functional_test:plus_minus6  ->  passed  
[0.199s]
[192.168.10.2] out: bin/sh/expansion/functional_test:plus_minus7  ->  passed  
[0.262s]
[192.168.10.2] out: bin/sh/expansion/functional_test:plus_minus8  ->  passed  
[0.339s]
[192.168.10.2] out: bin/sh/expansion/functional_test:question1  ->  passed  
[0.382s]
[192.168.10.2] out: bin/sh/expansion/functional_test:readonly1  ->  passed  
[0.340s]
[192.168.10.2] out: bin/sh/expansion/functional_test:redir1  ->  passed  
[0.422s]
[192.168.10.2] out: bin/sh/expansion/functional_test:set_u1  ->  passed  
[1.303s]
[192.168.10.2] out: bin/sh/expansion/functional_test:set_u2  ->  passed  
[0.295s]
[192.168.10.2] out: bin/sh/expansion/functional_test:set_u3  ->  passed  
[1.071s]
[192.168.10.2] out: bin/sh/expansion/functional_test:tilde1  ->  passed  
[0.362s]
[192.168.10.2] out: bin/sh/expansion/functional_test:tilde2  ->  passed  
[0.337s]
[192.168.10.2] out: bin/sh/expansion/functional_test:trim1  ->  passed  [0.194s]
[192.168.10.2] out: bin/sh/expansion/functional_test:trim2  ->  passed  [0.180s]
[192.168.10.2] out: bin/sh/expansion/functional_test:trim3  ->  passed  [0.186s]
[192.168.10.2] out: bin/sh/expansion/functional_test:trim4  ->  passed  [0.297s]
[192.168.10.2] out: bin/sh/expansion/functional_test:trim5  ->  passed  [0.521s]
[192.168.10.2] out: bin/sh/expansion/functional_test:trim6  ->  passed  [0.433s]
[192.168.10.2] out: bin/sh/expansion/functional_test:trim7  ->  passed  [0.510s]
[192.168.10.2] out: bin/sh/expansion/functional_test:trim8  ->  passed  [0.335s]
[192.168.10.2] out: bin/sh/parameters/functional_test:env1  ->  passed  [0.970s]
[192.168.10.2] out: bin/sh/parameters/functional_test:exitstatus1  ->  passed  
[0.322s]
[192.168.10.2] out: bin/sh/parameters/functional_test:mail1  ->  passed  
[0.550s]
[192.168.10.2] out: bin/sh/parameters/functional_test:mail2  ->  passed  
[0.506s]
[192.168.10.2] out: bin/sh/parameters/functional_test:optind1  ->  passed  
[1.282s]
[192.168.10.2] out: bin/sh/parameters/functional_test:optind2  ->  passed  
[2.549s]
[192.168.10.2] out: bin/sh/parameters/functional_test:positional1  ->  passed  
[0.371s]
[192.168.10.2] out: bin/sh/parameters/functional_test:positional2  ->  passed  
[0.253s]
[192.168.10.2] out: bin/sh/parameters/functional_test:positional3  ->  passed  
[0.224s]
[192.168.10.2] out: bin/sh/parameters/functional_test:positional4  ->  passed  
[0.220s]
[192.168.10.2] out: bin/sh/parameters/functional_test:positional5  ->  passed  
[0.202s]
[192.168.10.2] out: bin/sh/parameters/functional_test:positional6  ->  passed  
[0.180s]
[192.168.10.2] out: bin/sh/parameters/functional_test:positional7  ->  passed  
[0.385s]
[192.168.10.2] out: bin/sh/parameters/functional_test:pwd1  ->  passed  [0.670s]
[192.168.10.2] out: bin/sh/parameters/functional_test:pwd2  ->  passed  [0.674s]
[192.168.10.2] out: bin/sh/parser/functional_test:alias1  ->  passed  [0.316s]
[192.168.10.2] out: bin/sh/parser/functional_test:alias10  ->  passed  [0.222s]
[192.168.10.2] out: bin/sh/parser/functional_test:alias11  ->  passed  [0.312s]
[192.168.10.2] out: bin/sh/parser/functional_test:alias12  ->  passed  [0.285s]
[192.168.10.2] out: bin/sh/parser/functional_test:alias13  ->  passed  [0.265s]
[192.168.10.2] out: bin/sh/parser/functional_test:alias14  ->  passed  [0.430s]
[192.168.10.2] out: bin/sh/parser/functional_test:alias15  ->  passed  [0.406s]
[192.168.10.2] out: bin/sh/parser/functional_test:alias2  ->  passed  [0.555s]
[192.168.10.2] out: bin/sh/parser/functional_test:alias3  ->  passed  [0.550s]
[192.168.10.2] out: bin/sh/parser/functional_test:alias4  ->  passed  [0.345s]
[192.168.10.2] out: bin/sh/parser/functional_test:alias5  ->  passed  [0.253s]
[192.168.10.2] out: bin/sh/parser/functional_test:alias6  ->  passed  [0.960s]
[192.168.10.2] out: bin/sh/parser/functional_test:alias7  ->  passed  [0.306s]
[192.168.10.2] out: bin/sh/parser/functional_test:alias8  ->  passed  [0.295s]
[192.168.10.2] out: bin/sh/parser/functional_test:alias9  ->  passed  [0.243s]
[192.168.10.2] out: bin/sh/parser/functional_test:and_pipe_not  ->  passed  
[0.268s]
[192.168.10.2] out: bin/sh/parser/functional_test:case1  ->  passed  [0.324s]
[192.168.10.2] out: bin/sh/parser/functional_test:case2  ->  passed  [0.689s]
[192.168.10.2] out: bin/sh/parser/functional_test:dollar_quote1  ->  passed  
[0.518s]
[192.168.10.2] out: bin/sh/parser/functional_test:dollar_q

Re: Call for FreeBSD 2015Q2 (April-June) Status Reports

[Warren Block]

Have you submitted your quarterly report yet?  People need to know about 
the cool things being done with, or to, or by FreeBSD.


In an effort that will surely never come back to haunt us all, I have 
committed all the reports I saw in monthly@ to the upcoming status 
report.  However, I am also easily distracted by shiny objects and might 
have missed some.


If you have not yet received a passive-aggressive "thanks" mail, please 
make sure your report is included here: 
https://svnweb.freebsd.org/doc/head/en_US.ISO8859-1/htdocs/news/status/report-2015-04-2015-06.xml?view=markup


If your report is missing or not present, please resubmit to 
b...@freebsd.org, mont...@freebsd.org, and cc me at wbl...@freebsd.org.


The deadline is July 14 (yes, today), but of course some of us would 
rather wait than miss interesting reports.  Or dull ones, to be honest. 
But there is an interesting report lurking inside even the dull ones. 
Particularly if some words are replaced with others.


Assistance in polishing a bare list of feats into a truly Herculean 
accomplishment can be provided on a limited-time, first-come 
first-serve, contents may have settled during shipment basis.


Grammer can be goodered and Englished up, too.

On Wed, 8 Jul 2015, Benjamin Kaduk wrote:


Dear FreeBSD Community,

Only one week remains before the deadline to submit entries for the next
FreeBSD Quarterly Status update -- the deadline is July 14, 2015, for work
done in April through June.

Status report submissions do not have to be very long.  They may be
about anything happening in the FreeBSD project and community, and
provide a great way to inform FreeBSD users and developers about what
you're working on.  Submission of reports is not restricted to
committers.  Anyone doing anything interesting and FreeBSD-related
can -- and should -- write one!

The preferred and easiest submission method is to use the XML
generator [1] with the results emailed to the status report team at
monthly at freebsd.org .  There is also an XML template [2] which can be
filled out manually and attached if preferred.  For the expected
content and style, please study our guidelines on how to write a good
status report [3].  You can also review previous issues [4][5] for
ideas on the style and format.

We are looking forward to all of your 2015Q2 reports!

Thanks,
Ben (on behalf of monthly@)


[1] http://www.freebsd.org/cgi/monthly.cgi
[2] http://www.freebsd.org/news/status/report-sample.xml
[3] http://www.freebsd.org/news/status/howto.html
[4] http://www.freebsd.org/news/status/report-2014-10-2014-12.html
[5] http://www.freebsd.org/news/status/report-2015-01-2015-03.html



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

FreeBSD_HEAD_i386 - Build #569 - Failure

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #569 - Failure:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/569/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/569/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/569/console

Change summaries:

285522 by cem:
Fix cleanup race between unp_dispose and unp_gc

unp_dispose and unp_gc could race to teardown the same mbuf chains, which
can lead to dereferencing freed filedesc pointers.

This patch adds an IGNORE_RIGHTS flag on unpcbs marking the unpcb's RIGHTS
as invalid/freed. The flag is protected by UNP_LIST_LOCK.

To serialize against unp_gc, unp_dispose needs the socket object. Change the
dom_dispose() KPI to take a socket object instead of an mbuf chain directly.

PR: 194264
Differential Revision:  https://reviews.freebsd.org/D3044
Reviewed by:mjg (earlier version)
Approved by:markj (mentor)
Obtained from:  mjg
MFC after:  1 month
Sponsored by:   EMC / Isilon Storage Division

285517 by gjb:
Document r281440, psm(4) enhancements.

Sponsored by:   The FreeBSD Foundation

285516 by gjb:
Document r275800, reaper facility.

Sponsored by:   The FreeBSD Foundation

285515 by gjb:
Document r271918, fix for panic when destroying vnet jail with
gre(4).

Sponsored by:   The FreeBSD Foundation

285514 by gjb:
Document r271917, fix for panic when destroying vnet jail with
gif(4).

Sponsored by:   The FreeBSD Foundation



The end of the build log:

[...truncated 64577 lines...]
--- all_subdir_libclangstaticanalyzercore ---
--- SValBuilder.o ---
c++-O2 -pipe 
-I/usr/src/lib/clang/libclangstaticanalyzercore/../../../contrib/llvm/include 
-I/usr/src/lib/clang/libclangstaticanalyzercore/../../../contrib/llvm/tools/clang/include
 
-I/usr/src/lib/clang/libclangstaticanalyzercore/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Core
 -I. 
-I/usr/src/lib/clang/libclangstaticanalyzercore/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZER 
-fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd11.0\" 
-DLLVM_HOST_TRIPLE=\"i386-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\" 
-fstack-protector -Qunused-arguments  -std=c++11 -fno-exceptions -fno-rtti 
-stdlib=libc++ -Wno-c++11-extensions -c 
/usr/src/lib/clang/libclangstaticanalyzercore/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
 -o SValBuilder.o
--- all_subdir_libclangstaticanalyzercheckers ---
--- NoReturnFunctionChecker.o ---
c++-O2 -pipe 
-I/usr/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/include
 
-I/usr/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/include
 
-I/usr/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers
 -I. 
-I/usr/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZER 
-fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd11.0\" 
-DLLVM_HOST_TRIPLE=\"i386-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\" 
-fstack-protector -Qunused-arguments  -std=c++11 -fno-exceptions -fno-rtti 
-stdlib=libc++ -Wno-c++11-extensions -c 
/usr/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/NoReturnFunctionChecker.cpp
 -o NoReturnFunctionChecker.o
--- all_subdir_libclangsema ---
--- SemaLookup.o ---
c++-O2 -pipe 
-I/usr/src/lib/clang/libclangsema/../../../contrib/llvm/include 
-I/usr/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include 
-I/usr/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema 
-I. 
-I/usr/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include 
-DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS 
-DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd11.0\" 
-DLLVM_HOST_TRIPLE=\"i386-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\" 
-fstack-protector -Qunused-arguments  -std=c++11 -fno-exceptions -fno-rtti 
-stdlib=libc++ -Wno-c++11-extensions -c 
/usr/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaLookup.cpp
 -o SemaLookup.o
--- all_subdir_libclangstaticanalyzercore ---
--- SVals.o ---
c++-O2 -pipe 
-I/usr/src/lib/clang/libclangstaticanalyzercore/../../../contrib/llvm/include 
-I/usr/src/lib/clang/libclangstaticanalyzercore/../../../contrib/llvm/tools/clang/include
 
-I/usr/src/lib/clang/libclangstaticanalyzercore/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Core
 -I. 
-I/usr/src/lib/clang/libclangstaticanalyzercore/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__ST

Re: Lenovo BIOS boot fix

[Warren Block]

On Mon, 13 Jul 2015, Adrian Chadd wrote:


But the problem here is that we're using GPT but /not/ UEFI, right?
That's why that's all a mess?


If you have a GPT layout, but it boots on a BIOS machine, the missing 
active flag on a standards-correct PMBR partition usually does not keep 
it from booting.  Usually.


The Lenovo thing is just a bug, firmware that sees GPT and automatically 
assumes that a GPT disk has all the UEFI features (extra partitions and 
security and cryptography and all that).


That is wrong.  Lenovo can fix it, and there should be villagers with 
pitchforks at their gates politely requesting that they fix it for these 
still-broken models like they have for other models.

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

Re: Why shoud we cause panic in scsi_da.c?

[Kohji Okuno]

Hi,

From: Alexander Motin 
Date: Mon, 13 Jul 2015 18:29:36 +0300
> Hi.
> 
> On 13.07.2015 11:51, Kohji Okuno wrote:
>>> On 07/13/15 10:11, Kohji Okuno wrote:
 Could you comment on my quesion?

> I found panic() in scsi_da.c. Please find the following.
> I think we should return with error without panic().
> What do you think about this?
>
> scsi_da.c:
> 3018  } else if (bp != NULL) {
> 3019 if ((done_ccb->ccb_h.status & CAM_DEV_QFRZN) != 0)
> 3020  panic("REQ_CMP with QFRZN");
>
>>>
>>> It looks to me more like an KASSERT() is appropriate here.
> 
> As I can see, this panic() call was added by ken@ about 15 years ago.
> I've added him to CC in case he has some idea why it was done. From my
> personal opinion I don't see much reasons to allow CAM_DEV_QFRZN to be
> returned only together with error. While is may have little sense in
> case of successful command completion, I don't think it should be
> treated as error. Simply removing this panic is probably a bad idea,
> since if it happens device will just remain frozen forever, that will be
> will be difficult to diagnose, but I would better just dropped device
> freeze in that case same as in case of completion with error.

Thank you for your comment.
I have a strange USB HDD. When I access the specified sector, the
kernel causes panic("REQ_CMP with QFRZN") always.

After I modified the following, I think that I can recover from this
state, although the specified sector access fails. This recovery means
that I can access other sectors after this recovery.

What do you think about my idea?


@@ -3016,8 +3016,17 @@ dadone(struct cam_periph *periph, union ccb *done_ccb)
 /*timeout*/0,
 /*getcount_only*/0);
} else if (bp != NULL) {
+#if 0
if ((done_ccb->ccb_h.status & CAM_DEV_QFRZN) != 0)
panic("REQ_CMP with QFRZN");
+#else
+   if ((done_ccb->ccb_h.status & CAM_DEV_QFRZN) != 0)
+   cam_release_devq(done_ccb->ccb_h.path,
+/*relsim_flags*/0,
+/*reduction*/0,
+/*timeout*/0,
+/*getcount_only*/0);
+#endif
if (state == DA_CCB_DELETE)
bp->bio_resid = 0;
else

Best regards,
 Kohji Okuno
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Lenovo BIOS boot fix

[Adrian Chadd]

Hi,

But the problem here is that we're using GPT but /not/ UEFI, right?
That's why that's all a mess?



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

Re: Lenovo BIOS boot fix

[Warren Block]

On Mon, 13 Jul 2015, Adrian Chadd wrote:


I'm really confused. Why is the active flag not set again?

I thought that was the whole point of the active flag in the partition table.


At one point, smart people explained this to me.  My fault if I do not 
remember it correctly (not that it will stop me from attempting an 
explanation):


MBR partitions have active flags.  The BIOS is supposed to boot from the 
one that is set active.  It is not required that one be set active, 
though.  Most BIOS systems will still boot without any MBR partitions 
set active, presumably from the first partition.


The PMBR on a GPT disk is a simulation of an MBR.  However, according to 
the GPT standard, that simulated first MBR partition in the PMBR must 
not be set active.  A strict UEFI implementation will *not* boot if 
there is an active flag set for a PMBR partition.


Earlier versions of the FreeBSD PMBR had the PMBR partition set active, 
which was wrong.  The current version is correct.


I'm fairly sure we've seen people with both problems on the mailing 
lists and in the forums: BIOS systems that would not boot without an MBR 
partition set active, and UEFI systems that would not boot when a PMBR 
partition was set active.  They are rare, but it goes to prove you can't 
win.


(To fix old, incorrect FreeBSD PMBR versions, gpart can be used to set 
the "active" property on the GPT disk itself, which clears an active 
flag set on a PMBR partition.  So the problem should already be fixed, 
but this is the "set active" we are talking about.)

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

Re: Lenovo BIOS boot fix

[Warren Block]

On Mon, 13 Jul 2015, Kevin Oberman wrote:


This is possibly orthogonal and possibly not of use on X2nn systems, but I boot 
my T520 with a GPT formatted disk as the secondary drive by having the MBR 
disk0 configured with booteasy
and telling it to boot disk1. While this is of no use on single spindle systems 
like the X220, I have been told that a MBR USB drive can be used to do the same 
thing. I have not tried
this and can't confirm, though. Clearly a kludge work-around, but better than 
nothing and works well for me as I have always left Windows on the main drive 
and put FreeBSD on the
removable one.


Please, whoever has one of these systems, find a contact address for 
Lenovo.  It should be on every one of these messages, and we should be 
encouraging every affected user to contact Lenovo support.  I can post 
it in the forums, also.

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

Re: Lenovo BIOS boot fix

[Kevin Oberman]

On Mon, Jul 13, 2015 at 12:52 PM, Allan Jude  wrote:

> On 2015-07-13 15:45, Warren Block wrote:
>
>> On Mon, 13 Jul 2015, Allan Jude wrote:
>>
>>  On 2015-07-13 14:08, Warren Block wrote:
>>>
 On Mon, 13 Jul 2015, Allan Jude wrote:

  On 2015-07-13 11:19, Warren Block wrote:
>
>>
>>> Needing the active flag set is indeed a different problem. I am
>>> working
>>> on a patch for bsdinstall that will allow the user to request the
>>> active
>>> bit be set as well.
>>>
>>
>> For GPT, that should be the default, because it matches the standard.
>>
>> I would like to see an effort to get Lenovo to fix their broken
>> UEFI/BIOS.  Adding non-standard PMBR configurations should be
>> short-term
>> hack.
>>
>
> Lenovo has fixed the issue in newer models, x230, t530, t540 etc work
> fine.
>
> Just the x220, t420, and t520 etc series do not.
>

 The latest BIOS update for the x220 was less than two months ago, so it
 is still supported.  That they've fixed the problem in other models
 shows they understand the issue.  So owners of those models should be
 bugging Lenovo, so to speak.

 Long-term, it seems like they as a company would be concerned that
 special bug fixes naming their specific models are needed.

 Short-term, we probably can't avoid this.  It would be nice to be able
 to remove a Lenovo-specific hack from gpart in the future with a commit
 that says "Fixed by Lenovo BIOS update #123, no longer needed".

>>>
>>> I tried the latest bios update for the X220, from 2015-05-27
>>>
>>> It does not resolve the issue.
>>>
>>> Also, it required some hoop jumping, as they only provide a bootable
>>> cd (x220s do not have CD drives) and a windows program.
>>>
>>> However, if others are interested, this handy perl script:
>>> http://userpages.uni-koblenz.de/~krienke/ftp/noarch/geteltorito/
>>>
>>> can be used to extract the el torito image from that .iso to a file,
>>> that can then be dd'd to a USB stick and update the bios.
>>>
>>
>> Sorry, I did not mean to imply that the latest X220 BIOS fixed the
>> problem, just that they were continuing to release BIOS updates for it
>> and could not disown responsibility by saying the system was no longer
>> supported.
>>
>
> Right. I was not aware they were still publishing BIOSs, so I was hopeful
> it was fixed, and was disappointed after jumping through the hoops to get
> the update without installing windows on my machine, or somehow connecting
> a CD drive to it.
>
> Anyway, yes, hopefully Lenovo will fix this someday.
>
> --
> Allan Jude


This is possibly orthogonal and possibly not of use on X2nn systems, but I
boot my T520 with a GPT formatted disk as the secondary drive by having the
MBR disk0 configured with booteasy and telling it to boot disk1. While this
is of no use on single spindle systems like the X220, I have been told that
a MBR USB drive can be used to do the same thing. I have not tried this and
can't confirm, though. Clearly a kludge work-around, but better than
nothing and works well for me as I have always left Windows on the main
drive and put FreeBSD on the removable one.
--
Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Instant panic while trying run ports-mgmt/poudriere

[Pawel Pekala]

Hi Mateusz,

On 2015-07-13 23:28 +0200, Mateusz Guzik  wrote:
>On Mon, Jul 13, 2015 at 11:12:05PM +0200, Pawel Pekala wrote:
>> Hi
>> 
>> I'm getting 100% reproducible kernel crash while trying build ports
>> with poudriere on my system. This started to show up about 2-3 weeks
>> ago. I upgrade my system on weekly basis usually on saturday.
>> Here's backtrace:
>> 
>> (kgdb) bt
>[..]
>> at /hdd/src/sys/amd64/amd64/trap.c:201
>> #25 0x80dace32 in calltrap ()
>> at /hdd/src/sys/amd64/amd64/exception.S:235 #26 0x80941430
>> in knote (list=0xf801a2589408, hint=2147483648, lockflags=> optimized out>) at /hdd/src/sys/kern/kern_event.c:1920 #27
>> 0x80946a51 in exit1 (td=0xf801b84014d0, rv=> optimized out>) at /hdd/src/sys/kern/kern_exit.c:560 #28
>> 0x80945f1e in sys_sys_exit (td=0x0, uap=> out>) at /hdd/src/sys/kern/kern_exit.c:178 #29 0x80dcdaa2 in
>> out>amd64_syscall (td=0xf801b84014d0, traced=0)
>> at subr_syscall.c:133
>> #30 0x80dad11b in Xfast_syscall ()
>> at /hdd/src/sys/amd64/amd64/exception.S:395 #31 0x000800922eea
>> in ?? () Previous frame inner to this frame (corrupt stack?)
>> Current language:  auto; currently minimal
>> 
>> Let me know if you need more details.
>
>
>Well, if the problem is really that reproducible it would be best if
>you narrowed it down to the exact commit.
>
>However, quick look suggests you may be a "victim" of r284861.
>
>Can you enter kgdb and:
>f 26
>p *list
>
>?

(kgdb) f 26
#26 0x80941430 in knote (list=0xf801a2589408, hint=2147483648, 
lockflags=) at /hdd/src/sys/kern/kern_event.c:1920
1920} else if ((lockflags & KNF_NOKQLOCK) != 0) {
Current language:  auto; currently minimal
(kgdb) p *list
$1 = {kl_list = {slh_first = 0x0}, kl_lock = 0x809418e0 
, 
  kl_unlock = 0x80941900 , 
  kl_assert_locked = 0x80941920 , 
  kl_assert_unlocked = 0x80941940 , 
  kl_lockarg = 0xf801a2589120}


Forgot to add my uname -a last time:

FreeBSD blaviken.slowicza.org 11.0-CURRENT FreeBSD 11.0-CURRENT #44 r285509: 
Mon Jul 13 22:38:11 CEST 2015 
c...@blaviken.slowicza.org:/usr/obj/hdd/src/sys/GENERIC  amd64

-- 
pozdrawiam / with regards
Paweł Pękala
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Instant panic while trying run ports-mgmt/poudriere

[Mateusz Guzik]

On Mon, Jul 13, 2015 at 11:12:05PM +0200, Pawel Pekala wrote:
> Hi
> 
> I'm getting 100% reproducible kernel crash while trying build ports
> with poudriere on my system. This started to show up about 2-3 weeks
> ago. I upgrade my system on weekly basis usually on saturday.
> Here's backtrace:
> 
> (kgdb) bt
[..]
> at /hdd/src/sys/amd64/amd64/trap.c:201
> #25 0x80dace32 in calltrap () at 
> /hdd/src/sys/amd64/amd64/exception.S:235
> #26 0x80941430 in knote (list=0xf801a2589408, hint=2147483648, 
> lockflags=) at /hdd/src/sys/kern/kern_event.c:1920
> #27 0x80946a51 in exit1 (td=0xf801b84014d0, rv= out>)
> at /hdd/src/sys/kern/kern_exit.c:560
> #28 0x80945f1e in sys_sys_exit (td=0x0, uap=)
> at /hdd/src/sys/kern/kern_exit.c:178
> #29 0x80dcdaa2 in amd64_syscall (td=0xf801b84014d0, traced=0)
> at subr_syscall.c:133
> #30 0x80dad11b in Xfast_syscall () at 
> /hdd/src/sys/amd64/amd64/exception.S:395
> #31 0x000800922eea in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> Current language:  auto; currently minimal
> 
> Let me know if you need more details.


Well, if the problem is really that reproducible it would be best if you
narrowed it down to the exact commit.

However, quick look suggests you may be a "victim" of r284861.

Can you enter kgdb and:
f 26
p *list

?


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

Instant panic while trying run ports-mgmt/poudriere

[Pawel Pekala]

Hi

I'm getting 100% reproducible kernel crash while trying build ports
with poudriere on my system. This started to show up about 2-3 weeks
ago. I upgrade my system on weekly basis usually on saturday.
Here's backtrace:

(kgdb) bt
#0  doadump (textdump=1) at pcpu.h:221
#1  0x80984625 in kern_reboot (howto=260) at 
/hdd/src/sys/kern/kern_shutdown.c:447
#2  0x80984c18 in vpanic (fmt=, ap=)
at /hdd/src/sys/kern/kern_shutdown.c:744
#3  0x80984c63 in panic (fmt=0x0) at 
/hdd/src/sys/kern/kern_shutdown.c:675
#4  0x8098e281 in mi_switch (flags=, 
newtd=) at /hdd/src/sys/kern/kern_synch.c:406
#5  0x809d5991 in turnstile_wait (ts=, owner=0x0, 
queue=) at /hdd/src/sys/kern/subr_turnstile.c:751
#6  0x8098234d in __rw_wlock_hard (c=0x8185bd18, 
tid=18446735285002704080, 
file=, line=)
at /hdd/src/sys/kern/kern_rwlock.c:898
#7  0x80981f74 in _rw_wlock_cookie (c=, 
file=0x810e0c29 "/hdd/src/sys/amd64/amd64/pmap.c", line=3690)
at /hdd/src/sys/kern/kern_rwlock.c:268
#8  0x80dbcf1e in pmap_remove_all (m=0xf8041a03e450)
at /hdd/src/sys/amd64/amd64/pmap.c:3690
#9  0x80c30986 in cdev_pager_free_page (object=, 
m=0xf8041a03e450) at /hdd/src/sys/vm/device_pager.c:215
#10 0x8223ce30 in ttm_bo_release_mmap (bo=0xf800cd06e848)
at /hdd/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_bo_vm.c:390
#11 0x82238a7c in ttm_bo_unmap_virtual (bo=0xf800cd06e848)
at /hdd/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_bo.c:1651
#12 0x82081365 in radeon_pm_set_clocks (rdev=0xfe000133d000)
at 
/hdd/src/sys/modules/drm2/radeonkms/../../../dev/drm2/radeon/radeon_pm.c:146
#13 0x82081e4e in radeon_pm_compute_clocks (rdev=)
at 
/hdd/src/sys/modules/drm2/radeonkms/../../../dev/drm2/radeon/radeon_pm.c:777
#14 0x82093b63 in atombios_crtc_dpms (crtc=, 
mode=)
at 
/hdd/src/sys/modules/drm2/radeonkms/../../../dev/drm2/radeon/atombios_crtc.c:277
#15 0x820955f9 in atombios_crtc_prepare (crtc=0xf80005c7f000)
at 
/hdd/src/sys/modules/drm2/radeonkms/../../../dev/drm2/radeon/atombios_crtc.c:1829
#16 0x8221e938 in drm_crtc_helper_set_mode (crtc=0xf80005c7f000, 
mode=0xf80005775d00, x=0, y=0, old_fb=0xf80005c63100)
at /hdd/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_crtc_helper.c:454
#17 0x8221f504 in drm_crtc_helper_set_config (set=0xf80005742000)
---Type  to continue, or q  to quit---
at /hdd/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_crtc_helper.c:752
#18 0x822255c6 in vt_kms_postswitch (arg=)
at /hdd/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_fb_helper.c:344
#19 0x8081f249 in vt_window_switch (vw=0x81558208)
at /hdd/src/sys/dev/vt/vt_core.c:531
#20 0x8081ce83 in vtterm_cngrab (tm=)
at /hdd/src/sys/dev/vt/vt_core.c:1423
#21 0x8092f225 in cngrab () at /hdd/src/sys/kern/kern_cons.c:368
#22 0x809c1a9a in kdb_trap (type=9, code=0, tf=)
at /hdd/src/sys/kern/subr_kdb.c:651
#23 0x80dcd235 in trap_fatal (frame=0xfe046cfad950, eva=)
at /hdd/src/sys/amd64/amd64/trap.c:848
#24 0x80dccf03 in trap (frame=)
at /hdd/src/sys/amd64/amd64/trap.c:201
#25 0x80dace32 in calltrap () at 
/hdd/src/sys/amd64/amd64/exception.S:235
#26 0x80941430 in knote (list=0xf801a2589408, hint=2147483648, 
lockflags=) at /hdd/src/sys/kern/kern_event.c:1920
#27 0x80946a51 in exit1 (td=0xf801b84014d0, rv=)
at /hdd/src/sys/kern/kern_exit.c:560
#28 0x80945f1e in sys_sys_exit (td=0x0, uap=)
at /hdd/src/sys/kern/kern_exit.c:178
#29 0x80dcdaa2 in amd64_syscall (td=0xf801b84014d0, traced=0)
at subr_syscall.c:133
#30 0x80dad11b in Xfast_syscall () at 
/hdd/src/sys/amd64/amd64/exception.S:395
#31 0x000800922eea in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language:  auto; currently minimal

Let me know if you need more details.

-- 
pozdrawiam / with regards
Paweł Pękala
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD_HEAD-tests - Build #1181 - Fixed

[jenkins-admin]

FreeBSD_HEAD-tests - Build #1181 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1181/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1181/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1181/console

Change summaries:

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

Re: Lenovo BIOS boot fix

[Allan Jude]

On 2015-07-13 15:45, Warren Block wrote:

On Mon, 13 Jul 2015, Allan Jude wrote:


On 2015-07-13 14:08, Warren Block wrote:

On Mon, 13 Jul 2015, Allan Jude wrote:


On 2015-07-13 11:19, Warren Block wrote:


Needing the active flag set is indeed a different problem. I am
working
on a patch for bsdinstall that will allow the user to request the
active
bit be set as well.


For GPT, that should be the default, because it matches the standard.

I would like to see an effort to get Lenovo to fix their broken
UEFI/BIOS.  Adding non-standard PMBR configurations should be
short-term
hack.


Lenovo has fixed the issue in newer models, x230, t530, t540 etc work
fine.

Just the x220, t420, and t520 etc series do not.


The latest BIOS update for the x220 was less than two months ago, so it
is still supported.  That they've fixed the problem in other models
shows they understand the issue.  So owners of those models should be
bugging Lenovo, so to speak.

Long-term, it seems like they as a company would be concerned that
special bug fixes naming their specific models are needed.

Short-term, we probably can't avoid this.  It would be nice to be able
to remove a Lenovo-specific hack from gpart in the future with a commit
that says "Fixed by Lenovo BIOS update #123, no longer needed".


I tried the latest bios update for the X220, from 2015-05-27

It does not resolve the issue.

Also, it required some hoop jumping, as they only provide a bootable
cd (x220s do not have CD drives) and a windows program.

However, if others are interested, this handy perl script:
http://userpages.uni-koblenz.de/~krienke/ftp/noarch/geteltorito/

can be used to extract the el torito image from that .iso to a file,
that can then be dd'd to a USB stick and update the bios.


Sorry, I did not mean to imply that the latest X220 BIOS fixed the
problem, just that they were continuing to release BIOS updates for it
and could not disown responsibility by saying the system was no longer
supported.


Right. I was not aware they were still publishing BIOSs, so I was 
hopeful it was fixed, and was disappointed after jumping through the 
hoops to get the update without installing windows on my machine, or 
somehow connecting a CD drive to it.


Anyway, yes, hopefully Lenovo will fix this someday.

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

Re: Lenovo BIOS boot fix

[Warren Block]

On Mon, 13 Jul 2015, Allan Jude wrote:


On 2015-07-13 14:08, Warren Block wrote:

On Mon, 13 Jul 2015, Allan Jude wrote:


On 2015-07-13 11:19, Warren Block wrote:


Needing the active flag set is indeed a different problem. I am working
on a patch for bsdinstall that will allow the user to request the
active
bit be set as well.


For GPT, that should be the default, because it matches the standard.

I would like to see an effort to get Lenovo to fix their broken
UEFI/BIOS.  Adding non-standard PMBR configurations should be short-term
hack.


Lenovo has fixed the issue in newer models, x230, t530, t540 etc work
fine.

Just the x220, t420, and t520 etc series do not.


The latest BIOS update for the x220 was less than two months ago, so it
is still supported.  That they've fixed the problem in other models
shows they understand the issue.  So owners of those models should be
bugging Lenovo, so to speak.

Long-term, it seems like they as a company would be concerned that
special bug fixes naming their specific models are needed.

Short-term, we probably can't avoid this.  It would be nice to be able
to remove a Lenovo-specific hack from gpart in the future with a commit
that says "Fixed by Lenovo BIOS update #123, no longer needed".


I tried the latest bios update for the X220, from 2015-05-27

It does not resolve the issue.

Also, it required some hoop jumping, as they only provide a bootable cd 
(x220s do not have CD drives) and a windows program.


However, if others are interested, this handy perl script: 
http://userpages.uni-koblenz.de/~krienke/ftp/noarch/geteltorito/


can be used to extract the el torito image from that .iso to a file, that can 
then be dd'd to a USB stick and update the bios.


Sorry, I did not mean to imply that the latest X220 BIOS fixed the 
problem, just that they were continuing to release BIOS updates for it 
and could not disown responsibility by saying the system was no longer 
supported.

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

Re: Lenovo BIOS boot fix

[Allan Jude]

On 2015-07-13 14:08, Warren Block wrote:

On Mon, 13 Jul 2015, Allan Jude wrote:


On 2015-07-13 11:19, Warren Block wrote:


Needing the active flag set is indeed a different problem. I am working
on a patch for bsdinstall that will allow the user to request the
active
bit be set as well.


For GPT, that should be the default, because it matches the standard.

I would like to see an effort to get Lenovo to fix their broken
UEFI/BIOS.  Adding non-standard PMBR configurations should be short-term
hack.


Lenovo has fixed the issue in newer models, x230, t530, t540 etc work
fine.

Just the x220, t420, and t520 etc series do not.


The latest BIOS update for the x220 was less than two months ago, so it
is still supported.  That they've fixed the problem in other models
shows they understand the issue.  So owners of those models should be
bugging Lenovo, so to speak.

Long-term, it seems like they as a company would be concerned that
special bug fixes naming their specific models are needed.

Short-term, we probably can't avoid this.  It would be nice to be able
to remove a Lenovo-specific hack from gpart in the future with a commit
that says "Fixed by Lenovo BIOS update #123, no longer needed".


I tried the latest bios update for the X220, from 2015-05-27

It does not resolve the issue.

Also, it required some hoop jumping, as they only provide a bootable cd 
(x220s do not have CD drives) and a windows program.


However, if others are interested, this handy perl script: 
http://userpages.uni-koblenz.de/~krienke/ftp/noarch/geteltorito/


can be used to extract the el torito image from that .iso to a file, 
that can then be dd'd to a USB stick and update the bios.


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

Re: protection against module unloading ?

[Konstantin Belousov]

On Mon, Jul 13, 2015 at 08:56:36PM +0200, Luigi Rizzo wrote:
> On Mon, Jul 13, 2015 at 06:29:12PM +0300, Konstantin Belousov wrote:
> > On Mon, Jul 13, 2015 at 05:00:30PM +0200, Luigi Rizzo wrote:
> ...
> > > thanks a lot for the clarification on the intent.
> > > I clearly need to understand more on the architecture of the module 
> > > unload.
> > > 
> > > In any case: the global contention on devmtx for I/O syscalls is
> > > really a showstopper for making effective use of modular drivers
> > > so we should really find a way to remove it.
> > What contention do you see ?  Is it on the device node for a single
> > device ?  If yes, then any modification of the below proposal would
> > not help.  I explained this below.
> 
> It was adrian that pointed it out to me the huge devmtx contention
> with multiple threads doing I/O on netmap file descriptor
> (4-8 threads each of them issuing around 200K syscalls/s)
> 
> Now i see how even if my idea of per-dev lock was correct
> it would not remove contention at all.
> 
> One final thing:
> 
> > > Is there any other way to protect access to dev->si_threadcount ?
> > > 
> > > Eg how about the following:
> > > - use a (leaf) lock into struct cdev to protect dev->si_threadcount, so 
> > > that
> > >   we could replace dev_lock() with mtx_lock(&dev->foo) in 
> > > dev_refthread(dev)
> > >   dev_relthread(dev) and other places that access si_threadcount
> > This would not work, you cannot protect a lifetime of the object by a lock
> > contained in the object.
> 
> i thought so but then the current dev_refthread() is already unsafe,
> accessing dev->si_flags unprotected
> 
> sys/kern/kern_conf.c:
> 
>   struct cdevsw *
>   dev_refthread(struct cdev *dev, int *ref)
>   {
>   struct cdevsw *csw;
>   struct cdev_priv *cdp;
> 
>   mtx_assert(&devmtx, MA_NOTOWNED);
>   if ((dev->si_flags & SI_ETERNAL) != 0) {
>   *ref = 0;
>   return (dev->si_devsw);
>   }
>   dev_lock();
>   csw = dev->si_devsw;
>   if (csw != NULL) {
>   cdp = cdev2priv(dev);
>   if ((cdp->cdp_flags & CDP_SCHED_DTR) == 0)
>   atomic_add_long(&dev->si_threadcount, 1);
>   else
>   csw = NULL;
>   }
>   dev_unlock();
>   *ref = 1;
>   return (csw);
>   }
> 
> that is particularly bad though, because it prevents from
> checking the SI_ETERNAL flag without holding the lock (short
> of encoding the flag in the pointer!)
> 

I believe this check is fine, although for the complicated reasons.

E.g., for devfs_open(), the vnode is locked, so it cannot be reclaimed.
Since the vnode is not doomed, it referenced the v_rdev and struct cdev
memory cannot be freed and reused. So the access to the so_flags is
fine.

Note that devfs_fp_check(), which is called with the vnode unlocked,
still has a guarantee that the vnode is not going away, because the
vnode is referenced by the file descriptor. Then, the devvn_refthread()
checks VV_ETERNALDEV, without accessing the struct cdev at all. If the
vnode claims that the backing device is eternal, we have a guarantee
that v_rdev is either valid cdev, or NULL.

For the non-managed device pager, the vm object owns a reference on
the cdev, so again the device memory cannot go away while in the
dev_refthread().

I believe I considered all cases when I added eternal flag.

But note that what I explained above does not allow to put the per-device
lock (like dev_mtx) into the struct cdev, e.g. due to the vnode reference
trick.  If the vnode is not VV_ETERNAL, v_rdev might be invalidated at
any time, if you do not own vnode lock or interlock.


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

Re: protection against module unloading ?

[Luigi Rizzo]

On Mon, Jul 13, 2015 at 06:29:12PM +0300, Konstantin Belousov wrote:
> On Mon, Jul 13, 2015 at 05:00:30PM +0200, Luigi Rizzo wrote:
...
> > thanks a lot for the clarification on the intent.
> > I clearly need to understand more on the architecture of the module unload.
> > 
> > In any case: the global contention on devmtx for I/O syscalls is
> > really a showstopper for making effective use of modular drivers
> > so we should really find a way to remove it.
> What contention do you see ?  Is it on the device node for a single
> device ?  If yes, then any modification of the below proposal would
> not help.  I explained this below.

It was adrian that pointed it out to me the huge devmtx contention
with multiple threads doing I/O on netmap file descriptor
(4-8 threads each of them issuing around 200K syscalls/s)

Now i see how even if my idea of per-dev lock was correct
it would not remove contention at all.

One final thing:

> > Is there any other way to protect access to dev->si_threadcount ?
> > 
> > Eg how about the following:
> > - use a (leaf) lock into struct cdev to protect dev->si_threadcount, so that
> >   we could replace dev_lock() with mtx_lock(&dev->foo) in dev_refthread(dev)
> >   dev_relthread(dev) and other places that access si_threadcount
> This would not work, you cannot protect a lifetime of the object by a lock
> contained in the object.

i thought so but then the current dev_refthread() is already unsafe,
accessing dev->si_flags unprotected

sys/kern/kern_conf.c:

struct cdevsw *
dev_refthread(struct cdev *dev, int *ref)
{
struct cdevsw *csw;
struct cdev_priv *cdp;

mtx_assert(&devmtx, MA_NOTOWNED);
if ((dev->si_flags & SI_ETERNAL) != 0) {
*ref = 0;
return (dev->si_devsw);
}
dev_lock();
csw = dev->si_devsw;
if (csw != NULL) {
cdp = cdev2priv(dev);
if ((cdp->cdp_flags & CDP_SCHED_DTR) == 0)
atomic_add_long(&dev->si_threadcount, 1);
else
csw = NULL;
}
dev_unlock();
*ref = 1;
return (csw);
}

that is particularly bad though, because it prevents from
checking the SI_ETERNAL flag without holding the lock (short
of encoding the flag in the pointer!)

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

Re: Lenovo BIOS boot fix

[Warren Block]

On Mon, 13 Jul 2015, Allan Jude wrote:


On 2015-07-13 11:19, Warren Block wrote:


Needing the active flag set is indeed a different problem. I am working
on a patch for bsdinstall that will allow the user to request the active
bit be set as well.


For GPT, that should be the default, because it matches the standard.

I would like to see an effort to get Lenovo to fix their broken
UEFI/BIOS.  Adding non-standard PMBR configurations should be short-term
hack.


Lenovo has fixed the issue in newer models, x230, t530, t540 etc work fine.

Just the x220, t420, and t520 etc series do not.


The latest BIOS update for the x220 was less than two months ago, so it 
is still supported.  That they've fixed the problem in other models 
shows they understand the issue.  So owners of those models should be 
bugging Lenovo, so to speak.


Long-term, it seems like they as a company would be concerned that 
special bug fixes naming their specific models are needed.


Short-term, we probably can't avoid this.  It would be nice to be able 
to remove a Lenovo-specific hack from gpart in the future with a commit 
that says "Fixed by Lenovo BIOS update #123, no longer needed".

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

Re: Lenovo BIOS boot fix

[Allan Jude]

On 2015-07-13 13:19, Adrian Chadd wrote:

I'm really confused. Why is the active flag not set again?

I thought that was the whole point of the active flag in the partition table.


-a



Not that it counts much, but windows does not set the active flag in its 
pMBR.


I was under the impression the standard says that it should not be set, 
as anything actually examining the pMBR as if it were an MBR, obviously 
doesn't support GPT.


I've heard reports that GPT partitions with the active flag set, will 
not boot properly under UEFI.


At this point, I am not sure whether it should be set or not.

This fix is for the Lenovo's with the broken BIOS. It moves the 0xee 
partition in the pMBR to the 2nd slot instead of the first. This does 
not seem to break any previously working hardware, and it makes the 
Lenovo's work.


I have a patch: https://reviews.freebsd.org/D3065
that adds an option to gpart create to a pMBR with this fix applied.

If this gets committed, I can add 'GPT + Lenovo Fix' as an option during 
the installer. I already plan to add 'GPT + Active' for people like 
Colin Percival, who have a Dell or HP that seems to complain if the 
active flag is missing.


Windows avoids these issues by entirely refusing to boot from a GPT 
partitioned disk without UEFI, even though there is no such requirement.



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

Re: Lenovo BIOS boot fix

[Adrian Chadd]

I'm really confused. Why is the active flag not set again?

I thought that was the whole point of the active flag in the partition table.


-a


On 13 July 2015 at 08:54, Allan Jude  wrote:
> On 2015-07-13 11:19, Warren Block wrote:
>>>
>>>
>>> Needing the active flag set is indeed a different problem. I am working
>>> on a patch for bsdinstall that will allow the user to request the active
>>> bit be set as well.
>>
>>
>> For GPT, that should be the default, because it matches the standard.
>>
>> I would like to see an effort to get Lenovo to fix their broken
>> UEFI/BIOS.  Adding non-standard PMBR configurations should be short-term
>> hack.
>
>
> Lenovo has fixed the issue in newer models, x230, t530, t540 etc work fine.
>
> Just the x220, t420, and t520 etc series do not.
>
> --
> Allan Jude
>
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Lenovo BIOS boot fix

[Allan Jude]

On 2015-07-13 11:19, Warren Block wrote:


Needing the active flag set is indeed a different problem. I am working
on a patch for bsdinstall that will allow the user to request the active
bit be set as well.


For GPT, that should be the default, because it matches the standard.

I would like to see an effort to get Lenovo to fix their broken
UEFI/BIOS.  Adding non-standard PMBR configurations should be short-term
hack.


Lenovo has fixed the issue in newer models, x230, t530, t540 etc work fine.

Just the x220, t420, and t520 etc series do not.

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

Re: Why shoud we cause panic in scsi_da.c?

[Alexander Motin]

Hi.

On 13.07.2015 11:51, Kohji Okuno wrote:
>> On 07/13/15 10:11, Kohji Okuno wrote:
>>> Could you comment on my quesion?
>>>
 I found panic() in scsi_da.c. Please find the following.
 I think we should return with error without panic().
 What do you think about this?

 scsi_da.c:
 3018   } else if (bp != NULL) {
 3019 if ((done_ccb->ccb_h.status & CAM_DEV_QFRZN) != 0)
 3020   panic("REQ_CMP with QFRZN");

>>
>> It looks to me more like an KASSERT() is appropriate here.

As I can see, this panic() call was added by ken@ about 15 years ago.
I've added him to CC in case he has some idea why it was done. From my
personal opinion I don't see much reasons to allow CAM_DEV_QFRZN to be
returned only together with error. While is may have little sense in
case of successful command completion, I don't think it should be
treated as error. Simply removing this panic is probably a bad idea,
since if it happens device will just remain frozen forever, that will be
will be difficult to diagnose, but I would better just dropped device
freeze in that case same as in case of completion with error.

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

Re: protection against module unloading ?

[Konstantin Belousov]

On Mon, Jul 13, 2015 at 05:00:30PM +0200, Luigi Rizzo wrote:
> On Mon, Jul 13, 2015 at 03:46:03PM +0300, Konstantin Belousov wrote:
> > On Mon, Jul 13, 2015 at 02:28:40PM +0200, Luigi Rizzo wrote:
> > > Hi,
> > > I am trying to understand how to protect efficiently against
> > > module removals when a device driver is in use.
> > > This issue came up some time ago when trying netmap
> > > loaded as a module.
> > > 
> > > --- Summary of the current mode of operation (as i understand it): ---
> > > 
> > > When a device is compiled as a module, all devfs calls in
> > > sys/fs/devfs/devfs_vnops.c are protected by setting
> > > dev->si_threadcount (within dev*_refthread()) for the duration of the 
> > > call.
> > > 
> > > This is implemented using devfs_fp_check()/dev_relthread() which
> > > in turn, for the module case, updates the dev->si_threadcount under
> > > dev_lock() which is a single shared mutex, devmtx .
> > > 
> > > The above is problematic for driver modules that do a lot of I/O
> > > using poll, ioctl, read or write, because of the system-wide contention
> > > on devmtx
> > > 
> > > To mitigate the contention, statically compiled modules have the
> > > SI_ETERNAL attribute that prevents the lock (major contention point)
> > > and si_threadcount update.
> > > 
> > > --- Alternative ?
> > > 
> > > I was hoping to make the protection mechanism cheaper by only
> > > increasing  dev->si_threadcount on devfs_open() without calling
> > > dev_relthread() ), and then decreasing si_threadcount on defvs_close() .
> > > This way the reference is active for the lifetime of the file descriptor
> > > without needing to track individual high-frequency calls.
> > > 
> > > This is probably not enough because there could be mmap handlers,
> > > which remain active even after the device is closed.
> > This is of course wrong because destroy_dev(9) would be blocked until
> > all file descriptors referencing the device are closed.  The blocked
> > thread which called destroy_dev() is blocked hard, i.e. you cannot
> > interrupt it with a signal.  The situation is incomprehensible for
> > the user issued the kldunload command.
> > 
> > The current si_threadcount mechanism is designed and intended to work on
> > the code call granulariry, to allow the device destruction and driver
> > unload when there is no code call into the driver.
> 
> thanks a lot for the clarification on the intent.
> I clearly need to understand more on the architecture of the module unload.
> 
> In any case: the global contention on devmtx for I/O syscalls is
> really a showstopper for making effective use of modular drivers
> so we should really find a way to remove it.
What contention do you see ?  Is it on the device node for a single
device ?  If yes, then any modification of the below proposal would
not help.  I explained this below.

Also note that modules have more issues than lack of the ETERNAL cdevs.

E.g., on everything non-amd64 modules use PIC code. This means that any
access to the global variables is indirected through GOT, and that on
i386 one register is not available for computations from the already
scarce set of seven.

Modules do not use inlined fast-path for the locking primitives, as
well as they do not use inlined atomics.

Each loadable syscall requires an atomic on entry and atomic on exit.

There are probably more issues, this list is from the top of my
memory. The common wisdom is that you should not use modules if you do
benchmarking.

> Is there any other way to protect access to dev->si_threadcount ?
> 
> Eg how about the following:
> - use a (leaf) lock into struct cdev to protect dev->si_threadcount, so that
>   we could replace dev_lock() with mtx_lock(&dev->foo) in dev_refthread(dev)
>   dev_relthread(dev) and other places that access si_threadcount
This would not work, you cannot protect a lifetime of the object by a lock
contained in the object.

A modification that might work is to have the substitution lock for dev_mtx
embedded into cdevsw for the given device.  This is not completely trivial,
since there are some data in devfs and special node management that is
global.  Another complication is that drivers would need to call some
destructor for cdevsw, which is not required for current arrangement.

Still, even per-cdevsw dev_mtx would not help for the non-ETERNAL
contention on single devfs node.

> 
> - devvn_refthread() further uses vp->v_rdev, which elsewhere is protected by
>   VI_LOCK(vp), so devvn_refthread() could use the sequence
>   VI_LOCK(vp);
>   dev = vp->v_rdev;
>   if (dev != NULL) {
>   mtx_lock(&dev->foo)
>   if ( ... ) {
>   atomic_add_long(&dev->si_threadcount, 1);
>   }
>   mtx_unlock(&dev->foo);
>   }
>   VI_UNLOCK(vp)
> 
> 
>   (this is almos the same as what we have in devfs_allocv() and 
> devfs_reclaim(),
>   except that they use dev_lock() instead of the device-specific lock.
> 
> cheers
> luigi

Re: Lenovo BIOS boot fix

[Warren Block]

Needing the active flag set is indeed a different problem. I am working
on a patch for bsdinstall that will allow the user to request the active
bit be set as well.


For GPT, that should be the default, because it matches the standard.

I would like to see an effort to get Lenovo to fix their broken 
UEFI/BIOS.  Adding non-standard PMBR configurations should be short-term 
hack.

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

Re: protection against module unloading ?

[Luigi Rizzo]

On Mon, Jul 13, 2015 at 03:46:03PM +0300, Konstantin Belousov wrote:
> On Mon, Jul 13, 2015 at 02:28:40PM +0200, Luigi Rizzo wrote:
> > Hi,
> > I am trying to understand how to protect efficiently against
> > module removals when a device driver is in use.
> > This issue came up some time ago when trying netmap
> > loaded as a module.
> > 
> > --- Summary of the current mode of operation (as i understand it): ---
> > 
> > When a device is compiled as a module, all devfs calls in
> > sys/fs/devfs/devfs_vnops.c are protected by setting
> > dev->si_threadcount (within dev*_refthread()) for the duration of the call.
> > 
> > This is implemented using devfs_fp_check()/dev_relthread() which
> > in turn, for the module case, updates the dev->si_threadcount under
> > dev_lock() which is a single shared mutex, devmtx .
> > 
> > The above is problematic for driver modules that do a lot of I/O
> > using poll, ioctl, read or write, because of the system-wide contention
> > on devmtx
> > 
> > To mitigate the contention, statically compiled modules have the
> > SI_ETERNAL attribute that prevents the lock (major contention point)
> > and si_threadcount update.
> > 
> > --- Alternative ?
> > 
> > I was hoping to make the protection mechanism cheaper by only
> > increasing  dev->si_threadcount on devfs_open() without calling
> > dev_relthread() ), and then decreasing si_threadcount on defvs_close() .
> > This way the reference is active for the lifetime of the file descriptor
> > without needing to track individual high-frequency calls.
> > 
> > This is probably not enough because there could be mmap handlers,
> > which remain active even after the device is closed.
> This is of course wrong because destroy_dev(9) would be blocked until
> all file descriptors referencing the device are closed.  The blocked
> thread which called destroy_dev() is blocked hard, i.e. you cannot
> interrupt it with a signal.  The situation is incomprehensible for
> the user issued the kldunload command.
> 
> The current si_threadcount mechanism is designed and intended to work on
> the code call granulariry, to allow the device destruction and driver
> unload when there is no code call into the driver.

thanks a lot for the clarification on the intent.
I clearly need to understand more on the architecture of the module unload.

In any case: the global contention on devmtx for I/O syscalls is
really a showstopper for making effective use of modular drivers
so we should really find a way to remove it.
Is there any other way to protect access to dev->si_threadcount ?

Eg how about the following:
- use a (leaf) lock into struct cdev to protect dev->si_threadcount, so that
  we could replace dev_lock() with mtx_lock(&dev->foo) in dev_refthread(dev)
  dev_relthread(dev) and other places that access si_threadcount

- devvn_refthread() further uses vp->v_rdev, which elsewhere is protected by
  VI_LOCK(vp), so devvn_refthread() could use the sequence
VI_LOCK(vp);
dev = vp->v_rdev;
if (dev != NULL) {
mtx_lock(&dev->foo)
if ( ... ) {
atomic_add_long(&dev->si_threadcount, 1);
}
mtx_unlock(&dev->foo);
}
VI_UNLOCK(vp)


  (this is almos the same as what we have in devfs_allocv() and devfs_reclaim(),
  except that they use dev_lock() instead of the device-specific lock.

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

Re: Lenovo BIOS boot fix

[Allan Jude]

On 2015-07-13 03:58, Hans Ottevanger wrote:
> On 07/12/15 20:07, Allan Jude wrote:
>> On 2015-07-12 11:10, Andrey V. Elsukov wrote:
>>> On 12.07.2015 09:02, Allan Jude wrote:
 I forgot to include the link to the patch as well:

 http://www.allanjude.com/bsd/lenovofix_gpart.patch

 I will most likely make this patch optional, behind a flag to the
 'gpart
 create -s gpt' command, to avoid potentially breaking existing working
 systems, but if using offset 1 works on all other hardware, having
 it as
 the default would be nice.

 Another option would be to make a separate standalone program to modify
 the pMBR for Lenovo machines, rather than modifying gpart.
>>>
>>> Hi,
>>>
>>> I think Lenovo's BIOS just think that your partition layout is MBR and
>>> uses legacy boot.
>>>
>>> if (MBR_partition[0].type == 0xee && gpt_is_ok()) {
>>>  UEFI_boot();
>>> } else {
>>>  MBR_boot();
>>> }
>>>
>>
>> I am not sure what they actually do, but, by making it the
>> MBR_partition[1].type that is 0xee, FreeBSD is still perfectly happy,
>> and the Lenovo boots.
>>
>> Other non-lenovo machines I tested on also worked.
>>
>> Tested Platforms (in BIOS/non-UEFI mode):
>>
>> Lenovo X220
>> Lenovo X230 (doesn't have the bug, boots fine with MBR[0].type = 0xee)
>> Lenovo T530 (also doesn't have the bug)
>> Asus Core2Duo
>> Asus i7 Nehalem desktop
>> Asus i5 Sandy bridge desktop
>> Gigabyte i5 Ivy bridge desktop
>> Intel Ivy bridge NUC
>> Intel Haswell NUC
>> Supermicro i7 Haswell workstation
>>
>>
> 
> Hi Allan,
> 
> I did some experiments with the newest memstick image you provided
> (lenovofix_20150712-r285132.img).
> 
> On an oldish Q6600 based system using an INTEL DP965LT main-board (it
> only has BIOS mode) I first pulled the SATA connectors before trying to
> boot from the USB stick. It shows the same problem as always with a
> fresh install of FreeBSD 10.x:
> 
> No bootable device -- insert boot disk and press any key
> 
> This can be fixed by first modifying the image on the USB stick using
> 
> gpart recover da0
> 
> (the stick is 8Gbyte and the image as copied on it is 1Gbyte, so the GPT
> seems corrupt), followed by the usual
> 
> gpart set -a active da0
> 
> I think this issue manifests itself on a generation of older Intel and
> Foxconn main-boards and possibly differs from the problem that you try
> to solve with Lenovo hardware.
> 
> I also tried the unmodified image on an even older T7200 based system
> having an Asus NL4VM-DH main-board and there it just dumps the registers
> (followed by "BTX Halted") very early in the boot process. This has
> happened before on several occasions with FreeBSD 10.x. The board is
> probably too rare to worry about too much, though it still runs OpenBSD
> 5.7 perfectly.
> 
> 
> Kind regards,
> 
> Hans Ottevanger
> 
> Eindhoven, Netherlands
> www.beastielabs.net
> 
> 
> 
> 
> 

Needing the active flag set is indeed a different problem. I am working
on a patch for bsdinstall that will allow the user to request the active
bit be set as well.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: Lenovo BIOS boot fix

[Tomoaki AOKI]

Confirmed. Boots OK as expected for my ThinkPad T420 (has buggy BIOS).

On Sun, 12 Jul 2015 12:54:09 -0400
Allan Jude  wrote:

> On 2015-07-12 09:24, Tomoaki AOKI wrote:
> >
> > As far as I could confirm currently,
> >
> >*My ThinkPad didn't boot from decompressed .xz image written in
> > memstick.
> >
> >*The partition tables (both PMBR and GPT) looks fine.
> > (As expected. Verified with `gpart show` and `fdisk -p -v da0`)
> >
> >*Overwriting bootcode (gptzfsboot) in GPT partition 1 didn't help.
> >
> >
> > Not yet confirmed, but possible cause would be
> >
> >*Bootcode in PMBR is missing or corrupt.
> >  (I noticed I hadn't tested overwriting it.)
> >
> >*/boot in ZFS partition or anything related is not proper.
> >
> >
> > Sorry, I cannot reboot my ThinkPad right now.
> > Allan, can you confirm above?
> >
> 
> You are correct, the PMBR bootcode was missing, my mistake.
> 
> I have uploaded new images (and set the old ones to redirect to the new 
> ones)
> 
> compressed (193 MiB):
> http://www.allanjude.com/bsd/lenovofix_20150712-r285132.img.xz
> 
> uncompressed (1 GiB):
> http://www.allanjude.com/bsd/lenovofix_20150712-r285132.img
> 
> 
> 
> -- 
> Allan Jude
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 


-- 
青木 知明  [Tomoaki AOKI]
junch...@dec.sakura.ne.jp
mxe02...@nifty.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: protection against module unloading ?

[Konstantin Belousov]

On Mon, Jul 13, 2015 at 02:28:40PM +0200, Luigi Rizzo wrote:
> Hi,
> I am trying to understand how to protect efficiently against
> module removals when a device driver is in use.
> This issue came up some time ago when trying netmap
> loaded as a module.
> 
> --- Summary of the current mode of operation (as i understand it): ---
> 
> When a device is compiled as a module, all devfs calls in
> sys/fs/devfs/devfs_vnops.c are protected by setting
> dev->si_threadcount (within dev*_refthread()) for the duration of the call.
> 
> This is implemented using devfs_fp_check()/dev_relthread() which
> in turn, for the module case, updates the dev->si_threadcount under
> dev_lock() which is a single shared mutex, devmtx .
> 
> The above is problematic for driver modules that do a lot of I/O
> using poll, ioctl, read or write, because of the system-wide contention
> on devmtx
> 
> To mitigate the contention, statically compiled modules have the
> SI_ETERNAL attribute that prevents the lock (major contention point)
> and si_threadcount update.
> 
> --- Alternative ?
> 
> I was hoping to make the protection mechanism cheaper by only
> increasing  dev->si_threadcount on devfs_open() without calling
> dev_relthread() ), and then decreasing si_threadcount on defvs_close() .
> This way the reference is active for the lifetime of the file descriptor
> without needing to track individual high-frequency calls.
> 
> This is probably not enough because there could be mmap handlers,
> which remain active even after the device is closed.
This is of course wrong because destroy_dev(9) would be blocked until
all file descriptors referencing the device are closed.  The blocked
thread which called destroy_dev() is blocked hard, i.e. you cannot
interrupt it with a signal.  The situation is incomprehensible for
the user issued the kldunload command.

The current si_threadcount mechanism is designed and intended to work on
the code call granulariry, to allow the device destruction and driver
unload when there is no code call into the driver.

> 
> However I do not think the current devfs_fp_check() suffices either,
> and so drivers that have their own mmap code in a module that can be
> unloaded must already implement their own mechanism to protect
> against unloading.
Drivers which use (old) device pager cannot control the lifespan of
the mmapped regions.  The only way to properly track and clean up the
mappings is to use the MGTDEVICE pager, which creates the managed
fictitious mapping for the device mmaps.  Device destruction causes
correct removal of the ptes for the fictitious pages created by the
driver page fault handler.  See examples in the GEM and TTM.


> In fact, this could be achieved easily by making these drivers use
> dev_refthread() to hold a refcount while active.
No, this is reversed and breaks the correct mechanism.

> 
> Would the above work ? Anything missing ?
> 
> cheers
> luigi
> 
> -- 
> -+---
>  Prof. Luigi RIZZO, ri...@iet.unipi.it  . Dip. di Ing. dell'Informazione
>  http://www.iet.unipi.it/~luigi/. Universita` di Pisa
>  TEL  +39-050-2217533   . via Diotisalvi 2
>  Mobile   +39-338-6809875   . 56122 PISA (Italy)
> -+---
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

protection against module unloading ?

[Luigi Rizzo]

Hi,
I am trying to understand how to protect efficiently against
module removals when a device driver is in use.
This issue came up some time ago when trying netmap
loaded as a module.

--- Summary of the current mode of operation (as i understand it): ---

When a device is compiled as a module, all devfs calls in
sys/fs/devfs/devfs_vnops.c are protected by setting
dev->si_threadcount (within dev*_refthread()) for the duration of the call.

This is implemented using devfs_fp_check()/dev_relthread() which
in turn, for the module case, updates the dev->si_threadcount under
dev_lock() which is a single shared mutex, devmtx .

The above is problematic for driver modules that do a lot of I/O
using poll, ioctl, read or write, because of the system-wide contention
on devmtx

To mitigate the contention, statically compiled modules have the
SI_ETERNAL attribute that prevents the lock (major contention point)
and si_threadcount update.

--- Alternative ?

I was hoping to make the protection mechanism cheaper by only
increasing  dev->si_threadcount on devfs_open() without calling
dev_relthread() ), and then decreasing si_threadcount on defvs_close() .
This way the reference is active for the lifetime of the file descriptor
without needing to track individual high-frequency calls.

This is probably not enough because there could be mmap handlers,
which remain active even after the device is closed.

However I do not think the current devfs_fp_check() suffices either,
and so drivers that have their own mmap code in a module that can be
unloaded must already implement their own mechanism to protect
against unloading.
In fact, this could be achieved easily by making these drivers use
dev_refthread() to hold a refcount while active.

Would the above work ? Anything missing ?

cheers
luigi

-- 
-+---
 Prof. Luigi RIZZO, ri...@iet.unipi.it  . Dip. di Ing. dell'Informazione
 http://www.iet.unipi.it/~luigi/. Universita` di Pisa
 TEL  +39-050-2217533   . via Diotisalvi 2
 Mobile   +39-338-6809875   . 56122 PISA (Italy)
-+---
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD_HEAD-tests - Build #1180 - Still Failing

[jenkins-admin]

FreeBSD_HEAD-tests - Build #1180 - Still Failing:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1180/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1180/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1180/console

Change summaries:

No changes


The end of the build log:

Started by upstream project "Build_Image_and_Run_Tests_in_Bhyve_HEAD" build 
number 1238
originally caused by:
 Started by upstream project "FreeBSD_HEAD" build number 2962
 originally caused by:
  Started by an SCM change
Building remotely on havoc.ysv.freebsd.org (FreeBSD-CURRENT-baremetal) in 
workspace /builds/FreeBSD_HEAD-tests
No emails were triggered.
[FreeBSD_HEAD-tests] $ /bin/sh -xe /tmp/hudson5101072737704880453.sh
+ sudo python /vm/freebsd-ci/scripts/test/run-tests.py -f 
/vm/freebsd-ci/scripts/test/config/config.json
bridge1: flags=8843 metric 0 mtu 1500
ether 02:27:d1:9a:45:01
inet 192.168.10.1 netmask 0xff00 broadcast 192.168.10.255 
nd6 options=1
groups: bridge 
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: tap10 flags=143
ifmaxaddr 0 port 10 priority 128 path cost 200
member: tap11 flags=143
ifmaxaddr 0 port 9 priority 128 path cost 200
tap10: flags=8902 metric 0 mtu 1500
options=8
ether 00:bd:bf:03:5d:0a
nd6 options=29
media: Ethernet autoselect
status: no carrier
groups: tap 
['ifconfig', u'bridge1']

bhyveload -m 2G -d 
/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img 
vm_test
Consoles: userboot  

FreeBSD/amd64 User boot, Revision 1.1
(r...@havoc.ysv.freebsd.org, Sat Mar  7 06:40:36 UTC 2015)
|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|Loading
 /boot/defaults/loader.conf
/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|
  ````s` `.---...--.```   
-/+o   .--` /y:`  +. yo`:.:o  
`+-  y/   -/`   -o/ .-  
::/sy+:. / `--  /`: 
 :``:  :` /  
/ .--.  --  
-.   `:`  `:` .-- `--.  
  .---../-\|  __      _ _  
|  | |  _ \ / |  __ \ | |___ _ __ ___  ___ | 
|_) | (___ | |  | ||  ___| '__/ _ \/ _ \|  _ < \___ \| |  | || |   
| | |  __/  __/| |_) |) | |__| || |   | | |||| 
 |  |  ||_|   |_|  \___|\___||/|_/|_/ 
||||||||||||||||||||||||==++++/-\|/-\|/-Welcome
 to FreeBSD1 .Boot Multi User [Enter]2 
.Boot [S]ingle User3 .[Esc]ape to loader 
prompt4 .RebootOptions:5 
.[K]ernel: kernel (1 of 2)6 .Configure Boot 
[O]ptions...Autoboot in 9 seconds. [Space] to 
pauseAutoboot in 8 seconds. [Space] to 
pauseAutoboot in 7 seconds. [Space] to 
pauseAutoboot in 6 seconds. [Space] to 
pauseAutoboot in 5 seconds. [Space] to pause[2
 5;0HAutoboot in 4 seconds. [Space] to pauseAutoboot in 3 
seconds. [Space] to pauseAutoboot in 2 seconds. [Space] to 
pauseAutoboot in 1 seconds. [Space] to pause
   
\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-/boot/kernel/kernel
 text=0x10b05c0 
\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/data=0x131578+0x3d8240
 
-\|/-\|/-syms=[0x8+0x1515d8\|/-\|/-\|/+0x8+0x16d018-\|/-\|/-\|]
/-\|/-\|/-Booting...
\|/-\bhyve -c 2 -m 2G -AI -H -P -g 0 -s 0:0,hostbridge -s 1:0,lpc -s 
2:0,virtio-net,tap10

Re: Getting Asus FM200 working with FreeBSD

[Daniel Peyrolon]

Hi,

> what about PCBSD?
Probably should have said something about PCBSD... It didn't work when
trying to start X, it couldn't find the adapter.
I will nevertheless try the last images tomorrow, when I can, and let you
know.

El lun., 13 jul. 2015 a las 6:19, Julian Elischer ()
escribió:

> On 7/11/15 8:29 PM, Daniel Peyrolon wrote:
> > Hi everyone,
> >
> > I'm trying to get FreeBSD-CURRENT up and running with anything different
> > than console-only on an Asus FM200. I created a wiki page for it: [1].
> >
> > I've tried GhostBSD on it, and everything pretty much worked, except
> > suspend/resume, and audio.
> what about PCBSD?
> > I've CURRENT [2] installed on it, but so far, I haven't been able to get
> it
> > working, vesa is not even being loaded (error 19). Any idea, suggestions?
> >
> > [1]: https://wiki.freebsd.org/Laptops/ASUS_FM200
> > [2]: FreeBSD BlackBox 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r285358: Fri
> Jul
> > 10 18:40:27 CEST 2015 root@BlackBox:/usr/obj/usr/src/sys/GENERIC amd64
> >
> >
>
> --
Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Why shoud we cause panic in scsi_da.c?

[Kohji Okuno]

Hi HPS,

Thank you for your comment.
I will wait for the commnet.

Kohji Okuno

> On 07/13/15 10:11, Kohji Okuno wrote:
>> Hi,
>>
>> Could you comment on my quesion?
>>
>> Best regards,
>>   Kohji Okuno
>>
>>> Hi,
>>>
>>> I found panic() in scsi_da.c. Please find the following.
>>> I think we should return with error without panic().
>>> What do you think about this?
>>>
>>> scsi_da.c:
>>> 3018} else if (bp != NULL) {
>>> 3019 if ((done_ccb->ccb_h.status & CAM_DEV_QFRZN) != 0)
>>> 3020panic("REQ_CMP with QFRZN");
>>>
> 
> Hi,
> 
> It looks to me more like an KASSERT() is appropriate here.
> 
> Might be some people which can answer this are on vacation currently.
> 
> --HPS
> 
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Why shoud we cause panic in scsi_da.c?

[Hans Petter Selasky]

On 07/13/15 10:11, Kohji Okuno wrote:

Hi,

Could you comment on my quesion?

Best regards,
  Kohji Okuno


Hi,

I found panic() in scsi_da.c. Please find the following.
I think we should return with error without panic().
What do you think about this?

scsi_da.c:
3018} else if (bp != NULL) {
3019if ((done_ccb->ccb_h.status & CAM_DEV_QFRZN) != 
0)
3020panic("REQ_CMP with QFRZN");



Hi,

It looks to me more like an KASSERT() is appropriate here.

Might be some people which can answer this are on vacation currently.

--HPS

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

Re: Why shoud we cause panic in scsi_da.c?

[Kohji Okuno]

Hi,

Could you comment on my quesion?

Best regards,
 Kohji Okuno

> Hi,
> 
> I found panic() in scsi_da.c. Please find the following.
> I think we should return with error without panic().
> What do you think about this?
> 
> scsi_da.c:
> 3018  } else if (bp != NULL) {
> 3019  if ((done_ccb->ccb_h.status & CAM_DEV_QFRZN) != 
> 0)
> 3020  panic("REQ_CMP with QFRZN");
> 
> Best regards,
>  Kohji Okuno
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Lenovo BIOS boot fix

[Hans Ottevanger]

On 07/12/15 20:07, Allan Jude wrote:

On 2015-07-12 11:10, Andrey V. Elsukov wrote:

On 12.07.2015 09:02, Allan Jude wrote:

I forgot to include the link to the patch as well:

http://www.allanjude.com/bsd/lenovofix_gpart.patch

I will most likely make this patch optional, behind a flag to the 'gpart
create -s gpt' command, to avoid potentially breaking existing working
systems, but if using offset 1 works on all other hardware, having it as
the default would be nice.

Another option would be to make a separate standalone program to modify
the pMBR for Lenovo machines, rather than modifying gpart.


Hi,

I think Lenovo's BIOS just think that your partition layout is MBR and
uses legacy boot.

if (MBR_partition[0].type == 0xee && gpt_is_ok()) {
 UEFI_boot();
} else {
 MBR_boot();
}



I am not sure what they actually do, but, by making it the
MBR_partition[1].type that is 0xee, FreeBSD is still perfectly happy,
and the Lenovo boots.

Other non-lenovo machines I tested on also worked.

Tested Platforms (in BIOS/non-UEFI mode):

Lenovo X220
Lenovo X230 (doesn't have the bug, boots fine with MBR[0].type = 0xee)
Lenovo T530 (also doesn't have the bug)
Asus Core2Duo
Asus i7 Nehalem desktop
Asus i5 Sandy bridge desktop
Gigabyte i5 Ivy bridge desktop
Intel Ivy bridge NUC
Intel Haswell NUC
Supermicro i7 Haswell workstation




Hi Allan,

I did some experiments with the newest memstick image you provided 
(lenovofix_20150712-r285132.img).


On an oldish Q6600 based system using an INTEL DP965LT main-board (it 
only has BIOS mode) I first pulled the SATA connectors before trying to 
boot from the USB stick. It shows the same problem as always with a 
fresh install of FreeBSD 10.x:


No bootable device -- insert boot disk and press any key

This can be fixed by first modifying the image on the USB stick using

gpart recover da0

(the stick is 8Gbyte and the image as copied on it is 1Gbyte, so the GPT 
seems corrupt), followed by the usual


gpart set -a active da0

I think this issue manifests itself on a generation of older Intel and 
Foxconn main-boards and possibly differs from the problem that you try 
to solve with Lenovo hardware.


I also tried the unmodified image on an even older T7200 based system 
having an Asus NL4VM-DH main-board and there it just dumps the registers 
(followed by "BTX Halted") very early in the boot process. This has 
happened before on several occasions with FreeBSD 10.x. The board is 
probably too rare to worry about too much, though it still runs OpenBSD 
5.7 perfectly.



Kind regards,

Hans Ottevanger

Eindhoven, Netherlands
www.beastielabs.net





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

FreeBSD_HEAD-tests - Build #1179 - Still Failing

[jenkins-admin]

FreeBSD_HEAD-tests - Build #1179 - Still Failing:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1179/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1179/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1179/console

Change summaries:

No changes


The end of the build log:

Started by upstream project "Build_Image_and_Run_Tests_in_Bhyve_HEAD" build 
number 1237
originally caused by:
 Started by upstream project "FreeBSD_HEAD" build number 2961
 originally caused by:
  Started by an SCM change
Building remotely on havoc.ysv.freebsd.org (FreeBSD-CURRENT-baremetal) in 
workspace /builds/FreeBSD_HEAD-tests
No emails were triggered.
[FreeBSD_HEAD-tests] $ /bin/sh -xe /tmp/hudson1543752533853692684.sh
+ sudo python /vm/freebsd-ci/scripts/test/run-tests.py -f 
/vm/freebsd-ci/scripts/test/config/config.json
bridge1: flags=8843 metric 0 mtu 1500
ether 02:27:d1:9a:45:01
inet 192.168.10.1 netmask 0xff00 broadcast 192.168.10.255 
nd6 options=1
groups: bridge 
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: tap10 flags=143
ifmaxaddr 0 port 10 priority 128 path cost 200
member: tap11 flags=143
ifmaxaddr 0 port 9 priority 128 path cost 200
tap10: flags=8902 metric 0 mtu 1500
options=8
ether 00:bd:bf:03:5d:0a
nd6 options=29
media: Ethernet autoselect
status: no carrier
groups: tap 
['ifconfig', u'bridge1']

bhyveload -m 2G -d 
/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img 
vm_test
Consoles: userboot  

FreeBSD/amd64 User boot, Revision 1.1
(r...@havoc.ysv.freebsd.org, Sat Mar  7 06:40:36 UTC 2015)
|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|Loading
 /boot/defaults/loader.conf
/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|
  ````s` `.---...--.```   
-/+o   .--` /y:`  +. yo`:.:o  
`+-  y/   -/`   -o/ .-  
::/sy+:. / `--  /`: 
 :``:  :` /  
/ .--.  --  
-.   `:`  `:` .-- `--.  
  .---../-\|  __      _ _  
|  | |  _ \ / |  __ \ | |___ _ __ ___  ___ | 
|_) | (___ | |  | ||  ___| '__/ _ \/ _ \|  _ < \___ \| |  | || |   
| | |  __/  __/| |_) |) | |__| || |   | | |||| 
 |  |  ||_|   |_|  \___|\___||/|_/|_/ 
||||||||||||||||||||||||==++++/-\|/-\|/-Welcome
 to FreeBSD1 .Boot Multi User [Enter]2 
.Boot [S]ingle User3 .[Esc]ape to loader 
prompt4 .RebootOptions:5 
.[K]ernel: kernel (1 of 2)6 .Configure Boot 
[O]ptions...Autoboot in 9 seconds. [Space] to 
pauseAutoboot in 8 seconds. [Space] to 
pauseAutoboot in 7 seconds. [Space] to 
pauseAutoboot in 6 seconds. [Space] to 
pauseAutoboot in 5 seconds. [Space] to pause[2
 5;0HAutoboot in 4 seconds. [Space] to pauseAutoboot in 3 
seconds. [Space] to pauseAutoboot in 2 seconds. [Space] to 
pauseAutoboot in 1 seconds. [Space] to pause
   
\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-/boot/kernel/kernel
 text=0x10b05c0 
\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/data=0x131578+0x3d8240
 
-\|/-\|/-syms=[0x8+0x1515d8\|/-\|/-\|/+0x8+0x16d018-\|/-\|/-\|]
/-\|/-\|/-Booting...
\|/-\bhyve -c 2 -m 2G -AI -H -P -g 0 -s 0:0,hostbridge -s 1:0,lpc -s 
2:0,virtio-net,tap10