[Bug 218579] Wake on Lan doesn't work for bge NIC driver

2017-04-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218579

Bug ID: 218579
   Summary: Wake on Lan doesn't work for bge NIC driver
   Product: Base System
   Version: CURRENT
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: pozzu...@gmail.com

I use Nas4Free on HP ProLiant MicroServer. Nas4Free is based on FreeBSD and I
and some other people have a problem that is related to the bge NIC driver
included in the last FreeBSD kernel.

We can't use Wake On Lan feature, even if it is enabled in BIOS. It is an issue
with FreeBSD, because we can use WOL with other OS (such as Linux) on the same
hw.

Someone noticed the WOL feature works if the NIC is connected to a Gigabit
Ethernet, but not if the link is 100Mbps. Unfortunately I can't test Gigabit on
my system.

Someone says older Nas4Free versions worked, for example that based on FreeBSD
9.2.

You can read much more details on a specific thread present on Nas4Free forum,
here (https://www.nas4free.org/forums/viewtopic.php?f=58=4756=30).

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 218574] [patch] asmc add support for Macbook Air 2011, 11inch model 4,1 to control backlight

2017-04-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218574

Bug ID: 218574
   Summary: [patch] asmc add support for Macbook Air 2011, 11inch
model 4,1 to control backlight
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Keywords: patch
  Severity: Affects Only Me
  Priority: ---
 Component: misc
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: t43invisible...@gmail.com
  Keywords: patch

Created attachment 181703
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=181703=edit
asmc patch for macbook air 2011 11 inch model 4,1

I have created a patch for asmc for the Macbook Air 2011, 11 inch model 4,1

I dumped the smc stats from the macbook air using smc fan control

This patch enables the keyboard backlight and fan control

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 218571] umtx compat6 regression affecting 'jar' command

2017-04-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218571

Conrad Meyer  changed:

   What|Removed |Added

 CC||c...@freebsd.org

--- Comment #1 from Conrad Meyer  ---
Rather than adding backwards compatibility for a 10-year obsolete version of
FreeBSD to 11, why not just rebuild jdk1.5.0?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 218572] pass(4) driver sometimes does error recovery when CAM_PASS_ERR_RECOVER is not set

2017-04-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218572

Bug ID: 218572
   Summary: pass(4) driver sometimes does error recovery when
CAM_PASS_ERR_RECOVER is not set
   Product: Base System
   Version: 10.3-STABLE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: terry-free...@glaver.org

[This is a summation of a long discussion between me, ken@ and mav@]

After SVN rev 236814 in FreeBSD/head, the pass(4) driver does some error 
recovery, but not all cases, when the retry_count is set in the CCB and
CAM_PASS_ERR_RECOVER is not set.

Previously, the pass(4) driver would only do error recovery if
CAM_PASS_ERR_RECOVER is set.

This can be seen with 'camcontrol tur -v'.  camcontrol sets the retry_count
to 1 by default, so that the user will have at least one retry if he turns
on retries with -E.

If you reset a hard drive:

# camcontrol reset 1:172:0
Reset of 1:172:0 was successful

There should be a Unit Attention pending:

# camcontrol tur 1:172:0 -v
Unit is ready

But that doesn't happen, because the kernel is doing error recovery when
we have not turned it on with -E (which sets the CAM_PASS_ERR_RECOVER flag
on the CCB).

Retrying the experiment:

# camcontrol reset 1:172:0
Reset of 1:172:0 was successful

Now set the retry count to 0:

# camcontrol tur 1:172:0 -v -C 0
Unit is not ready
(pass42:mps1:0:172:0): TEST UNIT READY. CDB: 00 00 00 00 00 00 
(pass42:mps1:0:172:0): CAM status: SCSI Status Error
(pass42:mps1:0:172:0): SCSI status: Check Condition
(pass42:mps1:0:172:0): SCSI sense: UNIT ATTENTION asc:29,2 (SCSI bus reset
occurred)
(pass42:mps1:0:172:0): Field Replaceable Unit: 2

We get the unit attention.

Also, the "Filemark detected" asc/ascq entry (0x00,0x01) and other, similar
tape error recovery entries should probably have an error recovery action
of SS_NOP instead of SS_RDEF.  The application should be notified of 
Filemarks, setmarks, end of medium, etc.

[This affects everything after r237326 in 9-STABLE, so the affected releases
are 9.1/2/3, 10.0/1/2/3, 11.0, HEAD. As everything before 10.3 is EoL, the fix
only needs to be MFC'd back to 10.3.]

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 218571] umtx compat6 regression affecting 'jar' command

2017-04-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218571

Bug ID: 218571
   Summary: umtx compat6 regression affecting 'jar' command
   Product: Base System
   Version: 11.0-RELEASE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: nicholas.hardi...@gmail.com

Hello,
I'm in the process of upgrading about a hundred 8.2-RELEASE systems to
11.0-RELEASE (maybe 11.1 by the time I'm finished), and hit a snag with one of
my regression tests.  It involves running 'jar' from jdk1.5.0 (originally built
on 6.3-RELEASE I believe), which goes into a loop and hangs.  Replicating it is
very simple - just run 'jar' and instead of displaying the usage message, it
starts spinning.  I ran it under truss, and after some normal-looking things
(like a bunch of compat6 syscalls) saw a bunch of this at the end:

_umtx_op(0x641c10,UMTX_OP_RESERVED0,0x18947,0x0,0x0) ERR#45 'Operation not
supported'

Looking through the svn history, it appears that two umtx syscalls were removed
in https://svnweb.freebsd.org/base?view=revision=263318 and
https://svnweb.freebsd.org/base?view=revision=304525.  I don't
consider myself a kernel developer, but I managed to cobble together a patch
that got them working again for my use case.  There is currently a TODO
regarding the error handling - I just wanted to prove this would work and fix
the jar issue.  Looking through the rest of the code, it feels to me like the
correct thing to do is put this stuff back in under #ifdef COMPAT_FREEBSD6.  I
have attached a patch that resolves my issue with jar.  If the above approach
sounds reasonable, I can work on cleaning it up into an actual, acceptable,
form.

Thanks,
-Nicholas

diff -u -r src.fbsd11.stock/lib/libc/sys/Symbol.map
src.oldumtx/lib/libc/sys/Symbol.map
--- src.fbsd11.stock/lib/libc/sys/Symbol.map2016-09-28 19:25:57.0
-0400
+++ src.oldumtx/lib/libc/sys/Symbol.map2017-04-05 13:54:37.026112000 -0400
@@ -34,7 +34,9 @@
 __setugid;
 __syscall;
 __sysctl;
+_umtx_lock;
 _umtx_op;
+_umtx_unlock;
 abort2;
 accept;
 access;
@@ -453,8 +455,12 @@
 __sys___syscall;
 ___sysctl;
 __sys___sysctl;
+__umtx_lock;
+__sys__umtx_lock;
 __umtx_op;
 __sys__umtx_op;
+__umtx_unlock;
+__sys__umtx_unlock;
 _abort2;
 __sys_abort2;
 _accept;
diff -u -r src.fbsd11.stock/sys/compat/freebsd32/freebsd32_proto.h
src.oldumtx/sys/compat/freebsd32/freebsd32_proto.h
--- src.fbsd11.stock/sys/compat/freebsd32/freebsd32_proto.h2016-09-28
19:24:55.0 -0400
+++ src.oldumtx/sys/compat/freebsd32/freebsd32_proto.h2017-04-05
15:48:00.638984000 -0400
@@ -2,8 +2,8 @@
  * System call prototypes.
  *
  * DO NOT EDIT-- this file is automatically generated.
- * $FreeBSD: releng/11.0/sys/compat/freebsd32/freebsd32_proto.h 303858
2016-08-08 21:19:57Z bdrewery $
- * created from FreeBSD: stable/11/sys/compat/freebsd32/syscalls.master 302094
2016-06-22 21:15:59Z brooks
+ * $FreeBSD$
+ * created from FreeBSD: releng/11.0/sys/compat/freebsd32/syscalls.master
302094 2016-06-22 21:15:59Z brooks
  */

 #ifndef _FREEBSD32_SYSPROTO_H_
@@ -359,6 +359,12 @@
 char oucp_l_[PADL_(struct freebsd32_ucontext *)]; struct
freebsd32_ucontext * oucp; char oucp_r_[PADR_(struct freebsd32_ucontext *)];
 char ucp_l_[PADL_(const struct freebsd32_ucontext *)]; const struct
freebsd32_ucontext * ucp; char ucp_r_[PADR_(const struct freebsd32_ucontext
*)];
 };
+struct freebsd32_umtx_lock_args {
+char umtx_l_[PADL_(struct umtx *)]; struct umtx * umtx; char
umtx_r_[PADR_(struct umtx *)];
+};
+struct freebsd32_umtx_unlock_args {
+char umtx_l_[PADL_(struct umtx *)]; struct umtx * umtx; char
umtx_r_[PADR_(struct umtx *)];
+};
 struct freebsd32_ksem_timedwait_args {
 char id_l_[PADL_(semid_t)]; semid_t id; char id_r_[PADR_(semid_t)];
 char abstime_l_[PADL_(const struct timespec32 *)]; const struct timespec32
* abstime; char abstime_r_[PADR_(const struct timespec32 *)];
@@ -757,6 +763,8 @@
 intfreebsd32_getcontext(struct thread *, struct freebsd32_getcontext_args
*);
 intfreebsd32_setcontext(struct thread *, struct freebsd32_setcontext_args
*);
 intfreebsd32_swapcontext(struct thread *, struct
freebsd32_swapcontext_args *);
+intfreebsd32_umtx_lock(struct thread *, struct freebsd32_umtx_lock_args
*);
+intfreebsd32_umtx_unlock(struct thread *, struct
freebsd32_umtx_unlock_args *);
 intfreebsd32_ksem_timedwait(struct thread *, struct
freebsd32_ksem_timedwait_args *);
 intfreebsd32_thr_suspend(struct thread *, struct
freebsd32_thr_suspend_args *);
 intfreebsd32_umtx_op(struct thread *, struct freebsd32_umtx_op_args *);
@@ -1223,6 +1231,8 @@
 #defineFREEBSD32_SYS_AUE_freebsd32_getcontextAUE_NULL
 #defineFREEBSD32_SYS_AUE_freebsd32_setcontext

[Bug 211990] iscsi fails to reconnect and does not release devices

2017-04-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211990

Edward Tomasz Napierala  changed:

   What|Removed |Added

 Status|Open|Closed
 Resolution|--- |Works As Intended

--- Comment #44 from Edward Tomasz Napierala  ---
>From what I see, it's a networking problem, not a bug in iSCSI.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 218517] ppp fails adding route with error Value too large to be stored in data type

2017-04-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218517

--- Comment #1 from Gleb Smirnoff  ---
Created attachment 181690
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=181690=edit
Dtrace script to get more information

Hi!

Can you please launch the following script, tracing ppp and error 84 and then
ppp:

# kldload dtraceall
# ./kernel-error.d ppp 84

Then in other terminal launch ppp. Then terminate script with Ctrl-C. I need
output from the script. The script will consume a lot machine resources. The
machine will get unresponsive for several minutes after Ctrl-C, please be
patient.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 218568] vdev_geom_attach_by_guids can attach to wrong partition

2017-04-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218568

Alan Somers  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|asom...@freebsd.org
 Status|New |Open

--- Comment #1 from Alan Somers  ---
I already have a fix for this issue in our private FreeBSD fork.  I'll try to
merge it into head.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 218568] vdev_geom_attach_by_guids can attach to wrong partition

2017-04-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218568

Bug ID: 218568
   Summary: vdev_geom_attach_by_guids can attach to wrong
partition
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: asom...@freebsd.org

When opening a vdev whose path is unknown, vdev_geom must find a geom provider
with a label whose guids match te desired vdev.  However, due to partitioning,
it is possible that two non-synonomous providers will share two labels.  For
example, if the first partition starts at the beginning of the drive, then ada0
and ada0p1 will share the first label.  More troubling, if the last partition
runs to the end of the drive, then ada0p3 and ada0 will share the last label. 
If vdev_geom opens ada0 when it should've opened ada0p3, then the pool won't be
readable.  If it opens ada0 when it should've opened ada0p1, then it will
corrupt some other partition when it writes the 3rd and 4th labels.

The easiest way to observe this problem is to install ZFS to a pair of mirrored
drives, using the default GPT partitioning scheme.  Power off, swap the drives,
and power back on.  Depending on the order that geom probes its providers, ZFS
may or may not attach to the correct partitions.  If it doesn't, then importing
the pool will fail somewhere up stack, and the system will be left at the
mountroot> prompt.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

2017-04-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213903

--- Comment #29 from Ben Woods  ---
(In reply to Mateusz Guzik from comment #26)
I have been running with the patch with no crashes.

If you would like me to confirm whether the issue is still in CURRENT, I will
have to upgrade to the latest CURRENT without the patch, and let you know if I
get crashes again.

Let me know if this would be helpful for you.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"