[Bug 194522] smartmontools misbehaving (self-test timestamps do not match reality)
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. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 194606] filesystem unmount deadlock on 10.1 and head when TRIM enabled at unmount after r268815, MFC of 268205
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194606 --- Comment #4 from commit-h...@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. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 194681] New: [geom] a race in gmirror cause kernel panic during shutdown
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@FreeBSD.org
Reporter: alexandre.mart...@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 0xf, 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=0xfffe,
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 b
[Bug 194606] filesystem unmount deadlock on 10.1 and head when TRIM enabled at unmount after r268815, MFC of 268205
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. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 194112] [panic] Fatal trap 12: Page fault while in vm86 mode with kern.vty=vt console, hw.vga.textmode=1 and NVIDIA card
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. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 194685] New: CPU -1 on top
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@FreeBSD.org Reporter: dan...@freebsd.org The top command is showing -1 as CPU number. PID USERNAMETHR PRI NICE SIZERES STATE C TIMEWCPU COMMAND 99223 danilo 10 520 136M 83636K nanslp 3 0:56 27.39% doxygen 1629 danilo1 790 35456K 12228K CPU-1 -1 0:34 27.25% doxygen 3079 danilo1 790 35456K 12268K CPU-1 -1 0:27 26.47% doxygen 99390 danilo1 790 35456K 12260K CPU-1 -1 0:38 24.43% doxygen 1624 danilo1 780 35456K 12120K CPU33 0:35 21.49% doxygen 462 danilo1 520 35456K 12284K zio->i 1 0:37 20.37% doxygen 99353 danilo1 790 35456K 12644K CPU-1 -1 0:38 19.33% doxygen 1967 danilo1 780 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. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 178115] Laptop (Asus X55VD) locks up when configuring wifi (Ralink RT5390) from LiveCD mode of official install medium
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=178115 Kevin Lo changed: What|Removed |Added CC||ke...@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. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 178115] Laptop (Asus X55VD) locks up when configuring wifi (Ralink RT5390) from LiveCD mode of official install medium
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=178115 --- Comment #5 from purpleri...@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. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 194690] New: options IPSEC disables TCP keepalives
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@FreeBSD.org Reporter: m...@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. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 194690] options IPSEC disables TCP keepalives
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194690 Bjoern A. Zeeb changed: What|Removed |Added CC||b...@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. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 194690] options IPSEC disables TCP keepalives
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. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 194690] options IPSEC disables TCP keepalives
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. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 86319] [nfs] [request] support a "noac" NFS mount flag to turn off the attribute cache
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=86319 Edward Tomasz Napierala changed: What|Removed |Added CC||tr...@freebsd.org Assignee|freebsd-bugs@FreeBSD.org|tr...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 194696] New: Asus X551CAP brightness problem (acpi, acpi_video)
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@FreeBSD.org Reporter: theblackdaffodilc...@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. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 194685] CPU -1 on top
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194685 Mark Johnston changed: What|Removed |Added Status|Needs Triage|Issue Resolved CC||ma...@freebsd.org Resolution|--- |FIXED Assignee|freebsd-bugs@FreeBSD.org|j...@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. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 193758] either gptzfsboot or zfsloader hangs during boot after kernel and pool upgrade
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193758 m...@blackmans.org changed: What|Removed |Added CC||m...@blackmans.org --- Comment #4 from m...@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. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 194577] mbuf packet header leakage when closing TUN devices
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. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 193758] either gptzfsboot or zfsloader hangs during boot after kernel and pool upgrade
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193758 --- Comment #5 from m...@exonetric.com --- So there's a bug here still. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 193758] either gptzfsboot or zfsloader hangs during boot after kernel and pool upgrade
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193758 Andrey V. Elsukov changed: What|Removed |Added CC||a...@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. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 193758] either gptzfsboot or zfsloader hangs during boot after kernel and pool upgrade
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193758
--- Comment #7 from m...@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 NOPT14
#define NDEV3
-#define BIOS_NUMDRIVES0x475
+#define BIOS_NUMDRIVES0x475
#define DRV_HARD0x80
#define DRV_MASK0x7f
@@ -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.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 194577] mbuf packet header leakage when closing TUN devices
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. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 194697] New: incoming IP TOS bits get zeroed on mbufs that need checksumming
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@FreeBSD.org Reporter: s...@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. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 194697] incoming IP TOS bits get zeroed on mbufs that need checksumming
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. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
