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: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184149 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 09:57:34 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 09:57:34 +0000 Subject: [Bug 194416] New: Testing123 Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194416 Bug ID: 194416 Summary: Testing123 Product: Base System Version: 10.0-STABLE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Only Me Priority: Normal Component: misc Assignee: freebsd-bugs at FreeBSD.org Reporter: gavin at FreeBSD.org Just a test Environment: System: FreeBSD 10.0-STABLE FreeBSD 10.0-STABLE #0 r264497: Tue Apr 15 15:30:43 BST 2014 ga9 at g500s.lab.devrandom.co.uk:/usr/obj/space/freebsd/stable/10/sys/GENERIC amd64 How-To-Repeat: Test Fix: Test -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 17 11:14:49 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 11:14: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 fk at fabiankeil.de changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #147130|0 |1 is obsolete| | --- Comment #2 from fk at fabiankeil.de --- Created attachment 148389 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148389&action=edit Patch to remove trailing space in message requesting reentry of new passphrase -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 17 11:16:42 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 11:16:42 +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 --- Comment #3 from fk at fabiankeil.de --- The second attempt seems to have been successful. Thanks. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 17 11:17:25 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 11:17:25 +0000 Subject: [Bug 181116] CURRENT build always uses bmake, even though WITHOUT_BMAKE is specified In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181116 John Marino changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Issue Resolved CC| |marino at FreeBSD.org Resolution|--- |Overcome By Events --- Comment #7 from John Marino --- It seems that WITHOUT_BMAKE isn't implemented anymore. In fact, the old make isn't an option anymore, so this PR is obsolete. I'm closing it. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 17 11:32:36 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 11:32:36 +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 fk at fabiankeil.de changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #148389|0 |1 is obsolete| | --- Comment #4 from fk at fabiankeil.de --- Comment on attachment 148389 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148389 Patch to remove trailing space in message requesting reentry of new passphrase Please disregard this patch, I'll provide a better one in a couple of minutes. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 17 11:45:43 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 11:45:43 +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 --- Comment #5 from fk at fabiankeil.de --- Created attachment 148390 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148390&action=edit geli: Consistently use a trailing space in passphrase promts This patch adds trailing spaces to the two prompts that currently don't have one. All the other geli passphrase prompts seem to use a trailing space and the example in geli(8) were the password is shown has a space, too. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 17 12:30:44 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 12:30:44 +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 ---------------------------------------------------------------------------- Status|Needs Triage |Open --- Comment #24 from Oliver Pinter --- The UEFI mode remained broken, but in legacy mode I can install FreeBSD with the described hack. In overall, in legacy mode the system will boot if copied the loader binary (compiled with gcc) from FreeBSD 9.3 release to memstick usb installer, and named loader.gcc, and manually change to load them at boot time. After this, the installation completed as expected and the system able to boot up with the original 11-CURRENT's loader (which compiled with clang). -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 17 13:55:54 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 13:55:54 +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 #3 from commit-hook at freebsd.org --- A commit references this bug: Author: emaste Date: Fri Oct 17 13:55:46 UTC 2014 New revision: 273219 URL: https://svnweb.freebsd.org/changeset/base/273219 Log: Do nothing in vt_upgrade if there is no vt driver Previously, if no drivers attached at boot we would panic with "vtbuf_fill_locked begin.tp_row 0 must be < screen height 0". PR: 192248 Reviewed by: ray MFC after: 3 days Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D954 Changes: head/sys/dev/vt/vt_core.c -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 17 16:16:17 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 16:16:16 +0000 Subject: [Bug 194420] New: [vt] unloading i915kms causes black screen and reboot. Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194420 Bug ID: 194420 Summary: [vt] unloading i915kms causes black screen and reboot. Product: Base System Version: 10.0-STABLE Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: sasamotikomi at gmail.com I update my system (freebsd-update) from 10.1-RC1 to 10.1-RC2 and I see problem with unloading kernel module: I can load module(without X): # kldload i915kms (I think all fine but screen isn't cleaning for some reason) If I try unload kernel module (without X): # kldload i915kms I got black screen and system freeze(keyboard and mouse isn't work) and after 5-10 min just reboot without panic or any message. Hardware is intel GMA 3150. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 17 16:29:09 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 16:29:08 +0000 Subject: [Bug 194421] New: [vt] output still messy and discontinuous. Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194421 Bug ID: 194421 Summary: [vt] output still messy and discontinuous. Product: Base System Version: 10.0-STABLE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: sasamotikomi at gmail.com I tested (intel GMA 3150) 10.1-BETA 2/3 and 10.1-RC1/2 output still dirty and occurs in spurts and not so smooth compared with SYSCONS. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 17 16:59:20 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 16:59:20 +0000 Subject: [Bug 194421] [vt] output still messy and discontinuous. In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194421 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |vt 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 17 17:00:30 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 17:00:31 +0000 Subject: [Bug 194421] [vt] output still messy and discontinuous. In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194421 --- Comment #1 from Ed Maste --- Can you please quantify "dirty"? Perhaps a video showing what you observe. Also, please add details on the system. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 17 18:23:16 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 18:23:16 +0000 Subject: [Bug 194420] unloading i915kms causes black screen and reboot. In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194420 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |i915 Status|Needs Triage |In Discussion CC| |emaste at freebsd.org Summary|[vt] unloading i915kms |unloading i915kms causes |causes black screen and |black screen and reboot. |reboot. | --- Comment #1 from Ed Maste --- > If I try unload kernel module (without X): > # kldload i915kms Presumably you meant "kldunload i915kms" there. This is an issue with the i915 driver, it is not currently unloadable. (There is a related vt issue in code review D687, but the driver needs to be sorted out first for that to matter here. https://reviews.freebsd.org/D687 ) -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 17 18:37:16 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 18:37:16 +0000 Subject: [Bug 194424] New: mountd(8): feature enhancement: no DNS, ip only Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194424 Bug ID: 194424 Summary: mountd(8): feature enhancement: no DNS, ip only 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: ldang at nahannisys.com Created attachment 148395 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148395&action=edit mountd ip-only option In an environment without reverse DNS for dynamic clients, mounting NFS fileystems take a delay until mountd fails to get the DNS entry for the client. This patch adds an "-i" switch to use only IP addresses for everything. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 17 18:50:35 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 18:50:35 +0000 Subject: [Bug 194421] [vt] output still messy and discontinuous. In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194421 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |In Discussion -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 17 19:13:31 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 19:13:31 +0000 Subject: [Bug 194420] unloading i915kms causes black screen and reboot. In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194420 --- Comment #2 from sasamotikomi at gmail.com --- (In reply to Ed Maste from comment #1) > > If I try unload kernel module (without X): > > # kldload i915kms > > Presumably you meant "kldunload i915kms" there. This is an issue with the > i915 driver, it is not currently unloadable. > > (There is a related vt issue in code review D687, but the driver needs to be > sorted out first for that to matter here. https://reviews.freebsd.org/D687 ) Yes, sorry it's my mistake, this is look like my problem, it's patch should include in RC3? -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 17 19:16:06 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 19:16:06 +0000 Subject: [Bug 194425] New: mountd(8): feature enhancement: restrict exports to authorized hosts Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194425 Bug ID: 194425 Summary: mountd(8): feature enhancement: restrict exports to authorized hosts 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: ldang at nahannisys.com Created attachment 148396 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148396&action=edit new option to restrict exports in mountd Currently mountd will return all entries for exports and dump requests. In some cases it is desirable for these to be restricted to only authorized hosts or completely hidden. This feature is available in commercial products, such as EMC (https://community.emc.com/docs/DOC-7003) and HP-UX. The attached patch has three options to restrict exports results, using a new "-x" switch: * visible = default, all visible * host = only return results applicable to the host * hide = fully hidden -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 17 19:42:18 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 19:42:18 +0000 Subject: [Bug 194420] unloading i915kms causes black screen and reboot. In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194420 --- Comment #3 from Ed Maste --- The change in code review is not in 10.1-RC3 -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 17 23:42:54 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 23:42:54 +0000 Subject: [Bug 194359] bsdinstall(8) 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 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Component|misc |bin Summary|bsdinstall should set |bsdinstall(8) should set |active flag in GPT PMBR if |active flag in GPT PMBR if |not booting using EFI |not booting using EFI --- Comment #15 from Mark Linimon --- reclassify. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 17 23:44:44 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 23:44:43 +0000 Subject: [Bug 194121] device.hints not honored when selecting UART for system console In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194121 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Component|misc |conf --- Comment #1 from Mark Linimon --- reclassify. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 17 23:46:44 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 23:46:44 +0000 Subject: [Bug 193944] pkg version -Rv reports wrong version when two repositories in use. In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193944 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Component|misc |Individual Port(s) Version|9.3-RELEASE |Latest Assignee|freebsd-bugs at FreeBSD.org |pkg at FreeBSD.org Product|Base System |Ports Tree --- Comment #1 from Mark Linimon --- reclassify. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 17 23:48:55 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 23:48:55 +0000 Subject: [Bug 192857] graphics/netpbm build fails and breaks releng/9.3 release build In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192857 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Component|misc |Individual Port(s) Version|9.3-RELEASE |Latest Assignee|freebsd-bugs at FreeBSD.org |dinoex at FreeBSD.org Product|Base System |Ports Tree Summary|netpbm build fails and |graphics/netpbm build fails |breaks releng/9.3 release |and breaks releng/9.3 |build |release build --- Comment #1 from Mark Linimon --- reclassify and assign. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 17 23:49:02 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 17 Oct 2014 23:49:02 +0000 Subject: [Bug 194439] New: mld_v1_transmit_report corrupts memory Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194439 Bug ID: 194439 Summary: mld_v1_transmit_report corrupts memory 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: Herbie.Robinson at stratus.com The "MH_ALIGN(mh, sizeof(struct ip6_hdr));" in mld_v1_transmit_report should be "MH_ALIGN(mh, sizeof(struct ip6_hdr)+sizeof(struct mld_hdr));". The current code will always walk off the end of the buffer and corrupt whatever memory follows. It's a good thing that mldv2 is widely supported :-) -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 18 00:03:36 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 18 Oct 2014 00:03:36 +0000 Subject: [Bug 194401] [src/include/Makefile] [patch] 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 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|bsd.port.mk's OSVERSION |[src/include/Makefile] |change interferes with |[patch] bsd.port.mk's |option WITHOUT_TOOLCHAIN in |OSVERSION change interferes |src.conf |with option | |WITHOUT_TOOLCHAIN in | |src.conf -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 18 01:02:53 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 18 Oct 2014 01:02:52 +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 #2 from commit-hook at freebsd.org --- A commit references this bug: Author: adrian Date: Sat Oct 18 01:02:31 UTC 2014 New revision: 273244 URL: https://svnweb.freebsd.org/changeset/base/273244 Log: MFC r273112: 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: _U stable/10/ stable/10/sys/dev/ixgbe/ixgbe.c -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 18 01:06:25 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 18 Oct 2014 01:06: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 Adrian Chadd changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs MFC |Issue Resolved Resolution|--- |FIXED --- Comment #3 from Adrian Chadd --- all done! Thanks Luigi! -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 18 14:35:51 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 18 Oct 2014 14:35:51 +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 slaytanic at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Version|6.3-PRERELEASE |10.0-STABLE 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 Sat Oct 18 17:24:24 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 18 Oct 2014 17:24:24 +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 Hiroki Sato changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hrs at FreeBSD.org Assignee|freebsd-bugs at FreeBSD.org |hrs at FreeBSD.org --- Comment #12 from Hiroki Sato --- I will look into this. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 18 17:48:13 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 18 Oct 2014 17:48:13 +0000 Subject: [Bug 192539] Ports Query: wxgtk30 & wxgtk29 aren't found In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192539 --- Comment #3 from Jordan Irwin --- Here's a little more clarification of what is affected. wxgtk29 is the only version that is found searching the ports collection. None of them are found using "pkg search" $ make quicksearch name=wxgtk28 $ make quicksearch name=wxgtk29 Port: x11-toolkits/wxgtk29 Moved: x11-toolkits/wxgtk30 Date: 2014-03-24 Reason: wxGTK 2.9 was a development version superseded by the 3.0 release $ make quicksearch name=wxgtk30 $ $ pkg search wxgtk28 $ pkg search wxgtk29 $ pkg search wxgtk30 -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 18 19:15:10 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 18 Oct 2014 19:15:09 +0000 Subject: [Bug 194453] New: [dummynet] pipe config bw parameter is limited to 2Gbits per second Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 Bug ID: 194453 Summary: [dummynet] pipe config bw parameter is limited to 2Gbits per second Product: Base System Version: 10.0-STABLE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Many People Priority: Normal Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: boba at boba.name It's impossible to create "pipe" with bandwidth higher than 2Gbits per second. Possible due to "signed" type of variable. # ipfw pipe 1 config bw 2700mbit/s ipfw: bandwidth too large -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 18 20:45:20 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 18 Oct 2014 20:45:20 +0000 Subject: [Bug 194455] New: [PATCH] Preserve lowmem for devices on large memory machines Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194455 Bug ID: 194455 Summary: [PATCH] Preserve lowmem for devices on large memory machines 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: conrad.meyer at isilon.com Created attachment 148440 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148440&action=edit ( applies with -p1 on CURRENT ~r273263 ) Log: ==================================8<================================== Add an intermediate VM_FREELIST "DMA32" between DEFAULT and ISADMA on AMD64. Physical allocations try freelists ascending, so the effect is to prefer DEFAULT, then DMA32, then ISADMA. This leaves low memory available for things that need it (DMA) on large-memory systems which statically allocate a lot (e.g. bufs). Sponsored by: EMC / Isilon storage division ==================================8<================================== Historical note/context: So, we have 96-256 GB systems, and scale nbufs up with memory. On these systems we tune for much more than 4GB in bufs. It turns out the 'buf' static array is allocated from physmem fairly early (along with some other things that scale with memory), and without this change, devices starved for 32-bit DMA space. Internally, we had just bumped the ISADMA region from 16MB (24-bit) to 4GB. I think the attached patch with a seperate 32-bit DMA region is slightly cleaner (and avoids other devices starving out ISA BUS DMA devices, if those still exist). But, either approach fixes the problem for us. So, if people object to adding another freelist, a compromise might be renaming the ISADMA freelist to "DMA" and bumping the region up to 32 bits. Testing on an AMD64 VM: # sysctl vm.phys_free vm.phys_free: DOMAIN 0: FREE LIST 0: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 | POOL 2 -- -- -- -- -- -- -- -- 12 ( 16384K) | 257 | 0 | 0 11 ( 8192K) | 0 | 0 | 0 10 ( 4096K) | 2 | 1 | 0 9 ( 2048K) | 2 | 0 | 0 8 ( 1024K) | 1 | 0 | 0 7 ( 512K) | 1 | 0 | 0 6 ( 256K) | 1 | 0 | 0 5 ( 128K) | 0 | 2 | 0 4 ( 64K) | 0 | 1 | 0 3 ( 32K) | 4 | 1 | 0 2 ( 16K) | 3 | 3 | 0 1 ( 8K) | 0 | 9 | 0 0 ( 4K) | 1 | 1 | 0 FREE LIST 1: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 | POOL 2 -- -- -- -- -- -- -- -- 12 ( 16384K) | 221 | 0 | 0 11 ( 8192K) | 1 | 0 | 0 10 ( 4096K) | 0 | 0 | 0 9 ( 2048K) | 1 | 0 | 0 8 ( 1024K) | 0 | 0 | 0 7 ( 512K) | 1 | 0 | 0 6 ( 256K) | 1 | 0 | 0 5 ( 128K) | 1 | 0 | 0 4 ( 64K) | 1 | 0 | 0 3 ( 32K) | 0 | 0 | 0 2 ( 16K) | 0 | 0 | 0 1 ( 8K) | 0 | 0 | 0 0 ( 4K) | 1 | 0 | 0 FREE LIST 2: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 | POOL 2 -- -- -- -- -- -- -- -- 12 ( 16384K) | 0 | 0 | 0 11 ( 8192K) | 0 | 0 | 0 10 ( 4096K) | 0 | 0 | 0 9 ( 2048K) | 0 | 0 | 0 8 ( 1024K) | 1 | 0 | 0 7 ( 512K) | 0 | 0 | 0 6 ( 256K) | 1 | 0 | 0 5 ( 128K) | 1 | 0 | 0 4 ( 64K) | 2 | 0 | 0 3 ( 32K) | 2 | 0 | 0 2 ( 16K) | 1 | 0 | 0 1 ( 8K) | 0 | 0 | 0 0 ( 4K) | 1 | 0 | 0 -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 18 20:47:59 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 18 Oct 2014 20:47:59 +0000 Subject: [Bug 194455] [PATCH] Preserve lowmem for devices on large memory machines In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194455 --- Comment #1 from Conrad Meyer --- For what it's worth, this is basically identical to the problem and patch in bug 185727. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 18 21:22:24 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 18 Oct 2014 21:22:25 +0000 Subject: [Bug 194416] Testing123 In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194416 Gavin Atkinson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |Issue Resolved Resolution|--- |Not A Bug -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sun Oct 19 07:05:49 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sun, 19 Oct 2014 07:05:48 +0000 Subject: [Bug 194455] [PATCH] Preserve lowmem for devices on large memory machines In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194455 Garrett Cooper changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |Issue Resolved CC| |ngie at FreeBSD.org Resolution|--- |DUPLICATE Severity|Affects Only Me |Affects Some People --- Comment #2 from Garrett Cooper --- Marking this bug as a duplicate of bug 185727. *** This bug has been marked as a duplicate of bug 185727 *** -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sun Oct 19 12:53:40 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sun, 19 Oct 2014 12:53:40 +0000 Subject: [Bug 194466] New: Update printf(1) to support %T and %q bashisms [patch] Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194466 Bug ID: 194466 Summary: Update printf(1) to support %T and %q bashisms [patch] Product: Base System Version: 9.3-PRERELEASE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Only Me Priority: Normal Component: bin Assignee: freebsd-bugs at FreeBSD.org Reporter: mi at ALDAN.algebra.com The printf-implementation built into recent bash offers a very useful feature: %(datefmt)T causes printf to output the date-time string resulting from using datefmt as a format string for strftime(3). The corresponding argument is an integer representing the number of seconds since the epoch. Two special argument values may be used: -1 represents the current time, and -2 represents the time the shell was invoked. The feature makes it easier for script to produce time-stamped logs -- it can now be done without spawning a separate date(1) process for each log-entry. The enclosed patch updates our printf to support it. My patch one-ups bash-implementation by making the format string optional -- if simple %T is used, the "%a %b %d %T %Z %Y" is used by default (same as date(1)). My implementation also provides for future additions of other format-characters, which may need their own (sub)formats. For example, some day we may extend the built-in printf to print information about the process itself and any of the jobs -- using the same format-flexibility as ps(1): printf %(%cpu %mem)P -1 The patch also implements the %q feature of bash's printf to help escape special characters -- for completeness. While here, I also update the oft-used PF-macro to simply use printf(3), instead of the asprintf->fputs->free sequence. This hunk is separate from the new functionality, though, and can be omitted, if the current code is correct. Environment: System: FreeBSD narawntapu 9.3-PRERELEASE Fix: Index: printf.1 =================================================================== --- printf.1 (revision 273142) +++ printf.1 (working copy) @@ -290,6 +290,29 @@ .Cm \e0 Ns Ar num instead of .Cm \e Ns Ar num . +.It Cm q +As for +.Cm s , +but with certain characters (such as braces, blanks, parentheses and the like) +escaped. This makes the result (re)usable as shell argument or input. +.It Cm [(format)]T +Interpret the argument as the number of seconds since Unix epoch and turn +it into a timestamp according to +.Ar format . +If format is omitted, the string "%a %b %d %T %Z %Y" will be used -- this +is, what date(1) does by default. The specified format is passed to strftime(3). +As with +.Nm bash , +two special values for seconds-value are recognized to mean: +.Bl -tag -width Ds +.It -1 +current time. This allows scripts to log messages with timestamps without +executing date(1) for each message. +.It -2 +time, when the current sh-process was started. When using the standalone +.Nm +(rather than the sh-builtin), -2 and -1 are identical. +.El .It Cm \&% Print a `%'; no argument is used. .El @@ -322,6 +345,7 @@ .Xr echo 1 , .Xr sh 1 , .Xr printf 3 +.Xr strftime 3 .Sh STANDARDS The .Nm Index: printf.c =================================================================== --- printf.c (revision 273142) +++ printf.c (working copy) @@ -47,7 +47,12 @@ "$FreeBSD$"; #endif /* not lint */ +#include #include +#ifdef SHELL +#include +#include +#endif #include #include @@ -67,20 +72,15 @@ #endif #define PF(f, func) do { \ - char *b = NULL; \ if (havewidth) \ if (haveprec) \ - (void)asprintf(&b, f, fieldwidth, precision, func); \ + (void)printf(f, fieldwidth, precision, func); \ else \ - (void)asprintf(&b, f, fieldwidth, func); \ + (void)printf(f, fieldwidth, func); \ else if (haveprec) \ - (void)asprintf(&b, f, precision, func); \ + (void)printf(f, precision, func); \ else \ - (void)asprintf(&b, f, func); \ - if (b) { \ - (void)fputs(b, stdout); \ - free(b); \ - } \ + (void)printf(f, func); \ } while (0) static int asciicode(void); @@ -93,6 +93,9 @@ static const char *getstr(void); static char *mknum(char *, char); +#if defined(SHELL) +static void getstarttime(struct timeval *ptv); +#endif static void usage(void); static char **gargv; @@ -191,7 +194,10 @@ { static const char skip1[] = "#'-+ 0"; static const char skip2[] = "0123456789"; + static const char needescaping[] = "\n\t !\"$&'()*,;<>?[\\]^`{|}"; + char *fmt; + static char *subfmt; int fieldwidth, haveprec, havewidth, mod_ldbl, precision; char convch, nextch; @@ -281,6 +287,25 @@ PF(start, p); break; } + case 'q': { + const char *s, *p; + + s = getstr(); + /* + * #-signs only need escaping, if found at the beginning. + * ~ is only escaped at the beginning or after ':' or '=' + * Other special characters are always escaped: + */ + for (p = s; *p != '\0'; p++) { + if ((*p == '#' && p == s) || + (*p == '~' && + (p == s || p[-1] == ':' || p[-1] == '=')) || + index(needescaping, *p)) { + putchar('\\'); + } + putchar(*p); + } + } case 's': { const char *p; @@ -319,6 +344,98 @@ PF(start, (double)p); break; } + case '(': { + char *end = index(fmt + 1, ')'); + + if (end == NULL) { + warnx("No closing ')' detected"); + return (NULL); + } + + if (subfmt != NULL) { + warnx("Subformat \"%s\" already set", subfmt); + return NULL; + } + if (end == fmt) + break; /* Empty format -- presume default */ + asprintf(&subfmt, "%c%.*s", nextch, + (int)(end - fmt - 1), fmt + 1); + if (subfmt == NULL) { + warnx("%s", strerror(ENOMEM)); + return (NULL); + } + *fmt = nextch; + *end = '%'; + return (end); + } + case 'T': { + char *timebuf = NULL; + size_t buflen, timelen; + const char *timefmt; + intmax_t val; + uintmax_t uval; + struct timeval tv; + + if (subfmt == NULL) + timefmt = "%a %b %d %T %Z %Y"; /* date(1)'s default */ + else + timefmt = subfmt; + if (getnum(&val, &uval, 1) || (tv.tv_sec = val) != val) { + if (subfmt != NULL) { + free(subfmt); + subfmt = NULL; + } + *rval = 1; + return NULL; + } + switch (tv.tv_sec) { + case -2: +#if defined(SHELL) + getstarttime(&tv); + break; + /* Outside of shell, -2 and -1 both mean current time */ +#endif + case -1: + gettimeofday(&tv, NULL); + break; + default: + if (tv.tv_sec < 0) { + warnx("Can not turn %jd into date/time", val); + if (subfmt != NULL) { + free(subfmt); + subfmt = NULL; + } + *rval = 1; + return NULL; + } + } + /* + * No (easy) way to know, how big the buffer needs to be. + * Start small and double as necessary: + */ + buflen = strlen(timefmt) * 4; /* harmless overestimate */ + do { + buflen *= 2; + timebuf = realloc(timebuf, buflen); + if (timebuf == NULL) { + if (subfmt != NULL) { + free(subfmt); + subfmt = NULL; + } + warnx("%s", strerror(ENOMEM)); + return (NULL); + } + timelen = strftime(timebuf, buflen, timefmt, + localtime(&tv.tv_sec)); + } while(timelen == 0); + fputs(timebuf, stdout); + free(timebuf); + if (subfmt != NULL) { + free(subfmt); + subfmt = NULL; + } + break; + } default: warnx("illegal format character %c", convch); return (NULL); @@ -559,7 +676,43 @@ return (ch); } +#ifdef SHELL static void +getstarttime(struct timeval *ptv) +{ + static time_t start; /* We cache this value */ + int mib[4]; + size_t len; + struct kinfo_proc kp; + + ptv->tv_sec = 0; + ptv->tv_usec = 0; /* Not using microseconds at all */ + + if (start != 0) { + ptv->tv_sec = start; + return; + } + + len = 4; + if (sysctlnametomib("kern.proc.pid", mib, &len) != 0) { + warn("Unable to obtain script start-time: %s", + "sysctlnametomib"); + return; + } + mib[3] = getpid(); + len = sizeof(kp); + if (sysctl(mib, 4, &kp, &len, NULL, 0) != 0) { + warn("Unable to obtain script start-time: %s", + "sysctl"); + return; + } + /* XXX Should we check, whether len still equals sizeof(kinfo_proc)? */ + + start = ptv->tv_sec = kp.ki_start.tv_sec; +} +#endif + +static void usage(void) { (void)fprintf(stderr, "usage: printf format [arguments ...]\n"); -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sun Oct 19 19:36:07 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sun, 19 Oct 2014 19:36:07 +0000 Subject: [Bug 191511] opiepasswd(1) segfaults with a seed length > 12 In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191511 Andrey A. Chernov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Issue Resolved |Needs MFC Resolution|FIXED |--- --- Comment #3 from Andrey A. Chernov --- Buffer size change (and resulted library major bump) backed out in -stable and 10x due to ABI breakage. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at FreeBSD.org Sun Oct 19 21:00:26 2014 From: bugzilla-noreply at FreeBSD.org (bugzilla-noreply at FreeBSD.org) Date: Sun, 19 Oct 2014 21:00:26 +0000 Subject: Problem reports for freebsd-bugs@FreeBSD.org that need special attention Message-ID: <201410192100.s9JL0Q6x010890@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 | 32808 | [patch] tcpd.h lacks prototype for hosts_ctl Needs MFC | 42336 | [patch] ISO-fication of /usr/src/contrib/tcp_wr 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 14 problems total for which you should take action. From bugzilla-noreply at freebsd.org Mon Oct 20 00:44:17 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 00:44:17 +0000 Subject: [Bug 194473] New: clang built kernels failing to boot on sparc64 Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194473 Bug ID: 194473 Summary: clang built kernels failing to boot on sparc64 Product: Base System Version: 11.0-CURRENT Hardware: sparc64 OS: Any Status: Needs Triage Severity: Affects Many People Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: craig001 at lerwick.hopto.org clang kernels are failing to boot on sparc64 boxes. applying patch and following instructions from; https://docs.freebsd.org/cgi/getmsg.cgi?fetch=919883+0+/usr/local/www/db/text/2014/freebsd-current/20140716.freebsd-current produces; https://docs.freebsd.org/cgi/getmsg.cgi?fetch=94686+98764+/usr/local/www/db/text/2014/freebsd-sparc64/20141019.freebsd-sparc64 ##### jumping to kernel entry at 0xc00a8000 Data Access Exception ##### It has been suggested that PCPU is at fault and will need non-trivial fix. Regards Craig Butler -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 01:02:14 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 01:02:14 +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 #4 from commit-hook at freebsd.org --- A commit references this bug: Author: emaste Date: Mon Oct 20 01:01:55 UTC 2014 New revision: 273296 URL: https://svnweb.freebsd.org/changeset/base/273296 Log: MFC r273219: Do nothing in vt_upgrade if there is no vt driver Previously, if no drivers attached at boot we would panic with "vtbuf_fill_locked begin.tp_row 0 must be < screen height 0". PR: 192248 Changes: _U stable/10/ stable/10/sys/dev/vt/vt_core.c -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 01:06:02 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 01:06:02 +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 ---------------------------------------------------------------------------- Status|Needs Triage |Open -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 01:38:51 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 01:38:51 +0000 Subject: [Bug 194453] [dummynet] pipe config bw parameter is limited to 2Gbits per second In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-net at FreeBSD.org --- Comment #1 from Mark Linimon --- Over to maintainers. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 01:39:19 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 01:39:19 +0000 Subject: [Bug 194344] [regression] Wake on LAN no longer works on em(4) In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194344 --- Comment #1 from Mark Linimon --- Over to maintainers. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 01:46:26 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 01:46:26 +0000 Subject: [Bug 194238] [tcp] Ping attempted with MTU 9000 transmits fragmented packets of size 1500 In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194238 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-net at FreeBSD.org Summary|Ping attempted with MTU |[tcp] Ping attempted with |9000 transmits fragmented |MTU 9000 transmits |packets of size 1500 |fragmented packets of size | |1500 -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 01:46:52 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 01:46:52 +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 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-net at FreeBSD.org --- Comment #3 from Mark Linimon --- Over to maintainers. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 01:47:39 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 01:47:39 +0000 Subject: [Bug 194197] [igb] [patch] IGB cards need a kernel option to enable legacy mode (to support ALTQ) In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194197 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-net at FreeBSD.org Summary|IGB cards need a kernel |[igb] [patch] IGB cards |option to enable legacy |need a kernel option to |mode (to support ALTQ) |enable legacy mode (to | |support ALTQ) -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 01:47:55 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 01:47:56 +0000 Subject: [Bug 193986] [lor][network] multicast related In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193986 Mark Linimon 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 Mon Oct 20 01:48:17 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 01:48:17 +0000 Subject: [Bug 193724] [panic] [tcp] in tcp_discardcb (/usr/src/sys/netinet/tcp_subr.c:929) In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193724 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-net at FreeBSD.org Summary|[panic] in tcp_discardcb |[panic] [tcp] in |(/usr/src/sys/netinet/tcp_s |tcp_discardcb |ubr.c:929) |(/usr/src/sys/netinet/tcp_s | |ubr.c:929) -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 01:48:33 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 01:48:34 +0000 Subject: [Bug 193673] [ixgbe] flowid / rss field should only be set if the packettype field says it has a flowid In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193673 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-net at FreeBSD.org --- Comment #1 from Mark Linimon --- Over to maintainers. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 01:49:09 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 01:49:09 +0000 Subject: [Bug 193579] [axge] axge driver issue with tcp checksum offload with pf nat In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193579 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-net at FreeBSD.org --- Comment #1 from Mark Linimon --- Over to maintainers. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 01:49:25 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 01:49:25 +0000 Subject: [Bug 193488] [re] RTL8168F ignores incoming multicast packets In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193488 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-net at FreeBSD.org --- Comment #1 from Mark Linimon --- Over to maintainers. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 01:50:04 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 01:50:04 +0000 Subject: [Bug 194344] [regression] Wake on LAN no longer works on em(4) In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194344 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-net at FreeBSD.org --- Comment #2 from Mark Linimon --- Over to maintainers. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 03:18:24 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 03:18: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 --- Comment #5 from commit-hook at freebsd.org --- A commit references this bug: Author: emaste Date: Mon Oct 20 03:17:49 UTC 2014 New revision: 273300 URL: https://svnweb.freebsd.org/changeset/base/273300 Log: MFS10 r273296 (r273219 in HEAD): Do nothing in vt_upgrade if there is no vt driver Previously, if no drivers attached at boot we would panic with "vtbuf_fill_locked begin.tp_row 0 must be < screen height 0". PR: 192248 Approved by: re Changes: _U releng/10.1/ releng/10.1/sys/dev/vt/vt_core.c -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 08:00:03 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 08:00:02 +0000 Subject: [FreeBSD Bugzilla] Commit Needs MFC Message-ID: <201410200800.s9K802U9036122@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. (13 bugs) Bug 32808: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=32808 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-bugs at FreeBSD.org Status: Needs MFC Resolution: Summary: [patch] tcpd.h lacks prototype for hosts_ctl Bug 42336: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=42336 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-bugs at FreeBSD.org Status: Needs MFC Resolution: Summary: [patch] ISO-fication of /usr/src/contrib/tcp_wrappers 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 20 09:00:57 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 09:00:57 +0000 Subject: [Bug 194477] New: 10.1-RC1 tar(1) spurious directory permission error message Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194477 Bug ID: 194477 Summary: 10.1-RC1 tar(1) spurious directory permission error message Product: Base System Version: 10.1-RC1 Hardware: Any OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: bin Assignee: freebsd-bugs at FreeBSD.org Reporter: John.Marshall at riverwillow.com.au I don't know if tar(1) is the culprit or an innocent bystander but this is what I am seeing on 10.1-RC1 (r272468 amd64). The archive appears to be written properly prior to generation of the error message. Although the user is permitted to traverse the parent directory and read the -C directory, tar(1) emits the complaint if the parent directory is not also readable. Filesystem is UFS. $ tar -czf dtt.tgz -C /data/tftp/thlan . tar: .: Unable to continue traversing directory tree: Permission denied tar: Error exit delayed from previous errors. $ $ ls -ld /data /data/tftp /data/tftp/thlan drwxr-xr-x 33 root wheel 1024 2 Sep 20:13 /data drwxr-x--x 4 root wheel 512 23 Apr 09:00 /data/tftp drwxr-x--x 3 john wheel 512 23 Apr 10:28 /data/tftp/thlan # chmod o+r /data/tftp $ tar -czf dtt.tgz -C /data/tftp/thlan . $ I haven't played with 10.0 but this behaviour is different to other earlier releases (e.g. 9.3-RELEASE doesn't do this). -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 09:36:42 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 09:36:42 +0000 Subject: [Bug 194479] New: many file i/o operations hanging: softdepflush, suspfs Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194479 Bug ID: 194479 Summary: many file i/o operations hanging: softdepflush, suspfs Product: Base System Version: 10.0-RELEASE Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: kalten at gmx.at I think, this problem may have to do with the kernel: (May be closed Bug 149022 has to do with it?) I was building packages in poudriere when I noticed, that write operations in emacs hung. Audio files are still being read from disk (musicpd running) from another mount point (/usr) than the mount point poudriere resides on (/MOUNTER/ufs_D2 which is at 93% according to df(1)). A ls(1) on the mount point of poudriere (/MOUNTER/ufs_D2) has just stuck too. I had a look at poudrieres shell, and it is stuck at ---8<--- ====>> Starting/Cloning builders --->8--- Hitting ^t leads to: ---8<--- load: 0.16 cmd: sh 98249 [suspfs] 755.26r 0.00u 0.00s 0% 784k --->8--- According to ps(1) the PID 98249 belonges to /usr/local/share/poudriere/bulk.sh (same with the mentioned ls: [suspfs]) ps auxww | grep -E "(^USER|suspfs|softdepflush|dup)" ---8<--- USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 19 1.2 0.0 0 16 - DL 9Oct14 0:54.63 [softdepflush] root 97052 0.0 0.0 14756 2020 25 IN+ 10:30AM 0:00.96 cpdup -x /usr/local/poudriere/data/build/100amd64-default/ref /MOUNTER/ufs_D2/poudriere/poudriere/data/build/100amd64-default/02 root 97053 0.0 0.0 14756 1964 25 DN+ 10:30AM 0:00.84 cpdup -x /usr/local/poudriere/data/build/100amd64-default/ref /MOUNTER/ufs_D2/poudriere/poudriere/data/build/100amd64-default/03 root 97054 0.0 0.0 14756 1936 25 IN+ 10:30AM 0:00.84 cpdup -x /usr/local/poudriere/data/build/100amd64-default/ref /MOUNTER/ufs_D2/poudriere/poudriere/data/build/100amd64-default/01 --->8--- top tells me when hitting ?m?: ---8<--- PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND 19 root 28 0 0 24 0 24 92.31% softdepflush --->8--- tunefs -p /MOUNTER/ufs_D2 ---8<--- tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) enabled tunefs: MAC multilabel: (-l) enabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: space to hold for metadata blocks: (-k) 0 tunefs: optimization preference: (-o) time tunefs: volume label: (-L) ufsD2 --->8--- sync(8) does not help either. I can not kill the cpdup commands, etc. I am stuck with reboot. :-( ru, Kalten -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 09:38:53 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 09:38:53 +0000 Subject: [Bug 194479] many file i/o operations hanging: softdepflush, suspfs In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194479 --- Comment #1 from Kalten --- I am sorry: I have forgotten my uname(1) output: uname -a ---8<--- FreeBSD freeHugin.Walhalla.Leben 10.0-RELEASE-p9 FreeBSD 10.0-RELEASE-p9 #0: Mon Sep 15 14:35:52 UTC 2014 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 --->8--- ru, Kalten -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 09:55:10 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 09:55:10 +0000 Subject: [Bug 190787] OCZ-AGILITY3 SSD Not Detected In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190787 --- Comment #4 from aabienkowski at gmail.com --- Is there any update on this issue? -- You are receiving this mail because: You are the assignee for the bug. From sibananda.sahu at avagotech.com Mon Oct 20 10:06:57 2014 From: sibananda.sahu at avagotech.com (Sibananda Sahu) Date: Mon, 20 Oct 2014 15:36:46 +0530 Subject: [VM] PAGE FAULT in kernel mode at the vm_page_alloc() call Message-ID: <2f7771ef189788dcff304a9bb9eaee80@mail.gmail.com> Hi, We were doing internal testing using mrsas driver for certain feature on FreeBSD-10-release. While test execution ,we have observed frequent kernel panic in same code path on FreeBSD 10. Please find more detail about test case and symptoms. 1. Create more than 64 VD using latest mrsas feature which supports Extended VD. (This issue may not be related to this, but just wanted to highlight exact steps) All 240 VD is able to detect in ?camcontrol?. 2. Using LSI StorCli utility do Full Init on all 240 Virtual Drives those are connected behind an LSI controller. Eventually, we observe kernel panic with below backtraces. It is a random behavior but seems to be occurring at the same place all the time, i.e. around vm_page_alloc() call. -- KDB: stack backtrace: #0 0xffffffff808e7dd0 at kdb_backtrace+0x60 #1 0xffffffff808af8b5 at panic+0x155 #2 0xffffffff80c8e692 at trap_fatal+0x3a2 #3 0xffffffff80c8e969 at trap_pfault+0x2c9 #4 0xffffffff80c8e0f6 at trap+0x5e6 #5 0xffffffff80c75392 at calltrap+0x8 #6 0xffffffff80b1d1e9 at vm_page_alloc+0x389 #7 0xffffffff80b0f9fe at kmem_back+0xde #8 0xffffffff80b0f8f6 at kmem_malloc+0x66 #9 0xffffffff80b08c6b at uma_large_malloc+0x4b #10 0xffffffff80898c33 at malloc+0x103 #11 0xffffffff8030eaf5 at enc_daemon+0x1c5 #12 0xffffffff8088198a at fork_exit+0x9a #13 0xffffffff80c758ce at fork_trampoline+0xe -- Here I have attached the crash dump text file to grep more info. If you need more information from us, with some more config or debug parameters enabled or something else, please let me know. I can do some experiment to root cause the issue. I also check on web, but there was not clear direction on this type of kernel panic ..but looks like many folks encountered similar issues. Also, I verified same behavior on latest FreeBSD-11-Current as well. (Revision 273072) Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: core.txt.2 Type: application/octet-stream Size: 157453 bytes Desc: not available URL: From bugzilla-noreply at freebsd.org Mon Oct 20 10:20:11 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 10:20:11 +0000 Subject: [Bug 194479] many file i/o operations hanging: softdepflush, suspfs In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194479 olevole at olevole.ru changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |olevole at olevole.ru --- Comment #2 from olevole at olevole.ru --- The same behavior on 11.0-CURRENT/amd64 r273159M - system hangs ( in suspfs state ) during active disk operations (compiling and tar -cfz) root at gizmo:~ # tunefs -p / tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: space to hold for metadata blocks: (-k) 6408 tunefs: optimization preference: (-o) time tunefs: volume label: (-L) -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 11:55:28 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 11:55:28 +0000 Subject: [Bug 194483] New: [PATCH] libfetch: Properly deal with multi-line proxy responses to CONNECT requests Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194483 Bug ID: 194483 Summary: [PATCH] libfetch: Properly deal with multi-line proxy responses to CONNECT requests 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: fk at fabiankeil.de CC: des at FreeBSD.org Created attachment 148498 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148498&action=edit [PATCH] libfetch: Properly deal with multi-line proxy responses to CONNECT requests Currently http_connect() expects the proxy response for CONNECT requests to consist of a single response line with no common HTTP headers and otherwise leaves parts of the HTTP response unread. OpenSSL does not appreciate that: # Privoxy is being used as proxy fk at r500 ~/papers $fetch https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf 34380892520:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_clnt.c:787: fetch: https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf: Authentication error The attached patch fixes this. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 12:49:52 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 12:49:52 +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 ---------------------------------------------------------------------------- Status|Open |Issue Resolved Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 13:21:14 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 13:21:13 +0000 Subject: [Bug 194485] New: Userland cannot add IPv6 prefix routes Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194485 Bug ID: 194485 Summary: Userland cannot add IPv6 prefix routes Product: Base System Version: 10.0-RELEASE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: roy at marples.name Created attachment 148500 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148500&action=edit Allow userland to submit IPv6 prefix routes Userland cannot add IPv6 prefix routes because the kernel assumes it will always be the one handling prefix routes from Router Advertisements. Both NetBSD and OpenBSD have added checks to allow for neighbors on routes marked RTF_CLONING, but FreeBSD dropped this routing flag a while ago. As such, the only similar check that can be made is against the absence of RTF_STATIC. Attached is a patch that implements this and allows dhcpcd-6.5.1 to work entirely on FreeBSD. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 13:32:21 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 13:32:21 +0000 Subject: [Bug 194479] many file i/o operations hanging: softdepflush, suspfs In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194479 --- Comment #3 from Kalten --- Created attachment 148501 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148501&action=edit boot and fsck Well: rebooting took quite some work. :-( At shotdown the system got to ---8<--- init: some processes would not die; ps axl advised Syncing disks, vnodes remaining [?] 0 0 0 0 0 done All buffers synced. --->8--- and than it hung?I had to switch power off. Now to the boot thereafter: In this attachment (fsck.txt) you can read, what I have transcribed from photos taken (I should have remounted rw and copied at least dmesg there, but I did not ;-)). (I have separated the following points by lines of ----------- in the file) 1) The boot itself. (terrible Errors) 2) ?fsck -y /? 3) ?fsck -y /var? 4) ?fsck -y /usr? 5) ?fsck -y /MOUNTER/ufs_D2? They all differ a little bit in what went wrong. I have turned ?soft update journaling? off for now (?tunefs -j disable /? etc.). I have not deleted the ?.sujournal?-files yet, in case you should wish me to attache them in this report for debuging reasons. ru, Kalten -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 20 16:01:38 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 20 Oct 2014 16:01:38 +0000 Subject: [Bug 194489] New: Fatal trap 12: page fault while in kernel mode, when accessing rocketraid 1740/hptrr Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194489 Bug ID: 194489 Summary: Fatal trap 12: page fault while in kernel mode, when accessing rocketraid 1740/hptrr Product: Base System Version: 10.0-RELEASE Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: bc at skogen.nu Created attachment 148506 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148506&action=edit crash data I have a rocketraid 1740, bios 1.01, raid 5, 4x1Tbps, connected to a 10.0 system and consistently when running fsck on the raid, when fsck completes, and is about to mark the filesystem as clean I get Fatal trap 12. Repeatable. Which means I can't mount it.. It worked fine previously on a 8.4 system. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xfffffe0096aa5a40 frame pointer = 0x28:0x0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq20: hptrr0) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xffffffff808e7e90 at kdb_backtrace+0x60 #1 0xffffffff808af975 at panic+0x155 #2 0xffffffff80c8e822 at trap_fatal+0x3a2 #3 0xffffffff80c8eaf9 at trap_pfault+0x2c9 #4 0xffffffff80c8e286 at trap+0x5e6 #5 0xffffffff80c75522 at calltrap+0x8 Uptime: 57m31s Dumping 328 out of 2024 MB:..5%..15%..25%..35%..44%..54%..64%..74%..83%..93% Also dump if needed. -- You are receiving this mail because: You are the assignee for the bug. From mva at FreeBSD.org Tue Oct 21 06:09:40 2014 From: mva at FreeBSD.org (Marcus von Appen) Date: Tue, 21 Oct 2014 08:09:37 +0200 Subject: Convert your bugs from Needs MFC Message-ID: <20141021060937.GB1065@medusa.sysfault.org> Dear freebsd-bugs at FreeBSD.org, the "Needs MFC" status is subject to be removed in a few weeks and will be replaced by the newly added flags "mfc-stable8", "mfc-stable9" and "mfc-stable10". We would like you to convert the bugs with the status "Needs MFC", that are currently assigned to you, to those new flags and to set the bug to "In Discussion". Please set only those flags to "?", for which a MFC is still required. If a MFC already took place for a stable branch, set the flag to "+". If a MFC will not be done for a stable branch, set the flag to "-". All bugs, which are not converted within the next 14 days (until the 5th of November), will be converted by bugmeister, requesting a MFC for all branches, unknowingly, if that may be correct or not. Thanks for your help Marcus on behalf of bugmeister -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From bugzilla-noreply at freebsd.org Tue Oct 21 06:38:39 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 21 Oct 2014 06:38:39 +0000 Subject: [Bug 194506] New: [PATCH] "pciconf -a" asserts with unemerated device names Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194506 Bug ID: 194506 Summary: [PATCH] "pciconf -a" asserts with unemerated device names 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: accornehl at fastmail.fm CC: benno at FreeBSD.org, markj at FreeBSD.org Created attachment 148530 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148530&action=edit patch I noticed that passing an unenumerated device name to pciconf caused an assert, for what otherwise looks like valid input. # /usr/sbin/pciconf -a bge Assertion failed: (*cp == '\0'), function getdevice, file /usr/home/acornehl/freebsd/usr.sbin/pciconf/pciconf.c, line 677. Abort trap (core dumped) # /usr/sbin/pciconf -a bge0 bge0: attached The function, getdevice(), expects that the device name is enumerated before processing the string, and hits the assert when it isn't. I've added a small patch checking before walking the string to check if it is enumerated or not and returning an error instead of an assert. # ./pciconf -a bge pciconf: Device not found # ./pciconf -a bge0 bge0: attached # ./pciconf -a foobar pciconf: Device not found # ./pciconf -a foobar0 pciconf: Device not found -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 21 08:49:03 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 21 Oct 2014 08:49:03 +0000 Subject: [Bug 194489] Fatal trap 12: page fault while in kernel mode, when accessing rocketraid 1740/hptrr In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194489 --- Comment #1 from bc at skogen.nu --- The problem went away after applying revision 267368 from head to the driver. I can now fsck/mount the raid and everything seems to be working. The probe errors are gone as well. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 21 12:21:11 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 21 Oct 2014 12:21:11 +0000 Subject: [Bug 194513] New: zfs recv hangs in state kmem arena Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194513 Bug ID: 194513 Summary: zfs recv hangs in state kmem arena Product: Base System Version: 10.0-STABLE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: james-freebug at jrv.org I am having every attempt to replicate my ZFS pool fail due to "zfs recv" blocking on "kmem arena". This happens on two systems, and with both 10-STABLE and -CURRENT. It hangs within the first 5TB, usually by 2TB, last night it failed after 4.35 MB. I tried using a memstick image of -CURRENT made from the release/ process and this also hangs in "kmem arena". The two tested systems have 16GB and 32GB of ECC RAM. An uninvolved server of mine hung Friday night in state"kmem arena" during periodic's "zpool history". After a reboot it did not hang Saturday night. The command that fails is # zfs send -R BIGTEX/UNIX at snap | zfs recv -duvF BIGTOX -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 21 15:21:35 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 21 Oct 2014 15:21:35 +0000 Subject: [Bug 194376] [FreeBSD 10.1 RC2 on Hyper-v] In FreeBSD VM, cannot recognize the second IDE disk In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194376 Wei Hu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |weh at microsoft.com --- Comment #1 from Wei Hu --- Created attachment 148539 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148539&action=edit Proposed fix, tested by Microsoft OSTC team -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 21 15:27:34 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 21 Oct 2014 15:27:34 +0000 Subject: [Bug 194376] [FreeBSD 10.1 RC2 on Hyper-v] In FreeBSD VM, cannot recognize the second IDE disk In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194376 Glen Barber changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |re at FreeBSD.org Assignee|freebsd-bugs at FreeBSD.org |gjb at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 21 15:39:59 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 21 Oct 2014 15:39:59 +0000 Subject: [Bug 193672] FreeBSD UEFI boot panics with VirtualBox UEFI loader In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193672 --- Comment #4 from Glen Barber --- I am able to successfully run FreeBSD with UEFI under VirtualBox. The host environment details are: CPU: Intel(R) Core(TM) i7-2700K CPU @ 3.50GHz (3605.74-MHz K8-class CPU) Motherboard: ASUS P8Z77-V LX ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads Features=0xbfebfbff Features2=0x1f9ae3bf AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics VirtualBox version 4.3.10 Prior to installation, enable 'EFI' option for the virtual machine. After installing from the UEFI disc1.iso, shutdown the virtual machine, and detach the installation CD from the virtual machine prior to booting the installed OS. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 21 17:33:48 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 21 Oct 2014 17:33:49 +0000 Subject: [Bug 194506] [PATCH] "pciconf -a" asserts with unemerated device names In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194506 Mark Johnston changed: What |Removed |Added ---------------------------------------------------------------------------- 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 Tue Oct 21 18:16:55 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 21 Oct 2014 18:16:55 +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 #2 from nishida at asusa.net --- According to https://bugzilla.gnome.org/show_bug.cgi?id=738329, this seems to happen also with Linux. So, it's not a FreeBSD specific bug but a FUSE's bug. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 21 18:31:04 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 21 Oct 2014 18:31:04 +0000 Subject: [Bug 187114] rtld(1) does not expand $ORIGIN unless DF_ORIGIN flag is set In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187114 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Open 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 21 18:32:51 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 21 Oct 2014 18:32:51 +0000 Subject: [Bug 191930] Bring kernel debug files into line with userland standalone debug In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191930 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |Open Assignee|freebsd-bugs at FreeBSD.org |emaste 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 21 18:33:05 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 21 Oct 2014 18:33:05 +0000 Subject: [Bug 194515] New: Fatal Trap 12 Kernel with vimage Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194515 Bug ID: 194515 Summary: Fatal Trap 12 Kernel with vimage Product: Base System Version: 10.1-RC2 Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: ivan.uadm at gmail.com its enough to start pf inside jail to reproduce this bug. i was add to kernel only these options: options VIMAGE device pf final trap image can be seen at http://s25.postimg.org/qmumaj5y7/fatal_trap12.png uname -a FreeBSD host 10.1-RC2 FreeBSD 10.1-RC2 #2: Tue Oct 21 15:22:30 MSK 2014 admin at host:/usr/src/sys/amd64/compile/MSRV amd64 -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 21 18:35:25 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 21 Oct 2014 18:35:25 +0000 Subject: [Bug 194515] Fatal Trap 12 Kernel with vimage In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194515 Ivan changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|--- |Normal CC| |ivan.uadm at gmail.com -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 21 18:42:40 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 21 Oct 2014 18:42:40 +0000 Subject: [Bug 191263] [patch] dd(1): Incorrect casting of arguments In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191263 --- Comment #6 from Kurt Jaeger --- (In reply to will from comment #5) > Created attachment 147543 [details] > Better argument handling patch with fix for count=SIZE_MAX Thanks. Patch build-tested against src/bin/dd/ from HEAD, builds fine on 10.0p9-amd64. You have 3 test cases, with ...16, ...15 and ...14 as count values for dd. Interestingly the ...15 case behaves different from your example ? $ ./dd if=/dev/zero of=/dev/null count=18446744073709551615 0+0 records in 0+0 records out 0 bytes transferred in 0.000007 secs (0 bytes/sec) What's the difference ? -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 21 18:45:27 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 21 Oct 2014 18:45:27 +0000 Subject: [Bug 194359] bsdinstall(8) 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 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |Open --- Comment #16 from Ed Maste --- Presumably the change desired here is in gpart_ops.c::gpart_activate, adding scheme == GPT && x86_bootmethod() == BIOS to the list of schemes already there (MBR, EBR, PC98) -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 21 20:01:47 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 21 Oct 2014 20:01:47 +0000 Subject: [Bug 194517] New: [patch] sound: Remove obsolete __FreeBSD_version checks Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194517 Bug ID: 194517 Summary: [patch] sound: Remove obsolete __FreeBSD_version checks 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: ftigeot at wolfpond.org Created attachment 148545 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148545&action=edit sound: Remove obsolete __FreeBSD_version checks The sound subsystem contains many checks for various unsupported FreeBSD versions. This patch removes them, as well as some associated dead code. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 21 20:28:30 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 21 Oct 2014 20:28:30 +0000 Subject: [Bug 194517] [patch] sound: Remove obsolete __FreeBSD_version checks In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194517 ftigeot at wolfpond.org changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #148545|0 |1 is obsolete| | CC| |ftigeot at wolfpond.org --- Comment #1 from ftigeot at wolfpond.org --- Created attachment 148546 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148546&action=edit sound: Remove obsolete __FreeBSD_version checks The previous version of this patch contained a bug -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 21 21:17:55 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 21 Oct 2014 21:17:55 +0000 Subject: [Bug 194359] bsdinstall(8) 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 #17 from Allan Jude --- Created attachment 148547 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148547&action=edit make zfsboot set pmbr active flag if booted via BIOS The attached patch changes zfsboot ("ZFS Auto Mode" in the installer, not guided/manual mode) to set the pmbr active flag if the machdep.bootmethod = BIOS This needs testing by those with applicable hardware. I'll try to generate a .ISO with these changes later tonight. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 22 00:05:37 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 22 Oct 2014 00:05:37 +0000 Subject: [Bug 192463] vt and vt_vga, when two fonts are loaded, boarder not cleared In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192463 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Issue Resolved Resolution|--- |FIXED --- Comment #2 from Ed Maste --- jmg confirms fixed with dumbbell's round of VGA fixes -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 22 00:06:10 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 22 Oct 2014 00:06:10 +0000 Subject: [Bug 192463] vt and vt_vga, when two fonts are loaded, boarder not cleared In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192463 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 Wed Oct 22 00:06:34 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 22 Oct 2014 00:06:34 +0000 Subject: [Bug 192462] vt has display issues when switching vty's In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192462 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 Wed Oct 22 00:07:03 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 22 Oct 2014 00:07:03 +0000 Subject: [Bug 192462] vt has display issues when switching vty's In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192462 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |Issue Resolved Resolution|--- |FIXED --- Comment #2 from Ed Maste --- jmg confirms fixed by dumbbell's series of VGA fixes -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 22 00:15:31 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 22 Oct 2014 00:15:30 +0000 Subject: [Bug 194359] bsdinstall(8) 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 #18 from Allan Jude --- I've modified a pair of Glen's 11 snapshots to use this patched bsdinstall http://freebsd.bsdbasement.com/ I provided a bootonly .iso and a mini-memstick both have the MANIFEST file removed, so bsdinstall will install whatever is the latest snapshot on FTP without complaining about checksums If those with machines that exhibit this issue could test the 'Auto (ZFS)' mode in the installer and see if it solves the problem (it does a gpart set -a active $disk' -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 22 00:16:55 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 22 Oct 2014 00:16:54 +0000 Subject: [Bug 194359] bsdinstall(8) 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 Allan Jude changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #148547|0 |1 is obsolete| | --- Comment #19 from Allan Jude --- Created attachment 148553 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148553&action=edit Fix syntax error in previous patch Updated patch -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 22 00:35:04 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 22 Oct 2014 00:35:04 +0000 Subject: [Bug 194522] New: smartmontools misbehaving Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194522 Bug ID: 194522 Summary: smartmontools misbehaving Product: Base System Version: 9.2-STABLE Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: jdc at koitsu.org Created attachment 148554 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148554&action=edit dmesg.txt NOTE: FreeBSD version involved is technically 9.3-STABLE, but the Bugzilla GUI only offers up to 9.3-RELEASE. Rephrased: I run base/stable/9. I'm filing this PR in combination or relation to an open ticket I filed with the smartmontools folks: http://www.smartmontools.org/ticket/466 Full details, including all output and lots of examples, are there. Basically, there is something going on within FreeBSD (or possibly within smartmontools, although rebuilding smartmontools 6.2 and using that shows the same problems) where certain SMART attribute values do not seem to appear/behave correctly when compared to values in the SMART extended self-test log. The issue is 100% reproducible, and cannot be reproduced on Windows. Specifically, a self-test issued at a certain Power_On_Hours count does not appear that way -- e.g. if Power_On_Hours is 12345 and a self-test is run, the SMART extensive self-test log might show the test completed at time 12189, or possibly sometime in the future. This issue affects multiple models of MHDDs and SSDs, and makes data recovery and diagnostics extremely difficult given the behaviour. The ATA CDBs being submit to the drive + full response payload I can try to get using CAM debugging, but I at least wanted to file a PR on the matter because at this point it's looking to be FreeBSD-centric in some way. I'll attach dmesg output, as well as pciconf -lvbc output. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 22 00:35:19 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 22 Oct 2014 00:35:19 +0000 Subject: [Bug 194522] smartmontools misbehaving In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194522 --- Comment #1 from Jeremy Chadwick --- Created attachment 148555 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148555&action=edit pciconf -lvbc output -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 22 00:35:53 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 22 Oct 2014 00:35:53 +0000 Subject: [Bug 194522] smartmontools misbehaving (self-test timestamps do not match reality) In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194522 Jeremy Chadwick changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|smartmontools misbehaving |smartmontools misbehaving | |(self-test timestamps do | |not match reality) -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 22 04:13:41 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 22 Oct 2014 04:13:41 +0000 Subject: [Bug 194525] New: Restart Apache Causes page fault and kernel dump Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194525 Bug ID: 194525 Summary: Restart Apache Causes page fault and kernel dump Product: Base System Version: 10.1-RC2 Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: pete at nomadlogic.org On a 10.1-RC2 system where I run apache24 I seem to be reliably able to cause a kernel panic and system crash while restating apache24. I run mod_wsgi on my apache instance for serving graphite webUI. I have not been able to detect any hardware defects on this system at this time. Here is the output from /var/crash/panicmail.0. I can make all other related cores etc. avail upon request: > sudo cat panicmail.0 Dump header from device /dev/da0p3 Architecture: amd64 Architecture Version: 2 Dump Length: 3512709120B (3349 MB) Blocksize: 512 Dumptime: Tue Oct 21 20:47:57 2014 Hostname: pop.rubicorp.com Magic: FreeBSD Kernel Dump Version String: FreeBSD 10.1-RC2 #0 r272876: Fri Oct 10 01:12:21 UTC 2014 root at releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC Panic String: page fault Dump Parity: 3316977061 Bounds: 0 Dump Status: good Backtrace: Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/accf_data.ko.symbols...done. Loaded symbols for /boot/kernel/accf_data.ko.symbols Reading symbols from /boot/kernel/accf_http.ko.symbols...done. Loaded symbols for /boot/kernel/accf_http.ko.symbols Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/kernel/sem.ko.symbols...done. Loaded symbols for /boot/kernel/sem.ko.symbols Reading symbols from /boot/kernel/ums.ko.symbols...done. Loaded symbols for /boot/kernel/ums.ko.symbols Reading symbols from /boot/kernel/pflog.ko.symbols...done. Loaded symbols for /boot/kernel/pflog.ko.symbols Reading symbols from /boot/kernel/pf.ko.symbols...done. Loaded symbols for /boot/kernel/pf.ko.symbols Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/kernel/netgraph.ko.symbols...done. Loaded symbols for /boot/kernel/netgraph.ko.symbols Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. Loaded symbols for /boot/kernel/ng_ether.ko.symbols Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko #0 doadump (textdump=) at pcpu.h:219 in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:219 #1 0xffffffff809264b2 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:452 #2 0xffffffff80926874 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff80d2304f in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:865 #4 0xffffffff80d23368 in trap_pfault (frame=0xfffffe07e215d6d0, usermode=) at /usr/src/sys/amd64/amd64/trap.c:676 #5 0xffffffff80d229ca in trap (frame=0xfffffe07e215d6d0) at /usr/src/sys/amd64/amd64/trap.c:440 #6 0xffffffff80d08882 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #7 0xffffffff8090cb7a in lf_advlockasync (ap=0xfffffe07e215d860, statep=0xfffff80035c15ab8, size=) at /usr/src/sys/kern/kern_lockf.c:745 #8 0xffffffff8090d345 in lf_advlock (ap=, statep=0x0, size=0) at /usr/src/sys/kern/kern_lockf.c:771 #9 0xffffffff809b7549 in vop_stdadvlock (ap=0xfffffe07e215da18) at /usr/src/sys/kern/vfs_default.c:414 #10 0xffffffff80e42387 in VOP_ADVLOCK_APV (vop=, a=) at vnode_if.c:2531 #11 0xffffffff808e30a9 in kern_fcntl (td=, fd=, cmd=, arg=) at vnode_if.h:1041 #12 0xffffffff808e24ec in kern_fcntl_freebsd (td=0xfffff806ce129490, fd=9, cmd=, arg=34383977672) at /usr/src/sys/kern/kern_descrip.c:458 #13 0xffffffff80d23981 in amd64_syscall (td=0xfffff806ce129490, traced=0) at subr_syscall.c:134 #14 0xffffffff80d08b6b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #15 0x0000000801c8e33a in ?? () Current language: auto; currently minimal (kgdb) > -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 22 05:18:24 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 22 Oct 2014 05:18:24 +0000 Subject: [Bug 194527] New: Losted the first second of any sounds Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194527 Bug ID: 194527 Summary: Losted the first second of any sounds Product: Base System Version: 10.1-RC2 Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: bin Assignee: freebsd-bugs at FreeBSD.org Reporter: skuzmichov at yahoo.co.uk Any sounds (from audio player, video player or sound notification of pidgin) I hear start with 2 seconds: first seconds of sound is lost. If I run "cat /dev/zero > /dev/dsp" in background, then sounds plays fine. root at Desktop-PC:/sbin # cat /dev/sndstat Installed devices: pcm0: (play) pcm1: (play) pcm2: (play) pcm3: (play) default pcm4: (play/rec) pcm5: (play/rec) pcm6: (play) -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 22 07:11:06 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 22 Oct 2014 07:11:06 +0000 Subject: [Bug 189772] Driver to add support for LEDs on PC Engines APU boards. In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189772 olivier at cochard.me changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |olivier at cochard.me --- Comment #1 from olivier at cochard.me --- For compiling on latest -current, we just had to replace the getenv() by kern_getenv(). -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 22 08:58:22 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 22 Oct 2014 08:58:22 +0000 Subject: [Bug 194528] New: After fresh install, zpool.cache references disabled /dev/gptid devices, breaking zdb Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194528 Bug ID: 194528 Summary: After fresh install, zpool.cache references disabled /dev/gptid devices, breaking zdb Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: misc Assignee: freebsd-bugs at FreeBSD.org Reporter: marcus at blazingdot.com Since kern.geom.label.disk_ident.enable and kern.geom.label.gptid.enable are disabled on the system after the zpool is created, zpool.cache references non-existent devices. This breaks (at least) zdb. It can be fixed by running 'zpool reguid zroot' but the problem is not easy to track down when you first encounter it. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 22 12:47:10 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 22 Oct 2014 12:47:10 +0000 Subject: [Bug 194359] bsdinstall(8) 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 #20 from hans at beastielabs.net --- (In reply to Allan Jude from comment #19) I just tried the modified boot-only iso on an Intel DP965LT. After an Auto (ZFS) install the system now reboots without any problems. Auto (UFS) still has the same issue as before ("No bootable device -- insert boot disk and press any key"). which of course is as expected. On my Asus NL4VM-DH installing UFS works, but I still get a message about being unable to read the backup GPT header. Rebooting a ZFS installation fails (register dump followed by "BTX halted"), but that also happens when installing 10-RC2 on ZFS, so I do not think this is relevant to the issue at hand. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 22 15:02:05 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 22 Oct 2014 15:02:05 +0000 Subject: [Bug 194359] bsdinstall(8) 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 #21 from Allan Jude --- (In reply to hans from comment #20) > (In reply to Allan Jude from comment #19) > > I just tried the modified boot-only iso on an Intel DP965LT. After an Auto > (ZFS) install the system now reboots without any problems. Auto (UFS) still > has the same issue as before ("No bootable device -- insert boot disk and > press any key"). which of course is as expected. > Thanks for taking the time to test this for me. So it does seem that this is solving the problem > On my Asus NL4VM-DH installing UFS works, but I still get a message about > being unable to read the backup GPT header. Rebooting a ZFS installation > fails (register dump followed by "BTX halted"), but that also happens when > installing 10-RC2 on ZFS, so I do not think this is relevant to the issue at > hand. Is there anything special about your disk setup that might cause issues with the very last sector? Some motherboard RAID and other types of things store their metadata in the last sector, and can clash with GPT, although those are supposed to make the logical drive 1 sector smaller so that this doesn't happen. Is that NL4VM-DH using UEFI? -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 22 16:06:33 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 22 Oct 2014 16:06:33 +0000 Subject: [Bug 194534] New: [freebsd-update] upgrade from FreeBSD-10-RELEASE to FreeBSD-10.1RC2 system fail to boot. Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194534 Bug ID: 194534 Summary: [freebsd-update] upgrade from FreeBSD-10-RELEASE to FreeBSD-10.1RC2 system fail to boot. Product: Base System Version: 10.1-RC2 Hardware: Any OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: bin Assignee: freebsd-bugs at FreeBSD.org Reporter: sasamotikomi at gmail.com freebsd-update upgrade -r 10.1-RC2 freebsd-update install After first reboot system fail to boot: can't open '/boot/defaults/loader.conf' no such file or directory Error while including /boot/menu-commands.4th, in the line: include /boot/menusets.4th Error while including /boot/menu.rc, in the line: include /boot/menu-commands.4th can't load 'kernel' Why are menu script is not checked while system update? -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 22 16:40:46 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 22 Oct 2014 16:40:46 +0000 Subject: [Bug 194534] [freebsd-update] upgrade from FreeBSD-10-RELEASE to FreeBSD-10.1RC2 system fail to boot. In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194534 --- Comment #1 from Glen Barber --- I am unable to reproduce this. Please provide more information about your machine configuration. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 22 16:45:40 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 22 Oct 2014 16:45:39 +0000 Subject: [Bug 194359] bsdinstall(8) 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 #22 from hans at beastielabs.net --- (In reply to Allan Jude from comment #21) > (In reply to hans from comment #20) > > (In reply to Allan Jude from comment #19) > > > > I just tried the modified boot-only iso on an Intel DP965LT. After an Auto > > (ZFS) install the system now reboots without any problems. Auto (UFS) still > > has the same issue as before ("No bootable device -- insert boot disk and > > press any key"). which of course is as expected. > > > > Thanks for taking the time to test this for me. So it does seem that this is > solving the problem > Definitely, but for ZFS only. A similar change could be done for UFS, or something like in comment #16 could be implemented. > > On my Asus NL4VM-DH installing UFS works, but I still get a message about > > being unable to read the backup GPT header. Rebooting a ZFS installation > > fails (register dump followed by "BTX halted"), but that also happens when > > installing 10-RC2 on ZFS, so I do not think this is relevant to the issue at > > hand. > > Is there anything special about your disk setup that might cause issues with > the very last sector? Some motherboard RAID and other types of things store > their metadata in the last sector, and can clash with GPT, although those > are supposed to make the logical drive 1 sector smaller so that this doesn't > happen. > The disk was in use as single disk for ages in this same system. For now I blame it on the BIOS. > Is that NL4VM-DH using UEFI? No, it is a board from 2006, it has a BIOS. I only included these results to show that something that worked before, i.e. installing UFS without the "does not boot" issue, still works with your change. The NL4VM-DH is too rare to worry about much. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 22 23:18:40 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 22 Oct 2014 23:18:40 +0000 Subject: [Bug 194477] 10.1-RC1 tar(1) spurious directory permission error message In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194477 John Marshall changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|--- |Normal Severity|Affects Only Me |Affects Many People -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 22 23:33:10 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 22 Oct 2014 23:33:10 +0000 Subject: [Bug 194477] 10.1-RC1 tar(1) spurious directory permission error message In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194477 --- Comment #1 from John Marshall --- Confirmed independently on -stable@ https://lists.freebsd.org/pipermail/freebsd-stable/2014-October/080685.html The scenario of traversal-only access to the parent directory is common in a situation where the directory contains per-user subdirectories, and each user has no business knowing about any subdirectory but his own. The archive generated is fine, the user has full permission to the directory being archived, but tar(1) exits with an error status. I regard this regression as a bug. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 23 00:52:04 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 23 Oct 2014 00:52:04 +0000 Subject: [Bug 192730] [build] make checkdpadd failures with LD* variables being added to LDADD In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192730 Garrett Cooper changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs MFC |Issue Resolved Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 23 00:52:09 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 23 Oct 2014 00:52:09 +0000 Subject: [Bug 192730] [build] make checkdpadd failures with LD* variables being added to LDADD In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192730 --- Comment #6 from commit-hook at freebsd.org --- A commit references this bug: Author: ngie Date: Thu Oct 23 00:51:53 UTC 2014 New revision: 273500 URL: https://svnweb.freebsd.org/changeset/base/273500 Log: MFC r271365: Remove many false positives with make checkdpadd - Reduce DPADD and LDADD in checkdpadd to -l - Skip over -Wl,[es]*-group because -Wl,--end-group and -Wl,--start-group might be required to properly link objects (see usr.bin/clang/lldb as an example) This caveat has been present for a while with some components of the build. However, these false positives were made more more apparent after r269648. Phabric: D635 Reviewed by: jmmv (an earlier version) PR: 192730 Changes: _U stable/10/ stable/10/share/mk/bsd.dep.mk -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 23 00:57:20 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 23 Oct 2014 00:57:21 +0000 Subject: [Bug 181155] [libc] [patch] *access*(2) does not handle invalid amodes properly In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181155 Garrett Cooper changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs MFC |Issue Resolved Resolution|--- |FIXED --- Comment #9 from Garrett Cooper --- jilles requested for this commit to not be MFCed, and I agree. Marking the issue resolved. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 23 01:10:42 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 23 Oct 2014 01:10:41 +0000 Subject: [Bug 194359] bsdinstall(8) 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 Joseph Mingrone changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jrm at ftfl.ca --- Comment #23 from Joseph Mingrone --- I tested the modified image with a Lenovo X220, which refuses to legacy boot anything GPT. It wouldn't even boot the USB image unless I UEFI boot. I installed to an external drive with the auto ZFS option, but not luck legacy booting off that drive. I'm thinking the booting issue with the X220 is a different issue, i.e., not related to setting the active flag in GPT PMBR. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 23 01:13:14 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 23 Oct 2014 01:13:14 +0000 Subject: [Bug 192760] [build] sbin/ifconfig: missing DPADD for LIBM In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192760 Garrett Cooper changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |melifaro at FreeBSD.org --- Comment #2 from Garrett Cooper --- Assigning the bug to melifaro because he provided the fix -- thanks again :)! -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 23 02:11:24 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 23 Oct 2014 02:11:24 +0000 Subject: [Bug 194541] New: Cannot export zpool while completely unrelated mounted nfs is not responding Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194541 Bug ID: 194541 Summary: Cannot export zpool while completely unrelated mounted nfs is not responding Product: Base System Version: 10.0-STABLE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: misc Assignee: freebsd-bugs at FreeBSD.org Reporter: martin.dieringer at gmx.de "zpool export [-f] pool" doesn't return, can't be interrupted and not sent to background and will hang forever -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 23 05:58:33 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 23 Oct 2014 05:58:33 +0000 Subject: [Bug 189941] [libc] getgroups(2) implements first argument as unsigned int In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189941 --- Comment #2 from commit-hook at freebsd.org --- A commit references this bug: Author: ngie Date: Thu Oct 23 05:58:03 UTC 2014 New revision: 273517 URL: https://svnweb.freebsd.org/changeset/base/273517 Log: Expect getgroups_err to fail on FreeBSD PR: 189941 Submitted by: pho Sponsored by: EMC / Isilon Storage Division Changes: head/contrib/netbsd-tests/lib/libc/sys/t_getgroups.c -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 23 08:55:24 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 23 Oct 2014 08:55:23 +0000 Subject: [Bug 194547] New: [patch] freebsd-update(8) do no invoke $PAGER with empty output Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194547 Bug ID: 194547 Summary: [patch] freebsd-update(8) do no invoke $PAGER with empty output 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: tgyurci at gmail.com Created attachment 148574 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148574&action=edit freebsd-update $PAGER patch freebsd-update(8) utility shows the updatable/deletable etc. files at the fetch stage. This list is displayed using the $PAGER, even when there is no change. This is unnoticeable with more but, when the user sets less as the $PAGER then several empty pages are displayed. This patch changes the freebsd-update script to invoke $PAGER only if there are displayable information. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 23 09:23:17 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 23 Oct 2014 09:23:17 +0000 Subject: [Bug 194550] New: panic: race condition with epair and atmconfig Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194550 Bug ID: 194550 Summary: panic: race condition with epair and atmconfig 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: olevole at olevole.ru When epair created fast enough the system got the panic when performing atmconfig (afexist in /etc/network.subr executed by devd) Work-around: kill devd process or in the afexists() in /etc/network.subr prevent atmconfig execution: ----- atm) ++ return 1 if [ -x /sbin/atmconfig ]; then /sbin/atmconfig diag list > /dev/null 2>&1 else return 1 fi ----- Panic is easy to reproduce via script: ----- #!/bin/sh for i in $( seq 0 300 ); do echo $i /sbin/ifconfig epair${i} create [ $? -ne 0 ] && exit 1 done ----- Significantly accelerate the emergence of panic if run in parallel: ----- #!/bin/sh while [ 1 ];do /sbin/atmconfig diag list done ----- KGDB Backtrace: -- GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xfffffe007b5857b0 frame pointer = 0x28:0xfffffe007b5857e0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 3008 (atmconfig) Uptime: 1m47s Dumping 145 out of 2021 MB:..12%..23%..34%..45%..56%..67%..78%..89%..100% Reading symbols from /boot/kernel/pf.ko.symbols...done. Loaded symbols for /boot/kernel/pf.ko.symbols Reading symbols from /boot/kernel/nullfs.ko.symbols...done. Loaded symbols for /boot/kernel/nullfs.ko.symbols Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/kernel/if_epair.ko.symbols...done. Loaded symbols for /boot/kernel/if_epair.ko.symbols #0 doadump (textdump=1) at pcpu.h:219 219 __asm("movq %%gs:%1,%0" : "=r" (td) (kgdb) list 214 static __inline __pure2 struct thread * 215 __curthread(void) 216 { 217 struct thread *td; 218 219 __asm("movq %%gs:%1,%0" : "=r" (td) 220 : "m" (*(char *)OFFSETOF_CURTHREAD)); 221 return (td); 222 } 223 #ifdef __clang__ Current language: auto; currently minimal (kgdb) -- -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 23 09:50:26 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 23 Oct 2014 09:50:26 +0000 Subject: [Bug 194547] [patch] freebsd-update(8) do no invoke $PAGER with empty output In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194547 TEUBEL Gy?rgy changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #148574|0 |1 is obsolete| | --- Comment #1 from TEUBEL Gy?rgy --- Created attachment 148575 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148575&action=edit freebsd-update.sh $PAGER patch New patch without subshell usage -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 23 10:55:36 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 23 Oct 2014 10:55:36 +0000 Subject: [Bug 187015] [panic] make_dev_credv: bad si_name (error=17, si_name=agpgart) In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187015 fred+freebsdbugzilla at fredo1.info changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fred+freebsdbugzilla at fredo1 | |.info --- Comment #6 from fred+freebsdbugzilla at fredo1.info --- Encountering the same kernel panic with FreeBSD 10.1 RC3 installer (memstick img) (screenshot) http://pix.toile-libre.org/upload/original/1414061308.jpg Same intel 855GME adapter, on an Xploretech ix104c3 tablet PC. Booting with hint.agp.0.disabled=1 helped go further, but then I had to disable ACPI as well otherwise another type of kernel panic occured. Now blocked at "still waiting xpt_config" messages. If more details needed please ask (I'm new to FreeBSD). -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 23 12:39:04 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 23 Oct 2014 12:39:05 +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 --- Comment #1 from commit-hook at freebsd.org --- A commit references this bug: Author: dumbbell Date: Thu Oct 23 12:38:07 UTC 2014 New revision: 273544 URL: https://svnweb.freebsd.org/changeset/base/273544 Log: vt(4): Add PIO_VFONT_DEFAULT ioctl to restore the default builtin font To restore the default font using vidcontrol(1), use the "-f" flag without an argument: vidcontrol -f < /dev/ttyv0 PR: 193910 Differential Revision: https://reviews.freebsd.org/D971 Submitted by: Marcin Cieslak Reviewed by: ray@, emaste@ Approved by: ray@ MFC after: 1 week Changes: head/sys/dev/vt/vt_core.c head/sys/sys/consio.h head/usr.sbin/vidcontrol/vidcontrol.1 head/usr.sbin/vidcontrol/vidcontrol.c -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 23 12:52:27 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 23 Oct 2014 12:52:27 +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 Jean-S?bastien P?dron changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |Issue Resolved CC| |dumbbell at FreeBSD.org Resolution|--- |FIXED --- Comment #2 from Jean-S?bastien P?dron --- Compared to your originl patch, I renamed the ioctl to PIO_VFONT_DEFAULT which is more readable IMHO. Thank you Marcin for your contribution! -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 23 12:54:00 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 23 Oct 2014 12:54:00 +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 --- Comment #3 from Jean-S?bastien P?dron --- For the record, the associated review was here: https://reviews.freebsd.org/D971 -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 23 13:52:09 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 23 Oct 2014 13:52:09 +0000 Subject: [Bug 194550] panic: race condition with epair and atmconfig In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194550 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ae at FreeBSD.org Assignee|freebsd-bugs at FreeBSD.org |ae at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 23 14:21:31 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 23 Oct 2014 14:21:31 +0000 Subject: [Bug 194527] Losted the first second of any sounds In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194527 Sergey Kuzmichov changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|--- |Normal 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 23 15:17:21 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 23 Oct 2014 15:17:21 +0000 Subject: [Bug 184597] [PATCH] Fix rfcomm_sppd(1) pseudo slave TTY mode In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184597 --- Comment #4 from commit-hook at freebsd.org --- A commit references this bug: Author: emax Date: Thu Oct 23 15:16:42 UTC 2014 New revision: 273548 URL: https://svnweb.freebsd.org/changeset/base/273548 Log: Change the code to use the openpty(3) API which uses the pts(4) driver instead of the pty(4) driver. PR: 184597 Submitted by: tobias.rehbein MFC after: 2 weeks Changes: head/usr.bin/bluetooth/rfcomm_sppd/Makefile head/usr.bin/bluetooth/rfcomm_sppd/rfcomm_sppd.1 head/usr.bin/bluetooth/rfcomm_sppd/rfcomm_sppd.c -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 23 23:37:39 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 23 Oct 2014 23:37:39 +0000 Subject: [Bug 194568] New: [patch] add new sysctl for minimum soacceptqueue length Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194568 Bug ID: 194568 Summary: [patch] add new sysctl for minimum soacceptqueue length 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: nenolod at tortois.es Created attachment 148599 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148599&action=edit freebsd-soacceptqueue-minimum.patch Hello, The attached patch adds a new sysctl: kern.ipc.soacceptqueue_minimum It allows the system administrator to override the socket accept queue length. This is useful in cases where applications call listen(2) with too low of a socket queue length for a busy deployment, yet there is no application tunable for it. I look forward to any comments on the patch, we are using it in production on a large cluster already. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 24 05:59:05 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 24 Oct 2014 05:59:05 +0000 Subject: [Bug 194569] New: kernel panics while loading vmm(4) Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194569 Bug ID: 194569 Summary: kernel panics while loading vmm(4) Product: Base System Version: 11.0-CURRENT Hardware: amd64 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 Created attachment 148601 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148601&action=edit vmm.c.patch When loading vmm(4), following stack trace is shown and kernel panics. (kgdb) #0 doadump (textdump=0) at pcpu.h:219 #1 0xffffffff80332b8e in db_dump (dummy=, dummy2=0, dummy3=0, dummy4=0x0) at /data/rhea/usr/src/sys/ddb/db_command.c:533 #2 0xffffffff8033266d in db_command (cmd_table=0x0) at /data/rhea/usr/src/sys/ddb/db_command.c:440 #3 0xffffffff803323e4 in db_command_loop () at /data/rhea/usr/src/sys/ddb/db_command.c:493 #4 0xffffffff80334e60 in db_trap (type=, code=0) at /data/rhea/usr/src/sys/ddb/db_main.c:251 #5 0xffffffff806c9111 in kdb_trap (type=12, code=0, tf=) at /data/rhea/usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff808fd45c in trap_fatal (frame=0xfffffe046bcc2400, eva=) at /data/rhea/usr/src/sys/amd64/amd64/trap.c:861 #7 0xffffffff808fd6f6 in trap_pfault (frame=0xfffffe046bcc2400, usermode=) at /data/rhea/usr/src/sys/amd64/amd64/trap.c:677 #8 0xffffffff808fce0e in trap (frame=0xfffffe046bcc2400) at /data/rhea/usr/src/sys/amd64/amd64/trap.c:426 #9 0xffffffff808e20b2 in calltrap () at /data/rhea/usr/src/sys/amd64/amd64/exception.S:231 #10 0xffffffff807405fb in strlen (str=0x0) at /data/rhea/usr/src/sys/libkern/strlen.c:98 #11 0xffffffff8064e8de in freeenv (env=0x0) at /data/rhea/usr/src/sys/kern/kern_environment.c:266 #12 0xffffffff816059a8 in vmm_is_pptdev (bus=0, slot=0, func=0) at /data/rhea/usr/src/sys/modules/vmm/../../amd64/vmm/vmm.c:1969 #13 0xffffffff8160ca27 in ppt_probe (dev=0xfffff8000765bd00) at /data/rhea/usr/src/sys/modules/vmm/../../amd64/vmm/io/ppt.c:128 #14 0xffffffff806be860 in device_probe_child (dev=0xfffff8000765c000, child=0xfffff8000765bd00) at device_if.h:108 #15 0xffffffff806bf4c0 in device_probe (dev=0xfffff8000765bd00) at /data/rhea/usr/src/sys/kern/subr_bus.c:2763 #16 0xffffffff806bf5ae in device_probe_and_attach (dev=0xfffff8000765bd00) at /data/rhea/usr/src/sys/kern/subr_bus.c:2787 #17 0xffffffff804c8a6a in pci_driver_added (dev=0xfffff8000765c000, driver=) at /data/rhea/usr/src/sys/dev/pci/pci.c:3784 #18 0xffffffff806bdb5a in devclass_driver_added (dc=0xfffff800074aaf00, driver=0xffffffff816298e0) at bus_if.h:204 #19 0xffffffff806bdabc in devclass_add_driver (dc=0xfffff800074aaf00, driver=0xffffffff816298e0, pass=, dcp=) at /data/rhea/usr/src/sys/kern/subr_bus.c:1138 #20 0xffffffff80676490 in module_register_init (arg=0xffffffff81629958) at /data/rhea/usr/src/sys/kern/kern_module.c:123 #21 0xffffffff8066b238 in linker_load_module (kldname=, modname=0xfffff8000bf6e000 "vmm", parent=0x0, verinfo=0x0, lfpp=0xfffffe046bcc2a68) at /data/rhea/usr/src/sys/kern/kern_linker.c:224 #22 0xffffffff8066c617 in kern_kldload (td=, file=, fileid=0xfffffe046bcc2aa4) at /data/rhea/usr/src/sys/kern/kern_linker.c:1031 #23 0xffffffff8066c6db in sys_kldload (td=0xfffff80178059000, uap=) at /data/rhea/usr/src/sys/kern/kern_linker.c:1057 This panic occurs when "pptdev" kernel environment is not set. Attached patch fixes this problem, I think. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 24 08:31:08 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 24 Oct 2014 08:31:08 +0000 Subject: [Bug 194180] [panic] [zfs] Bio not on queue In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194180 Christer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |Issue Resolved Resolution|--- |FIXED --- Comment #1 from Christer --- This problem is no longer present. It seems possible that the hero is the commit below. https://github.com/freebsd/freebsd/commit/7f2e56c17ddf1e3524657c2a3e0397f2f842157e Very nice! -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 24 13:55:26 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 24 Oct 2014 13:55:26 +0000 Subject: [Bug 194577] New: mbuf packet header leakage when closing TUN devices Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194577 Bug ID: 194577 Summary: mbuf packet header leakage when closing TUN devices Product: Base System Version: 9.2-STABLE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: hselasky at FreeBSD.org Hi, I have a VPN client running which has automatic restarts activated. That means the TUN device is regularly opened and closed. Every time the TUN device closes, an mbuf header of 256 bytes is leaked. After some weeks of uptime the system stops working. I've added some additional code into the kernel to trace this, and the backtrace of one of those allocations what are not freed after 60 seconds, are as follows: X=184 KDB: stack backtrace: db_trace_self_wrapper(c0a38777,c0a678ac,c06c87f0,c7bd3750,a,c7bd3798,5,ffffffff,0,0,553b80,c7bd3818,c2a47440,c7bd3778,c06c824e, c7bd3798,c7bd378c,c06c82fb,c0a678ac,c7bd3798) at db_trace_self_wrapper+0x26/frame 0xc7bd3730 kdb_backtrace(c0a678ac,b8,20,1,c29525e0,...) at kdb_backtrace+0x2b/frame 0xc7bd378c uma_zalloc_arg(c13e45a0,c7bd3860,1,c29525e0,c0aff0e4,...) at uma_zalloc_arg+0x706/frame 0xc7bd37dc mld_v2_enqueue_group_record(0,0,2,20,c2a12a60,...) at mld_v2_enqueue_group_record+0x909/frame 0xc7bd38a8 mld_change_state(c302e200,0,0,0,2,...) at mld_change_state+0x509/frame 0xc7bd3904 in6_mc_leave_locked(c302e200,0,c2895000,c7bd394c,c0676d4a,...) at in6_mc_leave_locked+0x2d/frame 0xc7bd3928 in6_mc_leave(c302e200,0,4,c7bd39ec,c084a1fa,...) at in6_mc_leave+0x37/frame 0xc7bd394c in6_leavegroup(c2e163d0,c3250e90,10,4,0,...) at in6_leavegroup+0x20/frame 0xc7bd3960 in6_purgeaddr(c3250e00,0,0,c3274238,c3274200,...) at in6_purgeaddr+0xea/frame 0xc7bd39ec if_purgeaddrs(c2a54800,2,4,c7bd3aa8,0,...) at if_purgeaddrs+0x10a/frame 0xc7bd3a58 tunclose(c3281800,7,2000,c2afc2f0,c7bd3abc,...) at tunclose+0x15f/frame 0xc7bd3a80 devfs_close(c7bd3af4,c7bd3af4,c338cd50,7,c7bd3b18,...) at devfs_close+0x17f/frame 0xc7bd3ac4 VOP_CLOSE_APV(c0a99ce0,c7bd3af4,c0a40f74,141,c0ad08a0,...) at VOP_CLOSE_APV+0x4a/frame 0xc7bd3adc vn_close(c338cd50,7,c2956180,c2afc2f0,0,...) at vn_close+0x99/frame 0xc7bd3b18 vn_closefile(c314b460,c2afc2f0,c314b460,0,c2afc2f0,...) at vn_closefile+0x53/frame 0xc7bd3b74 devfs_close_f(c314b460,c2afc2f0,3000000,0,1,...) at devfs_close_f+0x34/frame 0xc7bd3b90 _fdrop(c314b460,c2afc2f0,0,c7bd3c00,2,0,0,c2b7d2d8,4,2,c7bd3c1c,c09b22e9,c2957760,288df000,2,0,c7bd3c10,c06462a4,1f,c314b460) a t _fdrop+0x2d/frame 0xc7bd3bac closef(c314b460,c2afc2f0,0,c7bd3c38,c09b1d76,...) at closef+0x5b/frame 0xc7bd3c10 kern_close(c2afc2f0,6,c7bd3c98,c09bb3b2,c0aff1c0,...) at kern_close+0x18d/frame 0xc7bd3c48 syscall(c7bd3d08) at syscall+0x535/frame 0xc7bd3cfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xc7bd3cfc --- syscall (6, FreeBSD ELF32, sys_close), eip = 0x283c2393, esp = 0xbfbfe37c, ebp = 0xbfbfe388 --- X=176 KDB: stack backtrace: db_trace_self_wrapper(c0a38777,c0a678ac,c06c87f0,d26fca30,a,d26fca78,5,ffffffff,0,0,d26fca70,c06d3f9d,c2e0ebc0,d26fca58,c06c824 e,d26fca78,d26fca6c,c06c82fb,c0a678ac,d26fca78) at db_trace_self_wrapper+0x26/frame 0xd26fca10 kdb_backtrace(c0a678ac,b0,20,2,c2edc6d4,...) at kdb_backtrace+0x2b/frame 0xd26fca6c uma_zalloc_arg(c13e45a0,d26fcadc,2,9d0001,0,...) at uma_zalloc_arg+0x706/frame 0xd26fcabc m_getm2(0,a1,2,1,2,...) at m_getm2+0xc1/frame 0xd26fcaf0 m_uiotombuf(d26fcbb0,2,800,64,2,...) at m_uiotombuf+0x80/frame 0xd26fcb24 sosend_generic(c32579c0,0,d26fcbb0,0,0,...) at sosend_generic+0x2be/frame 0xd26fcb80 kern_sendit(c326d000,4,d26fcc24,0,0,...) at kern_sendit+0x185/frame 0xd26fcbe0 sendit(0,0,0,d26fcc40,1,...) at sendit+0xda/frame 0xd26fcc18 sys_sendto(c326d000,d26fcccc,c0aff0e4,c09bb3b2,c0aff1c0,...) at sys_sendto+0x48/frame 0xd26fcc48 syscall(d26fcd08) at syscall+0x535/frame 0xd26fccfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xd26fccfc --- syscall (133, FreeBSD ELF32, sys_sendto), eip = 0x283a148b, esp = 0xbfbfd39c, ebp = 0xbfbfd3c8 --- X=177 KDB: stack backtrace: db_trace_self_wrapper(c0a38777,c0a678ac,c06c87f0,d26fc9d4,a,d26fca1c,5,ffffffff,0,0,c0aff1c0,c326d000,c326d000,d26fc9fc,c06c824 e,d26fca1c,d26fca10,c06c82fb,c0a678ac,d26fca1c) at db_trace_self_wrapper+0x26/frame 0xd26fc9b4 kdb_backtrace(c0a678ac,b1,20,1,c0695933,...) at kdb_backtrace+0x2b/frame 0xd26fca10 uma_zalloc_arg(c13e45a0,d26fca78,1,c2b06d00,0,...) at uma_zalloc_arg+0x706/frame 0xd26fca60 sbappendaddr_locked_internal(0,0,0,c2edc680,4,...) at sbappendaddr_locked_internal+0x49/frame 0xd26fca8c sbappendaddr_locked(c2edc6d4,c0a3dec0,c2b06d00,0,c2b06d9c,...) at sbappendaddr_locked+0x6c/frame 0xd26fcaac uipc_send(c32579c0,0,c2b06d00,0,0,...) at uipc_send+0x763/frame 0xd26fcb24 sosend_generic(c32579c0,0,d26fcbb0,c2b06d00,0,...) at sosend_generic+0x385/frame 0xd26fcb80 kern_sendit(c326d000,4,d26fcc24,0,0,...) at kern_sendit+0x185/frame 0xd26fcbe0 sendit(0,0,0,d26fcc40,1,...) at sendit+0xda/frame 0xd26fcc18 sys_sendto(c326d000,d26fcccc,c0aff0e4,c09bb3b2,c0aff1c0,...) at sys_sendto+0x48/frame 0xd26fcc48 syscall(d26fcd08) at syscall+0x535/frame 0xd26fccfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xd26fccfc --- syscall (133, FreeBSD ELF32, sys_sendto), eip = 0x283a148b, esp = 0xbfbfd39c, ebp = 0xbfbfd3c8 --- X=178 KDB: stack backtrace: db_trace_self_wrapper(c0a38777,c0a678ac,c06c87f0,d26fc9d4,a,d26fca1c,5,ffffffff,0,0,c0aff1c0,c326d000,c326d000,d26fc9fc,c06c824 e,d26fca1c,d26fca10,c06c82fb,c0a678ac,d26fca1c) at db_trace_self_wrapper+0x26/frame 0xd26fc9b4 kdb_backtrace(c0a678ac,b2,20,1,c0695933,...) at kdb_backtrace+0x2b/frame 0xd26fca10 uma_zalloc_arg(c13e45a0,d26fca78,1,c2b03700,0,...) at uma_zalloc_arg+0x706/frame 0xd26fca60 sbappendaddr_locked_internal(0,0,0,c2edc680,4,...) at sbappendaddr_locked_internal+0x49/frame 0xd26fca8c sbappendaddr_locked(c2edc6d4,c0a3dec0,c2b03700,0,c2b0379c,...) at sbappendaddr_locked+0x6c/frame 0xd26fcaac uipc_send(c32579c0,0,c2b03700,0,0,...) at uipc_send+0x763/frame 0xd26fcb24 sosend_generic(c32579c0,0,d26fcbb0,c2b03700,0,...) at sosend_generic+0x385/frame 0xd26fcb80 kern_sendit(c326d000,4,d26fcc24,0,0,...) at kern_sendit+0x185/frame 0xd26fcbe0 sendit(0,0,0,d26fcc40,1,...) at sendit+0xda/frame 0xd26fcc18 sys_sendto(c326d000,d26fcccc,d26fcc98,c09bb3b2,c0aff1c0,...) at sys_sendto+0x48/frame 0xd26fcc48 syscall(d26fcd08) at syscall+0x535/frame 0xd26fccfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xd26fccfc --- syscall (133, FreeBSD ELF32, sys_sendto), eip = 0x283a148b, esp = 0xbfbfd58c, ebp = 0xbfbfd5b8 --- --HPS -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 24 14:03:38 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 24 Oct 2014 14:03:38 +0000 Subject: [Bug 194577] mbuf packet header leakage when closing TUN devices In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194577 --- Comment #1 from Hans Petter Selasky --- Hi, Here are some more mbuf allocations, after TUN close, which my test program did not mark as stuck: KDB: stack backtrace: db_trace_self_wrapper(c0a38777,c0a678ac,c06c87f0,c7bd3838,a,c7bd3880,5,ffffffff,0,0,c326fd18,c13eea14,c13eea10,c7bd3860,c06c824 e,c7bd3880,c7bd3874,c06c82fb,c0a678ac,c7bd3880) at db_trace_self_wrapper+0x26/frame 0xc7bd3818 kdb_backtrace(c0a678ac,b6,20,1,c0ab8680,...) at kdb_backtrace+0x2b/frame 0xc7bd3874 uma_zalloc_arg(c13e45a0,c7bd38ec,1,c0b0a194,c7bd3914,...) at uma_zalloc_arg+0x706/frame 0xc7bd38c4 rt_msg1(c7bd3914,30,c2a54800,0,0,...) at rt_msg1+0x59/frame 0xc7bd3900 rtsock_addrmsg(2,c3250e00,0,c2eee9b4,0,...) at rtsock_addrmsg+0x73/frame 0xc7bd3950 rtinit(c3250e00,2,0,c7bd3aa8,0,...) at rtinit+0x1a4/frame 0xc7bd3a58 tunclose(c3281800,7,2000,c2afc2f0,c7bd3abc,...) at tunclose+0x280/frame 0xc7bd3a80 devfs_close(c7bd3af4,c7bd3af4,c338cd50,7,c7bd3b18,...) at devfs_close+0x17f/frame 0xc7bd3ac4 VOP_CLOSE_APV(c0a99ce0,c7bd3af4,c0a40f74,141,c0ad08a0,...) at VOP_CLOSE_APV+0x4a/frame 0xc7bd3adc vn_close(c338cd50,7,c2956180,c2afc2f0,0,...) at vn_close+0x99/frame 0xc7bd3b18 vn_closefile(c314b460,c2afc2f0,c314b460,0,c2afc2f0,...) at vn_closefile+0x53/frame 0xc7bd3b74 devfs_close_f(c314b460,c2afc2f0,3000000,0,1,...) at devfs_close_f+0x34/frame 0xc7bd3b90 _fdrop(c314b460,c2afc2f0,0,c7bd3c00,2,0,0,c2b7d2d8,4,2,c7bd3c1c,c09b22e9,c2957760,288df000,2,0,c7bd3c10,c06462a4,1f,c314b460) at _fdrop+0x2d/frame 0xc7bd3bac closef(c314b460,c2afc2f0,0,c7bd3c38,c09b1d76,...) at closef+0x5b/frame 0xc7bd3c10 kern_close(c2afc2f0,6,c7bd3c98,c09bb3b2,c0aff1c0,...) at kern_close+0x18d/frame 0xc7bd3c48 syscall(c7bd3d08) at syscall+0x535/frame 0xc7bd3cfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xc7bd3cfc --- syscall (6, FreeBSD ELF32, sys_close), eip = 0x283c2393, esp = 0xbfbfe37c, ebp = 0xbfbfe388 --- KDB: stack backtrace: db_trace_self_wrapper(c0a38777,c0a678ac,c06c87f0,c7bd380c,a,c7bd3854,5,ffffffff,0,0,c0ab35e0,c7bd3840,c0676dca,c7bd3834,c06c824 e,c7bd3854,c7bd3848,c06c82fb,c0a678ac,c7bd3854) at db_trace_self_wrapper+0x26/frame 0xc7bd37ec kdb_backtrace(c0a678ac,b6,20,1,c7bd38c0,...) at kdb_backtrace+0x2b/frame 0xc7bd3848 uma_zalloc_arg(c13e45a0,c7bd38c0,1,936,c7bd38e4,...) at uma_zalloc_arg+0x706/frame 0xc7bd3898 rt_msg1(c7bd38e4,30,0,c32eba00,c32eba1c,...) at rt_msg1+0x59/frame 0xc7bd38d4 rtsock_routemsg(2,c2a54800,0,c2eee9b4,0,...) at rtsock_routemsg+0x4f/frame 0xc7bd3920 rt_newaddrmsg_fib(2,c3250e00,0,c2eee9b4,0,...) at rt_newaddrmsg_fib+0x4e/frame 0xc7bd3950 rtinit(c3250e00,2,0,c7bd3aa8,0,...) at rtinit+0x1a4/frame 0xc7bd3a58 tunclose(c3281800,7,2000,c2afc2f0,c7bd3abc,...) at tunclose+0x280/frame 0xc7bd3a80 devfs_close(c7bd3af4,c7bd3af4,c338cd50,7,c7bd3b18,...) at devfs_close+0x17f/frame 0xc7bd3ac4 VOP_CLOSE_APV(c0a99ce0,c7bd3af4,c0a40f74,141,c0ad08a0,...) at VOP_CLOSE_APV+0x4a/frame 0xc7bd3adc vn_close(c338cd50,7,c2956180,c2afc2f0,0,...) at vn_close+0x99/frame 0xc7bd3b18 vn_closefile(c314b460,c2afc2f0,c314b460,0,c2afc2f0,...) at vn_closefile+0x53/frame 0xc7bd3b74 devfs_close_f(c314b460,c2afc2f0,3000000,0,1,...) at devfs_close_f+0x34/frame 0xc7bd3b90 _fdrop(c314b460,c2afc2f0,0,c7bd3c00,2,0,0,c2b7d2d8,4,2,c7bd3c1c,c09b22e9,c2957760,288df000,2,0,c7bd3c10,c06462a4,1f,c314b460) a t _fdrop+0x2d/frame 0xc7bd3bac closef(c314b460,c2afc2f0,0,c7bd3c38,c09b1d76,...) at closef+0x5b/frame 0xc7bd3c10 kern_close(c2afc2f0,6,c7bd3c98,c09bb3b2,c0aff1c0,...) at kern_close+0x18d/frame 0xc7bd3c48 syscall(c7bd3d08) at syscall+0x535/frame 0xc7bd3cfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xc7bd3cfc --- syscall (6, FreeBSD ELF32, sys_close), eip = 0x283c2393, esp = 0xbfbfe37c, ebp = 0xbfbfe388 --- -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 24 14:58:31 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 24 Oct 2014 14:58:31 +0000 Subject: [Bug 192316] Invariant TSC gets misdetected on Intel Core 2 Duo processors, resulting in sluggish system behavior In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192316 --- Comment #4 from John Baldwin --- I have a possible patch that will disable Cx entirely if you force the use of TSC on one of these CPUs. However, can you do one more test for me. Can you let your system use _CST as normal but restrict your C states to only using C1? I want to make sure that C1E also stops the TSC. (I'm pretty sure it does.) I think we don't use C2 by default, so if you haven't explicitly changed something in sysctl.conf or rc.conf to enable C2 and you are having problems with the TSC as a timecounter, that would count as a test. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 24 15:04:35 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 24 Oct 2014 15:04:34 +0000 Subject: [Bug 194359] bsdinstall(8) 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 Dominik Zajac changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |banym at banym.de --- Comment #24 from Dominik Zajac --- I tested the image including the fix on a Lenovo T420 with no luck. Here my status: - Booting the image from USB in UEFI mode worked. - Booting the image from USB in Legacy Only didn't work. Installing zfs without encryption just with default values didn't lead to a booting sytem after reboot. As far as I understood the UEFI/Bios bug reports in that specific version of Thinkpads not only checks the partition active status. It looks like the type of the first partition is part of the problem, too. I stumbled over this manual fix but had no time to try it. It looks just like a dirty workaround to have a useless first partition to trick the UEFI/Bios. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 24 15:06:30 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 24 Oct 2014 15:06:29 +0000 Subject: [Bug 192316] Invariant TSC gets misdetected on Intel Core 2 Duo processors, resulting in sluggish system behavior In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192316 John Baldwin changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #145227|0 |1 is obsolete| | Assignee|freebsd-bugs at FreeBSD.org |jhb at FreeBSD.org --- Comment #5 from John Baldwin --- Created attachment 148617 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148617&action=edit always_disable.patch -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 24 18:34:56 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 24 Oct 2014 18:34:56 +0000 Subject: [Bug 194583] New: [panic] kernel panic when you try to read a bad DVD-rom Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194583 Bug ID: 194583 Summary: [panic] kernel panic when you try to read a bad DVD-rom Product: Base System Version: 10.1-BETA3 Hardware: Any OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: fidaj at ukr.net Created attachment 148623 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148623&action=edit core.txt when trying to read a bad DVD-rom system FreeBSD 10.1-PRERELEASE #0 r273545 went into panic uname -a FreeBSD nonamehost.local 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r273545: Thu Oct 23 18:58:06 EEST 2014 ivan at nonamehost.local:/media/da0s1/obj/usr/src/sys/mk10 amd64 -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 25 05:39:44 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 25 Oct 2014 05:39:44 +0000 Subject: [Bug 191574] [tests] tools/regression/zfs doesn't run on CURRENT In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191574 Garrett Cooper changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |Needs MFC --- Comment #3 from Garrett Cooper --- Fixed in r273628 and r273627. The changes need to be MFCed to 10-STABLE and 9-STABLE. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 25 05:43:19 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 25 Oct 2014 05:43:19 +0000 Subject: [Bug 194586] New: [zfs] kernel panic when running zpool/add/option-f_size_mismatch.t Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194586 Bug ID: 194586 Summary: [zfs] kernel panic when running zpool/add/option-f_size_mismatch.t 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 Created attachment 148633 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148633&action=edit kgdb backtrace The kernel panics right after this point in the test run: # ----- expected failure from: zpool status -x zfstest_c8a7e4550ec700769cf1a12080b06504 # ----- output (exit code=1): # cannot open 'zfstest_c8a7e4550ec700769cf1a12080b06504': no such pool # ----- end The stack trace per kgdb is attached. I have the corefile if you need further information. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 25 05:53:57 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 25 Oct 2014 05:53:57 +0000 Subject: [Bug 194586] [zfs] kernel panic when running zpool/add/option-f_size_mismatch.t In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194586 Garrett Cooper changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-fs at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 25 05:58:55 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 25 Oct 2014 05:58:55 +0000 Subject: [Bug 194587] New: [zfs] kernel panic when running zpool/add/open-f_type_mismatch.t Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194587 Bug ID: 194587 Summary: [zfs] kernel panic when running zpool/add/open-f_type_mismatch.t 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 Created attachment 148634 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148634&action=edit kgdb backtrace The test panics right after this point: ok 6 # ----- expected success from: zpool create zfstest_de43e450f45092235d069b72253f1282 md0 The stack trace per kgdb is attached. I have the corefile if you need further information. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 25 05:59:14 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 25 Oct 2014 05:59:14 +0000 Subject: [Bug 194587] [zfs] kernel panic when running zpool/add/open-f_type_mismatch.t In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194587 Garrett Cooper changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-fs at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 25 06:07:06 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 25 Oct 2014 06:07:06 +0000 Subject: [Bug 191574] [tests] tools/regression/zfs doesn't run on CURRENT In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191574 Garrett Cooper changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=1915 | |73, | |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=1945 | |86, | |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=1945 | |87 Assignee|freebsd-bugs at FreeBSD.org |ngie at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 25 07:16:20 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 25 Oct 2014 07:16:20 +0000 Subject: [Bug 194588] New: [zfs] kernel panic when running zpool/remove/spare.t Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194588 Bug ID: 194588 Summary: [zfs] kernel panic when running zpool/remove/spare.t 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 Created attachment 148635 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148635&action=edit core.txt.4 The test panics right after this point: ./spare.t .. 1..18 The stack trace per kgdb is attached. I have the corefile if you need further information. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 25 07:17:17 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 25 Oct 2014 07:17:17 +0000 Subject: [Bug 194589] New: [zfs] kernel panic when running zpool/create/files.t Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194589 Bug ID: 194589 Summary: [zfs] kernel panic when running zpool/create/files.t 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 Created attachment 148636 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148636&action=edit core.txt.3 This testcase crashes almost immediately: files.t ........... 1..59 The stack trace per kgdb is attached. I have the corefile if you need further information. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 25 07:17:31 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 25 Oct 2014 07:17:31 +0000 Subject: [Bug 194589] [zfs] kernel panic when running zpool/create/files.t In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194589 Garrett Cooper changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-fs at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 25 07:17:44 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 25 Oct 2014 07:17:45 +0000 Subject: [Bug 194588] [zfs] kernel panic when running zpool/remove/spare.t In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194588 Garrett Cooper changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-fs at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 25 08:42:34 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 25 Oct 2014 08:42:33 +0000 Subject: [Bug 194359] bsdinstall(8) 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 #25 from Dominik Zajac --- Sry. Forgot the link to the manuall fix/workaround: http://lists.freebsd.org/pipermail/freebsd-i386/2013-March/010437.html -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 25 08:56:48 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 25 Oct 2014 08:56:48 +0000 Subject: [Bug 194583] [panic] kernel panic when you try to read a bad DVD-rom disk In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194583 Ivan Klymenko changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[panic] kernel panic when |[panic] kernel panic when |you try to read a bad |you try to read a bad |DVD-rom |DVD-rom disk -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 25 10:20:50 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 25 Oct 2014 10:20:50 +0000 Subject: [Bug 194592] New: pf not adding all IP addresses when hostname used in table Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194592 Bug ID: 194592 Summary: pf not adding all IP addresses when hostname used in table 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: jason.mann at gmail.com - Overview: The pf.conf(5) man page states the following under the TABLES section: "In addition to being specified by IP address, hosts may also be specified by their hostname. When the resolver is called to add a hostname to a table, all resulting IPv4 and IPv6 addresses are placed into the table." pf is not exhibiting this behaviour. It is failing to add IPv6 addresses when a table is initialised from a file containing a hostname that resolves to both an IPv4 and IPv6 address: This is either a bug in pf, or an inaccuracy in the pf man page. - Steps to Reproduce: 1. Create a file to be used to initialise a pf table, containing a hostname that resolves to both an IPv4 and and IPv6 address. 2. Add table declaration to pf.conf referencing the file 3. Reload pf configuration 4. Use pfctl to check entries in the table - Actual Results: # dig +short any beastie.b0rken.org 31.193.132.199 2a02:af8:1000:e6::1fc1:84c7 # cat /etc/pf.table.test beastie.b0rken.org # grep "" /etc/pf.conf table persist file "/etc/pf.table.test" # pfctl -Ts -t test 31.193.132.199 - Expected Results: # pfctl -Ts -t test 31.193.132.199 2a02:af8:1000:e6::1fc1:84c7 -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 25 14:41:56 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 25 Oct 2014 14:41:56 +0000 Subject: [Bug 189696] [Regression] mdconfig and mdconfig2 startup scripts In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189696 Ryan Steinmetz changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zi at FreeBSD.org Severity|Affects Only Me |Affects Some People --- Comment #1 from Ryan Steinmetz --- # grep mdconf /etc/rc.conf mdconfig_md0="-t malloc -s 128m -o reserve" mdconfig_md0_owner="1001" mdconfig_md0_perms="0700" # mdconfig restart Umounting /dev/md0. Destroying md0. Device /dev/md0_owner isn't mounted. Device /dev/md0_perms isn't mounted. Creating md0 device (malloc). Mounting /dev/md0. Creating md0_owner device (1001). usage: mdconfig -a -t type [-n] [-o [no]option] ... [-f file] [-s size] [-S sectorsize] [-u unit] [-x sectors/track] [-y heads/cylinder] mdconfig -d -u unit [-o [no]force] mdconfig -l [-v] [-n] [-f file] [-u unit] mdconfig file type = {malloc, vnode, swap} option = {cluster, compress, reserve} size = %d (512 byte blocks), %db (B), %dk (kB), %dm (MB), %dg (GB) or %dt (TB) Creating md0_owner device failed, moving on. Creating md0_perms device (0700). usage: mdconfig -a -t type [-n] [-o [no]option] ... [-f file] [-s size] [-S sectorsize] [-u unit] [-x sectors/track] [-y heads/cylinder] mdconfig -d -u unit [-o [no]force] mdconfig -l [-v] [-n] [-f file] [-u unit] mdconfig file type = {malloc, vnode, swap} option = {cluster, compress, reserve} size = %d (512 byte blocks), %db (B), %dk (kB), %dm (MB), %dg (GB) or %dt (TB) Creating md0_perms device failed, moving on. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 25 17:06:15 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 25 Oct 2014 17:06:15 +0000 Subject: [Bug 194598] New: Deadlock with swap file on nanobsd.sh Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194598 Bug ID: 194598 Summary: Deadlock with swap file on nanobsd.sh Product: Base System Version: 10.0-STABLE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: holger at freyther.de While using nanobsd.sh and swap based md the kernel deadlocks. In my case I have a VM with just 2GB of RAM and then added a swap file by making an entry in fstab as of the FreeBSD handbook. When the swap file starts being used the system deadlocks. No new applications can be started, console switching and ddb is still working fine. Re-produce: 0.) Have kernel with DDB and enable break with CTRL+ALT+ESC 1.) Create VM with 2GB of RAM 2.) add "md99 none swap sw,file=/usr/swap0 0 0" 3.) cd /usr/src/tools/tools/nanobsd/pcengines 4.) ./build.sh alix_dsk.conf ... wait 5.) until the disk image is being created. What happens: * the "dd" process seems to continue to exist. * "show alllocks" shows (access is through vnc so manual copy and paste by me) Process 27312 (dd) ... exclusive lockmgr bufwait (bufwait) r = 0 (0xff...2e8) locked @ vm_pager.c:308 Process 725 (md99) exclusive lockmgr bufwait (bufwait) r = 0 (0xff..68) locked @ vfs_bio.c:2325 exclusive lockmgr bufwait (bufwait) r = 0 (0xff..08) locked @ vfs_bio.c:2325 exclusive lockmgr ufs (ufs) r= 0 (0xff..98) locked @ md.c:783 exclusive lockmgr bufwait (bufwait) r = 0 (0xff..4e8) locked @ vm_pager.c:308 Process 7 (bufdaemon) exclusive lockmgr bufwait (bufwait) r = 0 (0xff..48) locked @ vfs_bio.c:2325 Process 12 (intr).. Giant lock.. probably due using DDB.. tr 725 goes to sched_switch and sleeps there.. from vm_wait/vm_page_grab/allocbuf/getblk/ufs_bmaparray/ufs_strategy../VOP_WRITE_APV tr 27312 .. sched_switch from bwait/physio/devfs_read_f/dofileread/kern_readv/sys_readv tr 100077 sched_switch ... vm_wait/allocbuf/getblk/softdep_process_journal/softdep_process_worklist.. Given my limited knowledge it might not be a deadlock but somehow the "waiting" never stops. So the "md99" sleeping in vm_wait is certainly bad as no free pages will become available until something is written to md99. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 25 17:32:40 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 25 Oct 2014 17:32:40 +0000 Subject: [Bug 194598] Deadlock with swap file on nanobsd.sh In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194598 holger at freyther.de changed: What |Removed |Added ---------------------------------------------------------------------------- Hardware|Any |amd64 --- Comment #1 from holger at freyther.de --- I disabled soft update journaling on UFS and the "bufferdaemon" is not sleeping due vm_wait but the same situation continues to exist. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 25 18:50:13 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 25 Oct 2014 18:50:13 +0000 Subject: [Bug 189696] [Regression] mdconfig and mdconfig2 startup scripts In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189696 Devin Teske changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |dteske at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 25 19:51:35 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 25 Oct 2014 19:51:34 +0000 Subject: [Bug 194601] New: FreeBSD 10.1-RC3 does not update acpi battery status from discharging when charging Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194601 Bug ID: 194601 Summary: FreeBSD 10.1-RC3 does not update acpi battery status from discharging when charging Product: Base System Version: 10.1-RC2 Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Many People Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: moertael at hotmail.com Created attachment 148643 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148643&action=edit dmesg On HP Elitebook 2530p with latest bios (no idea if bios related or not) acpiconf -i0 does not show updated battery status. Like 173408 but without the often part. Shows discharging even though battery is charging. IIRC with 100 % battery charging/discharging indication worked normally. root at elite:~ # acpiconf -i0 Design capacity: 5100 mAh Last full capacity: 4806 mAh Technology: secondary (rechargeable) Design voltage: 10800 mV Capacity (warn): 200 mAh Capacity (low): 100 mAh Low/warn granularity: 100 mAh Warn/full granularity: 100 mAh Model number: Primary Serial number: 02365 2010/03/11 Type: LIon OEM info: Hewlett-Packard State: discharging <---------------- Remaining capacity: 98% Remaining time: 5:59 Present rate: 791 mA (9650 mW) Present voltage: 12201 mV -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sat Oct 25 20:20:31 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 25 Oct 2014 20:20:30 +0000 Subject: [Bug 194359] bsdinstall(8) 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 Kurt Jaeger changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pi at FreeBSD.org --- Comment #26 from Kurt Jaeger --- (In reply to Joseph Mingrone from comment #23) > I tested the modified image with a Lenovo X220, which refuses to legacy boot > anything GPT. I have a X220 to do tests. Is anyone working on getting the uefi and zfs boot code integrated ? -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sun Oct 26 05:42:42 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sun, 26 Oct 2014 05:42:42 +0000 Subject: [Bug 194604] New: [libpam] [patch] pam_unix doesn't allow validation of own password Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194604 Bug ID: 194604 Summary: [libpam] [patch] pam_unix doesn't allow validation of own password 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: conrad.meyer at isilon.com Created attachment 148656 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148656&action=edit (Apply with -p1; diff against r273647.) Linux-PAM provides this functionality via a setuid helper program, and programs have come to depend on it. In particular, enlightenment desktop's lock screen uses this feature to allow unlocking. You could argue this is a bug in enlightenment, but I'm not sure we'd prefer more ports shipping setuid helpers instead of providing one standard one. I don't see the harm in presenting the additional functionality, and it means more Linux programs work on FreeBSD. I have attempted to keep the setuid helper quite simple and keep the attack surface small. This helper only facilitates authentication, and like pam_unix, does not validate account expiration time. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sun Oct 26 05:44:03 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sun, 26 Oct 2014 05:44:03 +0000 Subject: [Bug 194604] [libpam] [patch] pam_unix doesn't allow validation of own password In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194604 Conrad Meyer changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |security-team at FreeBSD.org --- Comment #1 from Conrad Meyer --- CC'ing security team for sign-off as this adds a setuid program to base. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sun Oct 26 09:51:06 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sun, 26 Oct 2014 09:51:06 +0000 Subject: [Bug 194606] New: filesystem deadlock on 10.1 and head when TRIM enabled at unmount after r268815, MFC of 268205 Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194606 Bug ID: 194606 Summary: filesystem deadlock on 10.1 and head when TRIM enabled at unmount after r268815, MFC of 268205 Product: Base System Version: 10.1-RC2 Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: madpilot at FreeBSD.org CC: imp at FreeBSD.org While performing some tests with nanobad, FreeBSD 10.1-RC3 on alix hardware I discovered a lockup when unmounting filesystems. This hardware is a small motherboard using CF card as main storage. I usually enable trim support on these. NanoBSD mounts filesystems read only, and I use scripts to mount/unmount filesystems when changes need to be saved. I have seen a deadlock when unmounting. With a debugging kernel I got this: root at qtest:~ [0]# umount /cfg panic: detach with active requests KDB: stack backtrace: db_trace_self_wrapper(c0968053,c08ea7f0,c2d48800,c23d6bc8,c0536a16,...) at db_trace_self_wrapper+0x2d/frame 0xc23d6b98 kdb_backtrace(c09639e1,c09fa7e8,c095761d,c23d6c54,c095761d,...) at kdb_backtrace+0x30/frame 0xc23d6c00 vpanic(c09fa682,100,c095761d,c23d6c54,c23d6c54,...) at vpanic+0x80/frame 0xc23d6c24 kassert_panic(c095761d,c09575b3,c2d7acc0,4c7,c2d7acc0,...) at kassert_panic+0xe9/frame 0xc23d6c48 g_detach(c2d7acc0,4,c095725c,1c2,c09c8d5c,...) at g_detach+0x1d3/frame 0xc23d6c64 g_wither_washer(c09f7df4,0,c0956544,124,0,...) at g_wither_washer+0x109/frame 0xc23d6c90 g_run_events(0,c23d6d08,c095d42a,3dc,0,...) at g_run_events+0x40/frame 0xc23d6ccc fork_exit(c05c4e60,0,c23d6d08) at fork_exit+0x7f/frame 0xc23d6cf4 fork_trampoline() at fork_trampoline+0x8/frame 0xc23d6cf4 --- trap 0, eip = 0, esp = 0xc23d6d40, ebp = 0 --- KDB: enter: panic [ thread pid 12 tid 100006 ] Stopped at kdb_enter+0x3d: movl $0,kdb_why db> I played around with ddb and discovered this: db> show geom 0xc2e98b40 consumer: 0xc2e98b40 class: VFS (0xc09c8d5c) geom: ffs.ada0s3 (0xc3293600) provider: ada0s3 (0xc2e7e200) access: r0w0e0 flags: 0x0030 nstart: 19 nend: 18 Which shows nstart != nend, while g_detach asserts them to be the same. Going up the chain of providers I find also it's providers have nstart - nend == 1: db> show geom 0xc2e9b7c0 consumer: 0xc2e9b7c0 class: PART (0xc09c96b0) geom: ada0 (0xc2e7e780) provider: ada0 (0xc2e7e500) access: r2w0e0 flags: 0x0030 nstart: 1430 nend: 1429 db> show geom 0xc2e7e500 provider: ada0 (0xc2e7e500) class: DISK (0xc09c8890) geom: ada0 (0xc2e7e580) mediasize: 4017807360 sectorsize: 512 stripesize: 0 stripeoffset: 0 access: r2w0e0 flags: (0x0030) error: 0 nstart: 2085 nend: 2084 consumer: 0xc2e9a700 (ada0), access=r0w0e0, flags=0x0030 consumer: 0xc2e9b480 (ada0), access=r0w0e0, flags=0x0030 consumer: 0xc2e9b7c0 (ada0), access=r2w0e0, flags=0x0030 Having no idea how to debug further I started testing various revisions and I finally discovered that the commit that broke it is r268815, which MFCed r268205. Also disabling trim on the FS "fixes" the problem, which seems to confirm that change to be involved. Since this depends on hardware support for trim I have been unable to reproduce this in virtualbox. I'm sorry I'm unable to produce a use case. I'm CCing imp, who committed r268815, hoping he can have some more insight in this. This also affects head, obviously. I'm available for any further testing or information needed. Thanks in advance. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sun Oct 26 13:59:47 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sun, 26 Oct 2014 13:59:47 +0000 Subject: [Bug 194606] filesystem unmount deadlock on 10.1 and head when TRIM enabled at unmount after r268815, MFC of 268205 In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194606 Guido Falsi changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|filesystem deadlock on 10.1 |filesystem unmount deadlock |and head when TRIM enabled |on 10.1 and head when TRIM |at unmount after r268815, |enabled at unmount after |MFC of 268205 |r268815, MFC of 268205 -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sun Oct 26 14:03:48 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sun, 26 Oct 2014 14:03:48 +0000 Subject: [Bug 194606] filesystem unmount deadlock on 10.1 and head when TRIM enabled at unmount after r268815, MFC of 268205 In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194606 --- Comment #1 from Warner Losh --- If you disable trim, does the problem go away? I had a hard time scrounging up a CF card to test with on a SATA system. I'm guessing that I've dropped a biodone given the debug you've posted. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sun Oct 26 14:19:50 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sun, 26 Oct 2014 14:19:50 +0000 Subject: [Bug 194606] filesystem unmount deadlock on 10.1 and head when TRIM enabled at unmount after r268815, MFC of 268205 In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194606 Guido Falsi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |In Discussion --- Comment #2 from Guido Falsi --- (In reply to Warner Losh from comment #1) > If you disable trim, does the problem go away? Yes, it does go away. It easy to test, since simply mounting thee FS, editing a file with vi and unmounting it causes the panic, if not at first try it does in 2-3. > > I had a hard time scrounging up a CF card to test with on a SATA system. > > I'm guessing that I've dropped a biodone given the debug you've posted. Maybe, unluckily I don't know much about the kernel and the VFS system, so I can't really help with the code. Looking at it I noticed that before that commit thee value of softc->trim_running is changed before any operation is performed, while after the patch the code calls the new functions performing operation before changing that value, which is changed after the conditional (line 1506). It could be unrelated, I don't really know what that variable means, but could it be related? If you have some patch I'll be happy to test and report back. I can perform any kind of test, since this is not production hardware. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sun Oct 26 14:32:08 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sun, 26 Oct 2014 14:32:08 +0000 Subject: [Bug 194612] New: Fetching 4 metadata files ... gunzip: (stdin) : unexpected end of file Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194612 Bug ID: 194612 Summary: Fetching 4 metadata files ... gunzip: (stdin) : unexpected end of file Product: Base System Version: 10.1-RC2 Hardware: Any OS: Any Status: Needs Triage Severity: Affects Many People Priority: --- Component: bin Assignee: freebsd-bugs at FreeBSD.org Reporter: mikhail.rokhin at gmail.com Any version of OS Fetching 4 metadata files ... gunzip: (stdin) : unexpected end of file -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sun Oct 26 14:33:24 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sun, 26 Oct 2014 14:33:25 +0000 Subject: [Bug 194612] Fetching 4 metadata files ... gunzip: (stdin) : unexpected end of file In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194612 --- Comment #1 from mikhail.rokhin at gmail.com --- executing 'portsnap fetch update' -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Sun Oct 26 18:41:11 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sun, 26 Oct 2014 18:41:11 +0000 Subject: [Bug 194606] filesystem unmount deadlock on 10.1 and head when TRIM enabled at unmount after r268815, MFC of 268205 In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194606 --- Comment #3 from commit-hook at freebsd.org --- A commit references this bug: Author: smh Date: Sun Oct 26 18:41:01 UTC 2014 New revision: 273704 URL: https://svnweb.freebsd.org/changeset/base/273704 Log: Fix CF ERASE breakage caused by 268205. This prevents BIO_DELETE requests getting stuck in the TRIM queue which results in a panic on shutdown due to outstanding requests. PR: 194606 Reported by: Guido Falsi Reviewed by: mav MFC after: 3 days Sponsored by: Multiplay Changes: head/sys/cam/ata/ata_da.c -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at FreeBSD.org Sun Oct 26 21:00:28 2014 From: bugzilla-noreply at FreeBSD.org (bugzilla-noreply at FreeBSD.org) Date: Sun, 26 Oct 2014 21:00:28 +0000 Subject: Problem reports for freebsd-bugs@FreeBSD.org that need special attention Message-ID: <201410262100.s9QL0SA9086131@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 | 32808 | [patch] tcpd.h lacks prototype for hosts_ctl Needs MFC | 42336 | [patch] ISO-fication of /usr/src/contrib/tcp_wr 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 | 184681 | A bug of bsdconfig(8) in 10.0 RC1 Needs MFC | 190186 | [patch] i915 driver: enable opregion handling Needs MFC | 191511 | opiepasswd(1) segfaults with a seed length > 12 Patch Ready | 191348 | [mps] LSI2308 with WD3000FYYZ drives disappears Patch Ready | 192350 | [ipf] ipnat doesn't work with INET6 kernel opti 13 problems total for which you should take action. From bugzilla-noreply at freebsd.org Mon Oct 27 01:27:44 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 01:27:44 +0000 Subject: [Bug 191263] [patch] dd(1): Incorrect casting of arguments In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191263 will at worrbase.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #147543|0 |1 is obsolete| | --- Comment #7 from will at worrbase.com --- Created attachment 148683 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148683&action=edit Fix for dd's argument processing Apparently the problem was that I didn't submit the latest patch. :/ -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 01:57:07 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 01:57:07 +0000 Subject: [Bug 194513] zfs recv hangs in state kmem arena In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194513 --- Comment #1 from James Van Artsdalen --- Created attachment 148687 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148687&action=edit program to allocate 24GB RAM temporarily -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 01:58:09 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 01:58:09 +0000 Subject: [Bug 194513] zfs recv hangs in state kmem arena In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194513 --- Comment #2 from James Van Artsdalen --- I was able to complete a ZFS replication by manually intervening each time "zfs recv" blocked on "kmem arena": running the attached program "eatmem" was sufficient to unblock zfs each of the 17 times zfs stalled. Eatmem is intended to consume about 24GB RAM out of 32GB physical RAM, thereby pressuring the ARC and kernel cache to shrink: when the program exits it would leave plenty of free RAM for zfs or whatever else. What actually happened is that every time, zfs unblocked as eatmem was growing: it was never necessary to wait for eatmem to exit and free memory before zfs unblocked. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 06:28:27 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 06:28:27 +0000 Subject: [Bug 191263] [patch] dd(1): Incorrect casting of arguments In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191263 --- Comment #8 from Kurt Jaeger --- Thanks. This behaves as described. I'll try to find someone to commit it. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 08:00:04 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 08:00:03 +0000 Subject: [FreeBSD Bugzilla] Commit Needs MFC Message-ID: <201410270800.s9R803jY068429@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 32808: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=32808 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-bugs at FreeBSD.org Status: Needs MFC Resolution: Summary: [patch] tcpd.h lacks prototype for hosts_ctl Bug 42336: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=42336 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-bugs at FreeBSD.org Status: Needs MFC Resolution: Summary: [patch] ISO-fication of /usr/src/contrib/tcp_wrappers 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 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 191511: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191511 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-bugs at FreeBSD.org Status: Needs MFC Resolution: Summary: opiepasswd(1) segfaults with a seed length > 12 From bugzilla-noreply at freebsd.org Mon Oct 27 08:23:44 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 08:23:44 +0000 Subject: [Bug 194577] mbuf packet header leakage when closing TUN devices In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194577 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ae at FreeBSD.org --- Comment #2 from Andrey V. Elsukov --- Hi, Hans, If I understand correctly, you are able to track what mbuf were allocated and not freed in some period. Is it possible to modify your patch for printing content of these mbufs? I mean something like this: struct ip *ip; struct ip6_hdr *ip6; if (m->m_len > sizeof(struct ip)) { ip = mtod(m, struct ip*); printf("IP version: %u\n", ip->ip_v); switch(ip->ip_v) { case IPVERSION: /* print ip_src, ip_dst, ip_p */ break; case (IPV6_VERSION >> 4): ip6 = mtod(m, struct ip6_hdr *); /* print ip6_src, ip6_dst, ip6_nxt */ break; } } -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 08:36:58 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 08:36:58 +0000 Subject: [Bug 194577] mbuf packet header leakage when closing TUN devices In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194577 --- Comment #3 from Hans Petter Selasky --- Yes, can you send me a working example code with everything you want to print, and I'll add it to the kernel, taking a "struct mbuf *" as input. --HPS -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 09:06:01 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 09:06:01 +0000 Subject: [Bug 194577] mbuf packet header leakage when closing TUN devices In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194577 --- Comment #4 from Andrey V. Elsukov --- Created attachment 148695 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148695&action=edit kernel function for printing mbuf info -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 09:07:17 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 09:07:17 +0000 Subject: [Bug 194577] mbuf packet header leakage when closing TUN devices In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194577 --- Comment #5 from Andrey V. Elsukov --- the function is untested, so be careful :) -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 10:00:32 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 10:00:32 +0000 Subject: [Bug 194577] mbuf packet header leakage when closing TUN devices In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194577 --- Comment #6 from Hans Petter Selasky --- Testing right now. You will have the result soonish ... -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 10:15:09 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 10:15:09 +0000 Subject: [Bug 194577] mbuf packet header leakage when closing TUN devices In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194577 --- Comment #7 from Hans Petter Selasky --- Hi, Here are the candidates for lost mbufs: Stuck MBUF[2] TID=100082 LEN=0 mbuf 0xc3265e00: len 20, flags 0x00000002 mbuf 0xc3265e00: ip_v 0 Stuck MBUF[3] TID=100087 LEN=0 mbuf 0xc2b04e00: len 20, flags 0x00000002 mbuf 0xc2b04e00: ip_v 0 Stuck MBUF[5] TID=100087 LEN=0 mbuf 0xc2b02900: len 20, flags 0x00000002 mbuf 0xc2b02900: ip_v 0 Stuck MBUF[22] TID=100082 LEN=0 mbuf 0xc2b05100: len 20, flags 0x00000002 mbuf 0xc2b05100: ip_v 0 Stuck MBUF[23] TID=100082 LEN=0 mbuf 0xc2b07600: len 20, flags 0x00000002 mbuf 0xc2b07600: ip_v 0 Stuck MBUF[89] TID=100087 LEN=0 mbuf 0xc325da00: len 20, flags 0x00000002 mbuf 0xc325da00: ip_v 0 Note, this is 9-stable, so the M_PRINT_FLAGS was not there, and I used 0x%08x instead. --HPS -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 11:38:27 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 11:38:27 +0000 Subject: [Bug 191263] [patch] dd(1): Incorrect casting of arguments In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191263 --- Comment #9 from commit-hook at freebsd.org --- A commit references this bug: Author: pi Date: Mon Oct 27 11:38:19 UTC 2014 New revision: 273734 URL: https://svnweb.freebsd.org/changeset/base/273734 Log: bin/dd: Fix incorrect casting of arguments dd(1) casts many of its numeric arguments from uintmax_t to intmax_t and back again to detect whether or not the original arguments were negative. This caused wrong behaviour in some boundary cases: $ dd if=/dev/zero of=/dev/null count=18446744073709551615 dd: count cannot be negative After the fix: $ dd if=/dev/zero of=/dev/null count=18446744073709551615 dd: count: Result too large PR: 191263 Submitted by: will at worrbase.com Approved by: cognet@ Changes: head/bin/dd/args.c head/bin/dd/conv.c head/bin/dd/dd.c head/bin/dd/dd.h head/bin/dd/position.c -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 11:39:14 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 11:39:14 +0000 Subject: [Bug 191263] [patch] dd(1): Incorrect casting of arguments In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191263 Kurt Jaeger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Issue Resolved Resolution|--- |FIXED Assignee|freebsd-bugs at FreeBSD.org |pi at FreeBSD.org --- Comment #10 from Kurt Jaeger --- Committed, thanks for you patience. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 14:10:26 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 14:10:26 +0000 Subject: [Bug 194604] [libpam] [patch] pam_unix doesn't allow validation of own password In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194604 Dag-Erling Sm??rgrav changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |Issue Resolved CC| |des at FreeBSD.org Resolution|--- |Feature Proposal Rejected --- Comment #2 from Dag-Erling Sm??rgrav --- Sorry, but no. Use something like kpasswd instead. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 14:11:00 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 14:11:00 +0000 Subject: [Bug 194604] [libpam] [patch] pam_unix doesn't allow validation of own password In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194604 --- Comment #3 from Dag-Erling Sm??rgrav --- Sorry, I meant kcheckpass. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 14:26:14 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 14:26:14 +0000 Subject: [Bug 190529] [kvm] [panic] Kernel panic in KVM after recent Linux host upgrade [regression] In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190529 Vasiliy Tolstov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |v.tolstov at selfip.ru --- Comment #2 from Vasiliy Tolstov --- What seabios version do you have? As i know seabios 1.7.4 have bugs, i'm confirm this bug under 1.7.4 , but in seabios 1.7.5 i'm succeseful run freebsd under packer. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 14:53:45 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 14:53:45 +0000 Subject: [Bug 194604] [libpam] [patch] pam_unix doesn't allow validation of own password In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194604 --- Comment #4 from Conrad Meyer --- (In reply to Dag-Erling Sm??rgrav from comment #2) > Sorry, but no. Use something like kpasswd instead. So, this option then? > we'd prefer more ports shipping > setuid helpers instead of providing one standard one. (In reply to Dag-Erling Sm??rgrav from comment #3) > Sorry, I meant kcheckpass. $ pkg install kcheckpass pkg: No packages available to install matching 'kcheckpass' have been found in the repositories Any idea which of the myriad KDE ports actually provides kcheckpass? -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 14:56:26 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 14:56:26 +0000 Subject: [Bug 194604] [libpam] [patch] pam_unix doesn't allow validation of own password In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194604 Conrad Meyer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Issue Resolved |In Discussion Resolution|Feature Proposal Rejected |--- --- Comment #5 from Conrad Meyer --- (In reply to Conrad Meyer from comment #4) > Any idea which of the myriad KDE ports actually provides kcheckpass? Ah, it's kde-workspace. $ pkg install kde-workspace ... The process will require 641 MB more space. 223 MB to be downloaded. You think that's a usable solution? -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 16:51:20 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 16:51:20 +0000 Subject: [Bug 193656] Installer keymap selection not updated for vt(4) use In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193656 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |Open -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 16:53:08 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 16:53:08 +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 #3 from Ed Maste --- > I don?t understand why it?s not dumping core... It happens too early for the coredump, unfortunately. The kernel core infrastructure relies on the system getting to multiuser and executing /etc/rc.d/dumpon in order to set the dump device. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 17:40:27 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 17:40:27 +0000 Subject: [Bug 194421] [vt] output still messy and discontinuous. In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194421 arcade at b1t.name changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arcade at b1t.name --- Comment #2 from arcade at b1t.name --- Hi all. Can I chime in? On distortions, I saw more then one time that cursor screen position is not updated when printing kernel messages. I haven't captured that yet but it's fairly reproducible. 1. After X starts restart it so another portion of vt/kms info would be printed to the console. 2. Switch to screen 0 and hit Ctrl-Alt-Del. The messages coming to console would start overwriting vt/kms info like the cursor was placed just before it. I'm on 10-STABLE and my video is Radeon HD 7560D. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 18:28:36 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 18:28:36 +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 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 Mon Oct 27 19:05:13 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 19:05:13 +0000 Subject: [Bug 194639] New: vt(4) does not properly clear the screen after switching from the splash screen Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194639 Bug ID: 194639 Summary: vt(4) does not properly clear the screen after switching from the splash screen 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: emaste at freebsd.org Created attachment 148712 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148712&action=edit QEMU screen grab after exiting splash mode vt(4) has nascent splash screen support - a compiled-in 2-colour bitmap of the FreeBSD logo. It is currently activated in boot -m ("mute") mode. Some garbage is left on the screen when switching out of splash mode, as in the attachment. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 19:05:50 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 19:05:50 +0000 Subject: [Bug 194639] vt(4) does not properly clear the screen after switching from the splash screen In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194639 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 Mon Oct 27 19:08:58 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 19:08:58 +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 #4 from Juan Ram?n Molina Menor --- > It happens too early for the coredump, unfortunately. The kernel core > infrastructure relies on the system getting to multiuser and executing > /etc/rc.d/dumpon in order to set the dump device. Thanks for the explanation, some new knowledge? :) I hope you?ll resolve this issue soon. I?m ready to test. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 19:24:42 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 19:24:42 +0000 Subject: [Bug 194641] New: [EFI] boot/loader.efi: miscompilation on Intel Haswell with AVX2 Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194641 Bug ID: 194641 Summary: [EFI] boot/loader.efi: miscompilation on Intel Haswell with AVX2 Product: Base System Version: 11.0-CURRENT Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: ohartman at zedat.fu-berlin.de Compileing world on Intel Haswell with CPUTYPE?=native set in either /etc/make.conf and/or /etc/src.conf renders /boot/loader.efi to fail: the EFI boot process stops and freezes when loader.efi is loaded. The problem affects only Haswell-based hardware (from my point of view, it seems to be AVX2), since Sandy_bridge and Ivy-Bridge based systems do not show the problem, even if world/kernel is compiled with -O3 and -march=native as I have tested on several CURRENT systems with most recent CURRENT as of today (FreeBSD 11.0-CURRENT #2 r273743: Mon Oct 27 19:51:01 CET 2014 amd64). The problem has been discussed recently on the CURRENT mailing list, but no PR has been issued so far. Please look at http://freebsd.1045724.n5.nabble.com/CURRENT-EFI-boot-failure-td5949387.html oh -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 19:54:35 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 19:54:35 +0000 Subject: [Bug 194577] mbuf packet header leakage when closing TUN devices In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194577 --- Comment #8 from Andrey V. Elsukov --- Comment on attachment 148695 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148695 kernel function for printing mbuf info > printf("mbuf %p: len %u, flags %b\n", m, m->m_len, > m->m_flags, M_FLAG_PRINTF); Nothing specific :( It seems the last what here can be interesting is the following: if (m->m_flags & M_PKTHDR) printf(" hdrlen %u\n", m, m->m_pkthdr.len) > if (m->m_len < sizeof(struct ip)) > return; -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 19:57:56 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 19:57:56 +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 Matthias Apitz changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |guru at unixarea.de --- Comment #2 from Matthias Apitz --- I have an USB disk with 11-CURRENT (r269739) and in /boot/loader.conf set: kern.vty=vt i915kms_load="YES" while the disk boots fine on Acer EeePC 900 and Acer Aspire One D250, it gives on Dell E6330 a black screen after some seconds of booting and the system seems to hang; only power-cycle is possible; commenting-out the i915kms_load line, the system boots up fine; as it is reproduceable fine, I'm willing to help and insert debug messages if someone could guide me through; thx -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 20:02:04 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 20:02:04 +0000 Subject: [Bug 194421] [vt] output still messy and discontinuous. In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194421 --- Comment #3 from Ed Maste --- > On distortions, I saw more then one time that cursor screen position is not updated when printing kernel messages. I haven't captured that yet but it's fairly reproducible. I believe you're describing this issue, from the wiki: The text cursor may end up in the middle of kernel messages after loading a kernel video driver. I'm not sure what the original submitter means though. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 20:09:26 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 20:09:26 +0000 Subject: [Bug 194641] [EFI] boot/loader.efi: miscompilation on Intel Haswell with AVX2 In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194641 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |uefi CC| |emaste at freebsd.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 20:50:48 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 20:50:48 +0000 Subject: [Bug 194604] [libpam] [patch] pam_unix doesn't allow validation of own password In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194604 --- Comment #6 from Conrad Meyer --- I'm ok with kcheckpass as a solution, but it must be installable without pulling in all of KDE. I think that's doable. I should make a kcheckpass port; change kde4-workspace plist to exclude kcheckpass and have the port require it as a run-time dep; and finally fix enlightenment to use kcheckpass on FreeBSD. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 21:39:14 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 21:39:13 +0000 Subject: [Bug 194643] New: VFS vnode locking incorrect for non-lockmgr vnodes Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194643 Bug ID: 194643 Summary: VFS vnode locking incorrect for non-lockmgr vnodes 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: conrad.meyer at isilon.com insmntque and probably other parts of VFS are broken for VFS that do not use lockmgr. E.g. insmntque_stddtr enters with the vnode locked exclusive, wipes out the v_op table, and then calls vput() which uses VOP_ISLOCKED, VOP_LOCK, VOP_UNLOCK. For VFS where vop_lock1, vop_unlock, vop_islocked doesn't use lockmgr, insmntque_stddtr leaks the original lock; then vput tries to upgrade via dead_vnops. This is pretty bogus. Even for VFS that use lockmgr, insmntque_stddtr doesn't reset v_vnlock to &v_lock; it should probably do this (or just let vgone() do it). Additionally, since vgonel() wipes out v_op with dead_vnops, anything else that holds a vnode lock over vgone() is bogus. (But, not observably so for lockmgr- / v_lock-using VFS.) -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 21:45:51 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 21:45:51 +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 Brooks Davis changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs MFC |In Discussion CC| |brooks at FreeBSD.org Assignee|freebsd-bugs at FreeBSD.org |pfg at FreeBSD.org Flags| |mfc-stable8?, mfc-stable9?, | |mfc-stable10? -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Mon Oct 27 22:59:02 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Mon, 27 Oct 2014 22:59:02 +0000 Subject: [Bug 194644] New: 10.1-RC3 ignores kern.vty=vt Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194644 Bug ID: 194644 Summary: 10.1-RC3 ignores kern.vty=vt Product: Base System Version: 10.1-RC2 Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: crum.zach at gmail.com Created attachment 148718 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148718&action=edit dmesg output from system In 10.1-RC2 kern.vty=vt in /boot/loader.conf.local enabled the new console. I loved it. Upgrading to RC3 lost the functionality. uname output: FreeBSD Shadow 10.0-RC3-p1 FreeBSD 10.0-RC3-p1 #0: Sat Jan 11 07:51:07 UTC 2014 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 28 00:10:16 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 28 Oct 2014 00:10:16 +0000 Subject: [Bug 190529] [kvm] [panic] Kernel panic in KVM after recent Linux host upgrade [regression] In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190529 Bryan Drewery changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bdrewery at FreeBSD.org --- Comment #3 from Bryan Drewery --- I've gotten this with a VMWare guest. sys/dev/fb/vesa.c:822 (vmbuf = x86bios_alloc) is returning NULL. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 28 00:33:30 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 28 Oct 2014 00:33:30 +0000 Subject: [Bug 190529] [kvm] [panic] Kernel panic in KVM after recent Linux host upgrade [regression] In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190529 --- Comment #4 from Bryan Drewery --- (In reply to Bryan Drewery from comment #3) > I've gotten this with a VMWare guest. sys/dev/fb/vesa.c:822 (vmbuf = > x86bios_alloc) is returning NULL. The issue here was having VMware configured for 8 CPU while it claimed only 2 were supported. Lowering to the 2 maximum allowed it to boot. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 28 00:36:50 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 28 Oct 2014 00:36:50 +0000 Subject: [Bug 190529] [kvm] [panic] Kernel panic in KVM after recent Linux host upgrade [regression] In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190529 --- Comment #5 from Bryan Drewery --- (In reply to Bryan Drewery from comment #4) > (In reply to Bryan Drewery from comment #3) > > I've gotten this with a VMWare guest. sys/dev/fb/vesa.c:822 (vmbuf = > > x86bios_alloc) is returning NULL. > > The issue here was having VMware configured for 8 CPU while it claimed only > 2 were supported. Lowering to the 2 maximum allowed it to boot. For further reference the guest did claim to have 8 CPU in this invalid configuration. -- You are receiving this mail because: You are the assignee for the bug. From johnandsara2 at cox.net Tue Oct 28 02:02:09 2014 From: johnandsara2 at cox.net (John D. Hendrickson and Sara Darnell) Date: Mon, 27 Oct 2014 19:54:18 -0500 Subject: [Bug 194477] 10.1-RC1 tar(1) spurious directory permission error message In-Reply-To: <6PZF1p00b2X408g01PZGNi> References: <6PZF1p00b2X408g01PZGNi> Message-ID: <544EE93A.8040707@cox.net> bugzilla-noreply at freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194477 > > --- Comment #1 from John Marshall --- > Confirmed independently on -stable@ > > https://lists.freebsd.org/pipermail/freebsd-stable/2014-October/080685.html > > The scenario of traversal-only access to the parent directory is common in a > situation where the directory contains per-user subdirectories, and each user > has no business knowing about any subdirectory but his own. > > The archive generated is fine, the user has full permission to the directory > being archived, but tar(1) exits with an error status. > > I regard this regression as a bug. > i'll bite very interesting is the error on tar or utar ? i assume you mean on tar -c but be specific is this new or do older version NOT do this? if so please state the right and wrong tar versions. also i need a firm permission basis. just because you are in same group may not be the same as owning (w/respect to utar, not tar) and if your using any "kernel extended permissions" (tar obviously uses only unix file security / bits. it stores file perms also user # in tar header) i don't see any follow-ups just the initial comlaint, did this complain expire ? From john.marshall at riverwillow.com.au Tue Oct 28 04:49:08 2014 From: john.marshall at riverwillow.com.au (John Marshall) Date: Tue, 28 Oct 2014 15:48:45 +1100 Subject: [Bug 194477] 10.1-RC1 tar(1) spurious directory permission error message In-Reply-To: <544EE93A.8040707@cox.net> References: <6PZF1p00b2X408g01PZGNi> <544EE93A.8040707@cox.net> Message-ID: <20141028044845.GB5687@rwpc15.gfn.riverwillow.net.au> On Mon, 27 Oct 2014, 19:54 -0500, John D. Hendrickson and Sara Darnell wrote: > bugzilla-noreply at freebsd.org wrote: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194477 > > > > --- Comment #1 from John Marshall --- > > Confirmed independently on -stable@ > > > > https://lists.freebsd.org/pipermail/freebsd-stable/2014-October/080685.html > > > > The scenario of traversal-only access to the parent directory is common in a > > situation where the directory contains per-user subdirectories, and each user > > has no business knowing about any subdirectory but his own. > > > > The archive generated is fine, the user has full permission to the directory > > being archived, but tar(1) exits with an error status. > > > > I regard this regression as a bug. > > > > i'll bite very interesting > > is the error on tar or utar ? i assume you mean on tar -c but be > specific [as per Bug 194477 report] tar -c -C > is this new or do older version NOT do this? if so please state the > right and wrong tar versions. [as per Bug 194477 report] Bug observed in 10.1-RC3. Fine =< 9.3-RELEASE > also i need a firm permission basis. just because you are in same > group may not be the same as owning (w/respect to utar, not tar) and > if your using any "kernel extended permissions" (tar obviously uses > only unix file security / bits. it stores file perms also user # in > tar header) Specific permissions documented in Bug 194477 report. Error is triggered if process running tar -c -C . does not have +r access to the parent of the directory . If the tar process has +x access only to the parent of the -C (and full access to ) then the tar archive is written correctly but tar exits with an error because it cannot read 's parent directory. It looks like the earlier tar used chdir() to walk back up the tree at the end whereas the current tar uses openat() and tries to openat() the parent of after the tree has been processed - and fails due to lack of +r access. > i don't see any follow-ups just the initial comlaint, did this > complain expire ? Nobody has picked this up yet but another user on -stable@ confirmed the problem and provided an even simpler test case. -- John Marshall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From bugzilla-noreply at freebsd.org Tue Oct 28 06:45:06 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 28 Oct 2014 06:45:06 +0000 Subject: [Bug 194651] New: FreeBSD 10.1-RC3 audio hiss with powerd options on Elitebook 2530p Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194651 Bug ID: 194651 Summary: FreeBSD 10.1-RC3 audio hiss with powerd options on Elitebook 2530p Product: Base System Version: 10.1-RC2 Hardware: Any OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: moertael at hotmail.com I found one of the weirdest bugs in my life. It seems that powerd's options cause hiss in the audio on my laptop. Here are the options from rc.conf: powerd_flags="-n min -b min -a adp -r 90 -m 800 -M 2100" and device.hints: #turn off connections that don't seem to exist hint.hdaa.0.nid18.config="conn=None" hint.hdaa.0.nid26.config="conn=None" hint.hdaa.0.nid28.config="conn=None" #speakers hint.hdaa.0.nid22.config="as=1 seq=0" #headphones with auto switching hint.hdaa.0.nid17.config="as=1 seq=15" #build in microphone hint.hdaa.0.nid21.config="as=2 seq=0" #microphone jack with auto switching hint.hdaa.0.nid20.config="as=2 seq=14" -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 28 06:45:54 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 28 Oct 2014 06:45:54 +0000 Subject: [Bug 194612] Fetching 4 metadata files ... gunzip: (stdin) : unexpected end of file In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194612 --- Comment #2 from mikhail.rokhin at gmail.com --- Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Updating from Thu Oct 23 20:45:44 MSK 2014 to Tue Oct 28 10:06:40 MSK 2014. Fetching 4 metadata patches. done. Applying metadata patches... done. Fetching 4 metadata files... gunzip: (stdin): unexpected end of file metadata is corrupt. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 28 07:58:26 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 28 Oct 2014 07:58:25 +0000 Subject: [Bug 194604] [libpam] [patch] pam_unix doesn't allow validation of own password In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194604 --- Comment #7 from Dag-Erling Sm??rgrav --- If you feel like writing your own version and are comfortable releasing it under the three-clause BSD license, I may include it in OpenPAM. It won't be available in FreeBSD until 10.2 at the earliest, more likely 11, but we can easily make a port to install it on systems that don't have it in base. BTW, this is vastly more flexible than the Linux-PAM solution, as the latter will only work for users with traditional password hashes available through NSS, not for users who authenticate through Kerberos, RADIUS or some other remote method. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 28 09:36:52 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 28 Oct 2014 09:36:51 +0000 Subject: [Bug 194654] New: 10.1-RC3 hangs with simultanious writes Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194654 Bug ID: 194654 Summary: 10.1-RC3 hangs with simultanious writes Product: Base System Version: 10.1-RC2 Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: misc Assignee: freebsd-bugs at FreeBSD.org Reporter: FreeBSD at ShaneWare.Biz Created attachment 148728 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148728&action=edit ASUS P8H61-M LE/USB3 dmesg.boot After almost 3 years of running 9.x on this machine with only manual reboots to install updates I find that I am unable to keep 10.1 running for more than a day. After some trial and error I have found that two simultaneous writes to disk causes a memory issue that ends with a hang once wired memory usage hits 7GB (8GB installed) at this stage the reset button is the only thing that still works. Under light usage this would appear to build up over the period of a day, while forced heavy usage causes a hang within a minute. Running two copies of the attached test.sh while watching top seems normal for a while, then within a minute the wired memory amount can quickly jump from 3GB to 7GB within 6 seconds. Running two instances of the script simultaneously on a USB memstick and the zfs filesystem or both on the zfs filesystem produces the same problem. I have tested this by booting into single user mode, mounting the filesystem and using screen to run top and two scripts at the same time with the same result. Machine is an ASUS P8H61-M LE/USB3 corei5 8GB with 3x 2TB Seagate drives in raidz. I think the pool was created with 9.2 (possibly with 9.1) and the pool and bootcode was updated after installing 10.1 just before RC2 was tagged. FreeBSD leader.local 10.1-RC3 FreeBSD 10.1-RC3 #16 r273471: Thu Oct 23 06:32:33 ACDT 2014 root at leader.local:/usr/obj/usr/src/sys/GENERIC amd64 In single user mode the following modules were loaded - kernel zfs.ko opensolaris.ko geom_eli.ko crypto.ko geom_journal.ko geom_mirror.ko geom_uzip.ko aio.ko coretemp.ko sem.ko smb.ko smbus.ko libiconv.ko libmchain.ko cd9660_iconv.ko ext2fs.ko msdosfs_iconv.ko udf.ko udf_iconv.ko tmpfs.ko nvidia.ko dtraceall.ko profile.ko cyclic.ko dtrace.ko systrace_freebsd32.ko systrace.ko sdt.ko lockstat.ko fasttrap.ko fbt.ko dtnfscl.ko dtmalloc.ko -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 28 09:39:00 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 28 Oct 2014 09:39:00 +0000 Subject: [Bug 194654] 10.1-RC3 hangs with simultanious writes In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194654 --- Comment #1 from FreeBSD at ShaneWare.Biz --- Created attachment 148729 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148729&action=edit forced stress script -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 28 10:08:40 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 28 Oct 2014 10:08:40 +0000 Subject: [Bug 193704] pw: group disappeared during update In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193704 Baptiste Daroussin changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |bapt at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 28 10:13:30 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 28 Oct 2014 10:13:28 +0000 Subject: [Bug 183429] pw(8) returns "pw: user 'foo' disappeared during update" after freebsd-update upgrade In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183429 Baptiste Daroussin changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |bapt at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 28 10:39:35 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 28 Oct 2014 10:39:35 +0000 Subject: [Bug 190529] [kvm] [panic] Kernel panic in KVM after recent Linux host upgrade [regression] In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190529 --- Comment #6 from Vasiliy Tolstov --- In my case seabios upgrade solve issue -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 28 11:18:14 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 28 Oct 2014 11:18:13 +0000 Subject: [Bug 194577] mbuf packet header leakage when closing TUN devices In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194577 --- Comment #9 from Hans Petter Selasky --- Hi, Here is how to reproduce: FreeBSD-9-stable: 1) install openvpn from ports 2) generate an openvpn key 3) start two instances of openvpn like this (no need for a client!) /usr/local/sbin/openvpn --keepalive 120 240 --float --lport 543 --dev tun3 \ --ifconfig 10.1.2.6 10.1.2.7 \ --secret xxxx.key --daemon testlink /usr/local/sbin/openvpn --proto tcp_server --keepalive 120 240 --float --lport 544 --dev tun4 \ --ifconfig 10.1.2.8 10.1.2.9 \ --secret xxxx.key --daemon testlink2 4) watch vmstat -z | grep -E "LIMIT|mbuf:" After some minutes, the number of mbufs in use starts growing simply. Maybe that's simpler for you to reproduce? --HPS -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 28 13:07:41 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 28 Oct 2014 13:07:41 +0000 Subject: [Bug 194604] [libpam] [patch] pam_unix doesn't allow validation of own password In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194604 --- Comment #8 from Conrad Meyer --- (In reply to Dag-Erling Sm??rgrav from comment #7) > If you feel like writing your own version and are comfortable releasing it > under the three-clause BSD license, I may include it in OpenPAM. Sure. The helper source file in the attached patch is 2-clause BSD; 3-clause is fine. (The attached patch also has one manual page derived from Linux-PAM, which is 3-clause BSD.) > It won't > be available in FreeBSD until 10.2 at the earliest, more likely 11, but we > can easily make a port to install it on systems that don't have it in base. CURRENT is what I care about, that is fine. > BTW, this My initial patch, kcheckpass, or something else you're proposing? > is vastly more flexible than the Linux-PAM solution, as the latter > will only work for users with traditional password hashes available through > NSS, not for users who authenticate through Kerberos, RADIUS or some other > remote method. If we're talking about the attached patch, it only modifies pam_unix and only checks for passwords available through getpwnam(3). My read of that man page was that it was only for local hashes. And of course, if a pam_unix is disabled in a PAM configuration, it won't be run at all which may be surprising if it is expected to check remote passwords. I'm happy to rework this in another way! Just let me know how you would like it to look and function, or anything I can do to help. Thanks. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 28 14:54:16 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 28 Oct 2014 14:54:16 +0000 Subject: [Bug 90114] [patch] pw(8) takes strings after option -g for GID 0 In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=90114 --- Comment #1 from commit-hook at freebsd.org --- A commit references this bug: Author: bapt Date: Tue Oct 28 14:54:05 UTC 2014 New revision: 273782 URL: https://svnweb.freebsd.org/changeset/base/273782 Log: Do not delete the group wheel when bad argument is passed to pw groupdel -g Check that the -g argument is actually a number, if not report an error. This argument is converted without checking with atoi(3) later so without this check it converts any alpha entries into 0 meaning it deletes the group wheel Add a regression test about it PR: 90114 Reported by: bkoenig at cs.tu-berlin.de MFC after: 1 week Changes: head/usr.sbin/pw/pw_group.c head/usr.sbin/pw/tests/pw_delete.sh -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 28 14:55:57 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 28 Oct 2014 14:55:57 +0000 Subject: [Bug 90114] [patch] pw(8) takes strings after option -g for GID 0 In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=90114 Baptiste Daroussin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Needs MFC -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 28 15:36:11 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 28 Oct 2014 15:36:11 +0000 Subject: [Bug 193865] [sys/conf/files.amd64] [patch]=?UTF-8?Q?=20option=20=E2=80=A6=5FDFLT=5FKEYMAP=20config=20header=20generation=20fix?= In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193865 Harald Schmalzbauer changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|option XXX_DFLT_KEYMAP |[sys/conf/files.amd64] |config header generation |[patch] option |fix |?_DFLT_KEYMAP config header | |generation fix -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 28 15:39:34 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 28 Oct 2014 15:39:34 +0000 Subject: [Bug 187189] [PATCH] pw(1): pw groupmod groupname -g ### creates duplicate groups In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187189 mcdouga9 at egr.msu.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs-patch |patch Summary|pw(1): pw groupmod |[PATCH] pw(1): pw groupmod |groupname -g ### creates |groupname -g ### creates |duplicate groups |duplicate groups 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 28 15:53:49 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 28 Oct 2014 15:53:49 +0000 Subject: [Bug 187189] [PATCH] pw(1): pw groupmod groupname -g ### creates duplicate groups In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187189 Baptiste Daroussin changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |bapt at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 28 17:10:42 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 28 Oct 2014 17:10:41 +0000 Subject: [Bug 194664] New: radeonkms_load="YES" halts system, Failed to load firmware! Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194664 Bug ID: 194664 Summary: radeonkms_load="YES" halts system, Failed to load firmware! Product: Base System Version: 10.1-RC2 Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: crum.zach at gmail.com Created attachment 148741 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148741&action=edit dmesg output from system When enabled, the radeon kms driver appears to halt the kernel. The only way to rescue the system is to use a different boot drive and remove the offending line from /boot/loader.conf.local This is the only part of the trace I can capture info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xffff800000c0000 (131072 bytes) info: [drm] ATOM BIOS: CAYMAN drmn0: info: VRAM: 2048M 0x0000000000000000 - 0x000000007FFFFFFF (2048M used) drmn0: info: GTT: 512M 0x0000000000000000 - 0x000000009FFFFFFF info: [drm] Detected VRAM RAM=2048M, BAR=256M info: [drm] RAM width 256bits DDR [TTM] Zone kernel: Available graphics memory: 8374848 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator info: [drm] radeon: 2048M of VRAM memory ready info: [drm] radeon: 512M of GTT memory ready. info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] radeon: irq initialized. info: [drm] GART: num cpu pages 131072, num gpu pages 131072 info: [drm] probinggen 2 caps for device 1022:9603 = 2/0 info: [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 info: [drm] Loading CAYMn Microcode error: [drm:pid0:ni_init_microcode] *ERROR* ni_cp: Failed to load firmware "radeonkmsfw_CAYMAN_pfp" error: [drm:pid0:cayman_startup] *ERROR* Failed to load firmware! drmn0: error: disabling GPU acceleration drmn0: warning: 0xffffff800075f6800 unpin not necessary drmn0: warning: 0xffffff800075f6800 unpin not necessaary error: [drm:pid0:cayman_init] *ERROR* radeon: MC ucode required for NI+. drmn0: error: Fatal error during GPU init info: [drm] radeon: finished device. [TTM] Finalizing pool allocator -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Oct 28 22:09:31 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 28 Oct 2014 22:09:31 +0000 Subject: [Bug 194672] New: [carp] Changing advskew to 0 from another value doesn't work Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194672 Bug ID: 194672 Summary: [carp] Changing advskew to 0 from another value doesn't work Product: Base System Version: 10.1-RC2 Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: cmb at pfsense.org When you configure advskew in CARP to be something other than 0, then try to change it back to 0, FreeBSD refuses to do so. It can be changed to any value other than 0, but never back to 0. This is a semi-common scenario, as it's how people would generally demote a system from master to backup for maintenance or other purposes, and would generally want to set it back to 0 afterwards. Initially setting it to 0 works fine. Tested on 10.0 release and 10.1-RC3, both behave the same. The following shows the issue and how to replicate. # ifconfig em0 vhid 55 advskew 0 pass PASSWORD alias 192.168.124.222/24 # ifconfig em0 em0: flags=8943 metric 0 mtu 1500 options=9b ether 00:0c:29:11:5e:be inet 192.168.124.132 netmask 0xffffff00 broadcast 192.168.124.255 inet 192.168.124.222 netmask 0xffffff00 broadcast 192.168.124.255 vhid 55 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active carp: MASTER vhid 55 advbase 1 advskew 0 Change it, it'll work. # ifconfig em0 vhid 55 advskew 100 # ifconfig em0 | grep carp: carp: MASTER vhid 55 advbase 1 advskew 100 Try changing it back to 0, and it won't. # ifconfig em0 vhid 55 advskew 0 # ifconfig em0 | grep carp: carp: MASTER vhid 55 advbase 1 advskew 100 But can change it to 1 or other values. # ifconfig em0 vhid 55 advskew 1 # ifconfig em0 | grep carp: carp: MASTER vhid 55 advbase 1 advskew 1 -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 04:27:22 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 04:27:22 +0000 Subject: [Bug 194675] New: [tests] bin/pkill tests implicitly require "kernel files" Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194675 Bug ID: 194675 Summary: [tests] bin/pkill tests implicitly require "kernel files" Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: misc Assignee: freebsd-bugs at FreeBSD.org Reporter: ngie at FreeBSD.org Spotted this in passing while trying to fix another one of my bugs: # kyua debug bin/pkill/pgrep-F_test:main kyua-tap-tester: Configuration variables not supported; ignoring 'has.cleanup=false' kyua-tap-tester: Configuration variables not supported; ignoring 'unprivileged-user=tests' 1..1 pgrep: Cannot open kernel files (empty file: Invalid argument) not ok - pgrep -F bin/pkill/pgrep-F_test:main -> failed: 1 tests of 1 failed # kyua debug bin/pkill/pgrep-LF_test:main kyua-tap-tester: Configuration variables not supported; ignoring 'has.cleanup=false' kyua-tap-tester: Configuration variables not supported; ignoring 'unprivileged-user=tests' 1..2 pgrep: Cannot open kernel files (empty file: Invalid argument) not ok 1 - pgrep -LF ok 2 - pgrep -LF bin/pkill/pgrep-LF_test:main -> failed: 1 tests of 2 failed -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 04:28:25 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 04:28:25 +0000 Subject: [Bug 194675] [tests] bin/pkill tests implicitly require "kernel files" In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194675 Garrett Cooper changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |Issue Resolved Resolution|--- |Not A Bug --- Comment #1 from Garrett Cooper --- Ah, nevermind. It was because I forgot to mount /dev in the chroot. Invalid.. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 08:34:55 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 08:34:55 +0000 Subject: [Bug 194522] smartmontools misbehaving (self-test timestamps do not match reality) In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194522 Jeremy Chadwick changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |Issue Resolved Resolution|--- |Overcome By Events --- Comment #2 from Jeremy Chadwick --- After system was power-cycled, issue can no longer be reproduced. My opinion is that the AHCI controller involved (ICH9) may have some kind of option ROM bug or general issue that was rectified via a power-cycle. See my most recent/final comment in the smartmontools ticket for details. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 11:12:16 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 11:12:16 +0000 Subject: [Bug 194606] filesystem unmount deadlock on 10.1 and head when TRIM enabled at unmount after r268815, MFC of 268205 In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194606 --- Comment #4 from commit-hook at freebsd.org --- A commit references this bug: Author: smh Date: Wed Oct 29 11:11:55 UTC 2014 New revision: 273818 URL: https://svnweb.freebsd.org/changeset/base/273818 Log: MFS10 r273814 MFC r273704 Fix ATA CF ERASE breakage caused by 268205 PR: 194606 Approved by: re (marius) Sponsored by: Multiplay Changes: _U releng/10.1/ releng/10.1/sys/cam/ata/ata_da.c -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 11:32:58 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 11:32:58 +0000 Subject: [Bug 194681] New: [geom] a race in gmirror cause kernel panic during shutdown Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194681 Bug ID: 194681 Summary: [geom] a race in gmirror cause kernel panic during shutdown Product: Base System Version: 9.2-RELEASE Hardware: i386 OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: alexandre.martins at netasq.com There is a race in the shutdown process of gmirror. Time to time, a synchronization completion event rise after the gmirror device was destroyed [1510] Waiting (max 60 seconds) for system process `vnlru' to stop...done [1510] Waiting (max 60 seconds) for system process `bufdaemon' to stop...done [1510] [1510] Waiting (max 60 seconds) for system process `syncer' to stop...Syncing disks, vnodes remaining...0 0 0 done [1512] All buffers synced. [1513] Uptime: 25m13s [1513] GEOM_MIRROR: Device gm0: rebuilding provider ad0 stopped. [1513] GEOM_MIRROR: Device gm0: provider mirror/gm0 destroyed. [1513] kernel trap 12 with interrupts disabled [1513] [1513] [1513] Fatal trap 12: page fault while in kernel mode [1513] cpuid = 2; apic id = 12 [1513] fault virtual address = 0xf000f858 [1513] fault code = supervisor read, page not present [1513] instruction pointer = 0x20:0x407574af [1513] stack pointer = 0x28:0x86e2da98 [1513] frame pointer = 0x28:0x86e2daa0 [1513] code segment = base 0x0, limit 0xfffff, type 0x1b [1513] = DPL 0, pres 1, def32 1, gran 1 [1513] processor eflags = resume, IOPL = 0 [1513] current process = 13 (g_up) [1513] Physical memory: 3050 MB [1513] Dumping 1256 MB: 1241 1225 1209 1193 1177 1161 1145 1129 1113 1097 1081 1065 1049 1033 1017 1001 985 969 953 937 921 905 889 873 857 841 825 809 793 777 761 745 729 713 697 681 665 649 633 617 601 585 569 553 537 521 505 489 473 457 441 425 409 393 377 361 345 329 313 297 281 265 249 233 217 201 185 169 153 137 121 105 89 73 57 41 25 9 gdb$ bt #0 doadump (textdump=0x86e2d638) at pcpu.h:249 #1 0x404b7e19 in db_fncall (dummy1=0x407574af, dummy2=0x0, dummy3=0xfffffffe, dummy4=0x86e2d6cc "???\206") at ../../../ddb/db_command.c:573 #2 0x404b824f in db_command (last_cmdp=0x40a1865c, cmd_table=0x0, dopager=0x0) at ../../../ddb/db_command.c:449 #3 0x404b8304 in db_command_script (command=0x40a19585 "call doadump()") at ../../../ddb/db_command.c:520 #4 0x404bc740 in db_script_exec (scriptname=0x4091f3aa "kdb.enter.default", warnifnotfound=) at ../../../ddb/db_script.c:302 #5 0x404bc83b in db_script_kdbenter (eventname=0x409a480e "unknown") at ../../../ddb/db_script.c:325 #6 0x404ba358 in db_trap (type=0xc, code=0x0) at ../../../ddb/db_main.c:230 #7 0x406d8af6 in kdb_trap (type=0xc, code=0x0, tf=0x86e2da58) at ../../../kern/subr_kdb.c:649 #8 0x408d75af in trap_fatal (frame=0x86e2da58, eva=0xf000f858) at ../../../i386/i386/trap.c:1035 #9 0x408d768d in trap_pfault (frame=0x86e2da58, usermode=0x0, eva=0xf000f858) at ../../../i386/i386/trap.c:859 #10 0x408d872b in trap (frame=0x86e2da58) at ../../../i386/i386/trap.c:555 #11 0x408c1fbc in calltrap () at ../../../i386/i386/exception.s:170 #12 0x407574af in strlen (str=0xf000f859
) at ../../../libkern/strlen.c:98 #13 0x406dcd2e in kvprintf (fmt=0x4095dd45 " @ %s:%d", func=0x406dbff0 , arg=0x86e2dbdc, radix=0xa, ap=0x86e2dc20 "L8\225@?\003") at ../../../kern/subr_prf.c:823 #14 0x406dd5bb in vsnprintf (str=0x40c85100 "mtx_lock() of spin mutex ", size=0x100, format=0x4095dd2a "mtx_lock() of spin mutex %s @ %s:%d", ap=0x86e2dc1c "Y?") at ../../../kern/subr_prf.c:556 #15 0x406a075e in panic (fmt=0x4095dd2a "mtx_lock() of spin mutex %s @ %s:%d") at ../../../kern/kern_shutdown.c:713 #16 0x4068e638 in _mtx_lock_flags (m=0x54, opts=0x0, file=0x4095384c "../../../geom/mirror/g_mirror.c", line=0x3dc) at ../../../kern/kern_mutex.c:204 #17 0x406315eb in g_mirror_sync_done (bp=0x8d865854) at ../../../geom/mirror/g_mirror.c:988 #18 0x40723adc in biodone (bp=0x8d865854) at ../../../kern/vfs_bio.c:3650 #19 0x40626f08 in g_io_schedule_up (tp=0x8ce9b2f0) at ../../../geom/geom_io.c:805 #20 0x40627acd in g_up_procbody (arg=0x0) at ../../../geom/geom_kern.c:97 #21 0x40670548 in fork_exit (callout=0x40627a30 , arg=0x0, frame=0x86e2dd08) at ../../../kern/kern_fork.c:992 #22 0x408c2064 in fork_trampoline () at ../../../i386/i386/exception.s:279 gdb$ f 17 #17 0x406315eb in g_mirror_sync_done (bp=0x8d865854) at ../../../geom/mirror/g_mirror.c:988 988 ../../../geom/mirror/g_mirror.c: No such file or directory. in ../../../geom/mirror/g_mirror.c gdb$ p bp->bio_from->geom->softc $3 = (void *) 0x0 980 static void 981 g_mirror_sync_done(struct bio *bp) 982 { 983 struct g_mirror_softc *sc; 984 985 G_MIRROR_LOGREQ(3, bp, "Synchronization request delivered."); 986 sc = bp->bio_from->geom->softc; 987 bp->bio_cflags = G_MIRROR_BIO_FLAG_SYNC; 988 *crash* mtx_lock(&sc->sc_queue_mtx); 989 bioq_disksort(&sc->sc_queue, bp); 990 mtx_unlock(&sc->sc_queue_mtx); 991 wakeup(sc); 992 } This problem look like : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=162997 -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 13:51:19 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 13:51:19 +0000 Subject: [Bug 194606] filesystem unmount deadlock on 10.1 and head when TRIM enabled at unmount after r268815, MFC of 268205 In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194606 Guido Falsi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Issue Resolved Resolution|--- |FIXED --- Comment #5 from Guido Falsi --- Thanks! -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 14:07:40 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 14:07:40 +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 #5 from Ed Maste --- > It happens too early for the coredump, unfortunately. The kernel core > infrastructure relies on the system getting to multiuser and executing > /etc/rc.d/dumpon in order to set the dump device. Oh, see dumpon(8) - you can set the dumpdev variable from the loader to set the dumpdev in early boot. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 15:02:27 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 15:02:26 +0000 Subject: [Bug 194685] New: CPU -1 on top Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194685 Bug ID: 194685 Summary: CPU -1 on top 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: danilo at FreeBSD.org The top command is showing -1 as CPU number. PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 99223 danilo 10 52 0 136M 83636K nanslp 3 0:56 27.39% doxygen 1629 danilo 1 79 0 35456K 12228K CPU-1 -1 0:34 27.25% doxygen 3079 danilo 1 79 0 35456K 12268K CPU-1 -1 0:27 26.47% doxygen 99390 danilo 1 79 0 35456K 12260K CPU-1 -1 0:38 24.43% doxygen 1624 danilo 1 78 0 35456K 12120K CPU3 3 0:35 21.49% doxygen 462 danilo 1 52 0 35456K 12284K zio->i 1 0:37 20.37% doxygen 99353 danilo 1 79 0 35456K 12644K CPU-1 -1 0:38 19.33% doxygen 1967 danilo 1 78 0 35456K 12228K CPU-1 -1 0:34 18.50% doxygen I'm running current r273751. This bug is probably related to r273266 (cpuid u_char -> int). -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 15:55:09 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 15:55:09 +0000 Subject: [Bug 178115] Laptop (Asus X55VD) locks up when configuring wifi (Ralink RT5390) from LiveCD mode of official install medium In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=178115 Kevin Lo changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kevlo at FreeBSD.org --- Comment #4 from Kevin Lo --- RT5390 is not supported by FreeBSD but I'm planning to add it support. Please stay tuned. :-) -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 15:57:05 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 15:57:05 +0000 Subject: [Bug 178115] Laptop (Asus X55VD) locks up when configuring wifi (Ralink RT5390) from LiveCD mode of official install medium In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=178115 --- Comment #5 from purpleritza at gmail.com --- (In reply to Kevin Lo from comment #4) > RT5390 is not supported by FreeBSD but I'm planning to add it support. > Please stay tuned. :-) I'd be grateful and be your tester, please update this bug. Thanks a ton! -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 16:34:06 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 16:34:06 +0000 Subject: [Bug 194690] New: options IPSEC disables TCP keepalives Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194690 Bug ID: 194690 Summary: options IPSEC disables TCP keepalives Product: Base System Version: 10.1-RC1 Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: mail at ross.cx Compiling IPSEC into the kernel disables TCP keepalives even on connections not using IPSEC. I stumbled over this because I had lots of stale sshd processes and sockets from days-long physically disconnected clients lingering, the connection never times out. If I remove IPSEC from the kernel, these processes and sockets disappear after a while. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 16:54:14 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 16:54:14 +0000 Subject: [Bug 194690] options IPSEC disables TCP keepalives In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194690 Bjoern A. Zeeb changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bz at FreeBSD.org --- Comment #1 from Bjoern A. Zeeb --- Just to clarify, do you use any IPsec? Have any policies or anything? -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 16:54:27 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 16:54:27 +0000 Subject: [Bug 194690] options IPSEC disables TCP keepalives In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194690 --- Comment #2 from Bjoern A. Zeeb --- Just to clarify, do you use any IPsec? Have any policies or anything? -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 17:02:50 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 17:02:50 +0000 Subject: [Bug 194690] options IPSEC disables TCP keepalives In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194690 --- Comment #3 from Michael Ross --- (In reply to Bjoern A. Zeeb from comment #2) > Just to clarify, do you use any IPsec? Have any policies or anything? No, nothing. It is totally unused, just compiled in. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 17:51:37 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 17:51:37 +0000 Subject: [Bug 86319] [nfs] [request] support a "noac" NFS mount flag to turn off the attribute cache In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=86319 Edward Tomasz Napierala changed: What |Removed |Added ---------------------------------------------------------------------------- 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 Wed Oct 29 19:33:25 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 19:33:24 +0000 Subject: [Bug 194696] New: Asus X551CAP brightness problem (acpi, acpi_video) Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194696 Bug ID: 194696 Summary: Asus X551CAP brightness problem (acpi, acpi_video) Product: Base System Version: 10.0-RELEASE Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: theblackdaffodilcult at gmail.com Hello, I can't adjust the display brightness on an ASUS X551CAP laptop running 10-RELEASE (amd64). There's a `hw.acpi.video.lcd0.brigthness' sysctl, which i can modify, but no change actual brightness can be observed: # sysctl hw.acpi.video.lcd0.brigthness=1 hw.acpi.video.lcd0.brightness: 20 -> 1 # sysctl hw.acpi.video.lcd0.brigthness=100 hw.acpi.video.lcd0.brightness: 1 -> 100 Nor can the 'hw.acpi.video.lcd0.active=0' be changed by using # sysctl hw.acpi.video.lcd0.active=1 hw.acpi.video.lcd0.active: 0 -> 0 (acpi_video.ko module was loaded while testing this, I made sure of that) After none of this worked I loaded the acpi_call module. A lot of the commands I threw at that had no effect or returned 'Unknown object type '0' (including these ones:) #acpi_call -p '\_SB-PCI0-GFX0.DD02._BCM' -i 4 #acpi_call -p '\VBRU' '(Brightness Up)' #acpi_call -p \VBRD' #acpi_call -p '\-SB.PCI0.GFX0.DD02._BQC' 0 #acpi_call -p '\-SB.PCI0.GFX0.DD02._BQC' #acpi_call -p '\-SB.PCI0.GFX0.DD02._BCM' #acpi_call -p '\-SB.PCI0.GFX0.DD02._BCL' #acpi_call -p '\-SB.PCI0.GFX0.DD02._BCL' 10 #acpi_call -p '\-SB.PCI0.GFX0.DD02._BCL' 4 i3 window manager on Xorg CPU: Intel(R) Celeron(R) CPU 1007U @ 1.50GHz (1496.64-M) My make.conf file has nothing specified but: PACKAGES=/usr/ports/packages PS: fn+f5 and fn+f6 cannot be used to affect the brightness either and do not change the value for ? hw.acpi.video.lcd0.brigthness? either. I came across more people experiencing the same issue as me while on my quest to find a solution on the Internet. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 19:59:34 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 19:59:34 +0000 Subject: [Bug 194685] CPU -1 on top In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194685 Mark Johnston changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |Issue Resolved CC| |markj at FreeBSD.org Resolution|--- |FIXED Assignee|freebsd-bugs at FreeBSD.org |jkim at FreeBSD.org --- Comment #1 from Mark Johnston --- This should be fixed by r273835. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 21:02:27 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 21:02:27 +0000 Subject: [Bug 193758] either gptzfsboot or zfsloader hangs during boot after kernel and pool upgrade In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193758 mark at blackmans.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mark at blackmans.org --- Comment #4 from mark at blackmans.org --- Following a suggestion from Matt Reimer, I've updated the bootcode gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 but using a gptzfsboot from FreeBSD 9.2-release. So my immediate problem is resolved, but it does mean there's a bug in the gptzfsboot for FreeBSD 8.4 at least. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 21:02:41 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 21:02:41 +0000 Subject: [Bug 194577] mbuf packet header leakage when closing TUN devices In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194577 --- Comment #10 from Andrey V. Elsukov --- Created attachment 148778 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148778&action=edit Proposed patch Hi, Hans, can you try this patch? My investigations led me to the following conclusions. The leak isn't specific to tun(4) device, it could be reproduced with any device where MLD works. The backtrace to the allocation that will not be freed is uma_zalloc_arg mld_v2_enqueue_group_record+0x678 mld_change_state+0x3b9 in6_mc_join_locked+0x346 in6_mc_join+0x94 in6_joingroup+0x58 in6_update_ifa+0xd2c in6_ifattach+0x506 ifioctl+0x8e0 kern_ioctl+0x3cd sys_ioctl+0x13c -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 21:07:10 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 21:07:10 +0000 Subject: [Bug 193758] either gptzfsboot or zfsloader hangs during boot after kernel and pool upgrade In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193758 --- Comment #5 from mark at exonetric.com --- So there's a bug here still. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 21:24:40 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 21:24:40 +0000 Subject: [Bug 193758] either gptzfsboot or zfsloader hangs during boot after kernel and pool upgrade In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193758 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ae at FreeBSD.org --- Comment #6 from Andrey V. Elsukov --- (In reply to mark from comment #2) > chance to try that, but as far as I can tell the only difference in zfsboot > between 8.4 and 9.2 were a couple of lines relating to serial console > handling, suggesting like the forum comment that gptzfsboot is hanging in > some serial console related code. The difference between 8.x and 9.x+ is very big. 9.x includes this commit and many other fixes https://svnweb.freebsd.org/base?view=revision&revision=243243 -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 21:48:20 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 21:48:20 +0000 Subject: [Bug 193758] either gptzfsboot or zfsloader hangs during boot after kernel and pool upgrade In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193758 --- Comment #7 from mark at exonetric.com --- Ok, I was looking at the difference between 8.4 and 9.2 just for the zfsboot directory. There is more to gptzfsboot than just zfsboot and I'd didn't look at all the contributions separately. $ svn diff https://svn0.eu.freebsd.org/base/releng/8.4/sys/boot/i386/zfsboot https://svn0.eu.freebsd.org/base/releng/9.2/sys/boot/i386/zfsboot Index: zfsboot.c =================================================================== --- zfsboot.c (.../8.4/sys/boot/i386/zfsboot) (revision 273837) +++ zfsboot.c (.../9.2/sys/boot/i386/zfsboot) (revision 273837) @@ -54,7 +54,7 @@ #define NOPT 14 #define NDEV 3 -#define BIOS_NUMDRIVES 0x475 +#define BIOS_NUMDRIVES 0x475 #define DRV_HARD 0x80 #define DRV_MASK 0x7f @@ -489,7 +489,12 @@ * will find any other available pools and it may fill in missing * vdevs for the boot pool. */ - for (i = 0; i < *(unsigned char *)PTOV(BIOS_NUMDRIVES); i++) { +#ifndef VIRTUALBOX + for (i = 0; i < *(unsigned char *)PTOV(BIOS_NUMDRIVES); i++) +#else + for (i = 0; i < MAXBDDEV; i++) +#endif + { if ((i | DRV_HARD) == *(uint8_t *)PTOV(ARGS)) continue; @@ -780,8 +785,10 @@ } ioctrl = OPT_CHECK(RBX_DUAL) ? (IO_SERIAL|IO_KEYBOARD) : OPT_CHECK(RBX_SERIAL) ? IO_SERIAL : IO_KEYBOARD; - if (ioctrl & IO_SERIAL) - sio_init(115200 / comspeed); + if (ioctrl & IO_SERIAL) { + if (sio_init(115200 / comspeed) != 0) + ioctrl &= ~IO_SERIAL; + } } if (c == '?') { dnode_phys_t dn; Index: Makefile =================================================================== --- Makefile (.../8.4/sys/boot/i386/zfsboot) (revision 273837) +++ Makefile (.../9.2/sys/boot/i386/zfsboot) (revision 273837) @@ -16,7 +16,6 @@ CFLAGS= -DBOOTPROG=\"zfsboot\" \ -O1 \ - -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 \ -DBOOT2 \ -DSIOPRT=${BOOT_COMCONSOLE_PORT} \ -DSIOFMT=${B2SIOFMT} \ @@ -78,7 +77,7 @@ SRCS= zfsboot.c -.if ${MACHINE_ARCH} == "amd64" +.if ${MACHINE_CPUARCH} == "amd64" beforedepend zfsboot.o: machine CLEANFILES+= machine machine: @@ -86,3 +85,7 @@ .endif .include + +# XXX: clang integrated-as doesn't grok .codeNN directives yet +CFLAGS.zfsldr.S= ${CLANG_NO_IAS} +CFLAGS+= ${CFLAGS.${.IMPSRC:T}} -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 21:52:30 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 21:52:30 +0000 Subject: [Bug 194577] mbuf packet header leakage when closing TUN devices In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194577 --- Comment #11 from Hans Petter Selasky --- Hi, I see no more buffer leakages currently. I'll let you know if I find more. Don't forget to MFC to 9- and 10- stable. Might be possible to get it in before 10.1-R too ... --HPS -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 23:15:45 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 23:15:44 +0000 Subject: [Bug 194697] New: incoming IP TOS bits get zeroed on mbufs that need checksumming Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194697 Bug ID: 194697 Summary: incoming IP TOS bits get zeroed on mbufs that need checksumming 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: seb at f5.com Created attachment 148780 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148780&action=edit save & restore IP TOS field when computing TCP checksum On mbufs that don't have the CSUM_DATA_VALID flag set, tcp_input() needs to compute the TCP checksum itself. The TCP checksum includes some but not all fields from the IP header. tcp_input() zeroes the fields of the IP header that are not to be included in the checksum, then checksums the entire packet (IP header, TCP header, and TCP data), then restores the IP header fields it will need later. The bug is that the IP TOS field was not restored, so the later read of it returned a zeroed byte instead of the incoming packet's actual TOS value. The attached patch contains a suggested fix that resolves the issue for me. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Wed Oct 29 23:16:26 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 29 Oct 2014 23:16:26 +0000 Subject: [Bug 194697] incoming IP TOS bits get zeroed on mbufs that need checksumming In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194697 --- Comment #1 from Sebastian Kuzminsky --- This bugfix is also available as a github Pull Request: https://github.com/freebsd/freebsd/pull/12 -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 30 07:28:26 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 30 Oct 2014 07:28:26 +0000 Subject: [Bug 194577] mbuf packet header leakage when closing TUN devices In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194577 --- Comment #12 from Hans Petter Selasky --- Created attachment 148792 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148792&action=edit Cleanup altq before destroy Hi, While at it, I suggest you add the attached patch to the commit aswell. What do you think? --HPS -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 30 08:07:50 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 30 Oct 2014 08:07:50 +0000 Subject: [Bug 194700] New: mmc driver panic: AutoCMD12 error but no command in progress Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194700 Bug ID: 194700 Summary: mmc driver panic: AutoCMD12 error but no command in progress Product: Base System Version: 10.1-RC2 Hardware: arm OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: me at mornfall.net When trying to boot FreeBSD 10.1-RC3 images on a RPI-B+ from a Kingston micro-SDHC card, I get a panic on boot in the SDHC driver. I think it may be the same problem as this: https://lkml.org/lkml/2014/2/3/12 ... unfortunately I don't have a serial console at the moment to copy the dump or a backtrace. The SDHC card in question gives me the warning quoted in the LKML post under Linux. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 30 11:00:06 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 30 Oct 2014 11:00:06 +0000 Subject: [Bug 194577] mbuf packet header leakage when closing TUN devices In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194577 --- Comment #13 from commit-hook at freebsd.org --- A commit references this bug: Author: ae Date: Thu Oct 30 10:59:58 UTC 2014 New revision: 273855 URL: https://svnweb.freebsd.org/changeset/base/273855 Log: Fix mbuf leak in IPv6 multicast code. When multicast capable interface goes away, it leaves multicast groups, this leads to generate MLD reports, but MLD code does deffered send and MLD reports are queued in the in6_multi's in6m_scq ifq. The problem is that in6_multi structures are freed when interface leaves multicast groups and thread that does deffered send will not take these queued packets. PR: 194577 MFC after: 1 week Sponsored by: Yandex LLC Changes: head/sys/netinet6/in6_mcast.c -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 30 11:01:00 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 30 Oct 2014 11:01:00 +0000 Subject: [Bug 194577] mbuf packet header leakage when closing TUN devices In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194577 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |Needs MFC Assignee|freebsd-bugs at FreeBSD.org |ae at FreeBSD.org --- Comment #14 from Andrey V. Elsukov --- Patched in head/. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 30 14:44:43 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 30 Oct 2014 14:44:43 +0000 Subject: [Bug 194703] New: makefs has trouble with nlink, time attributes from MANIFEST files Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194703 Bug ID: 194703 Summary: makefs has trouble with nlink,time attributes from MANIFEST files 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: bz at FreeBSD.org /tmp/makeroot.3fo7N/manifest:69: warning: nlink: unsupported keyword /tmp/makeroot.3fo7N/manifest:69: error: time: invalid value '1412983049' makefs: 68 error(s) and 68 warning(s) in mtree manifest sorting out these two attributes when running mtree -c -R blink,time | mtree -C > MANIFEST makes all problems go away. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Oct 30 22:27:04 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 30 Oct 2014 22:27:03 +0000 Subject: [Bug 194654] 10.1-RC3 hangs with simultanious writes In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194654 --- Comment #2 from FreeBSD at ShaneWare.Biz --- This is limited to the zpool I have 10.1 installed on. I can boot from 10.1-RC3-amd64-disc1.iso and import the zpool to repeat the issue. I also have a single disk zpool (external usb3 drive) that is a version 28 zpool - I can import this and have no issue. Properties of the zpool are - zrpleader size 5.41T - zrpleader capacity 86% - zrpleader altroot - default zrpleader health ONLINE - zrpleader guid 7653467844531205029 default zrpleader version - default zrpleader bootfs zrpleader local zrpleader delegation on default zrpleader autoreplace off default zrpleader cachefile - default zrpleader failmode wait default zrpleader listsnapshots off default zrpleader autoexpand off default zrpleader dedupditto 0 default zrpleader dedupratio 1.00x - zrpleader free 761G - zrpleader allocated 4.66T - zrpleader readonly off - zrpleader comment - default zrpleader expandsize 0 - zrpleader freeing 0 default zrpleader fragmentation 28% - zrpleader leaked 0 default zrpleader feature at async_destroy enabled local zrpleader feature at empty_bpobj active local zrpleader feature at lz4_compress active local zrpleader feature at multi_vdev_crash_dump enabled local zrpleader feature at spacemap_histogram active local zrpleader feature at enabled_txg active local zrpleader feature at hole_birth active local zrpleader feature at extensible_dataset enabled local zrpleader feature at embedded_data active local zrpleader feature at bookmarks enabled local zrpleader feature at filesystem_limits enabled local -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 31 07:57:26 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 31 Oct 2014 07:57:26 +0000 Subject: [Bug 194709] New: FreeBSD 10.1-RC3 boots without keyboard sporadically Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194709 Bug ID: 194709 Summary: FreeBSD 10.1-RC3 boots without keyboard sporadically Product: Base System Version: 10.1-RC2 Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs at FreeBSD.org Reporter: moertael at hotmail.com Created attachment 148817 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148817&action=edit dmesg Keyboard input does not come to the gdm login screen and the keys beep when I touch them. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 31 07:57:55 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 31 Oct 2014 07:57:55 +0000 Subject: [Bug 194709] FreeBSD 10.1-RC3 boots without keyboard sporadically In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194709 --- Comment #1 from Juha Nyg?rd --- The computer is Thinkpad T500. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 31 17:24:01 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 31 Oct 2014 17:24:00 +0000 Subject: [Bug 194718] New: vt(4): Keyboard not working properly when not using kbdmux(4) Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194718 Bug ID: 194718 Summary: vt(4): Keyboard not working properly when not using kbdmux(4) 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 When using kbdmux(4), which is the default in all supported versions of FreeBSD, the keyboard is working properly in the console and in an X session: $ kbdcontrol -i < /dev/ttyv0 kbd1: kbdmux0, type:AT 101/102 (2) $ xev (...) KeyPress event, serial 30, synthetic NO, window 0x2600001, root 0x2c3, subw 0x0, time 25050869, (525,686), root:(1486,706), state 0x10, keycode 45 (keysym 0x6b, k), same_screen YES, XLookupString gives 1 bytes: (6b) "k" XmbLookupString gives 1 bytes: (6b) "k" XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x2600001, root 0x2c3, subw 0x0, time 25050973, (525,686), root:(1486,706), state 0x10, keycode 45 (keysym 0x6b, k), same_screen YES, XLookupString gives 1 bytes: (6b) "k" XFilterEvent returns: False However, when kbdmux is disabled through "hint.kbdmux.0.disabled=1" in /boot/loader.conf, the keyboard isn't reported correctly by kbdcontrol: $ kbdcontrol -i < /dev/ttyv0 kbd0: 0, type:generic (0) And under X, the keyboard doesn't work at all. After the first keystroke, xev(1) receives invalid keyboard events in an infinite loop: KeyPress event, serial 30, synthetic NO, window 0x1200001, root 0x80, subw 0x0, time 81112, (639,380), root:(640,400), state 0x0, keycode 203 (keysym 0x0, NoSymbol), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x1200001, root 0x80, subw 0x0, time 81804, (639,380), root:(640,400), state 0x0, keycode 203 (keysym 0x0, NoSymbol), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 33, synthetic NO, window 0x1200001, root 0x80, subw 0x0, time 81804, (639,380), root:(640,400), state 0x0, keycode 203 (keysym 0x0, NoSymbol), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x1200001, root 0x80, subw 0x0, time 81845, (639,380), root:(640,400), state 0x0, keycode 203 (keysym 0x0, NoSymbol), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False Even the first keystroke is incorrect (here, it should be 'k'). The same situation tested with syscons works. kbdcontrol reports that atkbd0 is connected. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 31 17:24:31 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 31 Oct 2014 17:24:31 +0000 Subject: [Bug 194718] vt(4): Keyboard not working properly when not using kbdmux(4) In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194718 Jean-Sebastien Pedron 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 31 21:33:18 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 31 Oct 2014 21:33:18 +0000 Subject: [Bug 194604] [libpam] [patch] pam_unix doesn't allow validation of own password In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194604 --- Comment #9 from Dag-Erling Sm??rgrav --- I meant "your own version of something similar to kcheckpass". Sorry for the late response. For some reason, I didn't get a copy of your comment by email. -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 31 21:33:25 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 31 Oct 2014 21:33:26 +0000 Subject: [Bug 194604] [libpam] [patch] pam_unix doesn't allow validation of own password In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194604 Dag-Erling Sm??rgrav changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |des at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Oct 31 23:11:14 2014 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 31 Oct 2014 23:11:14 +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 --- Comment #4 from commit-hook at freebsd.org --- A commit references this bug: Author: dumbbell Date: Fri Oct 31 23:10:59 UTC 2014 New revision: 273921 URL: https://svnweb.freebsd.org/changeset/base/273921 Log: vt(4): Add PIO_VFONT_DEFAULT ioctl to restore the default builtin font To restore the default font using vidcontrol(1), use the "-f" flag without an argument: vidcontrol -f < /dev/ttyv0 PR: 193910 Differential Revision: https://reviews.freebsd.org/D971 Submitted by: Marcin Cieslak Reviewed by: ray@, emaste@ Approved by: ray@ MFC of: r273544 Changes: _U stable/10/ stable/10/sys/dev/vt/vt_core.c stable/10/sys/sys/consio.h stable/10/usr.sbin/vidcontrol/vidcontrol.1 stable/10/usr.sbin/vidcontrol/vidcontrol.c -- You are receiving this mail because: You are the assignee for the bug.