FreeBSD-current, ioctl() invalid arguments on microcode update
Hello,
Not sure about FreeBSD 11 or 10, but when you try to use cpuctl(4) and
Intel microcode from
http://git.exherbo.org/summer/packages/firmware/intel-microcode/index.html
this causes an error.
CC for maintainer of sysutils/devcpu-data, but not sure this is port
problem. Possible KPI was changed?
if the problem is complex, may be necessary to mark the port not compatible with
.if ${OPSYS} == FreeBSD && ${OSVERSION} < 120
IGNORE= does not support FreeBSD versions < 12.0
.endif
How to reproduce:
% make -C /usr/ports/sysutils/devcpu-data install && service
microcode_update onestart
log:
Updating cpucodes...
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl0 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl0 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl1 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl1 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl2 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl2 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl3 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl3 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl4 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl4 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl5 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl5 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl6 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl6 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl7 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl7 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
Done.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
1st build stops when WITH_AUTO_OBJ=yes
I decided to give a try to WITH_AUTO_OBJ and noted the first time I ran buildworld it failed with following message: /u/src # ❯❯❯ make WITH_AUTO_OBJ=yes buildworld [Creating objdir obj...] make: "/usr/src/share/mk/auto.obj.mk" line 61: could not use obj: .OBJDIR=/usr/src/obj After that I noted it created a directory /usr/src/obj and if I call it again it runs without issues. If I remove /usr/src/obj directory error happens again. -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: hang during kldload if_bwn
I don't know why it's hanging; and unfortunately I'll have to reinstall -head to get a working console (since the device I have here for doing ppc+bwn work wants syscons, /not/ vt.. :( ) -a On 6 November 2016 at 14:42, Justin Hibbits wrote: > Hi folks, > > I have a PowerBook G4 with an Airport Extreme card (bwi/bwn, can use > either one), and found if I don't have the exact correct firmware it > hangs. Here's a snippet of WITNESS before it hangs: > > siba_bwn0: mem > 0xa0004000-0xa0005fff irq 52 at device 17.0 on pci1 bwn0 on siba_bwn0 > bwn0: bwn_attach_core: forcing 2GHz only; no dual-band support for PHY > bwn0: WLAN (chipid 0x4318 rev 9) PHY (analog 3 type 2 rev 7) RADIO > (manuf 0x17f ver 0x2050 rev 8) bwn0: DMA (32 bits) > wlan0: Ethernet address: 00:14:51:7d:60:39 > bwn0: ucode fw: ucode5 > Sleeping on "fwload" with the following non-sleepable locks held: > exclusive sleep mutex bwn0 (network driver) r = 0 (0xd2e57004) locked > @ /usr/src/sys/modules/bwn/../../dev/bwn/if_bwn.c:814 stack backtrace: > #0 0x50fd64 at witness_warn+0x2c0 > #1 0x49ef0c at _sleep+0xc8 > #2 0x4e2e10 at firmware_get+0x120 > #3 0xd2d0a6e4 at bwn_fw_get+0xe4 > #4 0xd2d1057c at bwn_fw_gets+0x1ac > #5 0xd2d13130 at bwn_core_init+0x28c > #6 0xd2d151f0 at bwn_init+0x310 > #7 0xd2d15408 at bwn_parent+0x80 > #8 0xd2da794c at parent_updown+0x1c > #9 0x4fe6dc at taskqueue_run_locked+0x178 > #10 0x4ff468 at taskqueue_thread_loop+0xa8 > #11 0x44c99c at fork_exit+0xc0 > #12 0x8229dc at fork_trampoline+0xc > bwn_v4_ucode5: could not load firmware image, error 2 > bwn0: the fw file(bwn_v4_ucode5) not found > bwn0: ucode fw: ucode5 > Sleeping on "fwload" with the following non-sleepable locks held: > exclusive sleep mutex bwn0 (network driver) r = 0 (0xd2e57004) locked > @ /usr/src/sys/modules/bwn/../../dev/bwn/if_bwn.c:814 stack backtrace: > #0 0x50fd64 at witness_warn+0x2c0 > #1 0x49ef0c at _sleep+0xc8 > #2 0x4e2e10 at firmware_get+0x120 > #3 0xd2d0a6e4 at bwn_fw_get+0xe4 > #4 0xd2d1057c at bwn_fw_gets+0x1ac > #5 0xd2d13130 at bwn_core_init+0x28c > #6 0xd2d151f0 at bwn_init+0x310 > #7 0xd2d15408 at bwn_parent+0x80 > #8 0xd2da794c at parent_updown+0x1c > #9 0x4fe6dc at taskqueue_run_locked+0x178 > #10 0x4ff468 at taskqueue_thread_loop+0xa8 > #11 0x44c99c at fork_exit+0xc0 > #12 0x8229dc at fork_trampoline+0xc > bwn-open_v4_ucode5: could not load firmware image, error 2 > bwn0: the fw file(bwn-open_v4_ucode5) not found > > > Creating a symlink in /boot/modules of bwn_v4_ucode5.ko -> > bwn_v4_ucode.ko makes it not hang, but it still triggers WITNESS. > > - Justin > ___ > freebsd-wirel...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: was: CURRENT [r308087] still crashing: Backtrace provided
On Sun, Nov 06, 2016 at 11:13:56AM +0100, O. Hartmann wrote: > Yesterday, I ran the whole day (> 9 hours) without problems r307233 without > the reported > crash. > > Today's morning I got brave and tried r307234 - and had a crash within an > hour. Thanks for confirming - I cc'ed glebius@ and ae@, who can provide more insight than me. I was just trying to narrow down the problem to a specific commit. > > > > > > > > > Attached, you'll find the backtrace report as last time. I had to type in > > > "dump" > > > blindly on the system as a dark screen or a stuck X11 screen blocked the > > > console (I > > > use vt() and nVidia BLOB with my nVidia GPUs - and this is still broken > > > on FBSD). > > > > > > Please let me know how I can assist further. I saved both the core AND > > > this time the > > > culprit kernel. > > > > Great, thank you. I would first like to confirm that r307234 is indeed > > causing the crash - since it appears to be easy to trigger, that should > > be faster. If not, the core will help track down the real problem. > > Although I was under the impression the in-kernel-config option > > makeoptionsDEBUG=-g > > would make debugging symbols available, I'm proved wrong. > > I tried also on > > FreeBSD 12.0-CURRENT #15 r308329: Sat Nov 5 08:52:24 CET 2016 > > and crashed, from which I picked up kernel and vmcore as well as > the text of the backtrace as provided in an earlier mail (see below at > [core.txt.0], and > if I perform this suggested command sequence: > > ohartmann@thor [kernel_debug]: kgdb ./kernel vmcore.0 > 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"...(no debugging symbols > found)... > Attempt to extract a component of a value that is not a structure pointer. > Attempt to extract a component of a value that is not a structure pointer. > #0 0x807b8d83 in doadump () > (kgdb) frame 12 > #12 0x80923a74 in ip_output () > (kgdb) p *ifp > No symbol table is loaded. Use the "file" command. > (kgdb) p *ro > No symbol table is loaded. Use the "file" command. > (kgdb) > > Again, I'm doing this kind of debugging the very first time and I miss > something here, > apologizes for that. Hm, I'm not sure what the problem is. When a kernel is installed and WITHOUT_KERNEL_SYMBOLS is not set in src.conf, debug symbols should automatically be installed to /usr/lib/debug/boot/kernel. > > Sorry about the redundancy. > > The curious thing to me is that this bug is triggered on systems with Intel > CPU > architectures older or equal than IvyBridge. The very same /etc/make.conf > and /etc/src.conf as well as the very same kernel config apart from some > local hardware > dependend modifications are spread around my servers and workstations and > especially my > bureau's box is a sHaswell XEON with almost the exact same confict running on > CURRENT > (recent as of Thursday) without problems while the box I'm reporting this > error from is > crashing (i3-3220, the server, also crashing here, is a E3-1245 V2. Another > crashing > system is a 2009 C2D XEON 5XXX, two socket server, crashing the same way, but > with a > different kernel config. > I tried on the crashing systems with GENERIC as well with the same results. > > I'm using IPFW as the firewall on all systems. > > Please tell me if you revert some commits, I'll then checkout the sources up > to recent > CURRENT and try again. > > This just for addition and completion. > > > Kind regards and thanks in advance, > > Oliver > > [...] > [core.txt.0] > ... > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0x807b44fb > stack pointer = 0x28:0xfe0238f7c290 > frame pointer = 0x28:0xfe0238f7c310 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 521 (nslcd) > > Reading symbols from /boot/modules/nvidia-modeset.ko...done. > Loaded symbols for /boot/modules/nvidia-modeset.ko > Reading symbols from /boot/modules/nvidia.ko...done. > Loaded symbols for /boot/modules/nvidia.ko > #0 doadump (textdump=0) at pcpu.h:222 > 222 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=0) at pcpu.h:222 > #1 0x8049e1eb in db_dump (dummy=, dummy2=false, > dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:546 > #2 0x8049dfe9 in db_command (cmd_table=) > at /usr/src/sys/ddb/db_command.c:453 > #3 0x8049dd
problem with mpt driver. anyone seen this or similar? (10.3)
Does this ring any bells?
even a theory would be a big improvement.
memcpy+0xc
mpt_read_cfg_page+0xcc
mpt_cation+0x148e
xpt_action_default+0x7e
cam_periph_runccb+0x7c
passdoioctl+0x719
passioctl+0x30
devfs_ioctl_f+0x7c
kern_ioctl+0x1a8
sys_ioctl+0x11f
amd64_syscall+0x3f9
xfast_syscall+0xf7
we see a memory access fault at line 1821..
1786 int
1787 mpt_read_cfg_page(struct mpt_softc *mpt, int Action, uint32_t PageAddress,
1788 CONFIG_PAGE_HEADER *hdr, size_t len, int sleep_ok,
1789 int timeout_ms)
1790 {
1791 request_t*req;
1792 cfgparms_tparams;
1793 int error;
1794
1795 req = mpt_get_request(mpt, sleep_ok);
1796 if (req == NULL) {
1797 mpt_prt(mpt, "mpt_read_cfg_page: Get request failed!\n");
1798 return (-1);
1799 }
1800
1801 params.Action = Action;
1802 params.PageVersion = hdr->PageVersion;
1803 params.PageLength = hdr->PageLength;
1804 params.PageNumber = hdr->PageNumber;
1805 params.PageType = hdr->PageType & MPI_CONFIG_PAGETYPE_MASK;
1806 params.PageAddress = PageAddress;
1807 error = mpt_issue_cfg_req(mpt, req, ¶ms,
1808 req->req_pbuf + MPT_RQSL(mpt),
1809 len, sleep_ok, timeout_ms);
1810 if (error != 0) {
1811 mpt_prt(mpt, "read_cfg_page(%d) timed out\n", Action);
1812 return (-1);
1813 }
1814
1815 if ((req->IOCStatus & MPI_IOCSTATUS_MASK) !=
MPI_IOCSTATUS_SUCCESS) {
1816 mpt_prt(mpt, "mpt_read_cfg_page: Config Info Status %x\n",
1817 req->IOCStatus);
1818 mpt_free_request(mpt, req);
1819 return (-1);
1820 }
1821 memcpy(hdr, ((uint8_t *)req->req_vbuf)+MPT_RQSL(mpt), len);
<--
1822 mpt_free_request(mpt, req);
1823 return (0);
1824 }
1825
1826 int
1827 mpt_write_cfg_page(struct mpt_softc *mpt, int Action, uint32_t PageAddress,
"mpt/mpt.c" [readonly] 3146 lines --58%--
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
