date:20150713

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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST 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=1PERFORMNUD
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=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP
ifmaxaddr 0 port 10 priority 128 path cost 200
member: tap11 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP
ifmaxaddr 0 port 9 priority 128 path cost 200
tap10: flags=8902BROADCAST,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500
options=8LINKSTATE
ether 00:bd:bf:03:5d:0a
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
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
/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-[H[J\|/-\|
 [7;46H ````[8;46Hs` `.---...--.```   
-/[9;46H+o   .--` /y:`  +.[10;46H yo`:.:o  
`+-[11;46H  y/   -/`   -o/[12;46H .-  
::/sy+:.[13;46H / `--  /[14;46H`: 
 :`[15;46H`:  :`[16;46H /  
/[17;46H .--.[18;46H  --  
-.[19;46H   `:`  `:`[20;46H .-- `--.[21;46H  
  .---../-\| [1;2H __      _ _  
[2;2H|  | |  _ \ / |  __ \ [3;2H| |___ _ __ ___  ___ | 
|_) | (___ | |  | |[4;2H|  ___| '__/ _ \/ _ \|  _  \___ \| |  | |[5;2H| |   
| | |  __/  __/| |_) |) | |__| |[6;2H| |   | | |||| 
 |  |  |[7;2H|_|   |_|  \___|\___||/|_/|_/ 
[10;2H|[11;2H|[12;2H|[13;2H|[14;2H|[15;2H|[16;2H|[17;2H|[18;2H|[19;2H|[20;2H|[21;2H|[10;44H|[11;44H|[12;44H|[13;44H|[14;44H|[15;44H|[16;44H|[17;44H|[18;44H|[19;44H|[20;44H|[21;44H|[9;3H=[22;3H=[9;2H+[22;2H+[9;44H+[22;44H+[25;0H/-\|/-\|/-[9;15HWelcome
 to FreeBSD[11;5H1 [11;6H.[11;8HBoot Multi User [Enter][12;5H2 
[12;6H.[12;8HBoot [S]ingle User[13;5H3 [13;6H.[13;8H[Esc]ape to loader 
prompt[14;5H4 [14;6H.[14;8HReboot[16;5HOptions:[17;5H5 
[17;6H.[17;8H[K]ernel: kernel (1 of 2)[18;5H6 [18;6H.[18;8HConfigure Boot 
[O]ptions...[25;0H[23;4HAutoboot in 9 seconds. [Space] to 
pause[25;0H[23;4HAutoboot in 8 seconds. [Space] to 
pause[25;0H[23;4HAutoboot in 7 seconds. [Space] to 
pause[25;0H[23;4HAutoboot in 6 seconds. [Space] to 
pause[25;0H[23;4HAutoboot in 5 seconds. [Space] to pause[2
 5;0H[23;4HAutoboot in 4 seconds. [Space] to pause[25;0H[23;4HAutoboot in 3 
seconds. [Space] to pause[25;0H[23;4HAutoboot in 2 seconds. [Space] to 
pause[25;0H[23;4HAutoboot in 1 seconds. [Space] to pause[25;0H[23;4H
   
[25;0H\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-/boot/kernel/kernel
 text=0x10b05c0 
\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/data=0x131578+0x3d8240

protection against module unloading ?

2015-07-13 Thread 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

Re: protection against module unloading ?

2015-07-13 Thread 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

FreeBSD_HEAD_i386 - Build #569 - Failure

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

Re: protection against module unloading ?

2015-07-13 Thread 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

2015-07-13 Thread 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 allanj...@freebsd.org 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: Lenovo BIOS boot fix

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: Call for FreeBSD 2015Q2 (April-June) Status Reports

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

Re: Lenovo BIOS boot fix


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: Lenovo BIOS boot fix


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: protection against module unloading ?

2015-07-13 Thread 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: Lenovo BIOS boot fix


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 ?

2015-07-13 Thread 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



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: Lenovo BIOS boot fix

2015-07-13 Thread 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 allanj...@freebsd.org 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


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


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


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

Instant panic while trying run ports-mgmt/poudriere

2015-07-13 Thread 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=value optimized out, ap=value 
optimized out)
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=value optimized out, 
newtd=value optimized out) at /hdd/src/sys/kern/kern_synch.c:406
#5  0x809d5991 in turnstile_wait (ts=value optimized out, owner=0x0, 
queue=value optimized out) at /hdd/src/sys/kern/subr_turnstile.c:751
#6  0x8098234d in __rw_wlock_hard (c=0x8185bd18, 
tid=18446735285002704080, 
file=value optimized out, line=value optimized out)
at /hdd/src/sys/kern/kern_rwlock.c:898
#7  0x80981f74 in _rw_wlock_cookie (c=value optimized out, 
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=value optimized out, 
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=value optimized out)
at 
/hdd/src/sys/modules/drm2/radeonkms/../../../dev/drm2/radeon/radeon_pm.c:777
#14 0x82093b63 in atombios_crtc_dpms (crtc=value optimized out, 
mode=value optimized out)
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 return to continue, or q return to quit---
at /hdd/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_crtc_helper.c:752
#18 0x822255c6 in vt_kms_postswitch (arg=value optimized out)
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=value optimized out)
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=value optimized out)
at /hdd/src/sys/kern/subr_kdb.c:651
#23 0x80dcd235 in trap_fatal (frame=0xfe046cfad950, eva=value 
optimized out)
at /hdd/src/sys/amd64/amd64/trap.c:848
#24 0x80dccf03 in trap (frame=value optimized out)
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=value optimized out) at /hdd/src/sys/kern/kern_event.c:1920
#27 0x80946a51 in exit1 (td=0xf801b84014d0, rv=value optimized 
out)
at /hdd/src/sys/kern/kern_exit.c:560
#28 0x80945f1e in sys_sys_exit (td=0x0, uap=value optimized out)
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

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

2015-07-13 Thread Kevin Oberman

On Mon, Jul 13, 2015 at 12:52 PM, Allan Jude allanj...@freebsd.org 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: protection against module unloading ?

2015-07-13 Thread 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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any

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

2015-07-13 Thread 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: Lenovo BIOS boot fix


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: Lenovo BIOS boot fix


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: Instant panic while trying run ports-mgmt/poudriere

2015-07-13 Thread 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=value optimized out) at /hdd/src/sys/kern/kern_event.c:1920
 #27 0x80946a51 in exit1 (td=0xf801b84014d0, rv=value optimized 
 out)
 at /hdd/src/sys/kern/kern_exit.c:560
 #28 0x80945f1e in sys_sys_exit (td=0x0, uap=value optimized out)
 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 mjguzik gmail.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: Instant panic while trying run ports-mgmt/poudriere

2015-07-13 Thread Pawel Pekala

Hi Mateusz,

On 2015-07-13 23:28 +0200, Mateusz Guzik mjgu...@gmail.com 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=value
 optimized out) at /hdd/src/sys/kern/kern_event.c:1920 #27
 0x80946a51 in exit1 (td=0xf801b84014d0, rv=value
 optimized out) at /hdd/src/sys/kern/kern_exit.c:560 #28
 0x80945f1e in sys_sys_exit (td=0x0, uap=value optimized
 out) at /hdd/src/sys/kern/kern_exit.c:178 #29 0x80dcdaa2 in
 outamd64_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=value optimized out) 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 
knlist_mtx_lock, 
  kl_unlock = 0x80941900 knlist_mtx_unlock, 
  kl_assert_locked = 0x80941920 knlist_mtx_assert_locked, 
  kl_assert_unlocked = 0x80941940 knlist_mtx_assert_unlocked, 
  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: Lenovo BIOS boot fix

2015-07-13 Thread 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


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: Why shoud we cause panic in scsi_da.c?

2015-07-13 Thread Kohji Okuno

Hi,

From: Alexander Motin m...@freebsd.org
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

FreeBSD_HEAD-tests - Build #1179 - Still Failing