[Bug 211885] if_iwm firmware crashes and recovers

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211885

Bug ID: 211885
   Summary: if_iwm firmware crashes and recovers
   Product: Base System
   Version: CURRENT
  Hardware: amd64
OS: Any
Status: New
  Keywords: crash
  Severity: Affects Only Me
  Priority: ---
 Component: wireless
  Assignee: freebsd-wirel...@freebsd.org
  Reporter: r...@freebsd.org
CC: freebsd-amd64@FreeBSD.org
CC: freebsd-amd64@FreeBSD.org

Created attachment 173718
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=173718=edit
iwm firmware panic messages

if_iwm crashes firmware randomly(?) crashes with my iwm3165 card (which if_iwm
indeed shows as an iwm3165 but is handled by iwm7265fw.ko)

The firmware successfully restarts after these crashes, I'm typing this PR with
a restarted firmware. It also seems to crash after a few days of uptime
(typically 2+ days).

dmesg samples attached.

uname -a:
FreeBSD e17 12.0-CURRENT FreeBSD 12.0-CURRENT #7 r303697: Wed Aug  3 10:41:19
CEST 2016 rene@e17:/usr/obj/usr/home/rene/freebsd/src/head/sys/GENERIC 
amd64

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

[Bug 211884] IPKVM cannot reliably enter text under 11.0-RC2

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211884

Bug ID: 211884
   Summary: IPKVM cannot reliably enter text under 11.0-RC2
   Product: Base System
   Version: 11.0-RC1
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-b...@freebsd.org
  Reporter: k...@denninger.net
CC: freebsd-amd64@FreeBSD.org
CC: freebsd-amd64@FreeBSD.org

Updated from 11.0-ALPHA to 11.0-RC2 this afternoon on a test machine and ran
into a really odd problem.

The system in question has an encrypted root ZFS pool, which results in a
prompt for the GELI password during the boot and before the root filesystem
mounts.  This has been trouble-free for a long time.

This afternoon, however, it suddenly turned into a huge problem.  After the
kernel loads and the prompt comes up the keyboard was not recognized over the
IPMI interface; only one of every handful of keystrokes went through.  This
meant if you pounded the enter key a few times you'd eventually get one
through, but the keys you typed in the meantime (containing the GELI password!)
were of course lost - or some of them were anyway.

A locally-attached PS/2 keyboard (at the physical machine) works, but a
USB-attached keyboard *also* had intermittent problems, often NOT registering
the CAPS and NUMLOCK keys reliably.

The IPMI keyboard is recognized properly at the BIOS level (before the loader
gets control) and works fine there.

This is likely to be extremely serious for anyone who attempts to update a
system with encrypted disks over a remote link using a built-in IPKVM; the
machine in question has a SuperMicro board in it, but given that I *also* had
trouble with a USB plugged keyboard on the same machine (but not a PS/2
keyboard!) it appears that this is something in the kernel level and *not*
strictly an IPKVM interaction issue.

Reverting to the previous ALPHA kernel resolved the problem immediately.  In
addition if I change the mouse mode on the web interface (which forces a
detach/reattach for the keyboard, which I can see on the KVM console) it will
*sometimes* permit me to type the password.

IMHO this needs to be investigated as if RELEASE goes out with this problem
present it is likely to screw a large number of people who are doing the
upgrade remotely, possibly forcing a trip to the site with a physical keyboard
to get beyond the prompt.

I do not know if this was a problem on RC1 as I didn't run it but it was NOT an
issue in the ALPHA series of releases.

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

[Bug 211872] IPv6 UDP traffic sometimes sent using wrong mac address

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211872

Mark Linimon  changed:

   What|Removed |Added

 CC|freebsd-amd64@FreeBSD.org   |
   Assignee|freebsd-b...@freebsd.org|freebsd-...@freebsd.org

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

[Bug 211852] Unsafe shutdowns on Intel 750 SSD

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211852

Mark Linimon  changed:

   What|Removed |Added

 CC|freebsd-amd64@FreeBSD.org   |

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

[Bug 211872] IPv6 UDP traffic sometimes sent using wrong mac address

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211872

--- Comment #1 from Mike Andrews  ---
ok, on a lark I tried "ndp -nc" and it let me clear the table, where "ndp -c"
doesn't.  And that clears the wrong-mac problem up temporarily.  But it will
reappear later, for example after a reboot, and it's somewhat random and
difficult to reproduce on demand.

Even stranger, "ndp -c" sometimes bombs out on FreeBSD 10.3 also, with the same
"writing to routing socket: Invalid argument" error.  So maybe that error is an
unrelated bug, or a race condition where it's trying to delete a just-expired
entry or something.

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

[Bug 211872] IPv6 UDP traffic sometimes sent using wrong mac address

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211872

Bug ID: 211872
   Summary: IPv6 UDP traffic sometimes sent using wrong mac
address
   Product: Base System
   Version: 11.0-RC1
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-b...@freebsd.org
  Reporter: mandr...@bit0.com
CC: freebsd-amd64@FreeBSD.org
CC: freebsd-amd64@FreeBSD.org

Outbound IPv6 UDP traffic sometimes appears to put packets on the wire with the
destination MAC address of a completely different system.  "ndp -a" shows
correct MAC addresses.

Example:

Two nameservers, trying to query each other, on IPv6 private addresses
(fc00::/10)

fdfa::fafa:d53a, mac 00:25:90:57:21:b3
fdfa::fafa:d53b, mac 00:25:90:38:6f:fa

These are lagg0 interfaces aggregating two Intel em nics.

On each machine, run:  tcpdump -e -n net fdfa::/16 and port 53

On machine 2, run "host -t a www.fark.com fdfa::fafa:d53a" and it will timeout,
with its own tcpdump showing:
12:46:22.835604 00:25:90:38:6f:fa > 00:25:90:57:21:b3, ethertype IPv6 (0x86dd),
length 92: fdfa::fafa:d53b.15484 > fdfa::fafa:d53a.53: 47157+ A? www.fark.com.
(30)
12:46:27.836716 00:25:90:38:6f:fa > 00:25:90:57:21:b3, ethertype IPv6 (0x86dd),
length 92: fdfa::fafa:d53b.39323 > fdfa::fafa:d53a.53: 47157+ A? www.fark.com.
(30)

and machine 1's tcpdump showing a wrong MAC address used in the replies:
12:46:22.835118 00:25:90:38:6f:fa > 00:25:90:57:21:b3, ethertype IPv6 (0x86dd),
length 92: fdfa::fafa:d53b.15484 > fdfa::fafa:d53a.53: 47157+ A? www.fark.com.
(30)
12:46:22.835272 00:25:90:57:21:b3 > 00:25:90:23:be:bc, ethertype IPv6 (0x86dd),
length 232: fdfa::fafa:d53a.53 > fdfa::fafa:d53b.15484: 47157* 1/2/4 A
64.191.171.200 (170)
12:46:27.836186 00:25:90:38:6f:fa > 00:25:90:57:21:b3, ethertype IPv6 (0x86dd),
length 92: fdfa::fafa:d53b.39323 > fdfa::fafa:d53a.53: 47157+ A? www.fark.com.
(30)
12:46:27.836340 00:25:90:57:21:b3 > 00:25:90:23:be:bc, ethertype IPv6 (0x86dd),
length 232: fdfa::fafa:d53a.53 > fdfa::fafa:d53b.39323: 47157* 1/2/4 A
64.191.171.200 (170)

00:50:90:23:be:bc is a totally different 3rd machine.  That's weird. :)

Add the -T flag to the "host" command to force TCP, and it works.

Flip the queries around so that machine 1 queries machine 2, and it works.

I'm seeing similar issues with other similar machines (and similar hardware,
all Supermicro machines with Intel em nics of varying vintage) that have been
updated to 11.0-RC1.  All ware fine on 10.3-RELEASE.  The only em-specific
tweak I've got is "-tso", but turning tso back on doesn't change behavior any.

Another weird and possibly related issue: "ndp -c" fails on machine 1 -- it
deletes one or two entries and then stops with "ndp: writing to routing socket:
Operation not permitted".  On machine 2, "ndp -c" completes with no problems.

I haven't yet tried dropping the lagg interface and using the em interfaces
directly.

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

[Bug 211864] Compiler is using AVX instructions for CPUTYPE=btver1

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211864

Kubilay Kocak  changed:

   What|Removed |Added

   Keywords||needs-qa
 CC|freebsd-amd64@FreeBSD.org   |r...@freebsd.org
Summary|[Regression] Compiler is|Compiler is using AVX
   |using AVX instructions for  |instructions for
   |CPUTYPE=btver1  |CPUTYPE=btver1
 Status|New |Open
  Flags||mfc-stable11?

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

[Bug 211864] [Regression] Compiler is using AVX instructions for CPUTYPE=btver1

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211864

Baptiste Daroussin  changed:

   What|Removed |Added

Summary|Compiler is using AVX   |[Regression] Compiler is
   |instructions for|using AVX instructions for
   |CPUTYPE=btver1  |CPUTYPE=btver1

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

[Bug 211864] Compiler is using AVX instructions for CPUTYPE=btver1

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211864

Bug ID: 211864
   Summary: Compiler is using AVX instructions for CPUTYPE=btver1
   Product: Base System
   Version: 11.0-RC1
  Hardware: amd64
OS: Any
Status: New
  Keywords: regression
  Severity: Affects Some People
  Priority: ---
 Component: misc
  Assignee: freebsd-b...@freebsd.org
  Reporter: demik+free...@lostwave.net
CC: freebsd-amd64@FreeBSD.org
CC: freebsd-amd64@FreeBSD.org

Hello,

While rebuilding some ports after upgrading to 11.0-RC1 (with freebsd-update),
almost every binary is crashing with SIGILL 

The system hardware is bobcat based :
CPU: AMD C-70 APU with Radeon(tm) HD Graphics (1000.02-MHz K8-class CPU)

Bobcat CPUs have only MMX, SSE, SSE2, SSE3, SSSE3, SSE4A instructions.

Compiling without CPUTYPE results in working binaries.
With CPUTYPE=btver1, the binaries does not work, as the CPU does not have any
AVX instructions :

root@square:~ # lldb /usr/local/bin/sudo
(lldb) target create "/usr/local/bin/sudo"
Current executable set to '/usr/local/bin/sudo' (x86_64).
(lldb) run test
Process 71447 launching
Process 71447 launched: '/usr/local/bin/sudo' (x86_64)
Process 71447 stopped
* thread #1: tid = 101195, 0x000800a5421e libsudo_util.so.0`??? + 286, stop
reason = signal SIGILL: privileged instruction
frame #0: 0x000800a5421e libsudo_util.so.0`??? + 286
libsudo_util.so.0`???:
->  0x800a5421e <+286>: vzeroupper 
0x800a54221 <+289>: callq  0x800a511e4   ; symbol stub for:
sudo_debug_exit_int_v1
0x800a54226 <+294>: movq   0x20ad93(%rip), %rax  ;
libsudo_util.so.0..got + 72
0x800a5422d <+301>: movq   (%rax), %rax

Some information :

root@square:~ # uname -a
FreeBSD square 11.0-RC1 FreeBSD 11.0-RC1 #0 r303979: Fri Aug 12 02:28:24 UTC
2016 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

root@square:~ # cc -v
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM
3.8.0)
Target: x86_64-unknown-freebsd11.0
Thread model: posix
InstalledDir: /usr/bin

Everything was working fine while running 10.3-RELEASE

this bug might be related to this one :
https://reviews.llvm.org/D17682

Regards

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