From bugzilla-noreply at freebsd.org Wed Oct 1 03:40:31 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 03:40:31 +0000
Subject: [Bug 193873] [PATCH] Unify dumpsys() under generic kern_dump.c.
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193873
Conrad Meyer changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #147599|0 |1
is obsolete| |
--- Comment #5 from Conrad Meyer ---
Created attachment 147868
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147868&action=edit
v2 of the patch w/ feedback incorporated
Updated to incorporate feedback. Buildtested against the same architectures.
Diff is against r272336.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 03:41:21 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 03:41:21 +0000
Subject: [Bug 193873] [PATCH] Unify dumpsys() under generic kern_dump.c.
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193873
--- Comment #6 from Conrad Meyer ---
Created attachment 147869
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147869&action=edit
(Just the changes between v1 and v2.)
This isn't the whole patch, just the changes made after v1 per feedback.
--
You are receiving this mail because:
You are the assignee for the bug.
From sales at furnways.co.za Wed Oct 1 08:00:37 2014
From: sales at furnways.co.za (Johan Watson)
Date: Wed, 01 Oct 2014 08:00:34 GMT
Subject: October Specials from Furnways
Message-ID:
Hospitality Furniture
[Web version](http://furnways-uoonf0.soundestdirect.com/view/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213995/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213994/542ba73858026ef77f21399c/54264699fe7da963021cb804)
Furnways - Corporate Turnkey Solutions
[**Furnways is a leading office furniture supplier**](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213993/542ba73858026ef77f21399c/54264699fe7da963021cb804) in South Africa. WE offer the widest range of products, from executive desks [to school furniture](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213992/542ba73858026ef77f21399c/54264699fe7da963021cb804). We are the biggest online furniture store in Africa, delivering high quality products at affordable prices, understanding our customers' need to acquire top of the line furniture for their business with reasonable investments. If you are looking for stylish furniture for your office, hotel or restaurant, then this is the perfect place for you, as we specialize in creating innovative and chic designs for your furniture.
[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213991/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ Wimpey Side Chair ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213991/542ba73858026ef77f21399c/54264699fe7da963021cb804)
Available in over 20 Colours
5 Year Warranty.
R240.00 ???
[ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213991/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213990/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ Wimpey Arm Chair ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213990/542ba73858026ef77f21399c/54264699fe7da963021cb804)
Available in over 20 Colours
5 Year Warranty.
R260.00 ???
[ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213990/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398f/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ Wimpey Ultra Chair ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398f/542ba73858026ef77f21399c/54264699fe7da963021cb804)
Available in over 20 Colours
5 Year Warranty.
R280.00 ???
[ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398f/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398e/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ Chloe Chair ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398e/542ba73858026ef77f21399c/54264699fe7da963021cb804)
Available in over 20 Colours
5 Year Warranty.
R480.00 ???
[ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398e/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398d/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ Alpine Chairs ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398d/542ba73858026ef77f21399c/54264699fe7da963021cb804)
Available in over 20 Colours
5 Year Warranty.
R132.00 ???
[ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398d/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398c/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ Avatar Caf? Chair ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398c/542ba73858026ef77f21399c/54264699fe7da963021cb804)
Available in over 20 Colours
5 Year Warranty.
R260.00 ???
[ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398c/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398b/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ Double Pedestal Desk ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398b/542ba73858026ef77f21399c/54264699fe7da963021cb804)
32mm Melamine Top
1800mm*900mm
Single Pedestal: R2865
Available in a variety of colours
5 Year Warranty
R3540.00 ???
[ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398b/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398a/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ Rectangular Tables ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398a/542ba73858026ef77f21399c/54264699fe7da963021cb804)
16mm Melamine Tops
Available in Oak, Mahogany or Supawood
1800 * 900 From R1093
1400 * 700 From R663
1200 * 600 From R504?
5 Year Warranty
R504.00 ???
[ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398a/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213989/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ Perforated Metal Set ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213989/542ba73858026ef77f21399c/54264699fe7da963021cb804)
Contains:
2 tier letter tray
Paper bin
Pencil cup
Paper cube
5 Year Warranty
**Available in Siver for R1428**
Black/White: R1165.00 ???
[ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213989/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213988/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ Big & Tall Heavy Duty Chair ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213988/542ba73858026ef77f21399c/54264699fe7da963021cb804)
Supports Up to 150kg
Leather Seat
Chrome base
Chrome arms with polyurethane pads
5 Year Warranty
R3496.00 ???
[ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213988/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213987/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ Spine Ergonomic High Back Chair ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213987/542ba73858026ef77f21399c/54264699fe7da963021cb804)
2 Part shell
Permanent contact mechanism
Adjustable arms
Available in leather
Loads of extras and materials available
5 Year Warranty
R1750.00 ???
[ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213987/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213986/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ Lucea 1500 Ergonomic Typist Chair ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213986/542ba73858026ef77f21399c/54264699fe7da963021cb804)
Ergonomic shaped back with rake and height adjustment
Standard with black nylon base
Available in leather
Loads of extras and materials available
5 Year Warranty
R811.00 ???
[ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213986/542ba73858026ef77f21399c/54264699fe7da963021cb804)
[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213985/542ba73858026ef77f21399c/54264699fe7da963021cb804)
?[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213984/542ba73858026ef77f21399c/54264699fe7da963021cb804)? ?[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213983/542ba73858026ef77f21399c/54264699fe7da963021cb804)? ?[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213982/542ba73858026ef77f21399c/54264699fe7da963021cb804)?
[sales at furnways.co.za](mailto:sales at furnways.co.za)
Furnways
Lonehill Boulevard , 22 , Sandton , 2062 , South Africa
All prices are in ZAR and excludes VAT and delivery
? 2014 Furnways
[Unsubscribe](http://furnways-uoonf0.soundestdirect.com/unsubscribe/542ba73858026ef77f21399c/54264699fe7da963021cb804)
Proudly delivered by
[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213981/542ba73858026ef77f21399c/54264699fe7da963021cb804)
From bugzilla-noreply at freebsd.org Wed Oct 1 08:48:05 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 08:48:05 +0000
Subject: [Bug 194062] New: QUIRK: Innostor USB stick (add NO_RC16)
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194062
Bug ID: 194062
Summary: QUIRK: Innostor USB stick (add NO_RC16)
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: tcberner at gmail.com
USB stick: Hama Vilitas 128G [1] identified as Innostor
# camcontrol inquiry da0
pass5: Removable Direct Access SCSI-6 device
pass5: Serial Number 000000000000000051
pass5: 400.000MB/s transfers
# dmesg | grep ^da0
da0 at umass-sim0 bus 0 scbus13 target 0 lun 0
da0: Removable Direct Access SCSI-6 device
da0: Serial Number 000000000000000051
da0: 400.000MB/s transfers
da0: 121896MB (249644974 512 byte sectors: 255H 63S/T 15539C)
da0: quirks=0x12
# messages on gpt/newfs/...
(da0:umass-sim0:0:0:0): Error 22, Unretryable error
(da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 0e e9 47 49 00 00 04 00
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status: Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:21,0 (Logical block
address out of range)
Fix: add DA_Q_NO_RC16
# dmesg | grep ^da0
da0 at umass-sim0 bus 0 scbus13 target 0 lun 0
da0: Removable Direct Access SCSI-6 device
da0: Serial Number 000000000000000051
da0: 400.000MB/s transfers
da0: 121896MB (249644974 512 byte sectors: 255H 63S/T 15539C)
da0: quirks=0x12
# usbconfig
ugen1.2: at usbus1, cfg=0 md=HOST spd=SUPER (5.0Gbps)
pwr=ON (76mA)
[1]
https://en.hama.com/00114793/hama-flashpen-vilitas-usb-30-8-gb-70-mb-s-weiss-silber
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 08:49:08 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 08:49:08 +0000
Subject: [Bug 194062] QUIRK: Innostor USB stick (add NO_RC16)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194062
--- Comment #1 from tcberner at gmail.com ---
Created attachment 147875
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147875&action=edit
patchto add quirk
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 09:31:58 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 09:31:58 +0000
Subject: [Bug 187457] ifconfig(8): ifconfig IP range assignment too restrictive
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187457
Hiroki Sato changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hrs at FreeBSD.org
Assignee|freebsd-bugs at FreeBSD.org |hrs at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 09:44:24 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 09:44:24 +0000
Subject: [Bug 194063] New: installer fails to boot / kernel panic on HP
Probook 430 G1
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
Bug ID: 194063
Summary: installer fails to boot / kernel panic on HP Probook
430 G1
Product: Base System
Version: 10.1-BETA3
Hardware: amd64
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: op at freebsd.org
Created attachment 147876
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147876&action=edit
picture of the panic
The system is a HP Probook 430 G1 with Intel Core i5-4200U CPU and with
integrated GPU.
The kernel paniced with 10.1-BETA3 and current 11-SNAPSHOT too. See the
attached picture.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 09:45:36 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 09:45:36 +0000
Subject: [Bug 194063] installer fails to boot / kernel panic on HP Probook
430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
Oliver Pinter changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |i915, uefi, vt
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 09:56:39 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 09:56:38 +0000
Subject: [Bug 194063] installer fails to boot / kernel panic on HP Probook
430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #1 from Oliver Pinter ---
Created attachment 147878
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147878&action=edit
linux's dmesg
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 09:57:07 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 09:57:07 +0000
Subject: [Bug 194063] installer fails to boot / kernel panic on HP Probook
430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #2 from Oliver Pinter ---
Created attachment 147879
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147879&action=edit
linux's lspci
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 10:27:29 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 10:27:29 +0000
Subject: [Bug 193927] saslauthd Broken By Recent MFC
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193927
--- Comment #4 from commit-hook at freebsd.org ---
A commit references this bug:
Author: des
Date: Wed Oct 1 10:26:44 UTC 2014
New revision: 272351
URL: https://svnweb.freebsd.org/changeset/base/272351
Log:
MFH (r272280, r272281, r272348): allow use with null user and rhost
PR: 83099 193927
Approved by: re (kib)
Changes:
_U stable/10/
stable/10/lib/libpam/modules/pam_login_access/pam_login_access.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 10:29:43 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 10:29:43 +0000
Subject: [Bug 193927] saslauthd Broken By Recent MFC
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193927
--- Comment #5 from commit-hook at freebsd.org ---
A commit references this bug:
Author: des
Date: Wed Oct 1 10:29:15 UTC 2014
New revision: 272352
URL: https://svnweb.freebsd.org/changeset/base/272352
Log:
MFH (r272280, r272281, r272348): allow use with null user and rhost
PR: 83099 193927
Changes:
_U stable/9/lib/libpam/
stable/9/lib/libpam/modules/pam_login_access/pam_login_access.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 10:36:46 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 10:36:46 +0000
Subject: [Bug 193927] saslauthd Broken By Recent MFC
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193927
--- Comment #6 from commit-hook at freebsd.org ---
A commit references this bug:
Author: des
Date: Wed Oct 1 10:35:52 UTC 2014
New revision: 272353
URL: https://svnweb.freebsd.org/changeset/base/272353
Log:
MFH (r272280, r272281, r272348): allow use with null user and rhost
PR: 83099 193927
Changes:
_U stable/8/lib/libpam/
stable/8/lib/libpam/modules/pam_login_access/pam_login_access.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 10:40:33 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 10:40:33 +0000
Subject: [Bug 194063] installer fails to boot / kernel panic on HP Probook
430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #3 from Oliver Pinter ---
addr2line "RIP":
sys/vm/vm_map.c:502
map->system_map does not exists
void
_vm_map_lock_read(vm_map_t map, const char *file, int line)
{
if (map->system_map)
mtx_lock_flags_(&map->system_mtx, 0, file, line);
else
sx_slock_(&map->lock, file, line);
}
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 14:14:25 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 14:14:25 +0000
Subject: [Bug 194071] New: zfsloader broken on sparc64 since r268649
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194071
Bug ID: 194071
Summary: zfsloader broken on sparc64 since r268649
Product: Base System
Version: 10.1-BETA3
Hardware: sparc64
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: lidl at pix.net
It took a while to track this down, but the zfsloader on sparc64 machines
has been broken since r268649. That's when the lz4 compression was added
to ZFS.
This affects 10.1-BETA2 and 10.1-BETA3, where I did my diagnostic work.
I'm sure that it also affects head.
In a nutshell, the lz4 code is missing a couple of portability fixes that
allow for unaligned access to some of the data structures in a compressed
lz4 data stream.
When attempting to boot off a zfsloader with this problem, one will see errors
similar to this:
>> FreeBSD/sparc64 ZFS boot block
Boot path: /pci at 1f,0/pci at 1/scsi at 8/disk at 0,0:a
Consoles: Open Firmware console ^M
Memory Address not Aligned
After bisecting the stable/10 tree over the last couple of nights, I figured
out the exact revision where it failed. (r268649)
Looking at the lz4 project's sources, it appears there was a portability fix
introduced in this patchset: https://code.google.com/p/lz4/source/detail?r=95
In particular, the patch that is needed for sparc64 is addition of a
__attribute__((packed)) to some of the data structures for the lz4
implementation.
I've reduced this to use the FreeBSD __packed definition that is in
.
With the attached patch, recompiling stable/10 on a sparc64, I get a useable
zfsloader, so I can once again boot a zfs-only sparc64 machine.
Please include this patch (or equivalent) in HEAD and in the 10.1 release.
This will avoid a major regression in ZFS booting between 10.0 and 10.1
releases.
Thanks.
-Kurt
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 14:15:16 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 14:15:16 +0000
Subject: [Bug 194071] zfsloader broken on sparc64 since r268649
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194071
--- Comment #1 from lidl at pix.net ---
Created attachment 147885
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147885&action=edit
patch to sys/cddl/boot/zfs/lz4.c that fixes the problem
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 14:20:24 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 14:20:24 +0000
Subject: [Bug 194071] zfsloader broken on sparc64 since r268649
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194071
Glen Barber changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |delphij at FreeBSD.org,
| |re at FreeBSD.org
--- Comment #2 from Glen Barber ---
Xin, could you take a look at this?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 15:14:01 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 15:14:01 +0000
Subject: [Bug 194063] installer fails to boot / kernel panic on HP Probook
430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #4 from Oliver Pinter ---
After BIOS update to latest BIOS, the problem _not_ changed.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 15:18:22 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 15:18:22 +0000
Subject: [Bug 194063] installer fails to boot / kernel panic on HP Probook
430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #5 from Oliver Pinter ---
This is with UEFI Hybrid mode (with CSM).
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 15:23:02 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 15:23:02 +0000
Subject: [Bug 194063] installer fails to boot / kernel panic on HP Probook
430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #6 from Oliver Pinter ---
Created attachment 147887
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147887&action=edit
load prompt in UEFI native mode (without CSM)
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 15:23:17 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 15:23:17 +0000
Subject: [Bug 194063] installer fails to boot / kernel panic on HP Probook
430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #7 from Ed Maste ---
Would you kindly addr2line the previous few addresses in the backtrace?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 15:24:03 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 15:24:03 +0000
Subject: [Bug 194063] installer fails to boot / kernel panic on HP Probook
430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #8 from Oliver Pinter ---
Created attachment 147888
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147888&action=edit
load prompt in UEFI native mode (without CSM)
I got this screen, when booting with UEFI native mode (without CSM). Possibly
this is an kernel panic.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 15:26:54 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 15:26:54 +0000
Subject: [Bug 194063] installer fails to boot / kernel panic on HP Probook
430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #9 from Ed Maste ---
This looks like it might just be incorrect framebuffer information.
You may be able to try blindly logging in, or blindly rebooting if you're in
ddb.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 17:28:23 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 17:28:23 +0000
Subject: [Bug 194063] installer fails to boot / kernel panic on HP Probook
430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #10 from Oliver Pinter ---
Seems like the system is in ddb or something similar, because when I pressed
the power button, the system immediately go to S5 (shuting down).
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 17:31:54 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 17:31:54 +0000
Subject: [Bug 194063] installer fails to boot / kernel panic on HP Probook
430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #11 from Ed Maste ---
Does the screen change after kernel starts, or does it show the same static
corruption the whole time? (I.e., it's useful to know if it's booting up and
then panics, or happens very early on.)
You can confirm it's in ddb by blindly typing 'reset' and hitting enter -- if
it does reboot, then it was in ddb.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 18:02:02 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 18:02:03 +0000
Subject: [Bug 194071] zfsloader broken on sparc64 since r268649
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194071
--- Comment #3 from Xin LI ---
Hi,
Do we need the same treatment on the ZFS copy of lz4.c?
(sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lz4.c)?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 18:17:00 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 18:17:00 +0000
Subject: [Bug 194077] New: Improper enumerate ada (da) device ID in 10.1-R
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194077
Bug ID: 194077
Summary: Improper enumerate ada (da) device ID in 10.1-R
Product: Base System
Version: 10.1-BETA2
Hardware: amd64
OS: Any
Status: Needs Triage
Severity: Affects Many People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: jguojun at sbcglobal.net
This is regression issue on how ada/da device ID should be enumerated.
FreeBSD has kept using a fixed device ID for disk drives (ad#) for a historical
reason because dynamic disk device enumeration require amount work to make it
right; basically using drive serial number to maintain device ID initialized at
installation time for proper mounting.
10.1-BATE2 (I only noticed now and may already be in 10-R) has changed SATA
device from fixed ad# to dynamic ada#, which works fine for single or ordered
disk drive installation (home use), but breaks the random disk drive
installation that required by servers.
In order to keep a system drive bootable, this drive must keep its device ID
originally assigned at installation time. No matter what the ID was, and no
matter how many disk drives are installed in any SATA or USB port with random
order, already installed disk drive(s) MUST keep its / their assigned IDs when
those drives were partitioned and mounted.
During adding disk drive to 10.1-BETA2 system, it enumerates drive(s)
dynamically to assign ID to ada node (similar issue to da node).
Kernel clearly knows which drive is ad1, 2, 3, ..., but it does not assigned
proper ID to existing drive(s) for ada and da nodes.
That is, ad note IDs are still correct, but ada and da node IDs are dynamically
changing when a new drive is inserted at lower SATA port(s). This causes boot
fail and/or non boot drive unable to mount.
The dynamic enumeration is likely used for moving a boot drive from on system
to another or from one bus to another without manually modifying fstab entries.
This is desired feature, but need to be implemented correctly.
That is, this mechanism wants to ensure no matter where this drive is plugged
in, already mounted drive(s) should be always enumerated to the ID installation
assigned to.
How to ensure this? For boot drive, this is relatively easy -- the boot drive
is always this first one in general,
so this drive should always enumerated as ada0 or da0.
If ID assigned to boot drive is not 0 at installation, then generic enumeration
apply.
Generic enumeration is drive serial number (S#) based enumeration mechanism,
which has been used for at least two decades.
For example, if two drives installed and their S# are AAAA (mounted for
/workingSpace) and XXXXX (boot drive),
regardless what SATA port they resides at -- drive AAAA at ad9 and XXXXX at ad5
for example,
We knew installation will likely name drive XXXXX as ada0 and AAAA as ada1.
In fixed fashion, drive XXXXX is ad5 and AAAA is ad9, when a new drive is
inserted as ad0,
we knew drive XXXXX will be still ad5 and boot should not fail.
But in current 10.1-BETA2, the new drive is likely will be ada0, drive XXXXX
will be ada1, and AAAA will be ada2, then boot will fail.
In case if new drive is inserted as ad8, drive XXXXX will remain as ada0 but
AAAA will be ada2.
Even though boot will succeed in this case, but mounting drive AAAA will fail.
The S#-based enumeration will record the S# (unique to every drive) for
corresponding device ID in a boot configuration file for dynamic enumeration,
which is used in boot time to determine what device ID should be assigned to
each drive.
After existing drive ID has been enumerated, any new drive(s) will be given a
unused ID sequentially.
This ensures that existing drive(s) will always get device ID originally
assigned to, so the disk mounting operation will never fail no matter where a
disk drive (has FreeBSD already installed) is plugged in.
Without ensuring this enumeration correctness, IT will have big headache in
maintaining a large amount of disk sets for servers.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 18:48:43 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 18:48:43 +0000
Subject: [Bug 194078] New: 10.1-BETA2 kernel memory leak in routing table
upon PF reload
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194078
Bug ID: 194078
Summary: 10.1-BETA2 kernel memory leak in routing table upon PF
reload
Product: Base System
Version: 10.0-STABLE
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Many People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: telbizov at gmail.com
Corresponding discussion over email is available at:
http://lists.freebsd.org/pipermail/freebsd-stable/2014-September/080296.html
We discovered that our newly upgraded 10.1-BETA2 (r271983) has started leaking
kernel memory and the *wired* portion has been steadily growing over the last
few days. The *routetbl* pool is getting bloated with time.
# while true; do date; vmstat -m | grep routetbl; sleep 60; done
Type InUse MemUse HighUse Requests Size(s)
Mon Sep 29 18:27:55 UTC 2014
routetbl 5988792 2888491K - 14285826 32,64,128,256,512,2048
Mon Sep 29 18:28:55 UTC 2014
routetbl 5990120 2889131K - 14288972 32,64,128,256,512,2048
Mon Sep 29 18:29:55 UTC 2014
routetbl 5991448 2889771K - 14292352 32,64,128,256,512,2048
Mon Sep 29 18:30:55 UTC 2014
routetbl 5992776 2890411K - 14295464 32,64,128,256,512,2048
Mon Sep 29 18:31:55 UTC 2014
routetbl 5994104 2891051K - 14298576 32,64,128,256,512,2048
Mon Sep 29 18:32:55 UTC 2014
routetbl 5995432 2891691K - 14301904 32,64,128,256,512,2048
Mon Sep 29 18:33:55 UTC 2014
routetbl 5996096 2892011K - 14303624 32,64,128,256,512,2048
Mon Sep 29 18:34:55 UTC 2014
routetbl 5997422 2892650K - 14306980 32,64,128,256,512,2048
Mon Sep 29 18:35:55 UTC 2014
routetbl 5998750 2893290K - 14310092 32,64,128,256,512,2048
Mon Sep 29 18:36:55 UTC 2014
routetbl 6000078 2893930K - 14313204 32,64,128,256,512,2048
Mon Sep 29 18:37:55 UTC 2014
routetbl 6001406 2894570K - 14316532 32,64,128,256,512,2048
Mon Sep 29 18:38:55 UTC 2014
routetbl 6002734 2895210K - 14319644 32,64,128,256,512,2048
Mon Sep 29 18:39:55 UTC 2014
routetbl 6004062 2895850K - 14323024 32,64,128,256,512,2048
Mon Sep 29 18:40:56 UTC 2014
routetbl 6004726 2896170K - 14324745 32,64,128,256,512,2048
Mon Sep 29 18:41:56 UTC 2014
routetbl 6006054 2896810K - 14327857 32,64,128,256,512,2048
Mon Sep 29 18:42:56 UTC 2014
routetbl 6007382 2897450K - 14331185 32,64,128,256,512,2048
Mon Sep 29 18:43:56 UTC 2014
routetbl 6008710 2898090K - 14334297 32,64,128,256,512,2048
After some investigation we discovered that the memory leak is triggered by a
reload of the PF rule set. A simple test case with 1 rule and 1 table reveals
the bug and makes it easy to reproduce. Every time 'pfctl -f
/etc/firewall/pf.conf' (or your corresponding pf.conf file) is run the output
above shows an increase in memory. In between reloads the memory usage stays
stable.
The following DTrace script could be used to watch the same behavior:
#!/usr/sbin/dtrace -s
#pragma D option quiet
BEGIN {
printf("%-20s %20s %20s %20s\n", "FUNCTION", "ALLOCATED", "FREE", "TOTAL");
}
dtmalloc::$1:malloc {
@malloc[probefunc] = sum(args[3]);
@total[probefunc] = sum(args[3]);
}
dtmalloc::$1:free {
@free[probefunc] = sum(args[3]);
@total[probefunc] = sum(-args[3]);
}
tick-1s {
printa("%-20.20s %20 at d %20 at d %20 at d\n", @malloc, @free, @total);
}
Output:
# ./script2.d routetbl
FUNCTION ALLOCATED FREE TOTAL
routetbl 512 512 0
...
routetbl 46592 46592 0
routetbl 808960 444416 364544
...
routetbl 861184 496640 364544
routetbl 1623552 894464 729088
...
routetbl 1641984 912896 729088
Further diagnostics:
#!/usr/sbin/dtrace -s
fbt:kernel:rt_msg2:entry {
@rt_msg2[stack()] = count();
}
fbt:kernel:rn_addroute:entry {
@rn_addroute[stack()] = count();
}
Output:
kernel`sysctl_rtsock+0x274
kernel`sysctl_root+0x214
kernel`userland_sysctl+0x1d8
kernel`sys___sysctl+0x74
kernel`amd64_syscall+0x334
kernel`0xffffffff80900e0b
2340
kernel`sysctl_rtsock+0x64c
kernel`sysctl_root+0x214
kernel`userland_sysctl+0x1d8
kernel`sys___sysctl+0x74
kernel`amd64_syscall+0x334
kernel`0xffffffff80900e0b
4680
This problem was reported to Gleb Smirnoff and he managed to reproduce and
confirm the problem.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 18:58:52 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 18:58:52 +0000
Subject: [Bug 193803] zvol promote failing
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #4 from kash at tripleback.net ---
I've been hitting this bug repeatedly on production networks, it would be best
to get some feedback or it starts to look like FreeBSD ZFS is a dead project.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 19:15:39 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 19:15:39 +0000
Subject: [Bug 194078] 10.1-BETA2 kernel memory leak in routing table upon PF
reload
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194078
Gleb Smirnoff changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |glebius at FreeBSD.org
Assignee|freebsd-bugs at FreeBSD.org |glebius at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 19:21:28 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 19:21:28 +0000
Subject: [Bug 194071] zfsloader broken on sparc64 since r268649
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194071
--- Comment #4 from lidl at pix.net ---
(In reply to Xin LI from comment #3)
> Do we need the same treatment on the ZFS copy of lz4.c?
> (sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lz4.c)?
That code has wrapped with:
#ifndef LZ4_FORCE_UNALIGNED_ACCESS
#pragma pack(1)
#endif
#ifndef LZ4_FORCE_UNALIGNED_ACCESS
#pragma pack()
#endif
So it has already been treated in the same manner.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 1 21:33:39 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Oct 2014 21:33:39 +0000
Subject: [Bug 193803] zvol promote failing
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #5 from kash at tripleback.net ---
This bug along with the "zvol entries not showing up in /dev/ until after
reboot" one, and the lack of response shows the FreeBSD developers have
different priorities than the users, BHyVE gets who knows how much unnecessary
attention while critical ZFS bugs go unfixed? The proposed patch for #178999 in
the old tracker works but doesn't resolve all the issues, even admitted by the
author smh at freebsd, but yet, no additional work has gone in that ticket. It's
been "merged into head" but the new servers I've built still have the issue.
ZFS on Linux does not have the issues that FreeBSD ZFS has, so unfortunately my
company and our product (plus its thousands of users) will be converting to a
more reliable platform until some progress can be made here.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 00:13:50 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 00:13:50 +0000
Subject: [Bug 194071] zfsloader broken on sparc64 since r268649
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194071
Xin LI changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Needs Triage |Needs MFC
--- Comment #5 from Xin LI ---
(In reply to lidl from comment #4)
> (In reply to Xin LI from comment #3)
> > Do we need the same treatment on the ZFS copy of lz4.c?
> > (sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lz4.c)?
>
> That code has wrapped with:
>
> #ifndef LZ4_FORCE_UNALIGNED_ACCESS
> #pragma pack(1)
> #endif
>
>
>
> #ifndef LZ4_FORCE_UNALIGNED_ACCESS
> #pragma pack()
> #endif
>
> So it has already been treated in the same manner.
Can you try r272389 and let me know if it fixed your problem? If everything
works fine I'd like to merge this as soon as possible.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 00:14:00 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 00:14:00 +0000
Subject: [Bug 194071] zfsloader broken on sparc64 since r268649
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194071
--- Comment #6 from commit-hook at freebsd.org ---
A commit references this bug:
Author: delphij
Date: Thu Oct 2 00:13:09 UTC 2014
New revision: 272389
URL: https://svnweb.freebsd.org/changeset/base/272389
Log:
Diff reduction with kernel code: instruct the compiler that the data of
these types may be unaligned to their "normal" alignment and exercise
caution when accessing them.
PR: 194071
MFC after: 3 days
Changes:
head/sys/cddl/boot/zfs/lz4.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 05:42:28 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 05:42:28 +0000
Subject: [Bug 194063] installer fails to boot / kernel panic on HP Probook
430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #12 from Oliver Pinter ---
To this point the screen changed. The blindly writing trick don't working,
because to early to initialize the keyboard.
If I try boot -v in hybrid mode, I got a different trap: Privileged
instructionn fault in cam_compat.c +60 line of 10.1-BETA3. But at this point
it's again to early to get a working keyboard.
After that I tried to boot w/ and w/o EFI signing keys to boot, but none of
them worked.
Is there any EFI facility to create EFI logs, which I can read via EFI BIOS
menu?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 05:54:03 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 05:54:03 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
kash at tripleback.net changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|zvol promote failing |zvol rename failing due to
| |out of order locking
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 06:20:52 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 06:20:52 +0000
Subject: [Bug 193558] rm -rf should not fail if multiple processes deleting
same directory
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193558
Garrett Cooper changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Needs MFC |Issue Resolved
CC| |ngie at FreeBSD.org
Resolution|--- |DUPLICATE
--- Comment #2 from Garrett Cooper ---
*** This bug has been marked as a duplicate of bug 192490 ***
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 06:32:33 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 06:32:33 +0000
Subject: [Bug 172894] Out-of-tree kernel module compilation with GNU xargs in
$PATH
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=172894
Baptiste Daroussin changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bapt at FreeBSD.org |freebsd-bugs at FreeBSD.org
--- Comment #2 from Baptiste Daroussin ---
back to the pool
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 06:35:06 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 06:35:06 +0000
Subject: [Bug 187653] pw(8): 'pw user mod' is creating users instead of
changing them.
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187653
Baptiste Daroussin changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bapt at FreeBSD.org |freebsd-bugs at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 06:52:28 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 06:52:28 +0000
Subject: [Bug 194084] New: [PATCH] Add IPv6 support for quota(1)
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194084
Bug ID: 194084
Summary: [PATCH] Add IPv6 support for quota(1)
Product: Base System
Version: 10.1-BETA3
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: John.Marshall at riverwillow.com.au
Created attachment 147899
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147899&action=edit
IPv6 support for quota(1)
Bug 42004 included relevant patches for usr.bin/quota/quota.c and for
usr.sbin/rpc.statd/procs.c. The rpc.statd patch was applied to CURRENT 7.5
years ago but the PR was closed without ever applying the quota.c patch. This
means that quota(1) over IPv6 has still never worked.
I applied the quota.c patch from Bug 42004 to 10.1-BETA3 and, apart from an 8
line offset, it applied cleanly. I also patched inetd.conf to add a udp6
listener for rpc.quotad on the NFS server and now quota(1) works for me on
10.1-BETA3 (client and server) over IPv6.
Again, this is not MY patch: it was submitted by Jean-Luc Richier with PR 42004
back in 2002. All I did was find it, apply it and test it.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 07:06:25 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 07:06:25 +0000
Subject: [Bug 193669] [ipfw][dummynet] "copy_obj (WARN)" kernel warning for
ipfw pipe show
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193669
--- Comment #1 from Andriy Mayevskyy ---
Could anyone check this issue?
'Needs Triage' is not a good state for kernel bugs.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 07:15:17 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 07:15:17 +0000
Subject: [Bug 11024] [patch] getpwnam(3) uses incorrect #define to limit
username length
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=11024
Baptiste Daroussin changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|In Discussion |Issue Resolved
Resolution|--- |Overcome By Events
--- Comment #10 from Baptiste Daroussin ---
UT_NAMESIZE is not used anymore
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 07:30:02 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 07:30:02 +0000
Subject: [Bug 40572] vipw(8) prints silly message if $EDITOR fails
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=40572
--- Comment #1 from Baptiste Daroussin ---
It now says
vipw: pw_edit(): No such file or directory
which is not better
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 07:36:39 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 07:36:39 +0000
Subject: [Bug 194084] [PATCH] Add IPv6 support for quota(1)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194084
Hiroki Sato changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Needs Triage |In Discussion
CC| |hrs at FreeBSD.org
Assignee|freebsd-bugs at FreeBSD.org |hrs at FreeBSD.org
--- Comment #1 from Hiroki Sato ---
I will take a look into this.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 08:12:31 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 08:12:31 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
Steven Hartland changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |smh at FreeBSD.org
--- Comment #6 from Steven Hartland ---
Created attachment 147905
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147905&action=edit
Possible fix for zvol hang issues
Try this patch and lmk if it fixes the issues for you
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 14:25:31 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 14:25:31 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #7 from kash at tripleback.net ---
Comment on attachment 147905
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147905
Possible fix for zvol hang issues
This does not compile against 10-RELEASE-pX
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 14:50:40 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 14:50:40 +0000
Subject: [Bug 194071] zfsloader broken on sparc64 since r268649
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194071
--- Comment #7 from lidl at pix.net ---
I had my sparc grind through a partial buildworld of r272389.
I was able to get the zfsloader built, and it worked fine
to load the 10.1-BETA3 system that I had installed earlier.
The patch resolves the issue with zfsloader.
I really hope this can be included in the 10.1-RELEASE
image.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 14:58:02 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 14:58:02 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #8 from Steven Hartland ---
(In reply to kash from comment #7)
> Comment on attachment 147905 [details]
> Possible fix for zvol hang issues
>
> This does not compile against 10-RELEASE-pX
Its against stable/10 not release
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 15:00:30 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 15:00:30 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #9 from kash at tripleback.net ---
Can I get a patch for my RELEASE, because that's the version I filed this bug
against, I don't run STABLE and can't jump to a test version just for one bug..
thanks
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 15:27:54 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 15:27:54 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #10 from Steven Hartland ---
Created attachment 147915
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147915&action=edit
Possible fix for zvol hang issues (against 10.0-RELEASE)
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 15:37:14 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 15:37:14 +0000
Subject: [Bug 111077] date(1): /bin/date -j -f "%b %Y" "Feb 2007" +%m returns
03 for Feb!!
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=111077
Pedro F. Giffuni changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|In Discussion |Issue Resolved
CC| |pfg at FreeBSD.org
Resolution|--- |FIXED
--- Comment #2 from Pedro F. Giffuni ---
(In reply to paradox from comment #0)
> Date input of "mmm yyyy" for Feb always returns 03.
>
> Flaw exists across all know bsd versions, intel, amd, 64bit, not, etc.
>
> Fix:
>
> Got me :>
> How-To-Repeat: > # /bin/date -j -f "%b %Y" "Jan 2007" +%m
> > 01
> > # /bin/date -j -f "%b %Y" "Feb 2007" +%m
> > 03
> > # /bin/date -j -f "%m %Y" "02 2007" +%m
> > 03
> > # /bin/date -j -f "%m %Y" "02 2007" +%m-%b
> > 03-Mar
I cannot reproduce this on 11-current:
$ /bin/date -j -f "%b %Y" "Jan 2007" +%m
01
$ /bin/date -j -f "%b %Y" "Feb 2007" +%m
02
$ /bin/date -j -f "%m %Y" "02 2007" +%m
02
$ /bin/date -j -f "%m %Y" "02 2007" +%m-%b
02-Feb
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 15:41:19 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 15:41:19 +0000
Subject: [Bug 33834] strptime(3) is misleading
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=33834
Pedro F. Giffuni changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|In Discussion |Issue Resolved
Resolution|--- |FIXED
--- Comment #9 from Pedro F. Giffuni ---
%t and %n have been taken from illumos %W and %U are now implemented.
While some cleanups to the documentation would be good and there are other
known bugs, the basic issues in this PR have been resolved in 11-current and
will be MFC'd at a later time.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 16:29:34 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 16:29:34 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #11 from kash at tripleback.net ---
--- dnode_sync.o ---
ctfconvert -L VERSION -g dnode_sync.o
--- dnode.o ---
ctfconvert -L VERSION -g dnode.o
--- dsl_dataset.o ---
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:3016:12:
error: use of undeclared identifier 'newname'
kmem_free(newname, MAXPATHLEN);
^
/usr/src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/kmem.h:82:46: note:
expanded from macro 'kmem_free'
#define kmem_free(buf, size) zfs_kmem_free((buf), (size))
^
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:3017:12:
error: use of undeclared identifier 'oldname'
kmem_free(oldname, MAXPATHLEN);
^
/usr/src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/kmem.h:82:46: note:
expanded from macro 'kmem_free'
#define kmem_free(buf, size) zfs_kmem_free((buf), (size))
^
2 errors generated.
*** [dsl_dataset.o] Error code 1
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 16:50:46 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 16:50:46 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #12 from Steven Hartland ---
(In reply to kash from comment #11)
> --- dnode_sync.o ---
> ctfconvert -L VERSION -g dnode_sync.o
> --- dnode.o ---
> ctfconvert -L VERSION -g dnode.o
> --- dsl_dataset.o ---
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/
> dsl_dataset.c:3016:12: error: use of undeclared identifier 'newname'
> kmem_free(newname, MAXPATHLEN);
...
Line 3016 in 10.0-RELEASE is in dsl_dataset_space_wouldfree which has no
changes in this patch, are you sure it applied cleanly?
kmem_free(newname, MAXPATHLEN) should be on the following two lines only:
"sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c" line 1696 of
3073 --55%-- col 2-9
"sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c" line 2229 of
3073 --72%-- col 2-9
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 16:54:53 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 16:54:53 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #13 from Steven Hartland ---
In addition the functions these calls are in are: dsl_dataset_promote_sync and
dsl_dataset_rename_snapshot_sync_impl with the new one being added to:
dsl_dataset_promote_sync
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 16:59:30 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 16:59:31 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #14 from kash at tripleback.net ---
Ah, I'm using RELEASE-p7 it seems.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 17:42:18 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 17:42:18 +0000
Subject: [Bug 194071] zfsloader broken on sparc64 since r268649
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194071
--- Comment #8 from commit-hook at freebsd.org ---
A commit references this bug:
Author: delphij
Date: Thu Oct 2 17:41:28 UTC 2014
New revision: 272425
URL: https://svnweb.freebsd.org/changeset/base/272425
Log:
MFC r272389:
Diff reduction with kernel code: instruct the compiler that the data of
these types may be unaligned to their "normal" alignment and exercise
caution when accessing them.
PR: 194071
Approved by: re (gjb)
Changes:
_U stable/10/
stable/10/sys/cddl/boot/zfs/lz4.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 17:42:19 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 17:42:19 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #15 from Steven Hartland ---
-pX is just security patches, that won't effect the main code base.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 17:43:20 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 17:43:20 +0000
Subject: [Bug 194071] zfsloader broken on sparc64 since r268649
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194071
--- Comment #10 from commit-hook at freebsd.org ---
A commit references this bug:
Author: delphij
Date: Thu Oct 2 17:42:21 UTC 2014
New revision: 272427
URL: https://svnweb.freebsd.org/changeset/base/272427
Log:
MFC r272389:
Diff reduction with kernel code: instruct the compiler that the data of
these types may be unaligned to their "normal" alignment and exercise
caution when accessing them.
PR: 194071
Changes:
_U stable/8/sys/
_U stable/8/sys/cddl/
stable/8/sys/cddl/boot/zfs/lz4.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 17:53:06 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 17:53:06 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #16 from kash at tripleback.net ---
The patch does not apply cleanly to a new SVN pull of releng/10.0:
[/usr/src]-[root at fbsd-master]-[0]-[1704]
[:)] # cat sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c.rej
@@ -1684,8 +1682,7 @@
VERIFY0(zap_add(dp->dp_meta_objset, hds->ds_phys->ds_snapnames_zapobj,
ds->ds_snapname, 8, 1, &ds->ds_object, tx));
-#ifdef __FreeBSD__
-#ifdef _KERNEL
+#if defined(__FreeBSD__) && defined (_KERNEL)
oldname = kmem_alloc(MAXPATHLEN, KM_SLEEP);
newname = kmem_alloc(MAXPATHLEN, KM_SLEEP);
snprintf(oldname, MAXPATHLEN, "%s@%s", ddrsa->ddrsa_fsname,
@@ -2144,6 +2143,14 @@
dd->dd_phys->dd_clones, origin_head->ds_object, tx));
}
+#if defined(__FreeBSD__) && defined(_KERNEL)
+ /* Take the spa_namespace_lock so zvol renames don't livelock */
+ mutex_enter(&spa_namespace_lock);
+
+ oldname = kmem_alloc(MAXPATHLEN, KM_SLEEP);
+ newname = kmem_alloc(MAXPATHLEN, KM_SLEEP);
+#endif
+
/* move snapshots to this dir */
for (snap = list_head(&ddpa->shared_snaps); snap;
snap = list_next(&ddpa->shared_snaps, snap)) {
[/usr/src]-[root at fbsd-master]-[0]-[1705]
[:)] # cat sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c.rej
@@ -2393,9 +2381,10 @@
if (dmu_objset_type(os) == DMU_OST_ZVOL) {
dsl_dataset_long_hold(os->os_dsl_dataset, FTAG);
dsl_pool_rele(dmu_objset_pool(os), FTAG);
- if ((error = zvol_create_minor(name)) == 0)
+ error = zvol_create_minor(name);
+ if (error == 0 || error == EEXIST) {
error = zvol_create_snapshots(os, name);
- else {
+ } else {
printf("ZFS WARNING: Unable to create ZVOL %s
(error=%d).\n",
name, error);
}
@@ -2479,12 +2468,16 @@
size_t oldnamelen, newnamelen;
zvol_state_t *zv;
char *namebuf;
+ boolean_t locked = B_FALSE;
oldnamelen = strlen(oldname);
newnamelen = strlen(newname);
DROP_GIANT();
- mutex_enter(&spa_namespace_lock);
+ if (!MUTEX_HELD(&spa_namespace_lock)) {
+ mutex_enter(&spa_namespace_lock);
+ locked = B_TRUE;
+ }
g_topology_lock();
LIST_FOREACH(gp, &zfs_zvol_class.geom, geom) {
@@ -2507,6 +2500,7 @@
}
g_topology_unlock();
- mutex_exit(&spa_namespace_lock);
+ if (locked)
+ mutex_exit(&spa_namespace_lock);
PICKUP_GIANT();
}
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 17:55:32 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 17:55:32 +0000
Subject: [Bug 194071] zfsloader broken on sparc64 since r268649
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194071
Xin LI changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Needs MFC |Issue Resolved
Resolution|--- |FIXED
--- Comment #11 from Xin LI ---
Thanks for reporting and testing. I have merged the change to all supported
branches.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 17:56:46 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 17:56:47 +0000
Subject: [Bug 194071] zfsloader broken on sparc64 since r268649
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194071
--- Comment #12 from lidl at pix.net ---
Thanks!
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 18:42:49 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 18:42:49 +0000
Subject: [Bug 194098] New: Incorrect permissions on bind chroot 'master'
directory
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194098
Bug ID: 194098
Summary: Incorrect permissions on bind chroot 'master'
directory
Product: Base System
Version: 9.3-RELEASE
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: conf
Assignee: freebsd-bugs at FreeBSD.org
Reporter: matt at conundrum.com
According to /etc/mtree/BIND.chroot.dist the permissions of
/var/named/etc/named/master inherits an owner:group of root:wheel with the mode
0755. This should either be bind:wheel 0755 or root:bind 0775.
Turning on ixfr-from-differences will cause BIND to try to write a journal file
to the master directory, which it will attempt using the user:group of
bind:bind. There is no way to force the journal file to any other directory
except where the master file resides.
How-To-Repeat:
* enable ixfr-from-differences in the options stanza
* update a zone with type master
* issue an 'rndc reload' for the zone
A temporary workaround of moving master files into
/var/named/etc/namedb/dynamic is possible, but ignores the conceptual
separation of zone types.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 18:53:26 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 18:53:26 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #17 from Steven Hartland ---
(In reply to kash from comment #16)
> The patch does not apply cleanly to a new SVN pull of releng/10.0:
Just retested here against a clean checkout and it does apply for me without
issue.
Are you sure your checkout is clean?
smh> svn info
Path: .
Working Copy Root Path: freebsd/base/releng/10.0
URL: svn+ssh://svn.freebsd.org/base/releng/10.0
Relative URL: ^/releng/10.0
Repository Root: svn+ssh://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 272442
Node Kind: directory
Schedule: normal
Last Changed Author: delphij
Last Changed Rev: 271669
Last Changed Date: 2014-09-16 09:50:19 +0000 (Tue, 16 Sep 2014)
smh> svn status
smh>
root at node-dev:src-svn> patch -C -E -N -p0 -F1 -t <
/usr/src/patches/zfs-zvol-fixes.patch
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Various fixes for zvol devices not being correctly maintained when operations
|which effect them occur.
|--- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c.orig
2014-03-26 17:52:33.000000000 +0000
|+++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c
2014-09-29 18:52:24.903520480 +0000
--------------------------
Patching file sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c
using Plan A...
Hunk #1 succeeded at 1655.
Hunk #2 succeeded at 1684.
Hunk #3 succeeded at 1696.
Hunk #4 succeeded at 2072.
Hunk #5 succeeded at 2140.
Hunk #6 succeeded at 2180.
Hunk #7 succeeded at 2223.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zvol.h.orig
2014-03-26 17:52:33.000000000 +0000
|+++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zvol.h 2014-09-29
18:52:24.903520480 +0000
--------------------------
Patching file sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zvol.h using
Plan A...
Hunk #1 succeeded at 41.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c.orig
2014-03-26 17:52:33.000000000 +0000
|+++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c 2014-09-29
18:52:24.908521871 +0000
--------------------------
Patching file sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c using
Plan A...
Hunk #1 succeeded at 3517.
Hunk #2 succeeded at 3547.
Hunk #3 succeeded at 3643.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c.orig 2014-09-29
18:52:05.348521778 +0000
|+++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c 2014-09-29
18:52:24.909520935 +0000
--------------------------
Patching file sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c using Plan
A...
Hunk #1 succeeded at 630.
Hunk #2 succeeded at 757.
Hunk #3 succeeded at 782.
Hunk #4 succeeded at 2369 (offset -12 lines).
Hunk #5 succeeded at 2467 (offset -1 lines).
No such line 2505 in input file, ignoring
Hunk #6 succeeded at 2488 (offset -12 lines).
done
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 20:09:09 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 20:09:09 +0000
Subject: [Bug 163585] cpuset(1) by twice kill SMP functionality
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=163585
John Baldwin changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|In Discussion |Issue Resolved
CC| |jhb at FreeBSD.org
Resolution|--- |Feedback Timeout
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 21:05:38 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 21:05:38 +0000
Subject: [Bug 193499] [tests] usr.bin/yacc/err_syntax27.error failures with
the latest kyua
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193499
Craig Rodrigues changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-testing at freebsd.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 22:47:49 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 22:47:49 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #18 from kash at tripleback.net ---
I've built it but now I don't have /dev/zvol nodes showing up for clones.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 22:56:11 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 22:56:11 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #19 from kash at tripleback.net ---
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:1126:11:
warning: comparison of constant -1 with expression of type 'zfs_prop_t' is
always false [-Wtautological-constant-out-of-range-compare]
if (prop == ZPROP_INVAL) {
~~~~ ^ ~~~~~~~~~~~
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:2378:11:
warning: comparison of constant -1 with expression of type 'zfs_prop_t' is
always false [-Wtautological-constant-out-of-range-compare]
if (prop == ZPROP_INVAL) {
~~~~ ^ ~~~~~~~~~~~
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:2512:24:
warning: comparison of constant -1 with expression of type 'zfs_prop_t' is
always false [-Wtautological-constant-out-of-range-compare]
if (err == 0 && prop == ZPROP_INVAL) {
~~~~ ^ ~~~~~~~~~~~
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:2774:12:
warning: comparison of constant -1 with expression of type 'zfs_prop_t' is
always false [-Wtautological-constant-out-of-range-compare]
if (prop == ZPROP_INVAL) {
~~~~ ^ ~~~~~~~~~~~
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:2813:12:
warning: comparison of constant -1 with expression of type 'zfs_prop_t' is
always true [-Wtautological-constant-out-of-range-compare]
if (prop != ZPROP_INVAL && !zfs_prop_inheritable(prop))
~~~~ ^ ~~~~~~~~~~~
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:3661:11:
warning: comparison of constant -1 with expression of type 'zfs_prop_t' is
always false [-Wtautological-constant-out-of-range-compare]
if (prop == ZPROP_INVAL) {
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 2 23:04:33 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 23:04:33 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #20 from Steven Hartland ---
(In reply to kash from comment #19)
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/
> zfs_ioctl.c:1126:11: warning: comparison of constant -1 with expression of
> type 'zfs_prop_t' is always false
> [-Wtautological-constant-out-of-range-compare]
> if (prop == ZPROP_INVAL) {
> ~~~~ ^ ~~~~~~~~~~~
Nothing to do with this, it always does that.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 00:32:05 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 00:32:05 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #21 from kash at tripleback.net ---
Ok, wasn't sure if that was the intended behaviour - was zvol dev entry
creation purposefully removed?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 00:42:24 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 00:42:24 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #22 from Steven Hartland ---
(In reply to kash from comment #18)
> I've built it but now I don't have /dev/zvol nodes showing up for clones.
That's an issue already fixed in stable, its never worked in 10.0-RELEASE
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 00:43:40 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 00:43:40 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #23 from kash at tripleback.net ---
I've been using 10.0-RELEASE for a year with the original patch from this
thread. It does work, but not with the new locking patch you created.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 01:06:02 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 01:06:01 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
Steven Hartland changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #147915|0 |1
is obsolete| |
--- Comment #24 from Steven Hartland ---
Created attachment 147924
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147924&action=edit
Possible fix for zvol hang issues (against 10.0-RELEASE)
This also includes the fix from stable for clones not creating their
corrisponding zvols.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 01:07:13 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 01:07:13 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #25 from Steven Hartland ---
(In reply to kash from comment #23)
> I've been using 10.0-RELEASE for a year with the original patch from this
> thread. It does work, but not with the new locking patch you created.
There's no other patches on this PR, so I'm not sure what your refering to but
I've updated the patch for 10.0-RELEASE adding the fix from stable for clones
creating zvols.
I'd appreciate feedback on if the patch fixes your deadlock issue.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 01:39:43 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 01:39:43 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #26 from kash at tripleback.net ---
(In reply to Steven Hartland from comment #25)
> (In reply to kash from comment #23)
> > I've been using 10.0-RELEASE for a year with the original patch from this
> > thread. It does work, but not with the new locking patch you created.
>
> There's no other patches on this PR, so I'm not sure what your refering to
> but I've updated the patch for 10.0-RELEASE adding the fix from stable for
> clones creating zvols.
>
> I'd appreciate feedback on if the patch fixes your deadlock issue.
I meant from the other 'zvol not appearing' ticket.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 02:03:33 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 02:03:33 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #27 from kash at tripleback.net ---
Thanks for your patience, that's a good enough fix for now, hopefully soon the
locking code can be reworked within OpenZFS to have a generic approach across
Linux, Illumos and FreeBSD.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 02:04:01 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 02:04:01 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
kash at tripleback.net changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Needs Triage |Issue Resolved
Resolution|--- |Report to Upstream
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 03:36:59 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 03:36:59 +0000
Subject: [Bug 194108] New: Kernel panic on boot ACPI APIC table
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194108
Bug ID: 194108
Summary: Kernel panic on boot ACPI APIC table
Product: Base System
Version: 10.0-STABLE
Hardware: ia64
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: nefar at otherware.org
Created attachment 147926
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147926&action=edit
picture of boot screen
Fresh install. Motherboard: http://www.amazon.com/gp/product/B00FM4M7TQ
See screenshot for full details, but the computer freezes after displaying:
ACPI APIC Table:
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 03:47:48 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 03:47:48 +0000
Subject: [Bug 194108] Kernel panic on boot ACPI APIC table
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194108
--- Comment #1 from nefar at otherware.org ---
Note: FreeNAS boots with no issues.
--
You are receiving this mail because:
You are the assignee for the bug.
From spykey at importedeals.com Fri Oct 3 06:22:06 2014
From: spykey at importedeals.com (Importer Deals)
Date: Fri, 03 Oct 2014 15:51:58 +1000
Subject: Smallest Key Ring Spy Camera - Are you Bugged Bug Detector Sale
Message-ID: <348946080542e397e1642a.1412315518@www.vision6.com.au>
[1]Shop ImporterDeals
[2]Importer Dealer
HOT PRODUCT
LIMITED STOCK
Spy Camera Keyring
[key.png]
Only
$29.00
Was $249.00
Buy Now
Details
Cleverly disguised as a Standard Car Key Ring this device conceals a
pinhole sized video camera and high quality microphone enabling you to
discreetly capture high quality video with audio, images and separate
voice recordings for up to two hours while remaining undetected.
View
HOT PRODUCT
LIMITED STOCK
Wireless Spy Bug Detector
Video and Audio Tap Detector
[bug.png]
Only
$59.00
Was $299.00
Buy Now
Details
Wireless signals used in hidden spy cameras and other wireless
eavesdropping surveillance equipment can now be detected. Now you can
scan for high range hidden wireless signals that may be present in your
home or office. Keep you business and family matters safe from unwanted
viewers or listeners.
View
Safe Wash - Only $299.00
Watch Video
[3]Visit our website | QLD Australia
This email was sent by Importer Deals, Brisbane QLD 4000 to
freebsd-bugs at freebsd.org
[4]Unsubscribe
References
Visible links
1. http://www.vision6.com.au/ch/44773/8wjjs/1738542/9d52016zf9.html
2. http://www.vision6.com.au/ch/44773/8wjjs/1738543/9d520b93r.html
3. http://www.vision6.com.au/ch/44773/8wjjs/1738542/9d52016zf9-1.html
4. http://www.vision6.com.au/forms/u/13965c8/44773/6875698.html
Hidden links:
6. http://www.vision6.com.au/ch/44773/8wjjs/1799870/9d5204194.html
7. http://www.vision6.com.au/ch/44773/8wjjs/1799870/9d5204194-1.html
8. http://www.vision6.com.au/ch/44773/8wjjs/1799871/9d520f66c.html
9. http://www.vision6.com.au/ch/44773/8wjjs/1799871/9d520f66c-1.html
10. http://www.vision6.com.au/ch/44773/8wjjs/1799872/9d520bf5t.html
From bugzilla-noreply at freebsd.org Fri Oct 3 08:20:27 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 08:20:27 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #28 from Steven Hartland ---
So just to confirm, this does fix your deadlock issue?
For reference the current locking for zvol changes is actually quite specific
to FreeBSD so not really an upstream issue.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 08:21:31 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 08:21:31 +0000
Subject: [Bug 194109] New: [lor] if_lagg rmlock <-> if_addr_lock
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194109
Bug ID: 194109
Summary: [lor] if_lagg rmlock <-> if_addr_lock
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: dumbbell at FreeBSD.org
The following LOR appeared between r272024 and r272450:
Oct 3 10:11:38 magellan kernel: lock order reversal:
Oct 3 10:11:38 magellan kernel: 1st 0xfffff80006c92008 if_lagg rmlock (if_lagg
rmlock) @
/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/sys/modules/if_lagg/../../net/if_lagg.c:1395
Oct 3 10:11:38 magellan kernel: 2nd 0xfffff80029f77990 if_addr_lock
(if_addr_lock) @
/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/sys/modules/if_lagg/../../net/if_lagg.c:1499
Oct 3 10:11:38 magellan kernel: KDB: stack backtrace:
Oct 3 10:11:38 magellan kernel: db_trace_self_wrapper() at
db_trace_self_wrapper+0x2b/frame 0xfffffe012185e650
Oct 3 10:11:38 magellan kernel: kdb_backtrace() at kdb_backtrace+0x39/frame
0xfffffe012185e700
Oct 3 10:11:38 magellan kernel: witness_checkorder() at
witness_checkorder+0xdc2/frame 0xfffffe012185e790
Oct 3 10:11:38 magellan kernel: _rw_wlock_cookie() at
_rw_wlock_cookie+0x71/frame 0xfffffe012185e7d0
Oct 3 10:11:38 magellan kernel: lagg_ether_cmdmulti() at
lagg_ether_cmdmulti+0x5c/frame 0xfffffe012185e810
Oct 3 10:11:38 magellan kernel: lagg_ioctl() at lagg_ioctl+0x114c/frame
0xfffffe012185e8f0
Oct 3 10:11:38 magellan kernel: in_control() at in_control+0x30b/frame
0xfffffe012185e970
Oct 3 10:11:38 magellan kernel: ifioctl() at ifioctl+0xba8/frame
0xfffffe012185ea30
Oct 3 10:11:38 magellan kernel: kern_ioctl() at kern_ioctl+0x22b/frame
0xfffffe012185ea90
Oct 3 10:11:38 magellan kernel: sys_ioctl() at sys_ioctl+0x13c/frame
0xfffffe012185eae0
Oct 3 10:11:38 magellan kernel: amd64_syscall() at amd64_syscall+0x25a/frame
0xfffffe012185ebf0
Oct 3 10:11:38 magellan kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame
0xfffffe012185ebf0
Oct 3 10:11:38 magellan kernel: --- syscall (54, FreeBSD ELF64, sys_ioctl),
rip = 0x8011df81a, rsp = 0x7fffffffe3e8, rbp = 0x7fffffffe460 ---
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 08:23:55 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 08:23:55 +0000
Subject: [Bug 194110] New: [lor] if_lagg rmlock <-> re0
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194110
Bug ID: 194110
Summary: [lor] if_lagg rmlock <-> re0
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: dumbbell at FreeBSD.org
The following LOR appeared between r272024 and r272450:
Oct 3 10:11:38 magellan kernel: lock order reversal:
Oct 3 10:11:38 magellan kernel: 1st 0xfffff80006c92008 if_lagg rmlock (if_lagg
rmlock) @
/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/sys/modules/if_lagg/../../net/if_lagg.c:1448
Oct 3 10:11:38 magellan kernel: 2nd 0xfffffe0000edd218 re0 (network driver) @
/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/sys/dev/re/if_re.c:3416
Oct 3 10:11:38 magellan kernel: KDB: stack backtrace:
Oct 3 10:11:38 magellan kernel: db_trace_self_wrapper() at
db_trace_self_wrapper+0x2b/frame 0xfffffe012185e110
Oct 3 10:11:38 magellan kernel: kdb_backtrace() at kdb_backtrace+0x39/frame
0xfffffe012185e1c0
Oct 3 10:11:38 magellan kernel: witness_checkorder() at
witness_checkorder+0xdc2/frame 0xfffffe012185e250
Oct 3 10:11:38 magellan kernel: __mtx_lock_flags() at
__mtx_lock_flags+0xa8/frame 0xfffffe012185e2a0
Oct 3 10:11:38 magellan kernel: re_ioctl() at re_ioctl+0x114/frame
0xfffffe012185e2e0
Oct 3 10:11:38 magellan kernel: lagg_port_ioctl() at
lagg_port_ioctl+0xde/frame 0xfffffe012185e350
Oct 3 10:11:38 magellan kernel: if_addmulti() at if_addmulti+0x253/frame
0xfffffe012185e3d0
Oct 3 10:11:38 magellan kernel: lagg_ether_cmdmulti() at
lagg_ether_cmdmulti+0x108/frame 0xfffffe012185e410
Oct 3 10:11:38 magellan kernel: lagg_ioctl() at lagg_ioctl+0x7eb/frame
0xfffffe012185e4f0
Oct 3 10:11:38 magellan kernel: if_addmulti() at if_addmulti+0x253/frame
0xfffffe012185e570
Oct 3 10:11:38 magellan kernel: in6_mc_join_locked() at
in6_mc_join_locked+0x1a2/frame 0xfffffe012185e600
Oct 3 10:11:38 magellan kernel: in6_joingroup() at in6_joingroup+0x75/frame
0xfffffe012185e640
Oct 3 10:11:38 magellan kernel: in6_update_ifa() at in6_update_ifa+0xc37/frame
0xfffffe012185e740
Oct 3 10:11:38 magellan kernel: in6_ifattach() at in6_ifattach+0x455/frame
0xfffffe012185e970
Oct 3 10:11:38 magellan kernel: ifioctl() at ifioctl+0xad4/frame
0xfffffe012185ea30
Oct 3 10:11:38 magellan kernel: kern_ioctl() at kern_ioctl+0x22b/frame
0xfffffe012185ea90
Oct 3 10:11:38 magellan kernel: sys_ioctl() at sys_ioctl+0x13c/frame
0xfffffe012185eae0
Oct 3 10:11:38 magellan kernel: amd64_syscall() at amd64_syscall+0x25a/frame
0xfffffe012185ebf0
Oct 3 10:11:38 magellan kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame
0xfffffe012185ebf0
Oct 3 10:11:38 magellan kernel: --- syscall (54, FreeBSD ELF64, sys_ioctl),
rip = 0x8011df81a, rsp = 0x7fffffffe458, rbp = 0x7fffffffe4b0 ---
The lagg0 interface is configured like this in /etc/rc.conf:
ifconfig_lagg0="laggproto failover laggport re0 laggport wlan0 SYNCDHCP"
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 08:24:23 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 08:24:23 +0000
Subject: [Bug 194109] [lor] if_lagg rmlock <-> if_addr_lock
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194109
--- Comment #1 from Jean-S?bastien P?dron ---
The lagg0 interface is configured like this in /etc/rc.conf:
ifconfig_lagg0="laggproto failover laggport re0 laggport wlan0 SYNCDHCP"
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 08:25:43 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 08:25:43 +0000
Subject: [Bug 194111] New: [lor] iwn0_com_lock <-> if_addr_lock
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194111
Bug ID: 194111
Summary: [lor] iwn0_com_lock <-> if_addr_lock
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: dumbbell at FreeBSD.org
The following LOR appeared between r272024 and r272450:
Oct 3 10:11:38 magellan kernel: lock order reversal:
Oct 3 10:11:38 magellan kernel: 1st 0xfffffe0000f25018 iwn0_com_lock
(iwn0_com_lock) @
/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/sys/net80211/ieee80211_ioctl.c:3314
Oct 3 10:11:38 magellan kernel: 2nd 0xfffff800039b9990 if_addr_lock
(if_addr_lock) @
/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/sys/net/if.c:3278
Oct 3 10:11:38 magellan kernel: KDB: stack backtrace:
Oct 3 10:11:38 magellan kernel: db_trace_self_wrapper() at
db_trace_self_wrapper+0x2b/frame 0xfffffe012185e0e0
Oct 3 10:11:38 magellan kernel: kdb_backtrace() at kdb_backtrace+0x39/frame
0xfffffe012185e190
Oct 3 10:11:38 magellan kernel: witness_checkorder() at
witness_checkorder+0xdc2/frame 0xfffffe012185e220
Oct 3 10:11:38 magellan kernel: _rw_wlock_cookie() at
_rw_wlock_cookie+0x71/frame 0xfffffe012185e260
Oct 3 10:11:38 magellan kernel: if_delallmulti() at if_delallmulti+0x28/frame
0xfffffe012185e290
Oct 3 10:11:38 magellan kernel: ieee80211_ioctl() at
ieee80211_ioctl+0x22f/frame 0xfffffe012185e2e0
Oct 3 10:11:38 magellan kernel: lagg_port_ioctl() at
lagg_port_ioctl+0xde/frame 0xfffffe012185e350
Oct 3 10:11:38 magellan kernel: if_addmulti() at if_addmulti+0x253/frame
0xfffffe012185e3d0
Oct 3 10:11:38 magellan kernel: lagg_ether_cmdmulti() at
lagg_ether_cmdmulti+0x108/frame 0xfffffe012185e410
Oct 3 10:11:38 magellan kernel: lagg_ioctl() at lagg_ioctl+0x7eb/frame
0xfffffe012185e4f0
Oct 3 10:11:38 magellan kernel: if_addmulti() at if_addmulti+0x253/frame
0xfffffe012185e570
Oct 3 10:11:38 magellan kernel: in6_mc_join_locked() at
in6_mc_join_locked+0x1a2/frame 0xfffffe012185e600
Oct 3 10:11:38 magellan kernel: in6_joingroup() at in6_joingroup+0x75/frame
0xfffffe012185e640
Oct 3 10:11:38 magellan kernel: in6_update_ifa() at in6_update_ifa+0xc37/frame
0xfffffe012185e740
Oct 3 10:11:38 magellan kernel: in6_ifattach() at in6_ifattach+0x455/frame
0xfffffe012185e970
Oct 3 10:11:38 magellan kernel: ifioctl() at ifioctl+0xad4/frame
0xfffffe012185ea30
Oct 3 10:11:38 magellan kernel: kern_ioctl() at kern_ioctl+0x22b/frame
0xfffffe012185ea90
Oct 3 10:11:38 magellan kernel: sys_ioctl() at sys_ioctl+0x13c/frame
0xfffffe012185eae0
Oct 3 10:11:38 magellan kernel: amd64_syscall() at amd64_syscall+0x25a/frame
0xfffffe012185ebf0
Oct 3 10:11:38 magellan kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame
0xfffffe012185ebf0
Oct 3 10:11:38 magellan kernel: --- syscall (54, FreeBSD ELF64, sys_ioctl),
rip = 0x8011df81a, rsp = 0x7fffffffe458, rbp = 0x7fffffffe4b0 ---
The lagg0 interface is configured like this in /etc/rc.conf:
ifconfig_lagg0="laggproto failover laggport re0 laggport wlan0 SYNCDHCP"
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 08:41:00 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 08:41:00 +0000
Subject: [Bug 192951] Allow fdescfs to be used in hierarchical jails
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192951
ruben at verweg.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #146188|0 |1
is obsolete| |
--- Comment #2 from ruben at verweg.com ---
Created attachment 147927
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147927&action=edit
patch that introduces allow.mount.fdescfs
Patch adjusted with feedback from kib@
Still using allow.mount.fdescfs instead of proposed allow.mount.devfs as the
current pattern is that each pseudofs has its own flag.
It would be better to introduce an allow.mount.pseudofs for that, but this is
not the place nor time
patch can be applied to -current, followed by a MFC to stable/10
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 09:45:10 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 09:45:10 +0000
Subject: [Bug 194112] New: [panic] Fatal trap 12: Page fault while in vm86
mode with kern.vty=vt console and hw.vga.textmode=1
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194112
Bug ID: 194112
Summary: [panic] Fatal trap 12: Page fault while in vm86 mode
with kern.vty=vt console and hw.vga.textmode=1
Product: Base System
Version: 10.1-BETA3
Hardware: i386
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: info at juanmolina.eu
I?m getting a consistent panic with a NVIDIA GeForce FX 5600 XT (NV31) AGP card
when enabling both kern.vty=vt and hw.vga.textmode=1 in /boot/loader.conf.
FreeBSD 10.1-BETA3.
I wanted to test the VT console, enabled kern.vty=vt, but the graphics mode was
unusable due to the buffer being drawn out of the screen (that?s another
problem). I then added hw.vga.textmode=1 and kernel panicked.
Unfortunately, I?m not getting any core dumps despite having dumpdev="AUTO" in
/etc/rc.conf and a 3 GB swap device enabled (actual memory is 1.5 GB). I?ve not
found any erros related to savecore.
Here is some relevant text, copied by hand, from the panic:
vga0: ...
Fatal trap 12: Page fault while in vm86 mode
...
fault code: user read, page not present
...
I?m willing to test further if any developer is interested.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 09:45:56 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 09:45:56 +0000
Subject: [Bug 194112] [panic] Fatal trap 12: Page fault while in vm86 mode
with kern.vty=vt console, hw.vga.textmode=1 and NVIDIA card
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194112
Juan Ram?n Molina Menor changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[panic] Fatal trap 12: Page |[panic] Fatal trap 12: Page
|fault while in vm86 mode |fault while in vm86 mode
|with kern.vty=vt console |with kern.vty=vt console,
|and hw.vga.textmode=1 |hw.vga.textmode=1 and
| |NVIDIA card
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 11:11:59 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 11:11:58 +0000
Subject: [Bug 194063] installer fails to boot / kernel panic on HP Probook
430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #13 from Oliver Pinter ---
Created attachment 147929
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147929&action=edit
hbsd-11 native mode w/o csm
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 11:12:49 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 11:12:49 +0000
Subject: [Bug 194063] installer fails to boot / kernel panic on HP Probook
430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #14 from Oliver Pinter ---
Created attachment 147930
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147930&action=edit
hbsd-11 hybrid mode w/ csm
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 11:13:06 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 11:13:06 +0000
Subject: [Bug 194063] installer fails to boot / kernel panic on HP Probook
430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #15 from Oliver Pinter ---
Created attachment 147931
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147931&action=edit
hbsd-11 hybrid mode w/ csm
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 11:13:26 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 11:13:26 +0000
Subject: [Bug 194063] installer fails to boot / kernel panic on HP Probook
430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #16 from Oliver Pinter ---
Created attachment 147932
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147932&action=edit
hbsd-11 hybrid mode w/ csm
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 11:19:02 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 11:19:02 +0000
Subject: [Bug 194063] installer fails to boot / kernel panic on HP Probook
430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #17 from Oliver Pinter ---
http://www.crysys.hu/~op/freebsd/memstick-debug.img
Builded a new memstick installer, and enabled VERBOSE_SYSINIT and DEBUG options
in kernel config, but these options don't have any effect.
With CURRENT, I got a running DDB. In native mode w/o CSM the kernel hanged up
after printed out terminal settings. In native mode defaulted to 1366x768
resolution.
In hybrid mode, the system goes towards, but paniced due NULL pointer deref.
The stack traces are in newly uploaded images. The R12 registers value is 0,
and the system derefed this. In hybrid mode, the system defaulted to 1024x768
resolution.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 11:26:58 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 11:26:58 +0000
Subject: [Bug 194063] installer fails to boot / kernel panic on HP Probook
430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
Oliver Pinter changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #147930|0 |1
is obsolete| |
--- Comment #18 from Oliver Pinter ---
Created attachment 147933
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147933&action=edit
hbsd-11 hybrid mode w/ csm
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 13:25:02 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 13:25:02 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #29 from kash at tripleback.net ---
yes so far it resolves rename-related deadlocks.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 13:28:25 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 13:28:25 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #30 from kash at tripleback.net ---
(In reply to Steven Hartland from comment #28)
> So just to confirm, this does fix your deadlock issue?
>
> For reference the current locking for zvol changes is actually quite
> specific to FreeBSD so not really an upstream issue.
Richard Yao was saying there's potential for converging the pathways still, ZoL
and Illumos have different ways of structuring locks, and thought the way this
was handled is a bit too similar to the Big Kernel Lock, but I don't know much
about this, I'm a less articulate coder.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 14:05:40 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 14:05:40 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #31 from Steven Hartland ---
(In reply to kash from comment #30)
> (In reply to Steven Hartland from comment #28)
> > So just to confirm, this does fix your deadlock issue?
> >
> > For reference the current locking for zvol changes is actually quite
> > specific to FreeBSD so not really an upstream issue.
>
> Richard Yao was saying there's potential for converging the pathways still,
> ZoL and Illumos have different ways of structuring locks, and thought the
> way this was handled is a bit too similar to the Big Kernel Lock, but I
> don't know much about this, I'm a less articulate coder.
I believe this is around FS locking. The reason for the divergence in the code
bases around ZVOLs is due to the fact that upstream creates ZVOL dev entries on
the demand when a /dev/ lookup takes place. This is something FreeBSD currently
can't do hence the various static create/destroy/rename in various places so
they are always available.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 14:49:57 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 14:49:58 +0000
Subject: [Bug 193803] zvol rename failing due to out of order locking
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803
--- Comment #32 from commit-hook at freebsd.org ---
A commit references this bug:
Author: smh
Date: Fri Oct 3 14:49:50 UTC 2014
New revision: 272474
URL: https://svnweb.freebsd.org/changeset/base/272474
Log:
Fix various issues with zvols
When performing snapshot renames we could deadlock due to the locking
in zvol_rename_minors. In order to avoid this use the same workaround
as zvol_open in zvol_rename_minors.
Add missing zvol_rename_minors to dsl_dataset_promote_sync.
Protect against invalid index into zv_name in zvol_remove_minors.
Replace zvol_remove_minor calls with zvol_remove_minors to ensure
any potential children are also renamed.
Don't fail zvol_create_minors if zvol_create_minor returns EEXIST.
Restore the valid pool check in zfs_ioc_destroy_snaps to ensure we
don't call zvol_remove_minors when zfs_unmount_snap fails.
PR: 193803
MFC after: 1 week
Sponsored by: Multiplay
Changes:
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 15:03:35 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 15:03:35 +0000
Subject: [Bug 194112] [panic] Fatal trap 12: Page fault while in vm86 mode
with kern.vty=vt console, hw.vga.textmode=1 and NVIDIA card
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194112
Ed Maste changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |emaste at freebsd.org
--- Comment #1 from Ed Maste ---
Can you please add the backtrace if available (or just attach a picture of the
full panic output)?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 15:13:53 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 15:13:53 +0000
Subject: [Bug 194112] [panic] Fatal trap 12: Page fault while in vm86 mode
with kern.vty=vt console, hw.vga.textmode=1 and NVIDIA card
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194112
Ed Maste changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |vt
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 15:15:07 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 15:15:07 +0000
Subject: [Bug 194108] Kernel panic on boot ACPI APIC table
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194108
nefar at otherware.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Needs Triage |Issue Resolved
Resolution|--- |Works As Intended
--- Comment #2 from nefar at otherware.org ---
This appears to work fine with 10.1-BETA3
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 15:15:25 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 15:15:25 +0000
Subject: [Bug 192248] [vt] panic in vtbuf_fill_locked from vt_upgrade with no
vt(4) drivers attached
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192248
Ed Maste changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.freebsd.org/bu
| |gzilla/show_bug.cgi?id=1939
| |81
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 15:17:46 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 15:17:46 +0000
Subject: [Bug 193910] vt(4): add ability to restore default font via
vidcontrol(1) [patch]
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193910
Ed Maste changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 15:18:18 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 15:18:18 +0000
Subject: [Bug 193865] option XXX_DFLT_KEYMAP config header generation fix
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193865
Ed Maste changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch
CC| |emaste at freebsd.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 15:29:51 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 15:29:51 +0000
Subject: [Bug 194112] [panic] Fatal trap 12: Page fault while in vm86 mode
with kern.vty=vt console, hw.vga.textmode=1 and NVIDIA card
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194112
--- Comment #2 from Juan Ram?n Molina Menor ---
Created attachment 147937
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147937&action=edit
Screenshoot of panic with vt, textmode and NVIDIA
Sure, attached.
I don?t understand why it?s not dumping core? :(
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 15:31:33 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 15:31:33 +0000
Subject: [Bug 194117] New: libprocstat incorrectly extracts some ZFS
information
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194117
Bug ID: 194117
Summary: libprocstat incorrectly extracts some ZFS information
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Many People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: avg at FreeBSD.org
lib/libprocstat/zfs.c uses old ZFS znode_t layout that is not compatible with
what is currently in kernel when it extracts vn_mode and vn_size. In
particular, the code assumes that znode_t contains a pointer to a znode_phys_t
object, which is not the case.
I think that the required information can be extracted from z_size and z_mode
fields in znode_t.
While here, there is a comment in zfs_filestat() that talks about two byte
offsets, while in reality the offsets are 2 * sizeof(pointer), e.g. 16 bytes on
64-bit systems. The code itself is correct.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 15:33:26 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 15:33:26 +0000
Subject: [Bug 194117] libprocstat incorrectly extracts some ZFS information
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194117
Andriy Gapon changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |zfs
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 17:50:47 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 17:50:47 +0000
Subject: [Bug 193613] Loading i915 KMS driver in /boot/loader.conf and using
vt (newcons) results in endless reboot loop
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193613
Ed Maste changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |i915
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 20:39:38 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 20:39:38 +0000
Subject: [Bug 194121] New: device.hints not honored when selecting UART for
system console
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194121
Bug ID: 194121
Summary: device.hints not honored when selecting UART for
system console
Product: Base System
Version: 10.0-STABLE
Hardware: amd64
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: misc
Assignee: freebsd-bugs at FreeBSD.org
Reporter: mgsmith at netgate.com
I am trying to boot 10-STABLE on a system based on Intel's Atom C2538 board
with 2 UART devices. The first UART is not used. The second is exposed
externally to be used as the system console. When I try to set
hint.uart.1.flags="0x10" and unset that flag from UART 0, nothing gets
displayed to the system console when it boots.
I repeated the test on a SuperMicro system based on Intel's Atom C2758 board
and got similar results. Trying to force the second serial port to be the
system console doesn't work. If I set the flag to indicate that the second uart
is available as the system console, when the system comes up, the first uart is
still acting as the console. Here are the hints:
hint.uart.0.at="isa"
hint.uart.0.port="0x3F8"
hint.uart.0.irq="4"
hint.uart.1.at="isa"
hint.uart.1.port="0x2F8"
hint.uart.1.irq="3"
hint.uart.1.flags="0x10"
and the relevant info from dmesg:
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 on acpi0
uart0: console (115200,n,8,1)
uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0
I've tried other tricks:
1. Comment out the hints listed above and just add a new set of hints for
uart.0 that has irq 3, port 0x2f8, flags 0x10. The result was that the system
still found the other uart and made it the system console. dmesg data:
uart1: <16550 or compatible> port 0x3f8-0x3ff irq 4 on acpi0
uart1: console (115200,n,8,1)
uart0: <16550 or compatible> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0
2. Set hint.uart.0.disabled="1" with the hints listed above. The result was
that the system did not output any console messages on either serial port and
just used the VGA.
In all of this testing, I had both ttyu0 and ttyu1 enabled in /etc/ttys.
/boot/loader.conf had console="comconsole,vidconsole" and
comconsole_speed="115200". /boot.config contained -D.
I can boot both of these devices from FreeBSD 8.3 with the second serial port
set as the system console. Newer versions of FreeBSD, at least 10-STABLE and
11-CURRENT, it doesn't seem to work. I haven't tried any of the 9.x releases.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 23:17:01 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 23:17:01 +0000
Subject: [Bug 194128] New: CTL frontend possible race, missing ccb completion
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194128
Bug ID: 194128
Summary: CTL frontend possible race, missing ccb completion
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: smferris at gmail.com
Created attachment 147952
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147952&action=edit
ctl_frontend_cam_sim patch
While hunting some memory use-after-free bugs involving CAM_SIM_QUEUED being
set on a freed ccb, I found what looks like a possible race where the CTL
frontend can queue a ccb for processing before setting the CAM_SIM_QUEUED flag.
CTL also seems to be missing a ccb completion in the case where the ccb
couldn't be queued.
Patch attached.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 3 23:59:41 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Oct 2014 23:59:41 +0000
Subject: [Bug 194128] CTL frontend possible race, missing ccb completion
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194128
Benno Rice changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |mav at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 4 05:44:00 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 04 Oct 2014 05:44:00 +0000
Subject: [Bug 194132] New: rm(1) is ignoring more errors than it should in
rm_tree(..)
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194132
Bug ID: 194132
Summary: rm(1) is ignoring more errors than it should in
rm_tree(..)
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: ngie at FreeBSD.org
This code in bin/rm/rm.c catches more errors than it should:
338 if (!fflag && errno)
339 err(1, "fts_read");
340 fts_close(fts);
341 }
In particular, the code will mask errors if fts_read fails with anything other
than EACCES, ENOENT, or EPERM according to the intent of -f in rm(1):
-f Attempt to remove the files without prompting for confirmation,
regardless of the file's permissions. If the file does not
exist, do not display a diagnostic message or modify the exit
status to reflect an error. The -f option overrides any previous
-i options.
Please see the related bug for more details.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 4 05:44:25 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 04 Oct 2014 05:44:25 +0000
Subject: [Bug 194132] rm(1) is ignoring more errors than it should in
rm_tree(..)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194132
Garrett Cooper changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.freebsd.org/bu
| |gzilla/show_bug.cgi?id=1924
| |90
Assignee|freebsd-bugs at FreeBSD.org |imp at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 4 11:25:59 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 04 Oct 2014 11:25:58 +0000
Subject: [Bug 192248] [vt] panic in vtbuf_fill_locked from vt_upgrade with no
vt(4) drivers attached
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192248
--- Comment #1 from Jean-S?bastien P?dron ---
Created attachment 147965
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147965&action=edit
vtterm_cnprobe: Only recompute term size if screen size != 0
I see that there's no vt(4) driver built into RPI-B kernel configuration,
therefore, the screen size is unknown (and set to 0).
Could you please try the attached patch?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 4 11:27:00 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 04 Oct 2014 11:27:00 +0000
Subject: [Bug 192248] [vt] panic in vtbuf_fill_locked from vt_upgrade with no
vt(4) drivers attached
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192248
--- Comment #2 from Jean-S?bastien P?dron ---
Oops, sorry, I added the patch to the wrong bug report... I meant to do this in
193981 :)
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 4 11:28:25 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 04 Oct 2014 11:28:24 +0000
Subject: [Bug 192248] [vt] panic in vtbuf_fill_locked from vt_upgrade with no
vt(4) drivers attached
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192248
Jean-S?bastien P?dron changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #147965|0 |1
is obsolete| |
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 4 14:16:03 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 04 Oct 2014 14:16:03 +0000
Subject: [Bug 181263] grep(1) crashes at memchr/__sfvwrite when using colors
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181263
David CARLIER changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dcarlier at afilias.info
--- Comment #2 from David CARLIER ---
Created attachment 147970
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147970&action=edit
Proposed patch
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 4 18:55:55 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 04 Oct 2014 18:55:55 +0000
Subject: [Bug 194143] New: [PATCH] newsysog: better error reporting
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194143
Bug ID: 194143
Summary: [PATCH] newsysog: better error reporting
Product: Base System
Version: 10.0-RELEASE
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Many People
Priority: Normal
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: lyndon at orthanc.ca
Created attachment 147978
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147978&action=edit
patch to add filename to error message
When newsyslog receives an error when signalling a process, the resulting error
message provides no information to to identify which entry in newsyslog.conf
failed.
The attached patch adds the name of the pid file to the error message, to aid
in identifying the problematic entry.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 4 18:57:37 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 04 Oct 2014 18:57:37 +0000
Subject: [Bug 194143] [PATCH] newsyslog(8): better error reporting
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194143
lyndon at orthanc.ca changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[PATCH] newsysog: better |[PATCH] newsyslog(8):
|error reporting |better error reporting
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 4 19:37:13 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 04 Oct 2014 19:37:13 +0000
Subject: [Bug 193761] [PATCH] Add error return to minidumpsys(), use in
dumpsys()
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193761
Mark Johnston changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |markj at FreeBSD.org
Assignee|freebsd-bugs at FreeBSD.org |markj at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 4 19:38:12 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 04 Oct 2014 19:38:12 +0000
Subject: [Bug 194143] [PATCH] newsyslog(8): better error reporting
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194143
Mark Johnston changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |markj at FreeBSD.org
Assignee|freebsd-bugs at FreeBSD.org |markj at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 4 19:48:03 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 04 Oct 2014 19:48:03 +0000
Subject: [Bug 190493] [dtrace] failed to resolve cwd: Unknown variable name
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190493
Mark Johnston changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Needs Triage |Open
CC| |markj at FreeBSD.org
Assignee|freebsd-bugs at FreeBSD.org |markj at FreeBSD.org
--- Comment #1 from Mark Johnston ---
This is a known problem, discussed a bit here:
https://lists.freebsd.org/pipermail/freebsd-dtrace/2014-June/000219.html
In short, it's probably not straightforward to implement.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 4 20:31:17 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 04 Oct 2014 20:31:17 +0000
Subject: [Bug 194132] rm(1) is ignoring more errors than it should in
rm_tree(..)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194132
Warner Losh changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|imp at FreeBSD.org |freebsd-bugs at FreeBSD.org
--- Comment #2 from Warner Losh ---
and don't assign me bugs that I have no interest in fixing,
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 4 21:02:57 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 04 Oct 2014 21:02:57 +0000
Subject: [Bug 186293] tar(1): Problems with tar on FreeBSD 10.0
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186293
martin changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |palkovicm at gmail.com
--- Comment #5 from martin ---
Hi,
the same problem here, it seems that Solaris NFS server ignores "Mode" field of
"Set file attributes" command issued by FreeBSD 10 NFS client. The same command
issued by FreeBSD 8 NFS client was handled as expected including "Mode" field,
only difference is in access and modification time flags, FreeBSD 8 uses "set
to server time" flag, while FreeBSD 10 uses "set to client time" flag (see
request/response dumps below).
I will be grateful for any advices or workarounds.
Martin.
FreeBSD 10 request:
NFS: Proc = 2 (Set file attributes)
NFS: File handle = [6837]
NFS: D06911FA089EF0630A003400000000001D901C010A000400000000007BC91B01
NFS: Mode = 0644
NFS: Setuid = 0, Setgid = 0, Sticky = 0
NFS: Owner's permissions = rw-
NFS: Group's permissions = r--
NFS: Other's permissions = r--
NFS: User ID = (not set)
NFS: Group ID = (not set)
NFS: Size = (not set)
NFS: Access time = 04-Oct-14 18:10:43.000000 GMT (set to client time)
NFS: Modification time = 04-Oct-14 18:10:43.000000 GMT (set to client time)
Solaris 11 reply to FreeBSD 10 request:
NFS: Proc = 2 (Set file attributes)
NFS: Status = 0 (OK)
NFS: Pre-operation attributes:
NFS: Size = 0 bytes
NFS: Modification time = 11-Jan-36 14:28:33.-574173475 GMT
NFS: Attribute change time = 04-Oct-14 18:10:43.524178180 GMT
NFS: Post-operation attributes:
NFS: File type = 1 (Regular File)
NFS: Mode = 00
NFS: Setuid = 0, Setgid = 0, Sticky = 0
NFS: Owner's permissions = ---
NFS: Group's permissions = ---
NFS: Other's permissions = ---
NFS: Link count = 1, User ID = 0, Group ID = 0
NFS: File size = 0, Used = 512
NFS: Special: Major = 4294967295, Minor = 4294967295
NFS: File system id = 1176821104663, File id = 52
NFS: Last access time = 04-Oct-14 18:10:43.000000000 GMT
NFS: Modification time = 04-Oct-14 18:10:43.000000000 GMT
NFS: Attribute change time = 04-Oct-14 18:10:43.525300934 GMT
FreeBSD 8 request:
NFS: Proc = 2 (Set file attributes)
NFS: File handle = [D037]
NFS: D06911FA089EF0630A00380000000000A9901C010A000400000000007BC91B01
NFS: Mode = 0644
NFS: Setuid = 0, Setgid = 0, Sticky = 0
NFS: Owner's permissions = rw-
NFS: Group's permissions = r--
NFS: Other's permissions = r--
NFS: User ID = (not set)
NFS: Group ID = (not set)
NFS: Size = (not set)
NFS: Access time = (set to server time)
NFS: Modification time = (set to server time)
Solaris 11 reply to FreeBSD 8 request:
NFS: Proc = 2 (Set file attributes)
NFS: Status = 0 (OK)
NFS: Pre-operation attributes:
NFS: Size = 0 bytes
NFS: Modification time = 07-Feb-80 10:25:04.2130706433 GMT
NFS: Attribute change time = 04-Oct-14 18:22:26.916078703 GMT
NFS: Post-operation attributes:
NFS: File type = 1 (Regular File)
NFS: Mode = 0644
NFS: Setuid = 0, Setgid = 0, Sticky = 0
NFS: Owner's permissions = rw-
NFS: Group's permissions = r--
NFS: Other's permissions = r--
NFS: Link count = 1, User ID = 0, Group ID = 0
NFS: File size = 0, Used = 512
NFS: Special: Major = 4294967295, Minor = 4294967295
NFS: File system id = 1176821104663, File id = 56
NFS: Last access time = 04-Oct-14 18:22:26.917191243 GMT
NFS: Modification time = 04-Oct-14 18:22:26.917191299 GMT
NFS: Attribute change time = 04-Oct-14 18:22:26.917215996 GMT
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Oct 5 15:13:03 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Oct 2014 15:13:03 +0000
Subject: [Bug 194132] rm(1) is ignoring more errors than it should in
rm_tree(..)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194132
Jilles Tjoelker changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jilles at FreeBSD.org
--- Comment #3 from Jilles Tjoelker ---
The problem here is in fts(3), not in rm(1). If fts_read() aborts the traversal
because of a concurrent modification, that is a bug. If a concurrent rm -rf X/Y
causes an rm -rf X to abort, this may cause X/Z to escape removal erroneously.
A possible fix is to use the pathnames to go back to grandparent directories if
opening ".." fails (as with "..", st_dev and st_ino must be checked). A
consequence is that the current directory and fts_accpath in the FTS_DP result
will be different (fts_accpath will contain a slash, which it normally doesn't
if fts is changing directory). Also, this will not work in deep directory trees
with pathnames longer than PATH_MAX.
--
You are receiving this mail because:
You are the assignee for the bug.
From egoitz at ramattack.net Sun Oct 5 15:31:33 2014
From: egoitz at ramattack.net (Egoitz Aurrekoetxea)
Date: Sun, 5 Oct 2014 17:25:31 +0200
Subject: Release generation failure from 10.0-RELEASE to RELENG_10_0
Message-ID: <28D0D221-FB9A-4F75-83CE-0FB614C69708@ramattack.net>
Good afternoon,
Have found what seems to be a bug in the generate-release.sh script. When running the command for example :
sh generate-release.sh releng/10.0 /expert/release-generada
it fails when stats building pkg in the chrooted env. I think this is because in the chroot env are not created the shared library
cache hint files?. so it seems to be solved when modifying the script int he following way :
--- /root/generate-release.sh-defecto 2014-10-05 08:30:49.000000000 +0200
+++ /usr/src/release/generate-release.sh 2014-10-05 08:30:57.000000000 +0200
@@ -108,6 +108,8 @@
if [ -d ${CHROOTDIR}/usr/doc ]; then
cp /etc/resolv.conf ${CHROOTDIR}/etc/resolv.conf
+ ${CHROOT_CMD} /etc/rc.d/ldconfig onerestart
+
# Install docproj to build release documentation
${CHROOT_CMD} /bin/sh -c \
'make -C /usr/ports/textproc/docproj \
I think this is similar as reported in ports/186554 bug.
Could someone say if this should had been solved in another way?. I think this is correct. Isn?t it?.
Best regards,
From bugzilla-noreply at freebsd.org Sun Oct 5 15:55:40 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Oct 2014 15:55:40 +0000
Subject: [Bug 192324] [uefi] 2014-07-14 11.0-CURRENT snapshot doesn't boot
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192324
freebsdbugs at gushi.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |freebsdbugs at gushi.org
--- Comment #4 from freebsdbugs at gushi.org ---
So, I did a presentation on this board at BAFUG recently. In that
presentation, I included boot results and screenshots:
What I've found works is to get to an EFI shell, and then launch the loader
from the command line -- but ONLY when connected to an HDMI console.
You can see my output (they're embedded videos) at
http://www.gushi.org/minnowpreso
Hope these help.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Oct 5 19:56:35 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Oct 2014 19:56:35 +0000
Subject: [Bug 194173] New: Timezones (zoneinfo) starting from October 2014
wrong for Russia, etc
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194173
Bug ID: 194173
Summary: Timezones (zoneinfo) starting from October 2014 wrong
for Russia, etc
Product: Base System
Version: 9.3-RELEASE
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Many People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: leo at sai.msu.ru
The current installed version of FreeBSD 8.4-RELEASE-p16, 9.3-RELEASE-p2 and
10.0-RELEASE-p9 incorrectly convert UTC to/from local time. Differences between
actual zoneinfo IANA and FreeBSD versions [name wrong source file from the
directory contrib/tzdata (share/zoneinfo); country; one of the cities for which
an error has been observed; the near future for which the observed error]:
FreeBSD 8.4-RELEASE-p16:
europe Russia Europe/Moscow (26 Oct 2014)
africa Egypt Africa/Cairo (24 Apr 2015)
Libya Africa/Tripoli (31 Oct 2014)
asia Palestine Asia/Hebron (27 Mar 2015)
Zion Asia/Jerusalem (6 Oct 2014)
FreeBSD 10.0-RELEASE-p9:
europe Russia Europe/Moscow (26 Oct 2014)
africa Egypt Africa/Cairo (24 Apr 2015)
FreeBSD 9.3-RELEASE-p2:
europe Russia Europe/Moscow (26 Oct 2014)
Workarounds:
1. Temporarily use the current version of /usr/ports/misc/zoneinfo (see
attachment zoneinfo-2014.f.txz):
# portsnap fetch
# portsnap update
# cd /usr/ports/misc/zoneinfo
# make install
Add WITHOUT_ZONEINFO="yes" to your /etc/src.conf;
Run tzsetup(8) again to install the right file to /etc/localtime.
2. Copy directory /usr/share/zoneinfo from FreeBSD stable/8, stable/9 or
10.1-RC1.
Updated source files, see:
https://svnweb.freebsd.org/base/stable/8/share/zoneinfo/antarctica?revision=270814&view=markup
https://svnweb.freebsd.org/base/stable/9/contrib/tzdata/etcetera?revision=270815&view=markup
https://svnweb.freebsd.org/base/stable/10/contrib/tzdata/backward?revision=270817&view=markup
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Oct 5 20:04:05 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Oct 2014 20:04:05 +0000
Subject: [Bug 192324] [uefi] 2014-07-14 11.0-CURRENT snapshot doesn't boot
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192324
--- Comment #5 from Oliver Pinter ---
take a look at this PR:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Oct 5 20:04:25 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Oct 2014 20:04:25 +0000
Subject: [Bug 194063] [uefi] installer fails to boot / kernel panic on HP
Probook 430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
Oliver Pinter changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|installer fails to boot / |[uefi] installer fails to
|kernel panic on HP Probook |boot / kernel panic on HP
|430 G1 |Probook 430 G1
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Oct 5 20:28:55 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Oct 2014 20:28:55 +0000
Subject: [Bug 194173] Timezones (zoneinfo) starting from October 2014 wrong
for Russia, etc
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194173
--- Comment #1 from leo at sai.msu.ru ---
P.S.
Require changes only zone info data files (one, two, or three files). C code or
command files changes do not require.
-- Sorry for my best English.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Oct 5 20:49:10 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Oct 2014 20:49:10 +0000
Subject: [Bug 194173] Timezones (zoneinfo) starting from October 2014 wrong
for Russia, etc
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194173
--- Comment #2 from leo at sai.msu.ru ---
Created attachment 148016
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148016&action=edit
Package with zoneinfo data files
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at FreeBSD.org Sun Oct 5 21:00:27 2014
From: bugzilla-noreply at FreeBSD.org (bugzilla-noreply at FreeBSD.org)
Date: Sun, 05 Oct 2014 21:00:27 +0000
Subject: Problem reports for freebsd-bugs@FreeBSD.org that need special
attention
Message-ID: <201410052100.s95L0RUM013183@kenobi.freebsd.org>
To view an individual PR, use:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.
Status | Bug Id | Description
----------------+-----------+-------------------------------------------------
Needs MFC | 155028 | init(8): "init q" in single user causes segfaul
Needs MFC | 156481 | [kernel] [patch] kernel incorrectly reports PPS
Needs MFC | 165630 | [ndis][panic][patch] IRQL_NOT_GREATER_THAN
Needs MFC | 167133 | stale files in /usr/share/examples
Needs MFC | 169471 | [patch] pw(8) deletes group "username" on userd
Needs MFC | 171779 | [patch] passwd(1): make option NO_FSCHG incompl
Needs MFC | 181155 | [libc] [patch] *access*(2) does not handle inva
Needs MFC | 184681 | A bug of bsdconfig(8) in 10.0 RC1
Needs MFC | 190186 | [patch] i915 driver: enable opregion handling
Needs MFC | 192730 | [build] make checkdpadd failures with LD* varia
Needs MFC | 192760 | [build] sbin/ifconfig: missing DPADD for LIBM
Patch Ready | 192350 | [ipf] ipnat doesn't work with INET6 kernel opti
12 problems total for which you should take action.
From bugzilla-noreply at freebsd.org Mon Oct 6 08:00:03 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Oct 2014 08:00:02 +0000
Subject: [FreeBSD Bugzilla] Commit Needs MFC
Message-ID: <201410060800.s968022B050977@kenobi.freebsd.org>
Hi,
You have a bug in the "Needs MFC" state which has not been touched in 7 or more days. This email serves as a reminder that you may want to MFC this bug or marked it as completed.
In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days.
This reminder is only sent on Mondays. Please file a bug about concerns you may have.
This search was scheduled by eadler at FreeBSD.org.
(11 bugs)
Bug 155028:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=155028
Severity: Affects Only Me
Priority: Normal
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: init(8): "init q" in single user causes segfault
Bug 156481:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156481
Severity: Affects Only Me
Priority: Normal
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: [kernel] [patch] kernel incorrectly reports PPS jitter with accurate measurements
Bug 165630:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=165630
Severity: Affects Only Me
Priority: Normal
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: [ndis][panic][patch] IRQL_NOT_GREATER_THAN
Bug 167133:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167133
Severity: Affects Only Me
Priority: Normal
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: stale files in /usr/share/examples
Bug 169471:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169471
Severity: Affects Only Me
Priority: Normal
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: [patch] pw(8) deletes group "username" on userdel even if group "username" is not assoc. w/user "username"
Bug 171779:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171779
Severity: Affects Only Me
Priority: Normal
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: [patch] passwd(1): make option NO_FSCHG incomplete
Bug 181155:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181155
Severity: Affects Only Me
Priority: Normal
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: [libc] [patch] *access*(2) does not handle invalid amodes properly
Bug 184681:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184681
Severity: Affects Only Me
Priority: Normal
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: A bug of bsdconfig(8) in 10.0 RC1
Bug 190186:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190186
Severity: Affects Only Me
Priority: Normal
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: [patch] i915 driver: enable opregion handling
Bug 192730:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192730
Severity: Affects Some People
Priority: ---
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: [build] make checkdpadd failures with LD* variables being added to LDADD
Bug 192760:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192760
Severity: Affects Some People
Priority: ---
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: [build] sbin/ifconfig: missing DPADD for LIBM
From bugzilla-noreply at freebsd.org Mon Oct 6 09:49:11 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Oct 2014 09:49:11 +0000
Subject: [Bug 194180] New: [panic] [zfs] Bio not on queue
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194180
Bug ID: 194180
Summary: [panic] [zfs] Bio not on queue
Product: Base System
Version: 10.1-BETA3
Hardware: amd64
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: dev at vlsi.se
Created attachment 148026
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148026&action=edit
Kernel dump summary
Occurs intermittent related to destroying zfs pool, adding zfs spares and
adding zfs caches.
panic: Bio not on queue bp=0xfffff800098a66c8 target 0xffffffff814c0518
Unread portion of the kernel message buffer:
panic: Bio not on queue bp=0xfffff800098a66c8 target 0xffffffff814c0518
cpuid = 0
KDB: stack backtrace:
#0 0xffffffff8090c770 at kdb_backtrace+0x60
#1 0xffffffff808d3b96 at vpanic+0x126
#2 0xffffffff808d3a69 at kassert_panic+0x139
#3 0xffffffff80839ac0 at g_bioq_first+0x80
#4 0xffffffff80839c48 at g_io_schedule_up+0x88
#5 0xffffffff8083a24d at g_up_procbody+0x7d
#6 0xffffffff808a2c04 at fork_exit+0x84
#7 0xffffffff80cbc9ce at fork_trampoline+0xe
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Oct 6 14:48:08 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Oct 2014 14:48:08 +0000
Subject: [Bug 186293] tar(1): Problems with tar on FreeBSD 10.0
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186293
--- Comment #6 from jnaughto at ee.ryerson.ca ---
Hi All,
I can confirm Martin's NFS traces. I installed a brand new Solaris 11.2
server. I didn't configure anything except networking. Exported /var/mnt from
the Solaris 11.2 server to a Freebsd 10.0 client and got the following traces:
Freebsd 10.0 Client NFSv3 Request:
NFS: ----- Sun NFS -----
NFS:
NFS: Proc = 2 (Set file attributes)
NFS: File handle = [FBA3]
NFS: 1E59EFB108C388D40A00200000000000F8B80 5000A0004000000000052E40100
NFS: Mode = 0644
NFS: Setuid = 0, Setgid = 0, Sticky = 0
NFS: Owner's permissions = rw-
NFS: Group's permissions = r--
NFS: Other's permissions = r--
NFS: User ID = (not set)
NFS: Group ID = (not set)
NFS: Size = (not set)
NFS: Access time = 02-Oct-14 14:47:23.000000 GMT (set to client time)
NFS: Modification time = 02-Oct-14 14:47:23.000000 GMT (set to client time)
Solaris 11.2 NFS Server Response
NFS: ----- Sun NFS -----
NFS:
NFS: Proc = 2 (Set file attributes)
NFS: Status = 0 (OK)
NFS: Pre-operation attributes:
NFS: Size = 0 bytes
NFS: Modification time = 10-Oct-78 12:33:23.1364841573 GMT
NFS: Attribute change time = 02-Oct-14 10:47:57.031549787 GMT
NFS:
NFS: Post-operation attributes:
NFS: File type = 1 (Regular File)
NFS: Mode = 00
NFS: Setuid = 0, Setgid = 0, Sticky = 0
NFS: Owner's permissions = ---
NFS: Group's permissions = ---
NFS: Other's permissions = ---
NFS: Link count = 1, User ID = 0, Group ID = 0
NFS: File size = 0, Used = 512
NFS: Special: Major = 4294967295, Minor = 4294967295
NFS: File system id = 1198295941134, File id = 32
NFS: Last access time = 02-Oct-14 14:47:23.000000000 GMT
NFS: Modification time = 02-Oct-14 14:47:23.000000000 GMT
NFS: Attribute change time = 02-Oct-14 10:47:57.038686069 GMT
Freebsd 8.0 Client
NFS: ----- Sun NFS -----
NFS:
NFS: Proc = 2 (Set file attributes)
NFS: File handle = [27D9]
NFS: 1E59EFB108C388D40A0021000000000025C205000A0004000000000052E40100
NFS: Mode = 0644
NFS: Setuid = 0, Setgid = 0, Sticky = 0
NFS: Owner's permissions = rw-
NFS: Group's permissions = r--
NFS: Other's permissions = r--
NFS: User ID = (not set)
NFS: Group ID = (not set)
NFS: Size = (not set)
NFS: Access time = (set to server time)
NFS: Modification time = (set to server time)
Solaris 11.2 NFS Server response
NFS: ----- Sun NFS -----
NFS:
NFS: Proc = 2 (Set file attributes)
NFS: Status = 0 (OK)
NFS: Pre-operation attributes:
NFS: Size = 0 bytes
NFS: Modification time = 13-Nov-87 14:32:33.2130706433 GMT
NFS: Attribute change time = 02-Oct-14 14:03:35.971683411 GMT
NFS:
NFS: Post-operation attributes:
NFS: File type = 1 (Regular File)
NFS: Mode = 0644
NFS: Setuid = 0, Setgid = 0, Sticky = 0
NFS: Owner's permissions = rw-
NFS: Group's permissions = r--
NFS: Other's permissions = r--
NFS: Link count = 1, User ID = 0, Group ID = 0
NFS: File size = 0, Used = 512
NFS: Special: Major = 4294967295, Minor = 4294967295
NFS: File system id = 1198295941134, File id = 33
NFS: Last access time = 02-Oct-14 14:03:35.979188718 GMT
NFS: Modification time = 02-Oct-14 14:03:35.979188834 GMT
NFS: Attribute change time = 02-Oct-14 14:03:35.979237259 GMT
So it looks like (to me) that with FreeBSD 8.0 it would send set file
attributes in one request and set access time/modification time in a follow up
request. As of FreeBSD 9.0 and onwards the FreeBSD client sends a file mode
request and access time request in one packet. Solaris is responding OK in
with respect to the access time and modification time change but ignoring the
file mode additional change. You can see in the FreeBSD 8.0 the Access
time/Modification time is not set in the mode change. Any way we can go back
to doing this again? Right now NFSv3 is broken until this gets resolved.
I own a Oracle Contract support right now so I've also filed a ticket with
them. Yet this issue seems to be not prevalent with linux or Solaris Clients.
For example a Scientfic Linux Client 6.3 and Solaris 11.2 response was the
following:
Scientfic Linux NFS Client 6.3
NFS: ----- Sun NFS -----
NFS:
NFS: Proc = 2 (Set file attributes)
NFS: File handle = [07A3]
NFS: 1E59EFB108C388D40A001F00000000003BB805000A0004000000000052E40100
NFS: Mode = 0644
NFS: Setuid = 0, Setgid = 0, Sticky = 0
NFS: Owner's permissions = rw-
NFS: Group's permissions = r--
NFS: Other's permissions = r--
NFS: User ID = (not set)
NFS: Group ID = (not set)
NFS: Size = (not set)
NFS: Access time = (do not set)
NFS: Modification time = (do not set)
Solaris 11.2 NFS Server Response
NFS: ----- Sun NFS -----
NFS:
NFS: Proc = 2 (Set file attributes)
NFS: Status = 0 (OK)
NFS: Pre-operation attributes:
NFS: Size = 0 bytes
NFS: Modification time = 05-Sep-14 21:14:33.000000000 GMT
NFS: Attribute change time = 02-Oct-14 10:32:12.444447250 GMT
NFS:
NFS: Post-operation attributes:
NFS: File type = 1 (Regular File)
NFS: Mode = 0644
NFS: Setuid = 0, Setgid = 0, Sticky = 0
NFS: Owner's permissions = rw-
NFS: Group's permissions = r--
NFS: Other's permissions = r--
NFS: Link count = 1, User ID = 1061, Group ID = 2500
NFS: File size = 0, Used = 512
NFS: Special: Major = 4294967295, Minor = 4294967295
NFS: File system id = 1198295941134, File id = 31
NFS: Last access time = 02-Oct-14 14:33:15.191601635 GMT
NFS: Modification time = 05-Sep-14 21:14:33.000000000 GMT
NFS: Attribute change time = 02-Oct-14 10:32:12.457265934 GMT
So it looks like both Linux and FreeBSD pre 9.X does not have the issue. The
question is it legal to request both modification time changes and mode changes
within the same packet? What happens if you could change the mode but not the
access time what would you expect to get back from the server Status NOT OK?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Oct 6 15:11:54 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Oct 2014 15:11:54 +0000
Subject: [Bug 181448] [mlxen] [patch] Using sysctl for mlxen stats might
crash the kernel.
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181448
John Baldwin changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jhb at FreeBSD.org
Assignee|freebsd-bugs at FreeBSD.org |hselasky at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Oct 6 16:45:03 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Oct 2014 16:45:03 +0000
Subject: [Bug 193873] [PATCH] Unify dumpsys() under generic kern_dump.c.
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193873
--- Comment #7 from Ed Maste ---
https://reviews.freebsd.org/D904
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Oct 6 18:10:05 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Oct 2014 18:10:06 +0000
Subject: [Bug 193660] [PATCH] Fix build of IA-32 but not i686 systems (e.g.
alix)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193660
John Baldwin changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |jhb at FreeBSD.org
--- Comment #1 from John Baldwin ---
We can actually use a simpler test as I686_CPU is never defined on amd64 (so
can just check for that and ignore amd64 entirely). Thanks for the report,
sorry about the breakage.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Oct 6 18:15:20 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Oct 2014 18:15:20 +0000
Subject: [Bug 194173] Timezones (zoneinfo) starting from October 2014 wrong
for Russia, etc
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194173
--- Comment #3 from leo at sai.msu.ru ---
Also, this problem may cause application errors. For example:
[XXX at YYY ~]# freebsd-upgrade fetch
...
[XXX at YYY ~]# freebsd-upgrade install
...
[XXX at YYY ~]# pkg upgrade
...
[XXX at YYY ~]# date +'%d.%m.%Y %H:%M:%S %Z'
27.10.2014 12:30:00 MSK
[XXX at YYY ~]# TZ=Europe/Moscow date +'%d.%m.%Y %H:%M:%S %Z'
27.10.2014 12:30:06 MSK
[XXX at YYY ~]# php -r '
date_default_timezone_set("Europe/Moscow");
echo date("r e\n");'
Mon, 27 Oct 2014 11:30:21 +0300 Europe/Moscow
[XXX at YYY ~]# ruby -e "require 'tzinfo' ;
puts TZInfo::Timezone.get('Europe/Moscow').strftime('%d.%m.%Y %H:%M:%S %Z')"
27.10.2014 11:30:33 MSK
libc localtime may differ from localtime ruby, php and others with
unpredictable consequences
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Oct 6 18:15:56 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Oct 2014 18:15:56 +0000
Subject: [Bug 194197] New: IGB cards need a kernel option to enable legacy
mode (to support ALTQ)
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194197
Bug ID: 194197
Summary: IGB cards need a kernel option to enable legacy mode
(to support ALTQ)
Product: Base System
Version: 10.1-BETA3
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: dan_256 at yahoo.com
Created attachment 148039
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148039&action=edit
Adds IGB_LEGACY_TX and IXGBE_LEGACY_TX to kernel options
IGB cards still do not support ALTQ, except in "legacy" mode, since FreeBSD
7/8. To enable legacy mode, patching of the kernel source is required. There
is no official documentation on how to patch source, although reading between
the lines on various forums would point you in the right direction.
I created the attached patch to enable legacy mode in IGB driver through a
kernel option, rather than a patch. A similar patch needs to be created for
IXGBE.
Because of bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053, IXGBE
will not compile with the kernel option set, but IGB will. Still, there should
be a way to enable this option for IXGBE, even if it does not currently
compile.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Oct 6 18:17:24 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Oct 2014 18:17:24 +0000
Subject: [Bug 194025] [PATCH] nscd set query timeout properly
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194025
--- Comment #1 from commit-hook at freebsd.org ---
A commit references this bug:
Author: jhb
Date: Mon Oct 6 18:16:46 UTC 2014
New revision: 272668
URL: https://svnweb.freebsd.org/changeset/base/272668
Log:
Properly set the timeout in a query_state. The global query_timeout
configuration value is an integer count of seconds, it is not a timeval.
Using memcpy() to copy a timeval from it put garbage into the tv_usec
field.
PR: 194025
Submitted by: David Shane Holden
MFC after: 1 week
Changes:
head/usr.sbin/nscd/query.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Oct 6 18:33:20 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Oct 2014 18:33:20 +0000
Subject: [Bug 194025] [PATCH] nscd set query timeout properly
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194025
John Baldwin changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Needs Triage |Needs MFC
CC| |jhb at FreeBSD.org
Assignee|freebsd-bugs at FreeBSD.org |jhb at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Oct 6 18:49:55 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Oct 2014 18:49:54 +0000
Subject: [Bug 194063] [uefi] installer fails to boot / kernel panic on HP
Probook 430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #19 from Oliver Pinter ---
Created attachment 148041
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148041&action=edit
fbsd10rc1 uefi hybrid mode with csm
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Oct 6 18:50:33 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Oct 2014 18:50:33 +0000
Subject: [Bug 194063] [uefi] installer fails to boot / kernel panic on HP
Probook 430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #20 from Oliver Pinter ---
Created attachment 148042
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148042&action=edit
fbsd10rc1 uefi native mode without csm
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Oct 6 21:28:16 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Oct 2014 21:28:16 +0000
Subject: [Bug 194204] New: getentropy(2): sys call from openbsd
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194204
Bug ID: 194204
Summary: getentropy(2): sys call from openbsd
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: david.carlier at hardenedbsd.org
Created attachment 148045
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148045&action=edit
Proposed patch
it is a proposed simple FreeBSD version of the OpenBSD's
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Oct 7 03:16:24 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Oct 2014 03:16:24 +0000
Subject: [Bug 194209] New: ahciems should be optional
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194209
Bug ID: 194209
Summary: ahciems should be optional
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: ngie at FreeBSD.org
The code in sys/dev/ahci.c automatically detects whether or not a device has
AHCI_CAP_EMS support, then automatically loads the ahciem device. The ahciem
device should instead be loaded in the default kernel as a dependency of ahci.
310 if (ctlr->caps & AHCI_CAP_EMS) {
311 child = device_add_child(dev, "ahciem", -1);
312 if (child == NULL)
313 device_printf(dev, "failed to add enclosure device\n");
314 else
315 device_set_ivars(child, (void *)(intptr_t)-1);
316 }
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Oct 7 04:49:10 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Oct 2014 04:49:09 +0000
Subject: [Bug 194204] getentropy(2): sys call from openbsd
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194204
--- Comment #1 from David CARLIER ---
For reference
https://github.com/HardenedBSD/hardenedBSD/commit/c5406ea8467a89f3335c60d84dd11701177485fd
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Oct 7 06:35:45 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Oct 2014 06:35:45 +0000
Subject: [Bug 194209] ahciems should be optional
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194209
--- Comment #1 from Alexander Motin ---
Not sure I understand your proposition. Do you want ahciem to be separate
module, or do you want some tunable to disable it, or something else?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Oct 7 09:22:30 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Oct 2014 09:22:29 +0000
Subject: [Bug 186861] [PATCH] bsdgrep(1): xzgrep(1) sometimes doesn't find
matches it should find
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186861
Gavin Atkinson changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gavin at FreeBSD.org
Severity|Affects Only Me |Affects Some People
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Oct 7 10:55:03 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Oct 2014 10:55:03 +0000
Subject: [Bug 193925] CPU-frequeny scaling does not work on FSC Futro S400
thin-client
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193925
Andreas Glaeser changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bugs.andreas.glaeser at freene
| |t.de
--- Comment #1 from Andreas Glaeser ---
Try out my current Debian-image for Futro S400 or any 32-bit PC:
(Downloaded file may need to be renamed in order to get matching checksums)
Instant-Debian image for thin-clients
---------------------------------------
Image-download-link:
https://storage.demo.synnefo.org/public/YTXni05cyUpEHf9oUE5dw5
Cucumber-flavoured instant Linux, just add water ...
====================================================
This is the legacy version of my instant-wheezy image.
It should be workable for most 32-bit PCs, most thin-clients with or
without PAE, and it also should work with any NIC, or in virtual machines.
The most common criticism about Debian stable is the outdated software,
so backported packages were pinned to be preferred over otherwise stable
versions, and the default 3.2-kernel was removed.
Minimum hardware requirements are: 256 MB RAM, 512 MB recommended, 400
MHz i486-CPU, 16 GB CompactFlash or bootable USB2.
Instructions:
-Extract the image, then dd it on CompactFlash-card or onto
USB2-memory-stick:
$ unxz instant-wheezy-32-de-bpo.img.xz
$ dd if=instant-wheezy-32-de-bpo.img of=/dev/sdx
-in order to use Privoxy from localhost, basic configuration is
required, example files are provided.
-then configure the browser to use localhost on port 8118 as proxy for
both HTTP and HTTPS.
-when using it as web-proxy from the LAN, typically a static IP has to
be set for the server and the listen-address accordingly.
instant-wheezy-32-de-bpo.img.xz
===============================
md5sum: 4a41fa6c59153aa0fa944791b52bd38c
sha256sum: 9e68dbb39d81cca6c283398cde505bcde8809f5be7431276f427ee4b0c08bd69
file size: 1974881212 bytes
uncompresed: 15931539456 bytes
root-pw: wheezy
user-pw: user
===============================
Included Packages:
linux-image-3.16-0.bpo.2-486
linux-image-3.16-0.bpo.2-686-pae
iceweasel release 31.1
task-xfce-desktop
task-lxde-desktop
liferea
abiword
gnumeric
streamtuner2
streamripper
audacious
vlc
rhythmbox
icedove esr
enigmail
iceowl-extension
claws-mail
claws-mail-spam-report
claws-mail-pgpmime
claws-mail-pgpinline
gnupg2
seahorse
privoxy
xul-ext-adblock-plus
iceweasel-adblock-plus
midori
epiphany-browser
browser-plugin-vlc
hardinfo
gparted
pidgin
pidgin-microblog
transmission
remmina
imagemagick
TODO:
-make metapackage for easier setup
-make 64-bit version
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Oct 7 13:26:38 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Oct 2014 13:26:38 +0000
Subject: [Bug 194217] New: netstat -F bug in 10.1
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194217
Bug ID: 194217
Summary: netstat -F bug in 10.1
Product: Base System
Version: 10.1-BETA3
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Many People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: hunreal at gmail.com
# netstat -rnF 1
Routing tables (fib: 1)
netstat: sysctl: net.route.0.0.dump.1: Cannot allocate memory
# uname -a
FreeBSD us.hshh.org 10.1-RC1 FreeBSD 10.1-RC1 #0 r272565: Sun Oct 5 14:53:02
UTC 2014 root at us.hshh.org:/usr/obj/usr/src/sys/hshh amd64
It works while using `setfib 1 netstat -rn`.
There are also other people got this bug,
https://forums.freebsd.org/viewtopic.php?f=7&t=46972 .
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Oct 7 16:18:36 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Oct 2014 16:18:34 +0000
Subject: [Bug 194225] New: double fault after page fault on 8.4 Stable
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194225
Bug ID: 194225
Summary: double fault after page fault on 8.4 Stable
Product: Base System
Version: 8.4-RELEASE
Hardware: i386
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: longwitz at incore.de
On a server running 8.4-STABLE #0 r268802 i386 I got the following double fault
and need help to debug this, because I like to know the reason (hardware or
software ?). The server runs FreeBSD for many years without any problems:
Fatal double fault:
eip = 0xc0910b45
esp = 0xc75cbc30
ebp = 0xc75cbc30
cpuid = 1; apic id = 01
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 06
fault virtual address = 0x0
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc092fd4e
stack pointer = 0x28:0xea85c7d8
frame pointer = 0x28:0xea85c7e0
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = resume, IOPL = 0
current process = 20528 (sh)
timeout stopping cpus
[thread pid 20528 tid 100522 ]
Stopped at bcopy+0x1a: repe movsl (%esi),%es:(%edi)
db:0:kdb.enter.default> watchdog
No argument provided, disabling watchdog
db:0:kdb.enter.default> run ddbinfo
db:1:ddbinfo> capture on
db:1:on> run lockinfo
db:2:lockinfo> show lock Giant
class: sleep mutex
name: Giant
flags: {DEF, RECURSE}
state: {UNOWNED}
db:2:Giant> show lockedvnods
Locked vnodes
db:2:lockedvnods> show lockchain
thread 100522 (pid 20528, sh) running on CPU 2
db:2:lockchain> show sleepchain
thread 100522 (pid 20528, sh) running on CPU 2
db:1:sleepchain> show pcpu
cpuid = 2
dynamic pcpu = 0x6b71200
curthread = 0xcafb3b80: pid 20528 "sh"
curpcb = 0xea85cd80
fpcurthread = none
idlethread = 0xc79355c0: tid 100004 "idle: cpu2"
APIC ID = 6
currentldt = 0x50
db:1:pcpu> show allpcpu
Current CPU: 2
cpuid = 0
dynamic pcpu = 0x1df200
curthread = 0xcb825000: pid 20527 "tifftopnm"
curpcb = 0xeac84d80
fpcurthread = none
idlethread = 0xc7935000: tid 100006 "idle: cpu0"
APIC ID = 0
currentldt = 0x50
cpuid = 1
dynamic pcpu = 0x6b6e200
curthread = 0xc79352e0: pid 11 "idle: cpu1"
curpcb = 0xc75cbd80
fpcurthread = none
idlethread = 0xc79352e0: tid 100005 "idle: cpu1"
APIC ID = 1
currentldt = 0x50
cpuid = 2
dynamic pcpu = 0x6b71200
curthread = 0xcafb3b80: pid 20528 "sh"
curpcb = 0xea85cd80
fpcurthread = none
idlethread = 0xc79355c0: tid 100004 "idle: cpu2"
APIC ID = 6
currentldt = 0x50
cpuid = 3
dynamic pcpu = 0x6b74200
curthread = 0xc79358a0: pid 11 "idle: cpu3"
curpcb = 0xc75c5d80
fpcurthread = none
idlethread = 0xc79358a0: tid 100003 "idle: cpu3"
APIC ID = 7
currentldt = 0x50
db:1:allpcpu> bt
Tracing pid 20528 tid 100522 td 0xcafb3b80
bcopy(ea85cdc0,0,200) at bcopy+0x1a
savectx(4,ea85c8a8,c09328b6,cafb3b80,50,...) at savectx+0x63
ipi_nmi_handler(cafb3b80,50,33,0,cf52b000,...) at ipi_nmi_handler+0x2f
trap(ea85c8b4) at trap+0x36
calltrap() at calltrap+0x6
--- trap 0x13, eip = 0xc0927bb2, esp = 0xea85c8f4, ebp = 0xea85c91c ---
smp_tlb_shootdown(ea85c944,c09299bf,c5e6f000,c5e70000,0,...) at
smp_tlb_shootdown+0xd2
smp_invlpg_range(c5e6f000,c5e70000,0,ea85c964,1,...) at smp_invlpg_range+0x1c
pmap_invalidate_range(c0adb8a0,c5e6f000,c5e70000) at pmap_invalidate_range+0x4f
pmap_qremove(c5e6f000,1,c06ed30a,c8261d9c,cafb3b80,...) at pmap_qremove+0x58
pmap_remove_pages(cce9b0b0,cf52b000,ea85cbb4,0,c0a1fbc0,...) at
pmap_remove_pages+0x410
exec_new_vmspace(ea85cbb4,c0a31c20,8,c826bd48,80,...) at exec_new_vmspace+0x1b0
exec_elf32_imgact(ea85cbb4,ea85cbfc,c09b88e7,cafb3b80,50,...) at
exec_elf32_imgact+0x48e
kern_execve(cafb3b80,ea85cc48,0,883024b4,8830250c,e4c17000,e4c17000,e4c170b3,e4c17264,e4c57400,3fd9c,8,e,0)
at kern_execve+0x541
execve(cafb3b80,ea85ccec,c,c,c,...) at execve+0x4c
syscall(ea85cd28) at syscall+0x342
Xint0x80_syscall() at Xint0x80_syscall+0x21
--- syscall (59, FreeBSD ELF32, execve), eip = 0x88169c2b, esp = 0xbfbfe9bc,
ebp = 0xbfbfe9d8 ---
db:1:bt> ps
pid ppid pgrp uid state wmesg wchan cmd
20528 29408 62482 993 R CPU 2 sh
20527 20526 3552 993 RL CPU 0 tifftopnm
20526 3749 3552 993 S wait 0xca80b560 initial thread
19983 3099 26 0 S nanslp 0xc0a77c04 sleep
20578 2917 2917 125 S kqread 0xca258180 initial thread
3749 3552 3552 993 S wait 0xcd17e560 sh
3552 3550 3552 993 Ss wait 0xc8607810 sh
.................
db:1:ps> show thread
Thread 100522 at 0xcafb3b80:
proc (pid 20528): 0xcf52b000
name: sh
stack: 0xea85b000-0xea85cfff
flags: 0x4 pflags: 0
state: RUNNING (CPU 2)
priority: 180
container lock: sched lock 2 (0xc0a7c900)
db:1:thread> alltrace
Tracing command sh pid 20528 tid 100522 td 0xcafb3b80
bcopy(ea85cdc0,0,200) at bcopy+0x1a
savectx(4,ea85c8a8,c09328b6,cafb3b80,50,...) at savectx+0x63
ipi_nmi_handler(cafb3b80,50,33,0,cf52b000,...) at ipi_nmi_handler+0x2f
trap(ea85c8b4) at trap+0x36
calltrap() at calltrap+0x6
--- trap 0x13, eip = 0xc0927bb2, esp = 0xea85c8f4, ebp = 0xea85c91c ---
smp_tlb_shootdown(ea85c944,c09299bf,c5e6f000,c5e70000,0,...) at
smp_tlb_shootdown+0xd2
smp_invlpg_range(c5e6f000,c5e70000,0,ea85c964,1,...) at smp_invlpg_range+0x1c
pmap_invalidate_range(c0adb8a0,c5e6f000,c5e70000) at pmap_invalidate_range+0x4f
pmap_qremove(c5e6f000,1,c06ed30a,c8261d9c,cafb3b80,...) at pmap_qremove+0x58
pmap_remove_pages(cce9b0b0,cf52b000,ea85cbb4,0,c0a1fbc0,...) at
pmap_remove_pages+0x410
exec_new_vmspace(ea85cbb4,c0a31c20,8,c826bd48,80,...) at exec_new_vmspace+0x1b0
exec_elf32_imgact(ea85cbb4,ea85cbfc,c09b88e7,cafb3b80,50,...) at
exec_elf32_imgact+0x48e
kern_execve(cafb3b80,ea85cc48,0,883024b4,8830250c,e4c17000,e4c17000,e4c170b3,e4c17264,e4c57400,3fd9c,8,e,0)
at kern_execve+0x541
execve(cafb3b80,ea85ccec,c,c,c,...) at execve+0x4c
syscall(ea85cd28) at syscall+0x342
Xint0x80_syscall() at Xint0x80_syscall+0x21
--- syscall (59, FreeBSD ELF32, execve), eip = 0x88169c2b, esp = 0xbfbfe9bc,
ebp = 0xbfbfe9d8 ---
Tracing command tifftopnm pid 20527 tid 100845 td 0xcb825000
cpustop_handler(1,eac849fc,c09328b6,1,eac849a8,...) at cpustop_handler+0x34
ipi_nmi_handler(1,eac849a8,c062a16b,c7bca000,cb1d6560,...) at
ipi_nmi_handler+0x2f
trap(eac84a08) at trap+0x36
calltrap() at calltrap+0x6
--- trap 0x13, eip = 0xc06ecd99, esp = 0xeac84a48, ebp = 0xeac84a60 ---
_mtx_lock_sleep(c0a94ce4,cb825000,0,0,0,...) at _mtx_lock_sleep+0x79
pmap_enter(ca507198,88326000,2,c28a2120,3,...) at pmap_enter+0x66
vm_fault(ca5070e8,88326000,2,8,eac84c70,...) at vm_fault+0x1c14
trap_pfault(0,eac84cc8,c062a16b,c7bca000,cb1d6560,...) at trap_pfault+0x1ce
trap(eac84d28) at trap+0x263
calltrap() at calltrap+0x6
--- trap 0xc, eip = 0x880d5cdd, esp = 0xbfbfb640, ebp = 0xbfbfb698 ---
Tracing command perl5.14.2 pid 20526 tid 100278 td 0xcbc84b80
sched_switch(cbc84b80,0,104,3b38c51a,2123d7,...) at sched_switch+0x297
mi_switch(104,0,15c,ca80b560,ea3a5b70,...) at mi_switch+0x12f
sleepq_switch(cbc84b80,0,c09c15c1,1a3,cbc84b80,...) at sleepq_switch+0xcc
sleepq_catch_signals(15c,0,ea3a5bc4,c07073bc,ca80b560,...) at
sleepq_catch_signals+0x52
sleepq_wait_sig(ca80b560,5c,c09c1fa4,100,0,...) at sleepq_wait_sig+0x18
_sleep(ca80b560,ca80b5e8,15c,c09c1fa4,0,...) at _sleep+0x2bc
kern_wait(cbc84b80,502f,ea3a5c64,0,0,...) at kern_wait+0xfa1
wait4(cbc84b80,ea3a5cec,c,c,c,...) at wait4+0x3b
syscall(ea3a5d28) at syscall+0x342
Xint0x80_syscall() at Xint0x80_syscall+0x21
--- syscall (7, FreeBSD ELF32, wait4), eip = 0x882a1c6b, esp = 0xbfbfeb2c, ebp
= 0xbfbfeb48 ---
I can give more information from ddb output and or the written kerneldump.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Oct 7 16:59:07 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Oct 2014 16:59:07 +0000
Subject: [Bug 194228] New: Looks like longstanding cut & paste error in
nand_generic.c
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194228
Bug ID: 194228
Summary: Looks like longstanding cut & paste error in
nand_generic.c
Product: Base System
Version: 10.1-BETA2
Hardware: arm
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: dhorwitt at cox.net
FBSDID("$FreeBSD: stable/10/sys/dev/nand/nand_generic.c 259371 2013-12-14
00:54:05Z ian $");
10.1-BETA2 from 20140925
Line 395:
chip_params->spare_bytes_per_page = le32dec(¶ms.spare_bytes_per_page);
should be
chip_params->spare_bytes_per_page = le16dec(¶ms.spare_bytes_per_page);
On my AT91SAM9G20-based system (EMAC SOM-9G20M, 64 MB SDRAM) onfi_is_blk_bad()
hung trying to malloc 0x20000040 bytes instead of 0x40.
Thanks; FBSD rocks!
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Oct 7 20:12:52 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Oct 2014 20:12:52 +0000
Subject: [Bug 186806] dhclient(8): cannot prepend ipv6 servers
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186806
Lars Engels changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |lme at FreeBSD.org
Severity|Affects Only Me |Affects Some People
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Oct 7 20:13:20 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Oct 2014 20:13:20 +0000
Subject: [Bug 186806] dhclient(8): cannot prepend ipv6 servers
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186806
--- Comment #1 from Lars Engels ---
Still true on a recent HEAD.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Oct 7 20:55:23 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Oct 2014 20:55:23 +0000
Subject: [Bug 194233] New: sysctl -a shouldn't be listing kern.msgbuf
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194233
Bug ID: 194233
Summary: sysctl -a shouldn't be listing kern.msgbuf
Product: Base System
Version: 10.0-RELEASE
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: wkoszek at freebsd.czest.pl
I use FreeBSD 10.0 release. For reviewing sysctl settings I typically use:
sysctl -a
It always showed the presence of ``kern.msgbuf'', but it never listed its
content. I verified with 9.1-STABLE.
In FreeBSD 10 kern.msgbuf's content is shown. As a result of showing some
garbage from prior invocations of ncurses-based programs sysctl -a causes my
console to get stuck.
I must do 'reset' to unstuck it.
I think kern.msgbuf should be hidden from sysctl -a.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Oct 7 23:41:44 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Oct 2014 23:41:44 +0000
Subject: [Bug 183655] FreeBSD 10 Beta2: bootup screen presents "Enter
passphrase" for disk encryption out of order, appears to hang at USB keyboard
enumeration
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183655
wkoszek at freebsd.czest.pl changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |wkoszek at freebsd.czest.pl
--- Comment #1 from wkoszek at freebsd.czest.pl ---
I confirm that I'm seeing this problem in FreeBSD 10-RELEASE too.
Basically it seemed to me as if system was stuck. I pressed "ENTER" and got:
GEOM_ELI: Wrong key for ada0p4. Tried left: 2.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Oct 7 23:41:58 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Oct 2014 23:41:58 +0000
Subject: [Bug 194234] New: [ixgbe] Update ixgbe to 2.5.27
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194234
Bug ID: 194234
Summary: [ixgbe] Update ixgbe to 2.5.27
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: Normal
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: ricera10 at gmail.com
CC: freebsd-net at FreeBSD.org
Created attachment 148084
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148084&action=edit
Core code patch
Core changes:
- Fix to IXGBE_LEGACY_TX so it builds properly
- Added commented-out options to Makefile for IXGBE_LEGACY_BUILD support,
for builds on FreeBSD 7/8. This hasn't been tested thoroughly, though.
- Wrap some counter(9) code in driver in __FreeBSD_version >= 1100036 defines
so that there is still stats support in older versions of FreeBSD
- Most of this is derived from r272227 for ixl/v(4)
- Move SIOCGI2C ioctl under __FreeBSD_version >= 1100036 define as well
- Two new device IDs
Shared code changes:
- Primarily changes to support upcoming 10 gig products and bug fixes.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Oct 7 23:42:28 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Oct 2014 23:42:28 +0000
Subject: [Bug 194234] [ixgbe] Update ixgbe to 2.5.27
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194234
Eric Joyner changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ricera10 at gmail.com
--- Comment #1 from Eric Joyner ---
Created attachment 148085
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148085&action=edit
Shared code patch
Attaching second patch
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 8 00:55:20 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Oct 2014 00:55:20 +0000
Subject: [Bug 193965] [zfs] zpool coredump on import
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193965
--- Comment #2 from will at worrbase.com ---
My kernel panics on boot were resolved after re-adding the cache and logging
devices. Does this mean that it's not safe to remove a log device on ZFS on
root?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 8 08:31:22 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Oct 2014 08:31:22 +0000
Subject: [Bug 194236] New: Hourly cron jobs running to early
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194236
Bug ID: 194236
Summary: Hourly cron jobs running to early
Product: Base System
Version: 10.0-RELEASE
Hardware: i386
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: uffe at uffe.org
Seen on FreeBSD 10.0-RELEASE-p9 i386
After upgrading from 9.2-RELEASE-p12 (i386) to 10.0-RELEASE-p9 (i386)
cron runs hourly jobs up to a minutte too early.
This causes tasks like newsyslog to skip logrotation at the intended time -
rotation will occour one hour delayed.
It has been discussed here:
http://lists.freebsd.org/pipermail/freebsd-stable/2014-June/079106.html
and is reported solved - but I'm seeing the problem on latest official patch
level (10.0-RELEASE-p9)
Note: This seems to be an i386 problem only - as the equivalent amd64
installations runs hourly cron at the exact time.
# uname -a
FreeBSD asuseee 10.0-RELEASE-p9 FreeBSD 10.0-RELEASE-p9 #0: Mon Sep 15 14:32:29
UTC 2014 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
i386
BEFORE upgrade (running 9.2-RELEASE-p12 (i386))
# cat /var/log/cron | grep newsyslog
Oct 5 13:00:00 smtpd /usr/sbin/cron[11742]: (root) CMD (newsyslog)
Oct 5 14:00:00 smtpd /usr/sbin/cron[12271]: (root) CMD (newsyslog)
Oct 5 15:00:00 smtpd /usr/sbin/cron[12995]: (root) CMD (newsyslog)
Oct 5 16:00:00 smtpd /usr/sbin/cron[13595]: (root) CMD (newsyslog)
Oct 5 17:00:00 smtpd /usr/sbin/cron[14654]: (root) CMD (newsyslog)
Oct 5 18:00:00 smtpd /usr/sbin/cron[15614]: (root) CMD (newsyslog)
Oct 5 19:00:00 smtpd /usr/sbin/cron[16319]: (root) CMD (newsyslog)
Oct 5 20:00:00 smtpd /usr/sbin/cron[17884]: (root) CMD (newsyslog)
Oct 5 21:00:00 smtpd /usr/sbin/cron[38642]: (root) CMD (newsyslog)
Oct 6 00:00:00 smtpd /usr/sbin/cron[20850]: (root) CMD (newsyslog)
AFTER upgrade (running 10.0-RELEASE-p9 (i386))
# cat /var/log/cron | grep newsyslog
Oct 6 00:59:42 smtpd /usr/sbin/cron[7632]: (root) CMD (newsyslog)
Oct 6 01:59:38 smtpd /usr/sbin/cron[6222]: (root) CMD (newsyslog)
Oct 6 02:59:34 smtpd /usr/sbin/cron[7616]: (root) CMD (newsyslog)
Oct 6 03:59:34 smtpd /usr/sbin/cron[9793]: (root) CMD (newsyslog)
Oct 6 04:59:38 smtpd /usr/sbin/cron[10369]: (root) CMD (newsyslog)
Oct 6 05:58:55 smtpd /usr/sbin/cron[10897]: (root) CMD (newsyslog)
Oct 6 06:59:34 smtpd /usr/sbin/cron[11420]: (root) CMD (newsyslog)
Oct 6 07:58:55 smtpd /usr/sbin/cron[11848]: (root) CMD (newsyslog)
Oct 6 08:59:51 smtpd /usr/sbin/cron[12478]: (root) CMD (newsyslog)
Oct 6 09:59:47 smtpd /usr/sbin/cron[12995]: (root) CMD (newsyslog)
Oct 6 10:58:42 smtpd /usr/sbin/cron[13733]: (root) CMD (newsyslog)
Oct 6 11:58:55 smtpd /usr/sbin/cron[14416]: (root) CMD (newsyslog)
Oct 6 12:59:34 smtpd /usr/sbin/cron[15188]: (root) CMD (newsyslog)
Oct 6 13:59:29 smtpd /usr/sbin/cron[15935]: (root) CMD (newsyslog)
Oct 6 14:59:38 smtpd /usr/sbin/cron[16440]: (root) CMD (newsyslog)
Oct 6 15:59:42 smtpd /usr/sbin/cron[17655]: (root) CMD (newsyslog)
Oct 6 16:59:47 smtpd /usr/sbin/cron[18513]: (root) CMD (newsyslog)
Oct 6 17:59:34 smtpd /usr/sbin/cron[19025]: (root) CMD (newsyslog)
Oct 6 18:59:47 smtpd /usr/sbin/cron[19916]: (root) CMD (newsyslog)
Oct 6 20:00:00 smtpd /usr/sbin/cron[20624]: (root) CMD (newsyslog)
Oct 6 20:59:29 smtpd /usr/sbin/cron[21680]: (root) CMD (newsyslog)
Oct 6 21:59:34 smtpd /usr/sbin/cron[22962]: (root) CMD (newsyslog)
Oct 6 22:59:38 smtpd /usr/sbin/cron[23582]: (root) CMD (newsyslog)
Oct 6 23:59:47 smtpd /usr/sbin/cron[24275]: (root) CMD (newsyslog)
Oct 7 00:59:47 smtpd /usr/sbin/cron[24988]: (root) CMD (newsyslog)
Oct 7 01:59:34 smtpd /usr/sbin/cron[25758]: (root) CMD (newsyslog)
Oct 7 02:59:21 smtpd /usr/sbin/cron[26291]: (root) CMD (newsyslog)
Oct 7 03:59:47 smtpd /usr/sbin/cron[28272]: (root) CMD (newsyslog)
Oct 7 05:00:00 smtpd /usr/sbin/cron[28715]: (root) CMD (newsyslog)
Oct 7 05:59:12 smtpd /usr/sbin/cron[29252]: (root) CMD (newsyslog)
Oct 7 06:58:46 smtpd /usr/sbin/cron[29821]: (root) CMD (newsyslog)
Oct 7 07:59:51 smtpd /usr/sbin/cron[30357]: (root) CMD (newsyslog)
Oct 7 08:59:34 smtpd /usr/sbin/cron[31222]: (root) CMD (newsyslog)
Oct 7 09:59:51 smtpd /usr/sbin/cron[31980]: (root) CMD (newsyslog)
Oct 7 10:59:47 smtpd /usr/sbin/cron[32710]: (root) CMD (newsyslog)
Oct 7 11:59:51 smtpd /usr/sbin/cron[33278]: (root) CMD (newsyslog)
Oct 7 12:59:55 smtpd /usr/sbin/cron[33832]: (root) CMD (newsyslog)
Oct 7 13:59:34 smtpd /usr/sbin/cron[34276]: (root) CMD (newsyslog)
Oct 7 14:59:51 smtpd /usr/sbin/cron[34833]: (root) CMD (newsyslog)
Oct 7 15:59:21 smtpd /usr/sbin/cron[35492]: (root) CMD (newsyslog)
Oct 7 16:58:42 smtpd /usr/sbin/cron[36213]: (root) CMD (newsyslog)
Oct 7 17:59:42 smtpd /usr/sbin/cron[37072]: (root) CMD (newsyslog)
Oct 7 18:59:47 smtpd /usr/sbin/cron[37958]: (root) CMD (newsyslog)
Oct 7 19:59:47 smtpd /usr/sbin/cron[38780]: (root) CMD (newsyslog)
Oct 7 20:59:12 smtpd /usr/sbin/cron[39330]: (root) CMD (newsyslog)
Oct 7 21:58:55 smtpd /usr/sbin/cron[40561]: (root) CMD (newsyslog)
Oct 7 22:59:55 smtpd /usr/sbin/cron[41477]: (root) CMD (newsyslog)
Oct 7 23:59:25 smtpd /usr/sbin/cron[47064]: (root) CMD (newsyslog)
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 8 08:31:35 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Oct 2014 08:31:35 +0000
Subject: [Bug 194236] Hourly cron jobs running to early
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194236
uffe at uffe.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|Affects Some People |Affects Many People
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 8 08:33:11 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Oct 2014 08:33:11 +0000
Subject: [Bug 194236] Hourly cron jobs running too early
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194236
uffe at uffe.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Hourly cron jobs running to |Hourly cron jobs running
|early |too early
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 8 08:54:38 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Oct 2014 08:54:38 +0000
Subject: [Bug 194236] Hourly cron jobs running too early
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194236
Andrey A. Chernov changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ache at FreeBSD.org
--- Comment #1 from Andrey A. Chernov ---
I can't reproduce this problem on i386 -stable (10.1-RC1)
My /var/cron/log show exact times.
Looks like cron is not updated, first check cron.c have svn version 261231.
Then try to run cron with -x for debugging and search for suspicious results,
see cron(8)
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 8 11:59:17 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Oct 2014 11:59:17 +0000
Subject: [Bug 194238] New: Ping attempted with MTU 9000 transmits fragmented
packets of size 1500
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194238
Bug ID: 194238
Summary: Ping attempted with MTU 9000 transmits fragmented
packets of size 1500
Product: Base System
Version: 10.0-RELEASE
Hardware: amd64
OS: Any
Status: Needs Triage
Severity: Affects Many People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: praveenchoudary.gokina at emulex.com
Setup Details:
Machine1:
OS: FreeBSD 10.0
We are using below Emulex skyhawk adapter.
oce3 at pci0:4:0:3: class=0x020000 card=0xe8fe10df chip=0x072010df rev=0x10
hdr=0x00
vendor = 'Emulex Corporation'
device = 'OneConnect NIC (Skyhawk)'
class = network
subclass = ethernet
bar [10] = type Prefetchable Memory, range 64, base 0xfa700000, size
16384, enabled
bar [18] = type Prefetchable Memory, range 64, base 0xfa620000, size
131072, enabled
bar [20] = type Prefetchable Memory, range 64, base 0xfa600000, size
131072, enabled
Machine2:
OS: FreeBSD 10.0
We are using below Emulex skyhawk adapter.
oce1 at pci0:5:0:1: class=0x020000 card=0xe80010df chip=0x072010df rev=0x10
hdr=0x00
vendor = 'Emulex Corporation'
device = 'OneConnect NIC (Skyhawk)'
class = network
subclass = ethernet
bar [10] = type Prefetchable Memory, range 64, base 0xfa780000, size
16384, enabled
bar [18] = type Prefetchable Memory, range 64, base 0xfa720000, size
131072, enabled
bar [20] = type Prefetchable Memory, range 64, base 0xfa700000, size
131072, enabled
Both the adapters are connected directly without switch.
Both the interfaces are configured with mtu=9000
When we send jumbo frames from machine1 to machine2, packets are getting
fragmented to 1500bytes.
To reproduce, we can use "ping -s 9000 " on Machine1.
tcpdump on Machine1 shows packets of length 1500 bytes.
We are observing this behavior even with other adapters like Intel
igb0 at pci0:2:0:0: class=0x020000 card=0x152115d9 chip=0x15218086 rev=0x01
hdr=0x00
vendor = 'Intel Corporation'
device = 'I350 Gigabit Network Connection'
class = network
subclass = ethernet
bar [10] = type Memory, range 32, base 0xfbc20000, size 131072, enabled
bar [18] = type I/O Port, range 32, base 0xe020, size 32, enabled
bar [1c] = type Memory, range 32, base 0xfbc44000, size 16384, enabled
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 8 14:41:32 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Oct 2014 14:41:32 +0000
Subject: [Bug 186293] tar(1): Problems with tar on FreeBSD 10.0
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186293
--- Comment #7 from jnaughto at ee.ryerson.ca ---
I got my response back from Oracle with respect to this issue. This is what
they had to say:
--------------------------- Oracle's SR Response
-----------------------------------
Hi Jason,
I tried to extract a tar file to a NFSv3 share from a Solaris 11 client. Below
is the part of snoop while NFS created the file on share.
client: 10.163.223.163
server: 10.163.209.210
bash-3.2# snoop -r -i net2.cap.1 -p 32,33
32 0.00000 10.163.223.163 -> 10.163.209.210 NFS C CREATE3 FH=0599 (GUARDED)
vnet.log
33 0.00026 10.163.209.210 -> 10.163.223.163 NFS R CREATE3 OK FH=5A3B
Above snoop showed the client sent create request to server. Below are the
expanded snoops containing detailed information on NFS.
Packet 32:
Client sent create file request with proper acl information on file.
NFS: ----- Sun NFS -----
NFS:
NFS: Proc = 8 (Create file)
NFS: File handle = [0599]
NFS: 059000020000000B000A0000093A918C00000000000A0000093A918C00000000
NFS: File name = vnet.log
NFS: Method = Guarded
NFS: Mode = 0644
NFS: Setuid = 0, Setgid = 0, Sticky = 0
NFS: Owner's permissions = rw-
NFS: Group's permissions = r--
NFS: Other's permissions = r--
NFS: User ID = (not set)
NFS: Group ID = 0
NFS: Size = 0
NFS: Access time = (do not set)
NFS: Modification time = (do not set)
NFS:
NFS:
Packet 33:
Server create the file with correct acl:
NFS: ----- Sun NFS -----
NFS:
NFS: Proc = 8 (Create file)
NFS: Status = 0 (OK)
NFS: File handle = [5A3B]
NFS: 059000020000000B000A00002D6EEA350000004F000A0000093A918C00000000
NFS: Post-operation attributes:
NFS: File type = 1 (Regular File)
NFS: Mode = 0644
NFS: Setuid = 0, Setgid = 0, Sticky = 0
NFS: Owner's permissions = rw-
NFS: Group's permissions = r--
NFS: Other's permissions = r--
NFS: Link count = 1, User ID = 4294967294, Group ID = 4294967294
NFS: File size = 0, Used = 0
NFS: Special: Major = 4294967295, Minor = 4294967295
NFS: File system id = 1529008357378, File id = 762243637
NFS: Last access time = 08-Oct-14 01:38:13.152404410 GMT
NFS: Modification time = 08-Oct-14 01:38:13.152404410 GMT
NFS: Attribute change time = 08-Oct-14 01:38:13.152404410 GMT
NFS:
NFS: Pre-operation attributes:
NFS: Size = 790 bytes
NFS: Modification time = 08-Oct-14 01:37:35.189977830 GMT
NFS: Attribute change time = 08-Oct-14 01:37:35.189977830 GMT
NFS:
NFS: Post-operation attributes:
NFS: File type = 2 (Directory)
NFS: Mode = 01777
NFS: Setuid = 0, Setgid = 0, Sticky = 1
NFS: Owner's permissions = rwx
NFS: Group's permissions = rwx
NFS: Other's permissions = rwx
NFS: Link count = 7, User ID = 0, Group ID = 3
NFS: File size = 855, Used = 8192
NFS: Special: Major = 0, Minor = 0
NFS: File system id = 1529008357378, File id = 154833292
NFS: Last access time = 08-Oct-14 01:38:05.372080530 GMT
NFS: Modification time = 08-Oct-14 01:38:13.152486310 GMT
NFS: Attribute change time = 08-Oct-14 01:38:13.152486310 GMT
NFS:
NFS:
Let's compare the same operation in the snoop taken on FreeBSD.
Below are the packets doing this job.
bash-3.2$ snoop -i mole-eccles2.snoop -p 17,18
17 0.00000 dhcp-whq2op4-172-16-20-63.us.voip.oraclecorp.com ->
dhcp-whq2op4-172-16-20-68.us.voip.oraclecorp.com NFS C CREATE3 FH=71FF
(EXCLUSIVE) BOB
18 0.00679 dhcp-whq2op4-172-16-20-68.us.voip.oraclecorp.com ->
dhcp-whq2op4-172-16-20-63.us.voip.oraclecorp.com NFS R CREATE3 OK FH=FBA3
Pakcet 17:
Client sent request to create file, however with no acl information.
NFS: ----- Sun NFS -----
NFS:
NFS: Proc = 8 (Create file)
NFS: File handle = [71FF]
NFS: 1E59EFB108C388D40A0004000000000052E401000A0004000000000052E40100
NFS: File name = BOB
NFS: Guard = 5159D4651080B693
NFS:
Packet 18:
As a consequence, server doesn't know how to set acl on the new file. The
option left is to put blank on it.
NFS: ----- Sun NFS -----
NFS:
NFS: Proc = 8 (Create file)
NFS: Status = 0 (OK)
NFS: File handle = [FBA3]
NFS: 1E59EFB108C388D40A00200000000000F8B805000A0004000000000052E40100
NFS: Post-operation attributes:
NFS: File type = 1 (Regular File)
NFS: Mode = 00
NFS: Setuid = 0, Setgid = 0, Sticky = 0
NFS: Owner's permissions = ---
NFS: Group's permissions = ---
NFS: Other's permissions = ---
NFS: Link count = 1, User ID = 0, Group ID = 0
NFS: File size = 0, Used = 512
NFS: Special: Major = 4294967295, Minor = 4294967295
NFS: File system id = 1198295941134, File id = 32
NFS: Last access time = 02-Oct-14 10:47:57.031549787 GMT
NFS: Modification time = 10-Oct-78 12:33:23.1364841573 GMT
NFS: Attribute change time = 02-Oct-14 10:47:57.031549787 GMT
NFS:
NFS: Pre-operation attributes:
NFS: Size = 2 bytes
NFS: Modification time = 05-Sep-14 21:14:33.000000000 GMT
NFS: Attribute change time = 02-Oct-14 10:47:57.022257425 GMT
NFS:
NFS: Post-operation attributes:
NFS: File type = 2 (Directory)
NFS: Mode = 0755
NFS: Setuid = 0, Setgid = 0, Sticky = 0
NFS: Owner's permissions = rwx
NFS: Group's permissions = r-x
NFS: Other's permissions = r-x
NFS: Link count = 2, User ID = 1061, Group ID = 2500
NFS: File size = 3, Used = 1536
NFS: Special: Major = 4294967295, Minor = 4294967295
NFS: File system id = 1198295941134, File id = 4
NFS: Last access time = 02-Oct-14 14:47:23.000000000 GMT
NFS: Modification time = 02-Oct-14 10:47:57.031876316 GMT
NFS: Attribute change time = 02-Oct-14 10:47:57.031876316 GMT
NFS:
NFS:
It looks like the issue happened while the file was being created. FreeBSD
should have given correct acl to server but for some reason it didn't. I guess
this is more like a FreeBSD issue. Can you try the same test with another NFS
client other than FreeBSD?
------------------------------------------------------------------
So as I kinda expected the Oracle Engineers pointed the issue back to FreeBSD
with what appears to be strong evidence that the FreeBSD NFS client code is not
functioning properly.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 8 14:52:25 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Oct 2014 14:52:25 +0000
Subject: [Bug 186293] tar(1): Problems with tar on FreeBSD 10.0
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186293
--- Comment #8 from jnaughto at ee.ryerson.ca ---
Now the somewhat good news. So after getting the SR report back from Oracle
I started to dive into the FreeBSD NFS client code. So this is what I
modified and how I got the issue (which seems to be) resolved.
On my FreeBSD 10 station:
# uname -a
FreeBSD NFSCLIENT 10.1-BETA1 FreeBSD 10.1-BETA1 #4 r271672M: Tue Oct 7
16:52:00 EDT 2014 NFSCLIENT:/usr/obj/usr/src/sys/GENERIC amd64
I edited the files: nfs_subs.c
NFSCLIENT:/usr/src/sys/nfsclient # ls
nfs.h nfs_krpc.c nfs_subs.c nfsargs.h nfsnode.h
nfs_bio.c nfs_nfsiod.c nfs_vfsops.c nfsm_subs.h nfsstats.h
nfs_kdtrace.c nfs_node.c nfs_vnops.c nfsmount.h nlminfo.h
I commented out the following lines in this file
if (va->va_atime.tv_sec != VNOVAL) {
// if ((va->va_vaflags & VA_UTIMES_NULL) == 0) {
// tl = nfsm_build_xx(3 * NFSX_UNSIGNED, mb, bpos);
// *tl++ = txdr_unsigned(NFSV3SATTRTIME_TOCLIENT);
// txdr_nfsv3time(&va->va_atime, tl);
// } else {
tl = nfsm_build_xx(NFSX_UNSIGNED, mb, bpos);
*tl = txdr_unsigned(NFSV3SATTRTIME_TOSERVER);
// }
I also blocked out the following:
// if ((va->va_vaflags & VA_UTIMES_NULL) == 0) {
// tl = nfsm_build_xx(3 * NFSX_UNSIGNED, mb, bpos);
// *tl++ = txdr_unsigned(NFSV3SATTRTIME_TOCLIENT);
// txdr_nfsv3time(&va->va_mtime, tl);
// } else {
tl = nfsm_build_xx(NFSX_UNSIGNED, mb, bpos);
*tl = txdr_unsigned(NFSV3SATTRTIME_TOSERVER);
// }
How I read this is if the vaflags are set to NULL then let the NFS server set
the atime and mtime based on the server's Clock. We're not done yet. To use
this code you also seem to have to mount the filesystem with the "oldnfs" flag.
For example in my /etc/fstab I have:
NFSSERVER:/var/mnt /mnt oldnfs rw,soft 0 0
Now once I re-compiled the FreeBSD kernel to take the above changes into
account and of course mount the filesystem with the "oldnfs" flags in place the
problems (for what I see) went away. For example:
NFSCLIENT:/# mount /mnt
NFSCLIENT:/# mount
NFSSERVER:/var/mnt on /mnt (oldnfs)
NFSCLIENT:/# cd /mnt
NFSCLIENT:/mnt# tar xf ~user/foo.tar
Now foo.tar has only one file in it BOB which has perms of 0644. Now doing a
directory listing:
# ls -l
NFSCLIENT:/mnt # ls -l
total 1
-rw-r--r-- 1 user group 0 Oct 8 10:28 BOB
So far so good. Now this seems to resolve my problem right now but I'm not
sure whether or not this is going to open up other problems in the future.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 8 16:47:00 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Oct 2014 16:47:00 +0000
Subject: [Bug 194250] New: c_size() function parses terabyte sized files
incorrectly due to incorrect scale factor
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194250
Bug ID: 194250
Summary: c_size() function parses terabyte sized files
incorrectly due to incorrect scale factor
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: turingsboy at yahoo.com
In usr.bin/find/function.c in c_size() function, when parsing
terabyte sized files, it incorrectly thinks 1 TB is 64 GB.
case 'T': /* terabytes 1<<40 */
scale = 0x1000000000LL;
...
0x1000000000 bytes = 64GB
The correct code should read:
...
case 'T': /* terabytes 1<<40 */
scale = 0x10000000000LL;
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 8 17:31:51 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Oct 2014 17:31:51 +0000
Subject: [Bug 194250] c_size() function parses terabyte sized files
incorrectly due to incorrect scale factor
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194250
Ed Maste changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |emaste at freebsd.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 8 21:28:00 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Oct 2014 21:27:59 +0000
Subject: [Bug 194256] New: [cam] xptpdrvtraverse spins and deadlocks CAM
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194256
Bug ID: 194256
Summary: [cam] xptpdrvtraverse spins and deadlocks CAM
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Many People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: smferris at gmail.com
Created attachment 148117
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148117&action=edit
cam_xpt.diff
Change periph to next_periph inside of a couple of loops, so that the loops
skip over periphs that have CAM_PERIPH_FREE set, rather than spin forever and
deadlock CAM by never releasing a mutex. Looks like a copy&paste bug from some
other loops that iterated over periph rather than next_periph.
Sponsored-by: EMC/Isilon Storage Division
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 8 22:57:01 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Oct 2014 22:57:01 +0000
Subject: [Bug 186806] dhclient(8): cannot prepend ipv6 servers
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186806
Andrey V. Elsukov changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ae at FreeBSD.org
--- Comment #2 from Andrey V. Elsukov ---
dhclient(8) supports only DHCP protocol, for DCHPv6 you should use some another
software.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 8 23:31:53 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Oct 2014 23:31:53 +0000
Subject: [Bug 194258] New: CSTD idiom doesn't exist for CXXFLAGS
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194258
Bug ID: 194258
Summary: CSTD idiom doesn't exist for CXXFLAGS
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: conf
Assignee: freebsd-bugs at FreeBSD.org
Reporter: ngie at FreeBSD.org
CSTD sets -std= in CFLAGS, but not CXXFLAGS. It should do it for both (the
reason why I didn't commit a change immediately is that it requires discussion
and testing via a ports tinderbox).
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 01:50:39 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 01:50:39 +0000
Subject: [Bug 194236] Hourly cron jobs running too early
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194236
--- Comment #2 from uffe at uffe.org ---
It took some time as I had to perform an upgrade on a similar i386 appliance
not running production.
I can verify that the problem seems to be fixed on 10.1-RC1 i386 - here cron
again runs as it should.
A pity that the fix wasn't back-ported to one of the 10.0-RELEASE-px
patch-releases - the effect of the problem seems serious enough for that.
Anyway this case can be closed.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 02:05:47 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 02:05:47 +0000
Subject: [Bug 194173] Timezones (zoneinfo) starting from October 2014 wrong
for Russia, etc
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194173
--- Comment #4 from vas at mpeks.tomsk.su ---
I think outdated timezone information is a critical condition affecting many
installations in various ways, so the updated timezone files should make it
into the security branch, be available via freebsd-update etc. as a critical
update.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 02:07:25 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 02:07:25 +0000
Subject: [Bug 194173] Timezones (zoneinfo) starting from October 2014 wrong
for Russia, etc
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194173
--- Comment #5 from vas at mpeks.tomsk.su ---
And yes, we have a precedent set by
https://www.freebsd.org/security/advisories/FreeBSD-EN-07:04.zoneinfo.asc
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 03:45:49 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 03:45:49 +0000
Subject: [Bug 194236] Hourly cron jobs running too early
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194236
Andrey A. Chernov changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Needs Triage |Issue Resolved
Resolution|--- |FIXED
--- Comment #3 from Andrey A. Chernov ---
Close per submitter request.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 05:54:37 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 05:54:37 +0000
Subject: [Bug 194256] [cam] xptpdrvtraverse spins and deadlocks CAM
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194256
--- Comment #1 from commit-hook at freebsd.org ---
A commit references this bug:
Author: mav
Date: Thu Oct 9 05:53:59 UTC 2014
New revision: 272805
URL: https://svnweb.freebsd.org/changeset/base/272805
Log:
Use proper variable when looping through periphs with CAM_PERIPH_FREE.
PR: 194256
Submitted by: Scott M. Ferris
MFC after: 3 days
Sponsored by: EMC/Isilon Storage Division
Changes:
head/sys/cam/cam_xpt.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 05:54:46 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 05:54:46 +0000
Subject: [Bug 194256] [cam] xptpdrvtraverse spins and deadlocks CAM
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194256
Alexander Motin changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Needs Triage |Issue Resolved
Resolution|--- |FIXED
--- Comment #2 from Alexander Motin ---
Good catch. Committed.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 06:49:38 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 06:49:39 +0000
Subject: [Bug 194258] CSTD idiom doesn't exist for CXXFLAGS
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194258
--- Comment #1 from Dimitry Andric ---
Since the standard names for C and C++ are different, you cannot really use the
CSTD variable. I would suggest using CXXSTD, which is consistent with all the
other "CXX" prefixes.
The available options should probably be:
* c++98
* gnu++98
* c++03
* gnu++03
* c++0x
* gnu++0x
* c++11
* gnu++11
* c++1y
* gnu++1y
* c++14 (these are only available from clang 3.5 and higher)
* gnu++14
Although the usefulness of the 03, 0x and 1y 'standards' is debatable, at least
for the base system. For ports, all of these should obviously be available.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 08:29:06 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 08:29:06 +0000
Subject: [Bug 194264] New: crash in unp_gc -> unp_accessable
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194264
Bug ID: 194264
Summary: crash in unp_gc -> unp_accessable
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: avg at FreeBSD.org
Created attachment 148131
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148131&action=edit
kgdb postmortem session
First, I think that this panic could be related to a crash of chromium process
that preceded it. Perhaps the crash triggered closing of sockets and that
interacted badly with unp_gc code.
Unread portion of the kernel message buffer:
<6>pid 48502 (chrome), uid 1001: exited on signal 11 (core dumped)
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x100000021
fault code = supervisor read data, page not present
...
(kgdb) bt
#0 doadump (textdump=1) at pcpu.h:223
#1 0xffffffff8063d9fd in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:445
#2 0xffffffff8063df3f in panic (fmt=) at
/usr/src/sys/kern/kern_shutdown.c:621
#3 0xffffffff80861f4f in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:866
#4 0xffffffff8086229c in trap_pfault (frame=0xfffffe01dd5d89e0,
usermode=) at /usr/src/sys/amd64/amd64/trap.c:677
#5 0xffffffff808618be in trap (frame=0xfffffe01dd5d89e0) at
/usr/src/sys/amd64/amd64/trap.c:426
#6 0xffffffff808623f7 in trap_check (frame=) at
/usr/src/sys/amd64/amd64/trap.c:620
#7 0xffffffff80845122 in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:231
#8 0xffffffff806d6668 in unp_gc (arg=0x10, pending=32) at
/usr/src/sys/kern/uipc_usrreq.c:2152
#9 0xffffffff8068f465 in taskqueue_run_locked (queue=0xfffff80012294600) at
/usr/src/sys/kern/subr_taskqueue.c:371
#10 0xffffffff80690258 in taskqueue_thread_loop (arg=) at
/usr/src/sys/kern/subr_taskqueue.c:642
#11 0xffffffff80605a1a in fork_exit (callout=0xffffffff80690190
, arg=0xffffffff80ee17c0, frame=0xfffffe01dd5d8c00) at
/usr/src/sys/kern/kern_fork.c:977
#12 0xffffffff8084565e in fork_trampoline () at
/usr/src/sys/amd64/amd64/exception.S:605
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 08:42:45 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 08:42:45 +0000
Subject: [Bug 194264] crash in unp_gc -> unp_accessable
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194264
--- Comment #1 from Andriy Gapon ---
Created attachment 148132
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148132&action=edit
some more debug data
Not sure if this is important but so_state is SS_ISDISCONNECTED | SS_NBIO |
SS_NOFDREF, so_rcv.sb_state is SBS_CANTRCVMORE.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 10:12:52 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 10:12:52 +0000
Subject: [Bug 194264] crash in unp_gc -> unp_accessable
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194264
--- Comment #2 from Andriy Gapon ---
Created attachment 148136
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148136&action=edit
log of other thread being in sofree -> unp_dispose
So, looks like I missed an elephant in the room. There was a thread that was
running soclose -> sofree -> unp_dispose on exactly the same socket that
unp_gc_process was processing. The socket is 0xfffff801e7420000 (see the
previous attachment).
So, this is the race.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 10:16:30 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 10:16:30 +0000
Subject: [Bug 194264] race between unp_dispose (called from sofree) and unp_gc
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194264
Andriy Gapon changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|crash in unp_gc -> |race between unp_dispose
|unp_accessable |(called from sofree) and
| |unp_gc
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 11:20:50 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 11:20:50 +0000
Subject: [Bug 193152] mlxen driver problem with MT26448 interface
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193152
--- Comment #5 from gnoma ---
Hello,
Disabling TSO did the trick, now it's working normaly with iSCSI.
No issues. However with the driver provided by mellanox I didn't have this
issue.
Without TSO I got only a little more CPU load? Or it will interrupt other
stuff?
Thank you.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 11:29:27 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 11:29:27 +0000
Subject: [Bug 194268] New: Sementation fault on kaveri
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194268
Bug ID: 194268
Summary: Sementation fault on kaveri
Product: Base System
Version: 10.1-BETA3
Hardware: amd64
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: misc
Assignee: freebsd-bugs at FreeBSD.org
Reporter: reto.haeuptli at infinox.ch
Created attachment 148138
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148138&action=edit
Preprocessed source and script
When I try to build my kaveri based system with make -j5 buildworld, I get this
error message:
4.
/usr/src/usr.bin/clang/clang/../../../contrib/llvm/include/llvm/Option/ArgList.h:28:1:
parsing struct/union/class body 'arg_iterator'
c++: error: unable to execute command: Segmentation fault (core dumped)
c++: error: clang frontend command failed due to signal (use -v to see
invocation)
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.1
Thread model: posix
c++: note: diagnostic msg: PLEASE submit a bug report to
https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed
source, and associated run script.
c++: note: diagnostic msg:
********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
c++: note: diagnostic msg: /tmp/cc1_main-917e0f.cpp
c++: note: diagnostic msg: /tmp/cc1_main-917e0f.sh
c++: note: diagnostic msg:
********************
Parts of dmesg:
...
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
CPU: AMD A10-7850K APU with Radeon(TM) R7 Graphics (3693.36-MHz K8-class CPU)
Origin = "AuthenticAMD" Id = 0x630f01 Family = 0x15 Model = 0x30 Stepping
= 1
Features=0x178bfbff
Features2=0x3e98320b
AMD Features=0x2e500800
AMD
Features2=0xfebbfff,DBE,PTSC>
Structured Extended Features=0x9
TSC: P-state invariant, performance statistics
real memory = 34359738368 (32768 MB)
avail memory = 32162037760 (30672 MB)
...
This bug happens every second time when i try to build the system.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 14:12:35 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 14:12:35 +0000
Subject: [Bug 193927] saslauthd Broken By Recent MFC
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193927
Dag-Erling Sm??rgrav changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|In Discussion |Issue Resolved
CC| |des at FreeBSD.org
Resolution|--- |FIXED
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 17:17:55 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 17:17:55 +0000
Subject: [Bug 194173] Timezones (zoneinfo) starting from October 2014 wrong
for Russia, etc
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194173
Xin LI changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Needs Triage |Open
CC| |delphij at FreeBSD.org
Assignee|freebsd-bugs at FreeBSD.org |re at FreeBSD.org
--- Comment #6 from Xin LI ---
re@ will issue an errata for this.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 18:34:09 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 18:34:09 +0000
Subject: [Bug 193152] mlxen driver problem with MT26448 interface
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193152
--- Comment #6 from Edward Tomasz Napierala ---
Just a CPU load. Could you check if the problem persists in 10.1-RC1? There
were some significant TSO fixes.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 18:45:01 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 18:45:01 +0000
Subject: [Bug 190103] [build] makeoptions COPTFLAGS= is not used for kernel
modules
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190103
Navdeep Parhar changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |np at FreeBSD.org
Severity|Affects Only Me |Affects Some People
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 20:52:59 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 20:52:59 +0000
Subject: [Bug 192184] [uefi] fresh install of 2014-07-14 11.0-CURRENT amd64
snapshot doesn't boot
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192184
Pablo Olmos de Aguilera C. changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bugs at odac.co
--- Comment #14 from Pablo Olmos de Aguilera C. ---
>> An older FreeBSD boot .img had been dd'd to another disk partition.
>> It turns out that UEFI code will pick up the first available image
>> it recognises and boots from that, and not the loader.efi and
>> loader.conf etc in the same EFI location at boot1.efi or similar.
>> This would be worth addressing.
> Ahh, yes. Sorry this tripped you up.
>
> boot1.efi finds the first available UFS filesystem and loads loader.efi from
> here. You can skip boot1.efi altogether if you like, and just but loader.efi
> and the .4th and config files in your EFI system partition, but you'll then
> need to explicitly set currdev to load the kernel.
I'm finding a similar issue, but loading boot1.efi just get me:
>> FreeBSD EFI boot block
Loader path: /boot/loader.efi
panic: No bootable partition found
I guess that's because my system doesn't have any UFS partition, because I have
a freebsd-boot partition, and my root is on zfs. I tried to load.efi, but it
says the kernel is wrong and drop me into a loader console that works very
weird (characters get added, if I write "show", sometimes say "sh" not found,
or inserts random characters "shkokw". I tried to copy loader.4th over there,
but still nothing happens... even worse, it seems that after adding .4th not
even the `set` command is being recognized.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 21:22:35 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 21:22:35 +0000
Subject: [Bug 194279] New: teach dumpsys / savecore to use dumpdev's sectorsize
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194279
Bug ID: 194279
Summary: teach dumpsys / savecore to use dumpdev's sectorsize
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: rpokala at panasas.com
>From freebsd-hackers@, thread "Seeking reviewers for patch; PR 193873"[0]:
As mentioned in another thread ([1], [2]), I'm looking at dumping on systems w/
AF-4Kn drives (on a fairly old version of FreeBSD). Unfortunately, I'm not at
all familiar w/ the process. I'm going to pick at it a few more days, but will
probably end up having to punt and dumpsys onto a 512n or AF-512e device. But,
since you are refactoring all this code in -CURRENT anyway, I think it would be
awesome if you could look to the future and make it work w/o assuming that dump
device block size is DEV_BSIZE; it would be better to use the sector size, as
returned (for example) by ioctl(DIOCGSECTORSIZE).
[0]
https://lists.freebsd.org/pipermail/freebsd-hackers/2014-October/046217.html
[1]
https://lists.freebsd.org/pipermail/freebsd-hackers/2014-September/046164.html
[2]
https://lists.freebsd.org/pipermail/freebsd-hackers/2014-October/046181.html
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 21:27:22 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 21:27:22 +0000
Subject: [Bug 194279] teach dumpsys / savecore to use dumpdev's sectorsize
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194279
rpokala at panasas.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |conrad.meyer at isilon.com,
| |rpokala at panasas.com
See Also| |https://bugs.freebsd.org/bu
| |gzilla/show_bug.cgi?id=1938
| |73
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 22:03:22 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 22:03:22 +0000
Subject: [Bug 191348] [mps] LSI2308 with WD3000FYYZ drives disappears after
hotswapping
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191348
--- Comment #10 from Stephen McConnell ---
Created attachment 148149
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148149&action=edit
Spinup wait sysctl change
Michal, sorry about the delay in getting back to you on this. I have made a
new patch for this that I'd like you to try before I get it reviewed and commit
the fix. It's the spinup_wait.patch file. There is is new sysctl variable that
you can use to set the spinup wait time (default is 3 seconds), and you should
be able to see the wait message if you set the XINFO bit in the debug level
(assuming a wait is required). After you let me know your results I'll get it
reviewed by a couple other people before I commit it.
Thanks,
Steve
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 9 22:06:49 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Oct 2014 22:06:49 +0000
Subject: [Bug 191348] [mps] LSI2308 with WD3000FYYZ drives disappears after
hotswapping
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191348
Stephen McConnell changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Needs Triage |Patch Ready
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 10 06:20:31 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 10 Oct 2014 06:20:31 +0000
Subject: [Bug 193152] mlxen driver problem with MT26448 interface
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193152
--- Comment #7 from gnoma ---
I am sorry, this is a production system and I can't upgrade or reinstall the
OS. I have a spare system, but I can't remove the 10GB LAN card from the
production one :(
There's no way that I can test it until the next maintenance window - the next
3 mounts.
Sorry :(
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 10 07:26:47 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 10 Oct 2014 07:26:47 +0000
Subject: [Bug 192184] [uefi] fresh install of 2014-07-14 11.0-CURRENT amd64
snapshot doesn't boot
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192184
--- Comment #15 from Dave Cottlehuber ---
@pablo I'm successfully booting direct from ZFS, here's what I learned:
1. it must be a UEFI-enabled boot image (10.1 pre-releases are good)
2. zfs must have a dataset with mountpoint=/ and your usual /boot/* stuff in
here. Note this is not actually where the kernel will be loaded from, but it's
where I keep the master copy so it's safely versioned on zfs.
3. the zpool* must have property bootfs set to point to that dataset, for
example my default bootfs is:
bootfs=zroot/ROOT/default
4. you must have a FAT-style EFI partition, with the kernel modules & all boot
loader stuff in it. I am not exactly sure if there's a way to trim this down
and have a smaller set. You *must* copy this across from within FreeBSD, I was
unable to boot FreeBSD if I used either a linux system to transfer, or OSX --
the FAT 8.3 path mangling screwed things up.
I keep the master of /boot in ZFS but rsync it across to the EFI partition. My
/boot/loader.conf is:
# cat /efi/boot/loader.conf
# master in zfs:/boot/loader.conf but
# actually loaded from /EFI FAT partition
# remember to keep settings mirrored
# mkdir -m 0700 /efi
# mount -f msdosfs /dev/diskid/DISK-Z1F21XGNp1 /efi
# rsync -harv /boot /efi/boot --exclude=\*.symbols --del --partial --inplace
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
kern.vty="vt"
zfs_load="YES"
vfs.root.mountfrom="zfs:zroot/ROOT/default"
my EFI partition is (directories only):
# tree -qcd
.
??? boot
??? ??? defaults
??? ??? kernel
??? ??? modules
??? ??? zfs
??? ??? firmware
??? EFI
??? APPLE
??? ??? EXTENSIONS
??? ??? FIRMWARE
??? ??? CACHES
??? ??? CAFEBEEF
??? refind
??? icons
??? drivers_x64
??? tools_x64
As this is still a mac there is apple cruft in here. Working on getting rid of
that. This might be better discussed on one of the mailing lists BTW rather
than in a resolved ticket ;-).
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 10 18:17:20 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 10 Oct 2014 18:17:20 +0000
Subject: [Bug 194291] New: grdc shows 12 AM at noon
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194291
Bug ID: 194291
Summary: grdc shows 12 AM at noon
Product: Base System
Version: 10.0-RELEASE
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: mlsemon35 at gmail.com
Created attachment 148175
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148175&action=edit
patch to let grdc show PM instead of AM during the 12 PM hour
When I use `grdc -t`, it shows 12:00:00 AM at noon. I keep dragging this patch
along and using it. IOW, I patch it like this:
cd /usr/src/games/grdc
patch < grdc-noon-patch.diff
I don't know when this became the case, or whether I noticed it first in
FreeBSD 9.2 or in 10.0.
Thanks!
Michael
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 10 19:02:35 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 10 Oct 2014 19:02:35 +0000
Subject: [Bug 191936] ttyname_r failing isatty always returns ENOTTY instead
of the actual error
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191936
--- Comment #1 from commit-hook at freebsd.org ---
A commit references this bug:
Author: ngie
Date: Fri Oct 10 19:02:03 UTC 2014
New revision: 272903
URL: https://svnweb.freebsd.org/changeset/base/272903
Log:
FreeBSD returns ENOTTY instead of EBADF in ttyname_r; mark it as an expected
failure
PR: 191936
In collaboration with: pho
Sponsored by: EMC / Isilon Storage Division
Changes:
head/contrib/netbsd-tests/lib/libc/gen/t_ttyname.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 10 19:19:38 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 10 Oct 2014 19:19:38 +0000
Subject: [Bug 181127] [libc] [patch] set{domain,host}name doesn't permit NUL
terminated strings that are MAXHOSTNAMELEN long
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181127
--- Comment #4 from commit-hook at freebsd.org ---
A commit references this bug:
Author: ngie
Date: Fri Oct 10 19:18:53 UTC 2014
New revision: 272905
URL: https://svnweb.freebsd.org/changeset/base/272905
Log:
FreeBSD doesn't support strings greater than MAXHOSTNAMELEN-1 in
{get,set}{domain,host}name. Adjust the tests to not exceed that
value when testing out the code
Add a positive and negative test for MAXHOSTNAMELEN-1 and
MAXHOSTNAMELEN, respectively
PR: 181127
In collaboration with: pho
Sponsored by: EMC / Isilon Storage Division
Changes:
head/contrib/netbsd-tests/lib/libc/gen/t_setdomainname.c
head/contrib/netbsd-tests/lib/libc/gen/t_sethostname.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 10 19:32:07 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 10 Oct 2014 19:32:07 +0000
Subject: [Bug 189821] [libc] [patch] nice(3) on FreeBSD returns EACCES
instead of EPERM when provided negative prio's; is not compatible with
Linux/NetBSD/POSIX
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189821
Garrett Cooper changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|kern |bin
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 10 20:27:23 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 10 Oct 2014 20:27:23 +0000
Subject: [Bug 194292] New: Patch for adding firewall_myservices_tcp and
firewall_myservices_udp support to rc.conf
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194292
Bug ID: 194292
Summary: Patch for adding firewall_myservices_tcp and
firewall_myservices_udp support to rc.conf
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: conf
Assignee: freebsd-bugs at FreeBSD.org
Reporter: olivier at cochard.me
Created attachment 148177
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148177&action=edit
patch for adding firewall_myservices_udp to rc.conf
Settings firewall_myservices in etc/rc.conf permit to support only TCP
services.
This patch propose to add UDP services by 2 changes:
1. firewall_myservices became a deprecated alias, the new is
firewall_myservices_tcp
2. A new firewall_myservices_udp variable is added.
Patch to be apply to an up-to-date -current (tested on r272911).
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 10 20:30:25 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 10 Oct 2014 20:30:25 +0000
Subject: [Bug 194293] New: FUSE program freezes when seeking pos > file size
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194293
Bug ID: 194293
Summary: FUSE program freezes when seeking pos > file size
Product: Base System
Version: 10.1-BETA3
Hardware: amd64
OS: Any
Status: Needs Triage
Severity: Affects Many People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: nishida at asusa.net
This happens with both 10.1-RC1 and 9.3-Release.
I wrote a simple and straight forward file system program with FUSE.
It just does like:
open: open a file with the same name in a different directory
read: read a file with the same name in a different directory
write: write a file with the same name in a different directory
etc.
However, the program always freezes when saving a xcf file (Gimp's native
format) with Gimp.
Once it freezes, it cannot be killed even by shutdown.
Therefore, I always have to reset my PC after shutdown.
After investigating Gimp's source code, I found that this happened when Gimp
tried to fseek() a position greater than the file size.
In /usr/ports/graphics/gimp-app/work/gimp-2.8.10/app/xcf/xcf-seek.c, there is
xcf_seek_pos().
Adding
fstat(fd, &sb);
if (pos > sb.st_size) {
ftruncate(fd, pos);
}
to it solved the problem.
This is not only a FUSE's problem, but I guess it will be better to deal with
it.
Sincerely,
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 10 21:46:33 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 10 Oct 2014 21:46:33 +0000
Subject: [Bug 194293] FUSE program freezes when seeking pos > file size
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194293
--- Comment #1 from nishida at asusa.net ---
Created attachment 148181
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148181&action=edit
fseek test
Actually, I have noticed that the attached simple program also freezes my FUSE
program.
The program just fopen -> fseek(100) -> fwrite().
Please compile it and use for an EXISTING tiny file less than 100bytes like:
% test aaa
Interestingly, it does not freeze when aaa does not exist, in other words,
create() is called by FUSE.
It is only affected when an existing small file is specified.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 00:41:29 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 00:41:29 +0000
Subject: [Bug 194296] New: GNU binutils / ld(1): Be less obscure about
missing symbols/DSOs
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194296
Bug ID: 194296
Summary: GNU binutils / ld(1): Be less obscure about missing
symbols/DSOs
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: conrad.meyer at isilon.com
PR from Bryan Drewery:
" could not read symbols: Bad value"
It would be nice to fix our binutils to not be obscure here. It was fixed in
mor recent GPL versions, where they put "try adding -lname." ("Invalid DSO for
symbol," specifically.)
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 00:42:54 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 00:42:54 +0000
Subject: [Bug 194296] GNU binutils / ld(1): Be less obscure about missing
symbols/DSOs
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194296
Bryan Drewery changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |conrad.meyer at isilon.com
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 07:16:54 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 07:16:54 +0000
Subject: [Bug 194292] Patch for adding firewall_myservices_tcp and
firewall_myservices_udp support to rc.conf
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194292
Juan Ram?n Molina Menor changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |info at juanmolina.eu
--- Comment #1 from Juan Ram?n Molina Menor ---
You seem to have a typo (double initial ff) in line 151 of
/etc/defaults/rc.conf:
ffirewall_myservices_udp=""
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 07:40:24 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 07:40:24 +0000
Subject: [Bug 194292] Patch for adding firewall_myservices_tcp and
firewall_myservices_udp support to rc.conf
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194292
olivier at cochard.me changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #148177|0 |1
is obsolete| |
--- Comment #2 from olivier at cochard.me ---
Created attachment 148185
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148185&action=edit
patch for adding firewall_myservices_udp to rc.conf
fix the double "f" in etc/default/rc.conf
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 14:32:06 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 14:32:06 +0000
Subject: [Bug 194301] New: ssh-copy-id doesn't work on 10.1-RC2
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194301
Bug ID: 194301
Summary: ssh-copy-id doesn't work on 10.1-RC2
Product: Base System
Version: 10.1-BETA3
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: pkubaj at riseup.net
I use releng/10.1 at r272885. When I try to copy my private key with
'ssh-copy-id ~/.ssh/id_rsa.pub root at IP', I get:
Unmatched '.
Unmatched '.
Using ssh-copy-id in /usr/src/crypto/openssh/contrib/ seems to work.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 15:31:09 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 15:31:09 +0000
Subject: [Bug 42336] [patch] ISO-fication of /usr/src/contrib/tcp_wrappers:
fixes also PR#42327
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=42336
Pedro F. Giffuni changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #24810|0 |1
is obsolete| |
Attachment #24811|0 |1
is obsolete| |
Attachment #24812|0 |1
is obsolete| |
--- Comment #4 from Pedro F. Giffuni ---
Created attachment 148193
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148193&action=edit
Updated patch
The first two patches were bogus (no apparent change), and I don't find it
much use in dropping the __STDC__ . I did take the chance to cleanup somewhat
the spacing issues. This is pending testing.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 15:32:39 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 15:32:39 +0000
Subject: [Bug 42336] [patch] ISO-fication of /usr/src/contrib/tcp_wrappers
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=42336
Pedro F. Giffuni changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.freebsd.org/bu
| |gzilla/show_bug.cgi?id=4232
| |7
Summary|[patch] ISO-fication of |[patch] ISO-fication of
|/usr/src/contrib/tcp_wrappe |/usr/src/contrib/tcp_wrappe
|rs: fixes also PR#42327 |rs
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 15:59:35 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 15:59:35 +0000
Subject: [Bug 32808] [patch] tcpd.h lacks prototype for hosts_ctl
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=32808
Pedro F. Giffuni changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pfg at FreeBSD.org
--- Comment #4 from Pedro F. Giffuni ---
For reference, Illumos did this already
https://www.illumos.org/issues/4385
(with lots of other changes)
https://github.com/Nexenta/illumos-nexenta/commit/9b5f5885b666050a9ec3f0ff18de2c6bf4703232
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 16:40:17 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 16:40:17 +0000
Subject: [Bug 135718] [patch] enhance qsort(3) to properly handle 32-bit
aligned data on 64-bit systems
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=135718
Pedro F. Giffuni changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pfg at FreeBSD.org
--- Comment #2 from Pedro F. Giffuni ---
Created attachment 148195
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148195&action=edit
Updated diff
This is the same (latest) version but unencoded for easier examination.
Not the appropriate test but it does cause a small but measurable
improvement (user time) with:
/usr/src/tools/regression/lib/libc/stdlib/test-qsort
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 16:42:20 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 16:42:20 +0000
Subject: [Bug 135718] [patch] enhance qsort(3) to properly handle 32-bit
aligned data on 64-bit systems
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=135718
Pedro F. Giffuni changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #97013|0 |1
is obsolete| |
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 17:14:02 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 17:14:02 +0000
Subject: [Bug 42336] [patch] ISO-fication of /usr/src/contrib/tcp_wrappers
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=42336
--- Comment #5 from Pedro F. Giffuni ---
Created attachment 148196
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148196&action=edit
Updated patch
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 17:14:38 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 17:14:38 +0000
Subject: [Bug 42336] [patch] ISO-fication of /usr/src/contrib/tcp_wrappers
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=42336
Pedro F. Giffuni changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #148193|0 |1
is obsolete| |
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 17:58:41 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 17:58:40 +0000
Subject: [Bug 194304] New: gbde does not announce destroyed keys
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194304
Bug ID: 194304
Summary: gbde does not announce destroyed keys
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Many People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: mwlucas at michaelwlucas.com
One key feature of GBDE is that it's supposed to say "The passphrase exists,
but the key has been destroyed." This feature no longer works. (See the
discussion at
https://lists.freebsd.org/pipermail/freebsd-hackers/2014-October/046239.html)
Here's some examples:
# gbde nuke gpt/encrypted -l /etc/encrypted.lock -n -1
Enter passphrase:
Opened with key 0
Nuked key 0
Nuked key 1
Nuked key 2
Nuked key 3
# gbde attach gpt/encrypted -l /etc/encrypted.lock
Enter passphrase:
#
The .bde device isn't there, and my filesystem is gone. But I received
no confirmation that the keys were destroyed.
I also didn't get a message that the device couldn't be attached,
although it clearly isn't.
Let's try 'gbde destroy'.
# gbde init /dev/gpt/encrypted -L /etc/encrypted.lock
Enter new passphrase:
Reenter new passphrase:
# gbde destroy gpt/encrypted -l /etc/encrypted.lock
Enter passphrase:
Opened with key 0
# gbde attach gpt/encrypted -l /etc/encrypted.lock
Enter passphrase:
#
The device isn't attached, it just fails silently. And failing with a
specific complaint is the whole point of GBDE.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 18:34:39 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 18:34:39 +0000
Subject: [Bug 42336] [patch] ISO-fication of /usr/src/contrib/tcp_wrappers
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=42336
--- Comment #6 from commit-hook at freebsd.org ---
A commit references this bug:
Author: pfg
Date: Sat Oct 11 18:34:11 UTC 2014
New revision: 272949
URL: https://svnweb.freebsd.org/changeset/base/272949
Log:
tcpd: complete function prototypes.
This clears up at least a build issues on mysql-server
ports. While here also replace some spaces with tabs
in our headers.
PR: 42336
MFC after: 2 weeks
Changes:
head/contrib/tcp_wrappers/inetcf.h
head/contrib/tcp_wrappers/mystdarg.h
head/contrib/tcp_wrappers/tcpd.h
head/contrib/tcp_wrappers/tli-sequent.h
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 18:54:43 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 18:54:43 +0000
Subject: [Bug 32808] [patch] tcpd.h lacks prototype for hosts_ctl
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=32808
--- Comment #5 from commit-hook at freebsd.org ---
A commit references this bug:
Author: pfg
Date: Sat Oct 11 18:54:37 UTC 2014
New revision: 272950
URL: https://svnweb.freebsd.org/changeset/base/272950
Log:
tcpd.h: add prototype for hosts_ctl
According the hosts_access(3) man page the hosts_ctl() prototype
should be in tcpd.h. For now, follow other declarations and don't
add the arguments in the prototype.
Reference:
https://www.illumos.org/issues/4385
PR: 32808
MFC after: 2 weeks
Changes:
head/contrib/tcp_wrappers/tcpd.h
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 19:01:48 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 19:01:49 +0000
Subject: [Bug 42336] [patch] ISO-fication of /usr/src/contrib/tcp_wrappers
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=42336
Pedro F. Giffuni changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|In Discussion |Needs MFC
CC| |pfg at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 19:05:31 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 19:05:31 +0000
Subject: [Bug 32808] [patch] tcpd.h lacks prototype for hosts_ctl
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=32808
Pedro F. Giffuni changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|In Discussion |Needs MFC
See Also| |https://bugs.freebsd.org/bu
| |gzilla/show_bug.cgi?id=4233
| |6
--- Comment #6 from Pedro F. Giffuni ---
I kept the patch really simple but it should be enough for most applications.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 19:05:32 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 19:05:31 +0000
Subject: [Bug 42336] [patch] ISO-fication of /usr/src/contrib/tcp_wrappers
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=42336
Pedro F. Giffuni changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.freebsd.org/bu
| |gzilla/show_bug.cgi?id=3280
| |8
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 19:26:11 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 19:26:11 +0000
Subject: [Bug 169302] [libc] [patch] Applied MidnightBSD regex memory
consumption limits
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169302
Pedro F. Giffuni changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ngie at FreeBSD.org,
| |pfg at FreeBSD.org
--- Comment #3 from Pedro F. Giffuni ---
Added ngie@:
Hi Garrett,
I haven't been able to reproduce this locally. Perhaps you can reproduce this
test failure from the NetBSD tests?
http://cvsweb.netbsd.org/bsdweb.cgi/src/tests/lib/libc/regex/t_exhaust.c
Also verifying if the patch works would be good ;).
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 19:54:20 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 19:54:19 +0000
Subject: [Bug 194063] [uefi] installer fails to boot / kernel panic on HP
Probook 430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
Oliver Pinter changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.freebsd.org/bu
| |gzilla/show_bug.cgi?id=1874
| |88
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 22:26:03 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 22:26:03 +0000
Subject: [Bug 194063] [uefi] installer fails to boot / kernel panic on HP
Probook 430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #21 from Oliver Pinter ---
I can boot my 430, if I copied the 9.3 /boot/loader to installer (as troyax
mentioned in #187488) but only if I hit ESC and after it ENTER in first stage
loader.
Probably there are differences between gcc and clang generated /boot/loader.
I'm now investigating in this way.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 23:21:26 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 23:21:26 +0000
Subject: [Bug 194063] [uefi] installer fails to boot / kernel panic on HP
Probook 430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #22 from Oliver Pinter ---
Created attachment 148207
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148207&action=edit
mostly working loader from FreeBSD 9.3-RELEASE
added mostly working loader in legacy mode from FreeBSD 9.3-RELEASE
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 23:22:16 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 23:22:16 +0000
Subject: [Bug 194063] [uefi] installer fails to boot / kernel panic on HP
Probook 430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
--- Comment #23 from Oliver Pinter ---
Created attachment 148208
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148208&action=edit
broken loader from 11-CURRENT
broken loader in legacy mode from 11-CURRENT
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Oct 11 23:22:32 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Oct 2014 23:22:32 +0000
Subject: [Bug 194063] [uefi] installer fails to boot / kernel panic on HP
Probook 430 G1
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063
Oliver Pinter changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|Affects Only Me |Affects Some People
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Oct 12 02:43:50 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 12 Oct 2014 02:43:50 +0000
Subject: [Bug 194311] New: [ixgbe] DROP_EN needs to be set early to avoid RX
queue hanging
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194311
Bug ID: 194311
Summary: [ixgbe] DROP_EN needs to be set early to avoid RX
queue hanging
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: adrian at freebsd.org
>From Luigi Rizzo:
reviving this thread:
i am just running experiments on 10.1 beta3 and even
setting dev.ix.*.fc=0 and flipping the interface up and down
does not seem to help: if i read only from a subset of the
queues, the entire rx unit stalls eventually.
I need to drain all queues to keep moving.
Just tested this with 8 instances of netmap-ipfw running
on an 8-core machine (8 queues enabled).
netmap-ipfw netmap:ix0-0 netmap:ix1-0
netmap-ipfw netmap:ix0-1 netmap:ix1-1
...
and the source on another box is blasting on multiple queues with
pkt-gen -f tx -i ix0 -d 10.0.10.0-10.0.10.255
I going to look at the driver's code now to see if/how
this issue can be addressed.
...
don't have a way to test this on HEAD.
Do you know if there is any change that could be related ?
On 10.1 beta 3 I noticed is that when I open a single queue on an ixgbe
(and with incoming traffic), the rx unit stalls no matter what the
previous state of dev.ix.*.fc (i.e. the DROP_EN bits) or QDE are.
In this state, toggling DROP_EN has no effect, whereas something that seems
effective is setting the QDE bit(s) in the PFQDE register for all queues,
_after_ i open the device.
>From the above my take is the following:
- on NIC reset, the SRRCTL register starts at 0 including DROP_EN;
same goes for PFQDE.QDE
- setting SRRCTL.DROP_EN must happen before the receive unit is started;
- conversely, toggling PFQDE.QDE has effect even when the receive
unit has started
- sysctl dev.ix.*.fc sets/clear DROP_EN but at the wrong time
(the right time seems to be the window between reset and start)
I am going to run more tests to figure out.
cheers
...
Index: sys/dev/ixgbe/ixgbe.c
===================================================================
--- sys/dev/ixgbe/ixgbe.c (revision 272974)
+++ sys/dev/ixgbe/ixgbe.c (working copy)
@@ -4377,6 +4377,20 @@
srrctl &= ~IXGBE_SRRCTL_BSIZEPKT_MASK;
srrctl |= bufsz;
srrctl |= IXGBE_SRRCTL_DESCTYPE_ADV_ONEBUF;
+
+ /*
+ * Set DROP_EN iff we have no flow control and >1 queue.
+ * Note that srrctl was cleared shortly before during reset,
+ * so we do not need to clear the bit, but do it just in case
+ * this code is moved elsewhere.
+ */
+ if (adapter->num_queues > 1 &&
+ adapter->hw.fc.requested_mode == ixgbe_fc_none) {
+ srrctl |= IXGBE_SRRCTL_DROP_EN;
+ } else {
+ srrctl &= ~IXGBE_SRRCTL_DROP_EN;
+ }
+
IXGBE_WRITE_REG(hw, IXGBE_SRRCTL(i), srrctl);
/* Setup the HW Rx Head and Tail Descriptor Pointers */
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Oct 12 02:44:20 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 12 Oct 2014 02:44:21 +0000
Subject: [Bug 194311] [ixgbe] DROP_EN needs to be set early to avoid RX queue
hanging
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194311
Adrian Chadd changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Needs Triage |Open
CC| |adrian at freebsd.org,
| |gnn at FreeBSD.org,
| |luigi at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Oct 12 06:15:40 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 12 Oct 2014 06:15:40 +0000
Subject: [Bug 194256] [cam] xptpdrvtraverse spins and deadlocks CAM
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194256
--- Comment #3 from commit-hook at freebsd.org ---
A commit references this bug:
Author: mav
Date: Sun Oct 12 06:14:51 UTC 2014
New revision: 272977
URL: https://svnweb.freebsd.org/changeset/base/272977
Log:
Use proper variable when looping through periphs with CAM_PERIPH_FREE.
PR: 194256
Submitted by: Scott M. Ferris
Sponsored by: EMC/Isilon Storage Division
Changes:
_U stable/10/
stable/10/sys/cam/cam_xpt.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Oct 12 09:12:07 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 12 Oct 2014 09:12:08 +0000
Subject: [Bug 194301] ssh-copy-id doesn't work on 10.1-RC2
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194301
--- Comment #1 from pkubaj at riseup.net ---
I obviously meant public key, not the private one :)
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Oct 12 09:13:05 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 12 Oct 2014 09:13:04 +0000
Subject: [Bug 194314] New: [ixgbe] driver makes some dangerous assumptions
with struct mbuf sizing with IXGBE_RX_COPY_LEN
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194314
Bug ID: 194314
Summary: [ixgbe] driver makes some dangerous assumptions with
struct mbuf sizing with IXGBE_RX_COPY_LEN
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Many People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: ngie at FreeBSD.org
The code in sys/dev/ixgbe/ixgbe.h assumes that MLEN is always > 160, and
doesn't exceed the size of the mbuf. MSIZE is set to 256, so if MHLEN = MSIZE -
sizeof(struct m_hdr) - sizeof(struct pkthdr) < 160, ixgbe will scribble over
the header information in mbufs. Similarly, if IXGBE_RX_COPY_LEN is greater
than the size of the mbuf, it will scribble over other memory, potentially in
the same mbuf chain, or elsewhere.
This optimization needs better bounds checking/handling.
155 /*
156 * Used for optimizing small rx mbufs. Effort is made to keep the copy
157 * small and aligned for the CPU L1 cache.
158 *
159 * MHLEN is typically 168 bytes, giving us 8-byte alignment. Getting
160 * 32 byte alignment needed for the fast bcopy results in 8 bytes being
161 * wasted. Getting 64 byte alignment, which _should_ be ideal for
162 * modern Intel CPUs, results in 40 bytes wasted and a significant drop
163 * in observed efficiency of the optimization, 97.9% -> 81.8%.
164 */
165 #define IXGBE_RX_COPY_LEN 160
166 #define IXGBE_RX_COPY_ALIGN (MHLEN - IXGBE_RX_COPY_LEN)
60 * MLEN is data length in a normal mbuf.
61 * MHLEN is data length in an mbuf with pktheader.
62 * MINCLSIZE is a smallest amount of data that should be put into cluster.
63 */
64 #define MLEN ((int)(MSIZE - sizeof(struct m_hdr)))
65 #define MHLEN ((int)(MLEN - sizeof(struct pkthdr)))
66 #define MINCLSIZE (MHLEN + 1)
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Oct 12 09:15:01 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 12 Oct 2014 09:15:01 +0000
Subject: [Bug 194314] [ixgbe] driver makes some dangerous assumptions with
struct mbuf sizing with IXGBE_RX_COPY_LEN
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194314
Garrett Cooper changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jfv at FreeBSD.org,
| |ricera10 at gmail.com
--- Comment #1 from Garrett Cooper ---
Credit goes to Anton Rang @ Isilon for finding the bug.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Oct 12 09:15:21 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 12 Oct 2014 09:15:21 +0000
Subject: [Bug 194314] [ixgbe] driver makes some dangerous assumptions with
struct mbuf sizing with IXGBE_RX_COPY_LEN
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194314
Garrett Cooper changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-net at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Oct 12 15:26:22 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 12 Oct 2014 15:26:22 +0000
Subject: [Bug 194321] New: lagg/lacp does not work on startup.
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194321
Bug ID: 194321
Summary: lagg/lacp does not work on startup.
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: ki at hh.iij4u.or.jp
After commit 272547, lagg interface is not initialized in lacp mode properly.
before commit:
laggproto lacp lagghash l2,l3,l4
laggport: em2 flags=1c
laggport: em1 flags=1c
after commit:
laggproto lacp lagghash l2,l3,l4
laggport: em1 flags=1c
laggport: em2 flags=18 <-- this interface
does not become active.
In 272547, lladdr configuration for the primary port to a taskqueue.
I suppose this change cause this bug, but I cannot understand lacp yet.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Oct 12 17:08:25 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 12 Oct 2014 17:08:25 +0000
Subject: [Bug 194321] lagg/lacp does not work on startup.
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194321
Hiroki Sato changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hrs at FreeBSD.org
Assignee|freebsd-bugs at FreeBSD.org |hrs at FreeBSD.org
--- Comment #1 from Hiroki Sato ---
Take.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Oct 12 18:01:30 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 12 Oct 2014 18:01:30 +0000
Subject: [Bug 193646] UEFI Memory stick For 10.1-BETA1 hangs
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193646
--- Comment #5 from Reuben ---
Same behavior on RC2.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at FreeBSD.org Sun Oct 12 21:00:28 2014
From: bugzilla-noreply at FreeBSD.org (bugzilla-noreply at FreeBSD.org)
Date: Sun, 12 Oct 2014 21:00:28 +0000
Subject: Problem reports for freebsd-bugs@FreeBSD.org that need special
attention
Message-ID: <201410122100.s9CL0S2Q033491@kenobi.freebsd.org>
To view an individual PR, use:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.
Status | Bug Id | Description
----------------+-----------+-------------------------------------------------
Needs MFC | 155028 | init(8): "init q" in single user causes segfaul
Needs MFC | 156481 | [kernel] [patch] kernel incorrectly reports PPS
Needs MFC | 165630 | [ndis][panic][patch] IRQL_NOT_GREATER_THAN
Needs MFC | 167133 | stale files in /usr/share/examples
Needs MFC | 169471 | [patch] pw(8) deletes group "username" on userd
Needs MFC | 171779 | [patch] passwd(1): make option NO_FSCHG incompl
Needs MFC | 181155 | [libc] [patch] *access*(2) does not handle inva
Needs MFC | 184681 | A bug of bsdconfig(8) in 10.0 RC1
Needs MFC | 190186 | [patch] i915 driver: enable opregion handling
Needs MFC | 192730 | [build] make checkdpadd failures with LD* varia
Needs MFC | 192760 | [build] sbin/ifconfig: missing DPADD for LIBM
Patch Ready | 192350 | [ipf] ipnat doesn't work with INET6 kernel opti
12 problems total for which you should take action.
From bugzilla-noreply at freebsd.org Sun Oct 12 21:53:57 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 12 Oct 2014 21:53:57 +0000
Subject: [Bug 169302] [libc] [patch] Applied MidnightBSD regex memory
consumption limits
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169302
--- Comment #4 from commit-hook at freebsd.org ---
A commit references this bug:
Author: ngie
Date: Sun Oct 12 21:53:13 UTC 2014
New revision: 273010
URL: https://svnweb.freebsd.org/changeset/base/273010
Log:
Implement 64MB memory limit for test to ensure that it fails reliably in
600 seconds; it would previously fail inconsistently when run in some virtual
machine configurations
This patch might need to be reverted or revisited later (see the attached PR
for more details)
PR: 169302
Submitted by: pho
Sponsored by: EMC / Isilon Storage Division
Changes:
head/contrib/netbsd-tests/lib/libc/regex/t_exhaust.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Oct 12 23:47:10 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 12 Oct 2014 23:47:10 +0000
Subject: [Bug 189821] [libc] [patch] nice(3) on FreeBSD returns EACCES
instead of EPERM when provided negative prio's; is not compatible with
Linux/NetBSD/POSIX
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189821
--- Comment #1 from commit-hook at freebsd.org ---
A commit references this bug:
Author: ngie
Date: Sun Oct 12 23:46:25 UTC 2014
New revision: 273015
URL: https://svnweb.freebsd.org/changeset/base/273015
Log:
Expect nice_err to fail on FreeBSD with unprivileged users
PR: 189821
Sponsored by: EMC / Isilon Storage Division
Changes:
head/contrib/netbsd-tests/lib/libc/gen/t_nice.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Oct 13 04:20:36 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Oct 2014 04:20:36 +0000
Subject: [Bug 169302] [libc] [patch] Applied MidnightBSD regex memory
consumption limits
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169302
--- Comment #5 from Garrett Cooper ---
(In reply to Pedro F. Giffuni from comment #3)
> Added ngie@:
>
> Hi Garrett,
>
> I haven't been able to reproduce this locally. Perhaps you can reproduce
> this test failure from the NetBSD tests?
>
> http://cvsweb.netbsd.org/bsdweb.cgi/src/tests/lib/libc/regex/t_exhaust.c
>
> Also verifying if the patch works would be good ;).
There doesn't appear to be a functional regression.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Oct 13 05:13:07 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Oct 2014 05:13:07 +0000
Subject: [Bug 169302] [libc] [patch] Applied MidnightBSD regex memory
consumption limits
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169302
Pedro F. Giffuni changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|In Discussion |Issue Resolved
Resolution|--- |Unable to Reproduce
--- Comment #6 from Pedro F. Giffuni ---
(In reply to Garrett Cooper from comment #5)
> (In reply to Pedro F. Giffuni from comment #3)
> > Added ngie@:
> >
> > Hi Garrett,
> >
> > I haven't been able to reproduce this locally. Perhaps you can reproduce
> > this test failure from the NetBSD tests?
> >
> > http://cvsweb.netbsd.org/bsdweb.cgi/src/tests/lib/libc/regex/t_exhaust.c
> >
> > Also verifying if the patch works would be good ;).
>
> There doesn't appear to be a functional regression.
And that's exactly why the patch was not committed.
Thanks!
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Oct 13 08:00:03 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Oct 2014 08:00:02 +0000
Subject: [FreeBSD Bugzilla] Commit Needs MFC
Message-ID: <201410130800.s9D802wk035077@kenobi.freebsd.org>
Hi,
You have a bug in the "Needs MFC" state which has not been touched in 7 or more days. This email serves as a reminder that you may want to MFC this bug or marked it as completed.
In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days.
This reminder is only sent on Mondays. Please file a bug about concerns you may have.
This search was scheduled by eadler at FreeBSD.org.
(11 bugs)
Bug 155028:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=155028
Severity: Affects Only Me
Priority: Normal
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: init(8): "init q" in single user causes segfault
Bug 156481:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156481
Severity: Affects Only Me
Priority: Normal
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: [kernel] [patch] kernel incorrectly reports PPS jitter with accurate measurements
Bug 165630:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=165630
Severity: Affects Only Me
Priority: Normal
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: [ndis][panic][patch] IRQL_NOT_GREATER_THAN
Bug 167133:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167133
Severity: Affects Only Me
Priority: Normal
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: stale files in /usr/share/examples
Bug 169471:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169471
Severity: Affects Only Me
Priority: Normal
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: [patch] pw(8) deletes group "username" on userdel even if group "username" is not assoc. w/user "username"
Bug 171779:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171779
Severity: Affects Only Me
Priority: Normal
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: [patch] passwd(1): make option NO_FSCHG incomplete
Bug 181155:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181155
Severity: Affects Only Me
Priority: Normal
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: [libc] [patch] *access*(2) does not handle invalid amodes properly
Bug 184681:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184681
Severity: Affects Only Me
Priority: Normal
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: A bug of bsdconfig(8) in 10.0 RC1
Bug 190186:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190186
Severity: Affects Only Me
Priority: Normal
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: [patch] i915 driver: enable opregion handling
Bug 192730:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192730
Severity: Affects Some People
Priority: ---
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: [build] make checkdpadd failures with LD* variables being added to LDADD
Bug 192760:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192760
Severity: Affects Some People
Priority: ---
Hardware: Any
Assignee: freebsd-bugs at FreeBSD.org
Status: Needs MFC
Resolution:
Summary: [build] sbin/ifconfig: missing DPADD for LIBM
From gennyi at importedeals.com Mon Oct 13 11:42:23 2014
From: gennyi at importedeals.com (Importer Deals)
Date: Mon, 13 Oct 2014 21:42:14 +1000
Subject: Generator Portable 240vac Power
Message-ID: <1031437073543bba96e83ec.1413200534@www.vision6.com.au>
[1]Shop ImporterDeals
[2]Importer Dealer
[gen.jpg]
HOT PRODUCT
LIMITED STOCK
Portable Silent
4.4kVA Camping Generator
[black.png]
Only
$599.00
Was $1,599.00
Buy Now
Details
Featuring Honda technology, you are assured of cleanly generated power
with low fuel consumption superior to other types of generators. With
an advanced throttle control technology, the RPM of this generator is
automatically adjusted depending on the equipment connected to it,
reducing fuel consumption by up to 20% compared to conventional
generators.
View
"As we work to create light for others, we naturally light our own way"
Safe Wash - Only $299.00
Watch Video
[3]Visit our website | QLD Australia
This email was sent by Importer Deals, Brisbane QLD 4000 to
freebsd-bugs at freebsd.org
[4]Unsubscribe
References
Visible links
1. http://www.vision6.com.au/ch/44773/95khm/1738542/5d56216zf9.html
2. http://www.vision6.com.au/ch/44773/95khm/1738543/5d562b93r.html
3. http://www.vision6.com.au/ch/44773/95khm/1738542/5d56216zf9-1.html
4. http://www.vision6.com.au/forms/u/0623d87/44773/7443532.html
Hidden links:
6. http://www.vision6.com.au/ch/44773/95khm/1817559/5d562th4y.html
7. http://www.vision6.com.au/ch/44773/95khm/1817559/5d562th4y-1.html
8. http://www.vision6.com.au/ch/44773/95khm/1817560/5d562s8d.html
From bugzilla-noreply at freebsd.org Mon Oct 13 14:12:47 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Oct 2014 14:12:46 +0000
Subject: [Bug 193873] [PATCH] Unify dumpsys() under generic kern_dump.c.
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193873
Conrad Meyer changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #147868|0 |1
is obsolete| |
--- Comment #8 from Conrad Meyer ---
Created attachment 148257
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148257&action=edit
v2 of the patch rebased on top of r273035 (past conflicting r272766)
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Oct 13 14:58:12 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Oct 2014 14:58:12 +0000
Subject: [Bug 186251] authpf(8) always fails with "error removing stale
rulesets" on 10.0-RELEASE
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186251
--- Comment #1 from thomas.apel at gmx.net ---
I just checked: The problem still exists on the 10.1-RC2.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Oct 13 16:12:41 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Oct 2014 16:12:41 +0000
Subject: [Bug 194292] Patch for adding firewall_myservices_tcp and
firewall_myservices_udp support to rc.conf
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194292
Hiroki Sato changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hrs at FreeBSD.org
Assignee|freebsd-bugs at FreeBSD.org |hrs at FreeBSD.org
--- Comment #3 from Hiroki Sato ---
Take.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Oct 13 19:35:16 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Oct 2014 19:35:16 +0000
Subject: [Bug 194209] ahciems should be optional (at build or at run time)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194209
Garrett Cooper changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|ahciems should be optional |ahciems should be optional
| |(at build or at run time)
--- Comment #2 from Garrett Cooper ---
(In reply to Alexander Motin from comment #1)
> Not sure I understand your proposition. Do you want ahciem to be separate
> module, or do you want some tunable to disable it, or something else?
I jumped to a conclusion without providing a proper problem statement.
Basically we have a platform at work that has ahciems support, but our software
isn't coded up to handle ahciems currently, so this causes our software to poke
at the boot drives for ahciems status a little too much.
Having the support on by default makes sense from a usability perspective. In
general, being able to enable/disable ahciems on a global or a per-controller
basis (like atc.wc.enable) is desirable, because the end-user might not want
ahciems support to be enabled, or the device support provided/integrated in
with some vendors might be buggy/broken.
PS I was working on a patch to separate out the drivers, but then I realized
that it would introduce unnecessary complexity because of how the driver
currently hangs ahciems devices off of ahci controllers, and how the ahciems
instances are created/destroyed at ahci controller attach/detach.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Oct 13 21:50:22 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Oct 2014 21:50:22 +0000
Subject: [Bug 183598] [patch] netstat(1): wrong display of humanized packets
counter
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183598
--- Comment #1 from olivier at cochard.me ---
The patch fix counters "input errs" and " output errs" too.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Oct 14 02:15:49 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Oct 2014 02:15:49 +0000
Subject: [Bug 194344] New: [regression] Wake on LAN no longer works on em(4)
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194344
Bug ID: 194344
Summary: [regression] Wake on LAN no longer works on em(4)
Product: Base System
Version: 10.0-STABLE
Hardware: amd64
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: wblock at FreeBSD.org
Wake on LAN worked up until a couple of months ago. The target computer has
this network card:
em0 at pci0:8:0:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05
hdr=0x00
vendor = 'Intel Corporation'
device = '82541PI Gigabit Ethernet Controller'
class = network
subclass = ethernet
It is running:
FreeBSD nas.wonkity.com 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r273066: Mon
Oct 13 19:23:15 MDT 2014 root at nas.wonkity.com:/usr/obj/usr/src/sys/GENERIC
amd64
This might be related to bug 189531
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189531).
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Oct 14 11:14:22 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Oct 2014 11:14:22 +0000
Subject: [Bug 194347] New: Return an error when rc service is not enabled
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194347
Bug ID: 194347
Summary: Return an error when rc service is not enabled
Product: Base System
Version: 10.0-RELEASE
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Many People
Priority: ---
Component: conf
Assignee: freebsd-bugs at FreeBSD.org
Reporter: roy at marples.name
Created attachment 148290
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148290&action=edit
Return an error if service is not enabled.
Currently the rc service returns success when testing any function and it's not
enabled.
# in rc.conf
ntpd_enable=NO # or unset
# in a sample script
if /etc/rc.d/ntpd status >/dev/null 2>&1; then
# ntpd is running but we changed it's config, lets restart it for the new
one
/etc/rc.d/ntpd restart
fi
--
You are receiving this mail because:
You are the assignee for the bug.
From inverti at importedeals.com Tue Oct 14 11:51:42 2014
From: inverti at importedeals.com (Importer Deals Australia)
Date: Tue, 14 Oct 2014 21:21:32 +1000
Subject: Car Boat Caravan Inverter Power 12vdc to 240vac
Message-ID: <1738285941543d073c25db9.1413285692@www.vision6.com.au>
[1]Shop ImporterDeals
[2]Importer Dealer
[inverter.jpg]
HOT PRODUCT
LIMITED STOCK
3000W Power Inverter
12VDC - 240VAC
[inverter.png]
Only
$249.00
was $699.00
Buy Now
Details
This power inverter converts low voltage DC power to high voltage AC
household power. It is widely used indoor and outdoor. It can be used
by many types of equipment just with the battery. Power inverter takes
a big convenience for people on the power off situation.
View
Safe Wash - Only $299.00
Watch Video
[3]Visit our website | QLD Australia
This email was sent by Importer Deals, Brisbane QLD 4000 to
freebsd-bugs at freebsd.org
[4]Unsubscribe
References
Visible links
1. http://www.vision6.com.au/ch/44773/988t4/1738542/647a816zf9.html
2. http://www.vision6.com.au/ch/44773/988t4/1738543/647a8b93r.html
3. http://www.vision6.com.au/ch/44773/988t4/1738542/647a816zf9-1.html
4. http://www.vision6.com.au/forms/u/759d6c5/44773/7514074.html
Hidden links:
6. http://www.vision6.com.au/ch/44773/988t4/1837244/647a81265t.html
7. http://www.vision6.com.au/ch/44773/988t4/1837244/647a81265t-1.html
8. http://www.vision6.com.au/ch/44773/988t4/1837245/647a8145yf.html
From bugzilla-noreply at freebsd.org Tue Oct 14 16:35:21 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Oct 2014 16:35:21 +0000
Subject: [Bug 194304] gbde does not announce destroyed keys
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194304
--- Comment #1 from mwlucas at michaelwlucas.com ---
This seems to be a generic GBDE error message breakage. Here I change key 0's
passphrase and key file.
# gbde setkey da0p1 -n 0 -l da0p1.lock -k rat.jpg -L da0p1.lock-new
Enter passphrase:
Opened with key 0
Enter new passphrase:
Reenter new passphrase:
I now have a new lock file with a new passphrase. Let's try the old key file
and see what happens. It appears to work, except it doesn't.
# gbde attach da0p1 -l da0p1.lock -k rat.jpg
Enter passphrase:
# ls /dev/da0p1*
/dev/da0p1
# gbde detach da0p1
gbde: Detach of da0p1 failed: Geom not found: "da0p1.bde"
The new lock file and passphrase do work.
I would have expected the attach command to call me an idiot rather than fail
silently. An ignorant, uneducated, non-programmer look at the code encourages
my belief.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Oct 14 22:54:40 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Oct 2014 22:54:40 +0000
Subject: [Bug 194359] New: bsdinstall should set active flag in GPT PMBR if
not booting using EFI
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
Bug ID: 194359
Summary: bsdinstall should set active flag in GPT PMBR if not
booting using EFI
Product: Base System
Version: 10.1-BETA3
Hardware: amd64
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: misc
Assignee: freebsd-bugs at FreeBSD.org
Reporter: cperciva at FreeBSD.org
As mentioned in bug #133493, some systems will not boot if there is no "active"
slice in the "MBR". Others, such as my laptop, will boot but only after
printing "Invalid partition table!" and waiting for someone to hit Enter.
This was fixed in 2009 by r198097; but it turned out that this broke EFI
booting (since EFI requires that the GPT protective MBR has no active bits
set). EFI was unbroken 16 months ago by r251588... but this re-broke non-EFI
booting on the affected machines.
It seems to me that the right compromise here would be for bsdinstall to set
the "active" flag if and only if a system is being set up for GPT with "legacy"
booting.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Oct 14 23:03:12 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Oct 2014 23:03:12 +0000
Subject: [Bug 191748] Installing FreeBSD-10-STABLE pmbr makes disk unbootable
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191748
Colin Percival changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |cperciva at FreeBSD.org
--- Comment #2 from Colin Percival ---
Can you try reinstalling the 10.0 boot code and then running 'gpart set -a
active ada0'? I'm wondering if this is the same the same issue as bug #194359
which I just reported...
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Oct 14 23:15:02 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Oct 2014 23:15:02 +0000
Subject: [Bug 194359] bsdinstall should set active flag in GPT PMBR if not
booting using EFI
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #1 from Allan Jude ---
Is there an easy way to do that? Generally we're just installing what is in the
'/boot/pmbr' file. I don't think the gpart utility has the ability to set this
flag.
We either need gpart to be able to do that, or a 2nd file like
/boot/pmbr.active
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Oct 14 23:17:57 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Oct 2014 23:17:57 +0000
Subject: [Bug 194359] bsdinstall should set active flag in GPT PMBR if not
booting using EFI
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #2 from Colin Percival ---
Very easy, once you know how: gpart set -a active
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Oct 14 23:27:11 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Oct 2014 23:27:11 +0000
Subject: [Bug 194361] New: [BUG] 11-CURRENT does not build on 10.1-STABLE
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194361
Bug ID: 194361
Summary: [BUG] 11-CURRENT does not build on 10.1-STABLE
Product: Base System
Version: 11.0-CURRENT
Hardware: amd64
OS: Any
Status: Needs Triage
Severity: Affects Many People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: never at nevermind.kiev.ua
One cannot build 11-CURRENT on 10-STABLE
Log follows:
===> rescue/rescue/chown/tests (depend)
(cd /ssd/never/head/usr.sbin/chown/tests && make -f
/ssd/never/head/usr.sbin/chown/tests/Makefile SUBDIR= _RECURSING_PROGS=
depend)
cc -O2 -pipe -march=nocona -DRESCUE -std=gnu99 -fstack-protector
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations
-Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
-Qunused-arguments -c /ssd/never/head/usr.sbin/chown/chown.c
MAKEOBJDIRPREFIX=/ssd/never/obj/ssd/never/head/rescue/rescue make -f rescue.mk
exe
cc -O2 -pipe -march=nocona -c rescue.c
rescue.c:59:2: warning: implicit declaration of function 'crunched_usage' is
invalid in C99 [-Wimplicit-function-declaration]
crunched_usage();
^
1 warning generated.
echo "int _crunched_cat_stub(int argc, char **argv, char **envp){return
main(argc,argv,envp);}" >cat_stub.c
cc -O2 -pipe -march=nocona -c cat_stub.c
cat_stub.c:1:67: warning: implicit declaration of function 'main' is invalid in
C99 [-Wimplicit-function-declaration]
int _crunched_cat_stub(int argc, char **argv, char **envp){return
main(argc,argv,envp);}
^
1 warning generated.
make[5]: don't know how to make
/ssd/never/obj/ssd/never/head/rescue/rescue//ssd/never/head/bin/cat/cat.o. Stop
make[5]: stopped in /ssd/never/obj/ssd/never/head/rescue/rescue
*** Error code 2
Stop.
make[4]: stopped in /ssd/never/head/rescue/rescue
*** Error code 1
Stop.
make[3]: stopped in /ssd/never/head/rescue
*** Error code 1
Stop.
make[2]: stopped in /ssd/never/head
*** Error code 1
Stop.
make[1]: stopped in /ssd/never/head
*** Error code 1
Stop.
make: stopped in /ssd/never/head
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 15 00:37:14 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Oct 2014 00:37:14 +0000
Subject: [Bug 194359] bsdinstall should set active flag in GPT PMBR if not
booting using EFI
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #3 from Marcel Moolenaar ---
Indeed. The set attribute command was deliberately changed to apply not just to
partitions, but also to the scheme itself. This made it possible to to set the
active flag in the PMBR for the GPT scheme, even though GPT partitions
themselves do not have an active flag.
If the installer knows what the firmware is ((I don't know if we pass anything
from the loader to the kernel), then it can indeed set the active flag in PMBR
when the firmware is a BIOS and not do that when the firmware is (U)EFI. And
only do this on x86...
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 15 00:53:56 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Oct 2014 00:53:56 +0000
Subject: [Bug 194359] bsdinstall should set active flag in GPT PMBR if not
booting using EFI
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #4 from Colin Percival ---
I have only a very vague notion of how booting works these days, but my
understanding is that we're already setting up things differently based on
whether we expect to boot via BIOS or UEFI; and that (aside from when using a
ZFS root, which is incompatible with UEFI) the installer detects how it was
booted and sets up the system to boot the same way.
If the above is correct, I think all we need is a "if we're setting up the disk
to be booted via BIOS, gpart set -a active it". Allan, does this make sense?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 15 01:03:58 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Oct 2014 01:03:58 +0000
Subject: [Bug 194359] bsdinstall should set active flag in GPT PMBR if not
booting using EFI
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #5 from Allan Jude ---
I don't have one of the systems that does not work, so it is hard for me to
test.
Who has a system that refuses to boot if the fake partition in the fake MBR
used in a GPT partition table is not set to active? Does running the gpart set
command from the install cd then make it work?
What systems refuse to boot if it IS set active?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 15 01:12:10 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Oct 2014 01:12:10 +0000
Subject: [Bug 194359] bsdinstall should set active flag in GPT PMBR if not
booting using EFI
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #6 from Colin Percival ---
Allan: My laptop doesn't refuse to boot, but it does behave badly (bogus error
message) when booting via BIOS + GPT if the fake MBR is not set to active.
Running the above-mentioned command fixes this.
My understanding from Marcel's commit r251588 is that having the fake MBR set
as active breaks UEFI booting, but I haven't tested this myself.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 15 01:15:55 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Oct 2014 01:15:56 +0000
Subject: [Bug 194359] bsdinstall should set active flag in GPT PMBR if not
booting using EFI
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #7 from Allan Jude ---
Ok, I can test the UEFI stuff on this side.
I can easily add the gpart set to the zfsboot portion of bsdinstall
Although I might make more sense to add it elsewhere to make it apply to
Nathan's parts of the installer as well.
We can detect if the installer was booted BIOS or UEFI from a sysctl:
machdep.bootmethod
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 15 01:23:06 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Oct 2014 01:23:06 +0000
Subject: [Bug 194311] [ixgbe] DROP_EN needs to be set early to avoid RX queue
hanging
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194311
Adrian Chadd changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Open |Needs MFC
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 15 01:23:25 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Oct 2014 01:23:25 +0000
Subject: [Bug 194311] [ixgbe] DROP_EN needs to be set early to avoid RX queue
hanging
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194311
--- Comment #1 from commit-hook at freebsd.org ---
A commit references this bug:
Author: adrian
Date: Wed Oct 15 01:22:56 UTC 2014
New revision: 273112
URL: https://svnweb.freebsd.org/changeset/base/273112
Log:
Set the DROP_EN bit before the RX queue is brought up and active.
He noticed issues setting this bit in SRRCTL after the queue was up,
so doing it from the sysctl handler isn't enough and may not actually
work correctly.
This commit doesn't remove the sysctl path or try to change its
behaviour. I'll talk with others about how to finish fixing that
before I tackle that.
PR: kern/194311
Submitted by: luigi
MFC after: 3 days
Sponsored by: Norse Corp, Inc
Changes:
head/sys/dev/ixgbe/ixgbe.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 15 03:24:19 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Oct 2014 03:24:19 +0000
Subject: [Bug 194359] bsdinstall should set active flag in GPT PMBR if not
booting using EFI
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
Craig Rodrigues changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rodrigc at FreeBSD.org
--- Comment #8 from Craig Rodrigues ---
@Allan: I installed FreeBSD with GPT/ZFS on an HP Elitebook 8460p laptop, with
BIOS, not using EFI.
The system would not boot until I set the active partition.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 15 08:37:21 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Oct 2014 08:37:21 +0000
Subject: [Bug 194376] New: [FreeBSD 10.1 RC2 on Hyper-v] In FreeBSD VM,
cannot recognize the second IDE disk
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194376
Bug ID: 194376
Summary: [FreeBSD 10.1 RC2 on Hyper-v] In FreeBSD VM, cannot
recognize the second IDE disk
Product: Base System
Version: 10.1-BETA2
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: kyliel at microsoft.com
In FreeBSD VM, cannot recognize the second IDE disk. this only happens on
FreeBSD 10.1 RC2.
In hyper-v server 2012 R2:
1. Install FreeBSD 10.1 RC2 VM from
ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ISO-IMAGES/10.1/FreeBSD-10.1-RC2-amd64-dvd1.iso
2. Add second IDE disk in IDE controller 0
3. ls /dev/da*
dmesg | grep da
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 15 10:45:42 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Oct 2014 10:45:42 +0000
Subject: [Bug 191348] [mps] LSI2308 with WD3000FYYZ drives disappears after
hotswapping
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191348
--- Comment #11 from Micha? Margula ---
Hello,
I really appreciate and thank you for your effort. Today I applied patch to
10.0-RELEASE-p9. It still works flawlessly?- I can remove disk and reinsert
them freely, but few things:
- to apply that patch I had to change version inside patch (mpsvar.h file)
because your contains version 19.00.00.00-fbsd and mine in that FreeBSD release
is 16.00.00.00-fbsd
- sysctl does not work properly - I set hw.mps.spinup_wait_time=5 in
/boot/loader.conf and it shows in sysctl properly:
root at boromir:~ # sysctl dev.mps.0.spinup_wait_time
dev.mps.0.spinup_wait_time: 5
But in dmesg I see (after a reboot of course):
Oct 15 12:01:47 boromir kernel: Sleeping 3 seconds
Oct 15 12:01:50 boromir kernel: finished Sleeping 3 seconds
Also can't change that setting while running (but it may be proper behaviour, I
don't know FreeBSD that much):
root at boromir:~ # sysctl dev.mps.0.spinup_wait_time=5
sysctl: oid 'dev.mps.0.spinup_wait_time' is read only
If you need anything else, please let me know. Once again - big thanks.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 15 16:42:44 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Oct 2014 16:42:44 +0000
Subject: [Bug 117711] [rpc] rpcbind binds to all interfaces on random ports
even when using the -h flag
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=117711
Harry Weppner changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |harry.weppner at gmx.net
--- Comment #11 from Harry Weppner ---
I just also encountered this on 10.0-RELEASE issue while setting up a jail. 7
years is a pretty long time...
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 15 17:21:24 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Oct 2014 17:21:24 +0000
Subject: [Bug 160760] (Kernel) Log messages garbled/interleaved
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=160760
tilghman at meg.abyt.es changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tilghman at meg.abyt.es
--- Comment #1 from tilghman at meg.abyt.es ---
This issue has now just occurred to us, as well, on FreeBSD 9.1:
-----snip-----
<<<<66>n66>n>e>newwnnenffessw wsnfe serrs vsneevefr sr vfrsrervee r fereeefr
refnnasearns:/amse:/mnennt/:/mpatn/t/poopoool/l/zosez/ooel:///amaznoe/rtta/poo/rlima/t/rgiezomate//iarmgsaet/igessma:
g:eno:s : nnot trote respo rendnsinsgpp
oo
nd
<6ing
<>6>tndin respgo
n
ding
newnfs server freenas:/mnt/pool/zoe/art/imagesne:n wenfwsn fsnoervts e
rseerverspro fnrdeinenag
fs
<<6>6>:r/emennnatse:w/m/npnoewnftons f/s lserse/vrpooezrl/
vozoe/fartre/ee/enarimaa rtfreegse:s:n//a s:minmnt/apges: /mnonoott t
/prresol/zpoeospnoe/ondiol/dingng
a
-----snip-----
The message fragments seem to be specifically about a constantly mounted NFS
server (running FreeNAS). The server on which this occurred also happens to be
running under VMware (as is the FreeNAS server).
--
You are receiving this mail because:
You are the assignee for the bug.
From johnandsara2 at cox.net Wed Oct 15 17:38:48 2014
From: johnandsara2 at cox.net (John D. Hendrickson)
Date: Wed, 15 Oct 2014 13:38:31 -0400
Subject: [Bug 194236] New: Hourly cron jobs running to early
In-Reply-To: <0YXQ1p01Q2X408g01YXRfJ>
References: <0YXQ1p01Q2X408g01YXRfJ>
Message-ID: <543EB117.1060705@cox.net>
now keep in mind this note isn't about you in particular. there's a
massive problem with people hacking away with free permissions that end
up causing others a life time of "upgrade failed" problems which is what
i'm really getting at.
i'm not so sure your right - maybe cron is runnign same code as always
for i386 (unless someone hacked it): and those people would be harmed by
your hacking in changes
what your saying is in order to fix your computer that i386 you wish to
damage anyone running a cron i386 who is NOT using amd64 (are you on a
VAX?): which is wrong.
my guess is your pc is f'ed up (is it from china?), or that cron always
ran at the end of the minute (under certain conditions) and the new code
is f'ed up (ie, they "smartly" added better time resolution not
realizing how cron ever ran to begin with) or that bsd, when i386 is in
use falsely reports time: which again it's not a reason to hack cron
it's a reason to firmly question who hacking IN the problem in bsd
in the past i've tried to make a tight system that relied on time before
and canceled it: it's just too likely to go wrong (clock settings and
updates, even the code handling, are too UNRELIABLE), too likely even
when, say, two pc's are continually checked to stay even: even then it's
too unreliable for file/data safety.
another thing i found is time resolution. if you end up relying on a
resolution that's shorter than what is really effective: you will end up
either missing not once BUT ALWAYS or doubling your trigger (what i mean
is you shouldn't intently write code that will become a race condition,
only your pc has Hz configuration sharable with itself: if that, and
your not a realtime HP unix: if that). were NOT all running one amd.
some regularly deal with various sites: some of which are UTC or not,
some of which have correct time, others that are misconfigured.
ESPECIALLY if your talking about code distributed on many OSes and
platforms: hacking in hardware time improvments that only work on some
little pc's into cron to fix it on one computer (break it on another).
bad, bad, bad
i don't mean to be stiff on you only
why doesn't my cron, which i compiled myself, on three different chips
(and i used to compile 386 and distribute bins instead of recompiling
everwhere, far easier)
why doesn't cron start on wrong times?
WAY WAY before filing a bug against cron and suggesting it's wrong and
you'd like to edit it, you should be in user channel asking other
questions, posting code you think may be responsible, and even posting A
PATCH THAT FIXES IT
it's pretty pretentious to assume the old generation did not have
elaborate plans, engineering degrees, and act in good faith and know
exactly what they were doing. i see a lot of disrespect and
irresponsibility going on. and i mean distro admins not bug posters.
(they've broken countless softwares and hardwares, incurred countless
complaints: on stuff that was working fine, due to allowing their
friends to hack anything for any reason. i'm pissed personally.)
bugzilla-noreply at freebsd.org wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194236
>
> Bug ID: 194236
> Summary: Hourly cron jobs running to early
> Product: Base System
> Version: 10.0-RELEASE
> Hardware: i386
> OS: Any
> Status: Needs Triage
> Severity: Affects Some People
> Priority: ---
> Component: bin
> Assignee: freebsd-bugs at FreeBSD.org
> Reporter: uffe at uffe.org
>
> Seen on FreeBSD 10.0-RELEASE-p9 i386
>
> After upgrading from 9.2-RELEASE-p12 (i386) to 10.0-RELEASE-p9 (i386)
>
> cron runs hourly jobs up to a minutte too early.
>
> This causes tasks like newsyslog to skip logrotation at the intended time -
> rotation will occour one hour delayed.
>
> It has been discussed here:
>
> http://lists.freebsd.org/pipermail/freebsd-stable/2014-June/079106.html
>
> and is reported solved - but I'm seeing the problem on latest official patch
> level (10.0-RELEASE-p9)
>
> Note: This seems to be an i386 problem only - as the equivalent amd64
> installations runs hourly cron at the exact time.
>
> # uname -a
> FreeBSD asuseee 10.0-RELEASE-p9 FreeBSD 10.0-RELEASE-p9 #0: Mon Sep 15 14:32:29
> UTC 2014 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
> i386
>
>
> BEFORE upgrade (running 9.2-RELEASE-p12 (i386))
>
> # cat /var/log/cron | grep newsyslog
>
> Oct 5 13:00:00 smtpd /usr/sbin/cron[11742]: (root) CMD (newsyslog)
> Oct 5 14:00:00 smtpd /usr/sbin/cron[12271]: (root) CMD (newsyslog)
> Oct 5 15:00:00 smtpd /usr/sbin/cron[12995]: (root) CMD (newsyslog)
> Oct 5 16:00:00 smtpd /usr/sbin/cron[13595]: (root) CMD (newsyslog)
> Oct 5 17:00:00 smtpd /usr/sbin/cron[14654]: (root) CMD (newsyslog)
> Oct 5 18:00:00 smtpd /usr/sbin/cron[15614]: (root) CMD (newsyslog)
> Oct 5 19:00:00 smtpd /usr/sbin/cron[16319]: (root) CMD (newsyslog)
> Oct 5 20:00:00 smtpd /usr/sbin/cron[17884]: (root) CMD (newsyslog)
> Oct 5 21:00:00 smtpd /usr/sbin/cron[38642]: (root) CMD (newsyslog)
> Oct 6 00:00:00 smtpd /usr/sbin/cron[20850]: (root) CMD (newsyslog)
>
> AFTER upgrade (running 10.0-RELEASE-p9 (i386))
>
> # cat /var/log/cron | grep newsyslog
>
> Oct 6 00:59:42 smtpd /usr/sbin/cron[7632]: (root) CMD (newsyslog)
> Oct 6 01:59:38 smtpd /usr/sbin/cron[6222]: (root) CMD (newsyslog)
> Oct 6 02:59:34 smtpd /usr/sbin/cron[7616]: (root) CMD (newsyslog)
> Oct 6 03:59:34 smtpd /usr/sbin/cron[9793]: (root) CMD (newsyslog)
> Oct 6 04:59:38 smtpd /usr/sbin/cron[10369]: (root) CMD (newsyslog)
> Oct 6 05:58:55 smtpd /usr/sbin/cron[10897]: (root) CMD (newsyslog)
> Oct 6 06:59:34 smtpd /usr/sbin/cron[11420]: (root) CMD (newsyslog)
> Oct 6 07:58:55 smtpd /usr/sbin/cron[11848]: (root) CMD (newsyslog)
> Oct 6 08:59:51 smtpd /usr/sbin/cron[12478]: (root) CMD (newsyslog)
> Oct 6 09:59:47 smtpd /usr/sbin/cron[12995]: (root) CMD (newsyslog)
> Oct 6 10:58:42 smtpd /usr/sbin/cron[13733]: (root) CMD (newsyslog)
> Oct 6 11:58:55 smtpd /usr/sbin/cron[14416]: (root) CMD (newsyslog)
> Oct 6 12:59:34 smtpd /usr/sbin/cron[15188]: (root) CMD (newsyslog)
> Oct 6 13:59:29 smtpd /usr/sbin/cron[15935]: (root) CMD (newsyslog)
> Oct 6 14:59:38 smtpd /usr/sbin/cron[16440]: (root) CMD (newsyslog)
> Oct 6 15:59:42 smtpd /usr/sbin/cron[17655]: (root) CMD (newsyslog)
> Oct 6 16:59:47 smtpd /usr/sbin/cron[18513]: (root) CMD (newsyslog)
> Oct 6 17:59:34 smtpd /usr/sbin/cron[19025]: (root) CMD (newsyslog)
> Oct 6 18:59:47 smtpd /usr/sbin/cron[19916]: (root) CMD (newsyslog)
> Oct 6 20:00:00 smtpd /usr/sbin/cron[20624]: (root) CMD (newsyslog)
> Oct 6 20:59:29 smtpd /usr/sbin/cron[21680]: (root) CMD (newsyslog)
> Oct 6 21:59:34 smtpd /usr/sbin/cron[22962]: (root) CMD (newsyslog)
> Oct 6 22:59:38 smtpd /usr/sbin/cron[23582]: (root) CMD (newsyslog)
> Oct 6 23:59:47 smtpd /usr/sbin/cron[24275]: (root) CMD (newsyslog)
> Oct 7 00:59:47 smtpd /usr/sbin/cron[24988]: (root) CMD (newsyslog)
> Oct 7 01:59:34 smtpd /usr/sbin/cron[25758]: (root) CMD (newsyslog)
> Oct 7 02:59:21 smtpd /usr/sbin/cron[26291]: (root) CMD (newsyslog)
> Oct 7 03:59:47 smtpd /usr/sbin/cron[28272]: (root) CMD (newsyslog)
> Oct 7 05:00:00 smtpd /usr/sbin/cron[28715]: (root) CMD (newsyslog)
> Oct 7 05:59:12 smtpd /usr/sbin/cron[29252]: (root) CMD (newsyslog)
> Oct 7 06:58:46 smtpd /usr/sbin/cron[29821]: (root) CMD (newsyslog)
> Oct 7 07:59:51 smtpd /usr/sbin/cron[30357]: (root) CMD (newsyslog)
> Oct 7 08:59:34 smtpd /usr/sbin/cron[31222]: (root) CMD (newsyslog)
> Oct 7 09:59:51 smtpd /usr/sbin/cron[31980]: (root) CMD (newsyslog)
> Oct 7 10:59:47 smtpd /usr/sbin/cron[32710]: (root) CMD (newsyslog)
> Oct 7 11:59:51 smtpd /usr/sbin/cron[33278]: (root) CMD (newsyslog)
> Oct 7 12:59:55 smtpd /usr/sbin/cron[33832]: (root) CMD (newsyslog)
> Oct 7 13:59:34 smtpd /usr/sbin/cron[34276]: (root) CMD (newsyslog)
> Oct 7 14:59:51 smtpd /usr/sbin/cron[34833]: (root) CMD (newsyslog)
> Oct 7 15:59:21 smtpd /usr/sbin/cron[35492]: (root) CMD (newsyslog)
> Oct 7 16:58:42 smtpd /usr/sbin/cron[36213]: (root) CMD (newsyslog)
> Oct 7 17:59:42 smtpd /usr/sbin/cron[37072]: (root) CMD (newsyslog)
> Oct 7 18:59:47 smtpd /usr/sbin/cron[37958]: (root) CMD (newsyslog)
> Oct 7 19:59:47 smtpd /usr/sbin/cron[38780]: (root) CMD (newsyslog)
> Oct 7 20:59:12 smtpd /usr/sbin/cron[39330]: (root) CMD (newsyslog)
> Oct 7 21:58:55 smtpd /usr/sbin/cron[40561]: (root) CMD (newsyslog)
> Oct 7 22:59:55 smtpd /usr/sbin/cron[41477]: (root) CMD (newsyslog)
> Oct 7 23:59:25 smtpd /usr/sbin/cron[47064]: (root) CMD (newsyslog)
>
From americans76132 at gmail.com Wed Oct 15 17:47:27 2014
From: americans76132 at gmail.com (americans76132 at gmail.com)
Date: Wed, 15 Oct 2014 10:47:26 -0700 (PDT)
Subject: Has your website : mail-archive.com been penalized by Google ?
Message-ID: <543eb32e.e92a460a.5abb.03fc@mx.google.com>
Good Morning Bussiness Owner
Has your website lost traffic or rankings in last few weeks ? If yes,
then your website is a VICTIM to these NEW google algorithm updates. To
correct this you need to hire a professioanl Search Engine Optimization
company who understands these changes better than what you can. More
with these new updates coming each month you need your online web
presence to be taken care by a group of SEO Experts who are dedicated
to learn all these new changes coming their way.
We are presently offering a 15 days FREE Trial for our S.E.O Service,
so that you can experience our expert S.E.O skills and then decided to
sign up with us. Our S.E.O Plans start from just 199$ and go to 399$ /
month making sure your website is optimized for all possible keywords
and not just 10-20 keywords like other companies offer.
Google has recently launched 3 Big updates and refreshes keep coming
every month
1) Google Panda Update : Targeting Websites with Bad ONSITE
2) Google Penguin : Targeting Websites with Bad backlinks
3) Google Pigeon : Targeting Websites with bad local presence
We have helped our clients pass all these algorithms pass these updates
in last 3 years and we are one of those few ONLY SEO companies who have
not been affected MUCH by these updates.
What makes our company different :
1) We optimize website not keywords : ( We optimize your website for as
many keywords possible )
2) We assure results in first 15 days itself
3) We have the best possible pricing on the web
4) We abide by all google rules
5) Every link built is shared with for your future use
6) We Offer complete SEO Service not just LINK BUILDING
Email us back with your website and your phone number so we can study
your website and email you back with our Customized proposal. Looking
forward working with you.
Regards
Vince G
SEO Manager ( TOB )
Skype
________________________________________
NO CLICK in the subject to STOP EMAILS
From bugzilla-noreply at freebsd.org Wed Oct 15 19:06:00 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Oct 2014 19:06:00 +0000
Subject: [Bug 194359] bsdinstall should set active flag in GPT PMBR if not
booting using EFI
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #9 from Ed Maste ---
> If the installer knows what the firmware is ((I don't know if we pass anything from the loader to the kernel))
We report if the system was booted by BIOS or UEFI via the machdep.bootmethod
sysctl (returns BIOS or UEFI).
I think this won't help though, because it returns BIOS for both the legacy
BIOS case and the UEFI CSM (i.e. simulated BIOS) case, and based on the
discussion here it seems (some) real BIOS needs the PMBR active flag set while
CSM needs it unset.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 15 19:33:02 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Oct 2014 19:33:02 +0000
Subject: [Bug 194359] bsdinstall should set active flag in GPT PMBR if not
booting using EFI
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
hans at beastielabs.net changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hans at beastielabs.net
--- Comment #10 from hans at beastielabs.net ---
(In reply to Allan Jude from comment #7)
> Ok, I can test the UEFI stuff on this side.
>
Allen,
Back home I have a legacy system that is affected by this issue and another one
that isn't, see:
https://lists.freebsd.org/pipermail/freebsd-stable/2014-October/080500.html
Whenever I get home (hopefully by tomorrow) I can help testing. Both systems
are available, nothing else is currently running on them.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 15 19:59:08 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Oct 2014 19:59:08 +0000
Subject: [Bug 194386] New: Common storage of original MAC address
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194386
Bug ID: 194386
Summary: Common storage of original MAC address
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: rpokala at panasas.com
Add a common location in the network stack to store the original MAC address
for an interface. It will be preserved even if the working MAC address has
changed due to being manually set w/ `ifconfig', or being part of a lagg(4).
Discussed on freebsd-hackers@ in thread "Common storage of original MAC
address":
https://lists.freebsd.org/pipermail/freebsd-hackers/2014-August/thread.html#45822
https://lists.freebsd.org/pipermail/freebsd-hackers/2014-September/thread.html#45955
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 15 20:01:25 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Oct 2014 20:01:25 +0000
Subject: [Bug 194386] Common storage of original MAC address
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194386
rpokala at panasas.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rpokala at panasas.com
--- Comment #1 from rpokala at panasas.com ---
Created attachment 148347
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148347&action=edit
Patch to add common storage of original MAC address
194386.patch - Patch to implement the desired functionality, as discussed on
freebsd-hackers at .
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 15 20:01:55 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Oct 2014 20:01:54 +0000
Subject: [Bug 194359] bsdinstall should set active flag in GPT PMBR if not
booting using EFI
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #11 from Marcel Moolenaar ---
(In reply to Ed Maste from comment #9)
> > If the installer knows what the firmware is ((I don't know if we pass anything from the loader to the kernel))
>
> We report if the system was booted by BIOS or UEFI via the
> machdep.bootmethod sysctl (returns BIOS or UEFI).
>
> I think this won't help though, because it returns BIOS for both the legacy
> BIOS case and the UEFI CSM (i.e. simulated BIOS) case, and based on the
> discussion here it seems (some) real BIOS needs the PMBR active flag set
> while CSM needs it unset.
I guess that means we need to be able to distinguish between true BIOS and UEFI
CSM. There seems to be some code for that:
http://kernel.ubuntu.com/git?p=cking/debug-code/.git;a=commit;h=2e654e01bf4014b27387cf64bb03316064478eea
I have no idea how well this works or if this is at all a legit way to do that.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 15 20:17:45 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Oct 2014 20:17:45 +0000
Subject: [Bug 194359] bsdinstall should set active flag in GPT PMBR if not
booting using EFI
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #12 from Ed Maste ---
>From that file:
> 73 if (stat("/sys/firmware/efi", &buf) != -1)
> 74 flag |= EFI_SUPPORT;
I'm not sure if Linux creates /sys/firmware/efi for the legacy boot case, but
if so we'd need to find out how it does that.
Do we know which systems fail to boot with PMBR active bit set in the
non-(U)EFI boot case?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 15 23:05:49 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Oct 2014 23:05:49 +0000
Subject: [Bug 194394] New: rc infrastructure uses egrep in places; egrep not
provided with /rescue; breaks some custom infrastructures like mfsbsd
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194394
Bug ID: 194394
Summary: rc infrastructure uses egrep in places; egrep not
provided with /rescue; breaks some custom
infrastructures like mfsbsd
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: ngie at FreeBSD.org
mfsbsd doesn't have /usr mounted immediately, so some tools like egrep aren't
available, which means that some of the rc infrastructure doesn't necessarily
work as expected.
egrep should be added to /rescue as a hardlink.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Oct 15 23:09:19 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Oct 2014 23:09:19 +0000
Subject: [Bug 194394] rc infrastructure uses egrep in places; egrep not
provided with /rescue; breaks some custom infrastructures like mfsbsd
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194394
Garrett Cooper changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Needs Triage |Issue Resolved
Resolution|--- |Not A Bug
--- Comment #1 from Garrett Cooper ---
Sorry. The change done was internal to Isilon, i.e. not a bug :(...
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 16 01:08:00 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Oct 2014 01:08:00 +0000
Subject: [Bug 194359] bsdinstall should set active flag in GPT PMBR if not
booting using EFI
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #13 from Marcel Moolenaar ---
(In reply to Ed Maste from comment #12)
> From that file:
> > 73 if (stat("/sys/firmware/efi", &buf) != -1)
> > 74 flag |= EFI_SUPPORT;
>
> I'm not sure if Linux creates /sys/firmware/efi for the legacy boot case,
> but if so we'd need to find out how it does that.
>
> Do we know which systems fail to boot with PMBR active bit set in the
> non-(U)EFI boot case?
I known ia64 rejects the partitioning entirely. I belief lstewart@ ran into the
problems on x86 that triggered the change to not set the active flag by
default.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 16 01:21:44 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Oct 2014 01:21:43 +0000
Subject: [Bug 194359] bsdinstall should set active flag in GPT PMBR if not
booting using EFI
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #14 from Craig Rodrigues ---
lstewart described the problem he encountered here:
https://lists.freebsd.org/pipermail/freebsd-fs/2012-August/014864.html
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 16 01:28:07 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Oct 2014 01:28:07 +0000
Subject: [Bug 194397] New: Base GNU grep does not handle \s in extended regex
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194397
Bug ID: 194397
Summary: Base GNU grep does not handle \s in extended regex
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: emaste at freebsd.org
\s should match whitespace but does not:
FreeBSD 11.0-CURRENT from Sep. 21
joule% echo 'a b' | /usr/bin/grep -E '^a\sb'
joule%
joule% /usr/bin/grep --version
grep (GNU grep) 2.5.1-FreeBSD
GNU grep package works:
joule% echo 'a b' | /usr/local/bin/grep -E '^a\sb'
a b
joule% /usr/local/bin/grep --version
/usr/local/bin/grep (GNU grep) 2.20
BSD grep works:
echo 'a b' | /usr/bin/bsdgrep -E '^a\sb'
joule% /usr/bin/bsdgrep --version
bsdgrep (BSD grep) 2.5.1-FreeBSD
BSD grep and base GNU grep both link against /usr/lib/libgnuregex.so.5
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 16 03:39:40 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Oct 2014 03:39:40 +0000
Subject: [Bug 194397] Base GNU grep does not handle \s in extended regex
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194397
Ed Maste changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|Affects Only Me |Affects Some People
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 16 06:07:46 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Oct 2014 06:07:46 +0000
Subject: [Bug 194398] New: lib/libc/posix1e/acl_size.c is stubbed out/not
integrated into lib/libc; should it be reaped?
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194398
Bug ID: 194398
Summary: lib/libc/posix1e/acl_size.c is stubbed out/not
integrated into lib/libc; should it be reaped?
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: ngie at FreeBSD.org
Something I noticed in passing while reading through some XXX comments about it
"being present in libc, but not available in the build" at Isilon.
$ grep -r acl_size /usr/src/lib/libc/
/usr/src/lib/libc/posix1e/acl_size.c:acl_size(acl_t acl)
$ grep acl_size /usr/src/lib/libc/posix1e/Makefile.inc || echo not found
not found
Maybe the file should just be removed?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 16 09:14:15 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Oct 2014 09:14:15 +0000
Subject: [Bug 192431] Crypt(3) (-lcrypt) does not work as documented
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192431
Dag-Erling Sm??rgrav changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Needs Triage |Issue Resolved
CC| |des at FreeBSD.org
Resolution|--- |DUPLICATE
--- Comment #1 from Dag-Erling Sm??rgrav ---
*** This bug has been marked as a duplicate of bug 192277 ***
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 16 10:45:23 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Oct 2014 10:45:23 +0000
Subject: [Bug 194401] New: bsd.port.mk's OSVERSION change interferes with
option WITHOUT_TOOLCHAIN in src.conf
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194401
Bug ID: 194401
Summary: bsd.port.mk's OSVERSION change interferes with option
WITHOUT_TOOLCHAIN in src.conf
Product: Base System
Version: 10.0-STABLE
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: misc
Assignee: freebsd-bugs at FreeBSD.org
Reporter: bugzilla.freebsd at omnilan.de
Created attachment 148369
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148369&action=edit
Install /usr/include/sys/param.h with WITHOUT_TOOLCHAIN set
In ports/Mk/bsd.ports.mk the following cahnge was made:
-OSVERSION!= ${SYSCTL} -n kern.osreldate
+.error Unable to determine OS version. Either define OSVERSION, install
/usr/include/sys/param.h or define SRC_BASE.
On systems which were installed with "WITHOUT_TOOLCHAIN=true" in src.conf,
there is no 'param.h'.
Since BSD.include.dist will always be populated by mtree at installworld stage,
regardless the WITHOUT_TOOLCHAIN option, I'd like to see param.h beeing present
an all systems, also regardless of WITHOUT_TOOLCHAIN.
The attached patch incorporates this.
It's useful for using the ports-tree as information source, when someone might
want to 'make fetch' or 'make makesum' (for automated updates of own ports) or
'make -V'...
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 16 15:35:31 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Oct 2014 15:35:31 +0000
Subject: [Bug 194401] bsd.port.mk's OSVERSION change interferes with option
WITHOUT_TOOLCHAIN in src.conf
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194401
Brooks Davis changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |brooks at FreeBSD.org
--- Comment #1 from Brooks Davis ---
How is the ports collection remotely useful on a system without a toolchain? I
guess "make index" might work, but nothing will build so what's the point?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 16 16:06:49 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Oct 2014 16:06:49 +0000
Subject: [Bug 194401] bsd.port.mk's OSVERSION change interferes with option
WITHOUT_TOOLCHAIN in src.conf
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194401
--- Comment #2 from Brooks Davis ---
Sorry, missed your examples in the first message. I apologize for not reading
carefully. The first two cases seem like the sort of thing we'd like to note
support as they could be harmful to the project. It really don't make sense to
update a port if you can't build it.
The error message suggests a perfectly functional workaround. Why is that not
acceptable? Just add:
OSVERSION!=sysctl -n kern.osreldate
to your make.conf or put in your environment.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 16 16:44:44 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Oct 2014 16:44:44 +0000
Subject: [Bug 194401] bsd.port.mk's OSVERSION change interferes with option
WITHOUT_TOOLCHAIN in src.conf
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194401
--- Comment #3 from Harald Schmalzbauer ---
(In reply to Brooks Davis from comment #2)
> Sorry, missed your examples in the first message. I apologize for not
> reading carefully. The first two cases seem like the sort of thing we'd
> like to note support as they could be harmful to the project. It really
> don't make sense to update a port if you can't build it.
The 'make makesum' example is from a very special case! We do automated
'distfile' updates for local (inofficial) ports with a script running on a
jail-host without toolchain.
The 'make fetch' example is often useful if you want to get a quick look into
any unknown project. Downloading source doesn't implicate the intention to
compile it ? but it could be done in a very convenient way with the help of
'make fetch'.
Checking for updates without compiling them (portmaster -ai e.g.) absolutely
makes sense, also on machines which can't even compile anything themself!
I frequently do this on remote machines without toolchains, but with read-only
(temporary) ports tree because it's the fastest way (I'm ware of) to determine
what updates _would_ be available.
If there's something relevant for upgrading revealed, I go to the build host
(which has knwoledge of detailed project info regarding the destination host,
like what complete port set is installed, corresponding db/ports/* options
etc.) and roll out a package repository CD on that build host, which afterward
gets mounted on the destination machine and pkg upgrade will do the rest.
(Using FreeBSDs pkg repositroy is not an option for almost all of my setups,
since virtually every port was compiled with non-standard options defined!)
> The error message suggests a perfectly functional workaround. Why is that
> not acceptable? Just add:
>
> OSVERSION!=sysctl -n kern.osreldate
>
> to your make.conf or put in your environment.
For the same reason it was changed in bsd.ports.mk. It's very often wrong.
Doesn't matter for the tasks described here, but I think there's a better
solution - unconditionally shipping param.h. Like described, regardless of the
WITHOUT_TOOLCHAIN option, there's always a populated /usr/include directory
tree, so adding the 11kB "param.h" shouldn't hurt in any way, but it could be
used as a reliable source of correct version information, which si not possible
with 'sysctl -n kern.osreldate'
Thanks,
-Harry
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 16 18:30:48 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Oct 2014 18:30:48 +0000
Subject: [Bug 194398] lib/libc/posix1e/acl_size.c is stubbed out/not
integrated into lib/libc; should it be reaped?
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194398
Edward Tomasz Napierala changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Needs Triage |Open
CC| |trasz at FreeBSD.org
Assignee|freebsd-bugs at FreeBSD.org |trasz at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 16 20:03:03 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Oct 2014 20:03:03 +0000
Subject: [Bug 194234] [ixgbe] Update ixgbe to 2.5.27
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194234
Eric Joyner changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jhb at FreeBSD.org
--- Comment #2 from Eric Joyner ---
I'll re-submit a core code patch; John Baldwin made valid comments about some
parts of it.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 16 20:18:08 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Oct 2014 20:18:08 +0000
Subject: [Bug 183494] [PATCH] limits(1): usr.bin/limits: cannot set kqueues
limit
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183494
Bryan Drewery changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|In Discussion |Issue Resolved
CC| |bdrewery at FreeBSD.org
Resolution|--- |FIXED
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 16 20:18:29 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Oct 2014 20:18:29 +0000
Subject: [Bug 183484] [PATCH] limits(1): usr.bin/limits: make -e work without
/proc
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183484
Bryan Drewery changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|In Discussion |Issue Resolved
CC| |bdrewery at FreeBSD.org
Resolution|--- |FIXED
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 16 21:27:30 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Oct 2014 21:27:30 +0000
Subject: [Bug 194386] Common storage of original MAC address
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194386
--- Comment #2 from rpokala at panasas.com ---
Brooks / Allan / John - since you all chimed in on the thread where this was
designed, could one of you review this and submit it for me? Thanks!
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Oct 16 22:38:49 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Oct 2014 22:38:49 +0000
Subject: [Bug 193496] Inconsistent trailing space in "geli init" output
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193496
Gavin Atkinson changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gavin at FreeBSD.org
--- Comment #1 from Gavin Atkinson ---
Hi,
It doesn't look lie your patch was attached to the PR successfully - could you
resubmit it please?
Thanks,
Gavin
--
You are receiving this mail because:
You are the assignee for the bug.
From heavenlywords at angelofthelord.net Thu Oct 16 22:39:59 2014
From: heavenlywords at angelofthelord.net (Heavenly Words)
Date: Thu, 16 Oct 2014 14:28:12 -0700
Subject: [Prophecy] October 16, 2014 Communique - Gog And Magog - Part III
Message-ID:
Christian Media
Communiqu?
GOG AND MAGOG - Part III
The Valley Of Dry Bones
In our last installment examining the prophecies of Ezekiel preceding
the famous Gog and Magog attack on Israel in Ezekiel 38 and 39, we
showed how God pronounced judgment on Mount Seir, and the Idumaean
identity, for their ongoing “envy” of Israel. This
repudiation of the descendants of Esau, Abraham’s promissory
descendant who wasted his preferential position, is confirmed in
adjacent prophets, notably Isaiah, Obadiah, and Malachi.
“…and they shall call them…The people against whom
the Lord hath indignation forever” (Malachi 1:4).
Isaiah provides a 2nd witness to Ezekiel’s denunciation of
“Mount Seir,” Esau’s ancestral home, saying it will
be a land of eternal desolation, a dusty desolate locale which is to be
the object of God’s eternal wrath:
“And the streams thereof shall be turned into pitch, and dust
thereof into brimstone, and the land thereof shall become burning
pitch…from generation to generation it shall lie waste; none
shall pass through it forever and ever” (Isaiah 34:9).
This wrath of God against the Edomite identity (Idumaea is a variant
name of Edomaea), occurs in the same chapter of Ezekiel, in which God
promises to eternally bless the lost sheep of the house of Israel,
through the work of “one shepherd” – who is
associated with the house of David. This grace, which is to be
Spiritually poured out upon Israel, in which God vows to install
“a new heart” and “put my spirit within you,”
occurs in the chapter preceding Ezekiel 37, where we find the
astonishing prophecy of the LORD raising up a people out of a valley
filled with dead and dry bones:
“Then he said unto me, Son of man, these bones are the whole
house of Israel: behold, they say, Our bones are dried, and our hope is
lost…as I prophesied, there was a noise, and behold a shaking,
and the bones came together, bone to his bone, the skin covered them
above…and the breath came into them, and they lived, and stood
upon their feet…” (Ezekiel 37:11, 10).
Such passages expose those who insist on literal prophetic fulfillment
as exceedingly foolish. However, metaphorically speaking, it is a
historical fact that this was fulfilled long ago. Years after the time
of Ezekiel, in the days of the Persian Union (well after the 70 years
of the Babylonian captivity of Ezekiel and Daniel’s generations),
Nehemiah received the “commandment to restore and to build
Jerusalem” (Daniel 9:25) and, in the midst of fierce opposition,
he achieved the re-settlement of Jewish exiles in Judaea and Jerusalem:
“…when Sanballat, and Tobiah, and the Arabians, and the
Ashdodites [all related to Edom] heard that the walls of Jerusalem were
made up, and that the breaches began to be stopped, then they were very
wroth. And conspired all of them together to come and fight against
Jerusalem, and to hinder it” (Nehemiah 4:7, 8).
After many years of hardship, with tremendous antagonism and
significant violence arrayed against them, the Jews led by Nehemiah,
were regathered in Jerusalem, and rebuilt the temple of the LORD -- but
the entrance of the Spirit of the LORD would await the arrival of
JESUS, many generations later.
“…but there was no breath in them [the dry bones]. Then he
said unto me, Prophesy unto the wind, prophesy, son of man, and say to
the wind, Thus saith the Lord God; Come from the four winds, O breath,
and breathe upon these slain, that they may live” (Ezekiel 37:
8,9).
When the Word of God, Jesus Christ, arrived centuries later to
regenerate Israel, the Jews had long forgotten the revival of their
faith which had occurred in the days of Nehemiah. However, God had not
forgotten His promises, given through Ezekiel, to “take away the
stony heart” and place “a new spirit” (Ezekiel 36:26)
within what was to become born again Israel:
“…some seeds….fell upon stony places, where they had
not much earth…some fell by the way side, and it was trodden
down, and the fowls of the air devoured it. But other fell into good
ground, and brought forth fruit, some an hundredfold, some sixtyfold,
some thirtyfold” (Matthew 13:4, 5, Luke 8:5, Matthew 13:8)
The prophet Ezekiel, in the last chapter preceding the introduction of
Gog and Magog as the ultimate enemy of God’s people Israel,
clearly separated the regathering of Israel, from the breath of God
which was to resurrect them:
“…but there was no breath in them [the dry bones]. Then he
said unto me, Prophesy unto the wind, prophesy, son of man, and say to
the wind, Thus saith the Lord God; Come from the four winds, O breath,
and breathe upon these slain, that they may live” (Ezekiel 37:
8,9).
Thus, after His crucifixion and resurrection, as Jesus had assembled
His temple of believers to give them His parting instructions, he told
His disciples to remain in Jerusalem because there was one more phase
of God’s ancient promise in Ezekiel, which was yet to come:
“And, behold, I send the promise of my Father upon you: but tarry
ye in the city of Jerusalem, until ye be endued with power from on
high” (Luke 24:49).
Most believers know the astonishing story of how the disciples were all
gathered together, when the promise of the Father to fill those dry
bones with His Spirit was miraculously fulfilled:
“And suddenly there came a sound from heaven as of a rushing
mighty wind, and it filled all the house where they were sitting. And
they were all filled with the Holy Ghost, and began to speak with other
tongues, as the Spirit gave them utterance…and the same day were
added unto them about three thousand souls” (Acts 2: 2, 41).
When the LORD’s Spirit was poured out, Jerusalem was hosting
people from the surrounding nations, who had gathered for the feast of
Pentecost:
“And they were all amazed and marvelled…Parthians, and
Medes, and Elamites, and the dwellers in Mosopotamia, and in Judaea,
and Cappadocia, in Pontus, and Asia. Phygia, and Pamphylia, in Egypt,
and in the parts of Libya about Cyrene, and strangers of Rome, Jews and
proselytes. Cretess and Arabians…And when this was noised abroad,
the multitude came together….” (Acts 2:7, 9-11, 6).
Thus, the passage of the Dry Bones, in which the LORD said He would
gather together His people from the nations, and put “a new
spirit” within them, a prophecy characterizing the Spirit of God
as wind, was fulfilled:
“For I will take you from among the heathen, and gather you out
of all countries….After many days thou shalt be visited: in the
latter years thou shalt come into the land that is brought back from
the sword, and is gathered out of many people, against the mountains of
Israel, which have been always waste; but it is brought forth out of
the nations, and they shall dwell safely all of them” (Ezekiel
36:24, 38:8).
Those who retained their “stony” heart, and those who
mocked the amazing fulfillment of God’s promise to redeem the
metaphoric “mountains of Israel,” became the Spiritual
mountains of Idumaea (Ezekiel 35:2, 8, 15), even as rivers of living
water flowed throughout the genuine Israel of God (Galatians 6:16,
Romans 8:14) – the body of believers who heard and responded to
the call of Jesus of Nazareth.
-- James Lloyd
Next: The Two Houses Of Israel And Judah Are Made One House With One
King
________________________________________________________________________
________________________________________________________________________
Dear Christian Friend,
This prophecy article was sent to you by one of our volunteers –
a person who believes the LORD is doing a very special work at the
ministry which produces this writing. People need to receive this
information, but the resistance is fierce in these end times.
The Communique is but a part of the Christian Media ministry. A lot of
people are trying to stop us from what we’re doing in Bible
Prophecy, so if you’d like to read more along the lines of the
present writing, we would love to send you the Communique in the future
-- but we need to hear from you, as there are far too many people out
there to continually send it on an unsolicited basis.
To get the next installment of the Communique (it’s all free),
just hit reply and put the word YES! in the subject line, and the
person who forwarded this email to you will arrange for us to send you
links on prophecy and predictions of things you can expect to see in
the near future.
We also stream prophecy audio 24/7 and have downloadable video shows as
well, so a YES! response will get you all the links you need to access
these materials.
Some are convinced Christians should never send an Email to someone
without permission (Did the Disciples of Jesus ask people for
permission to tell them the Good News?), while others don’t
consider prophecy important – and there are other reasons people
don’t want to receive our material. If that’s the case,
just reply with the word REMOVE in the subject line (that part is
important as our software looks for that word), and we will cheerfully
delete your name from our database.
Thanks for reading this far, and we hope you’ll respond
favorably, reply with a YES!, and take a look at what the LORD has
shown us here at the Christian Media ministry.
________________________________________________________________________
__________________
Welcome To The World Of Christian Media!
Christian Media
PO Box 1414
Medford OR 97501
541/899/8888
From bugzilla-noreply at freebsd.org Thu Oct 16 22:45:31 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Oct 2014 22:45:31 +0000
Subject: [Bug 192000] ports-mgmt/pkg reports wrong version when refusing to
downgrade
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192000
Gavin Atkinson changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Needs Triage |Open
Component|bin |Individual Port(s)
Version|11.0-CURRENT |Latest
Assignee|freebsd-bugs at FreeBSD.org |freebsd-ports-bugs at FreeBSD.
| |org
Product|Base System |Ports Tree
Summary|pkg reports wrong version |ports-mgmt/pkg reports
|when refusing to downgrade |wrong version when refusing
| |to downgrade
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 17 03:56:02 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 17 Oct 2014 03:56:01 +0000
Subject: [Bug 146079] FreeBSD-8.0 handbook out of date
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=146079
--- Comment #3 from commit-hook at freebsd.org ---
A commit references this bug:
Author: gjb
Date: Fri Oct 17 03:55:34 UTC 2014
New revision: 273204
URL: https://svnweb.freebsd.org/changeset/base/273204
Log:
Add more descriptive metadata to the ISO images.
PR: 146079
Submitted by: Roman Bogorodskiy
MFC after: 3 days
X-MFC-10.1: yes
Sponsored by: The FreeBSD Foundation
Changes:
head/release/Makefile
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 17 03:59:19 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 17 Oct 2014 03:59:19 +0000
Subject: [Bug 146079] FreeBSD-8.0 handbook out of date
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=146079
--- Comment #4 from Glen Barber ---
Oops, referenced wrong PR in this commit.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 17 06:19:00 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 17 Oct 2014 06:19:00 +0000
Subject: [Bug 164763] [vnet] Memory leak in VNET
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=164763
Craig Rodrigues changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rodrigc at FreeBSD.org
Assignee|freebsd-bugs at FreeBSD.org |freebsd-net at FreeBSD.org
--- Comment #5 from Craig Rodrigues ---
Bjoern gave a link to his Perforce repo here:
https://lists.freebsd.org/pipermail/freebsd-net/2014-October/040075.html
It would be good to merge these memory leak fixes into FreeBSD HEAD
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 17 06:37:25 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 17 Oct 2014 06:37:25 +0000
Subject: [Bug 191468] [vimage] options VIMAGE - kernel panic, crashes during
system boot
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191468
Craig Rodrigues changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rodrigc at FreeBSD.org
Assignee|freebsd-bugs at FreeBSD.org |freebsd-net at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Oct 17 06:40:31 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 17 Oct 2014 06:40:31 +0000
Subject: [Bug 184149] [vimage] IPv6 link-local collisions on epair[n]b devices
In-Reply-To: