Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
___ 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: r360902 breaks VLAN interface on if_em (82579LM)
Hi
I'm told the content was stripped from my emails...
I noticed that my VLAN interfaces stopped working after a recent build.
tcpdump showed traffic leaving leaving and entering the interface but no
host on the network actually received any packets from this host. A
binary search led me to r360902 and indeed the following change fixed
the issue for me:
Index: sys/dev/e1000/if_em.c
===
--- sys/dev/e1000/if_em.c (revision 361538)
+++ sys/dev/e1000/if_em.c (working copy)
@@ -4054,7 +4054,7 @@
{
switch (event) {
case IFLIB_RESTART_VLAN_CONFIG:
- return (false);
+ return (true);
default:
return (true);
}
Hardware according to pciconf is:
em0@pci0:0:25:0: class=0x02 rev=0x04 hdr=0x00 vendor=0x8086
device=0x1502 subvendor=0x103c subdevice=0x1495
vendor = 'Intel Corporation'
device = '82579LM Gigabit Network Connection (Lewisville)'
class = network
subclass = ethernet
cap 01[c8] = powerspec 2 supports D0 D3 current D0
cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
cap 13[e0] = PCI Advanced Features: FLR TP
Ian
--
Ian Freislich
___
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: r360902 breaks VLAN interface on if_em (82579LM)
___ 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"
r360902 breaks VLAN interface on if_em (82579LM)
___ 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: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'
I moved the #ifdef down one line and its compiling. Ian -- Ian Freislich On 08/29/2018 07:40 PM, John Baldwin wrote: > On 8/29/18 4:20 PM, Ian FREISLICH wrote: >> Hi >> >> I see the definition of interrupt_sorted is #ifdefed out by #ifdef SMP >> at line 84. My system is UP so I'm not compiling an SMP kernel. >> >> /usr/src/sys/x86/x86/intr_machdep.c:176:2: error: use of undeclared >> identifier 'interrupt_sorted'; did you mean 'interrupt_sources'? >> interrupt_sorted = mallocarray(num_io_irqs, >> sizeof(*interrupt_sorted), >> ^~~~ >> interrupt_sources >> /usr/src/sys/x86/x86/intr_machdep.c:83:24: note: 'interrupt_sources' >> declared here >> static struct intsrc **interrupt_sources; >> ^ >> /usr/src/sys/x86/x86/intr_machdep.c:176:54: error: use of undeclared >> identifier 'interrupt_sorted'; did you mean 'interrupt_sources'? >> interrupt_sorted = mallocarray(num_io_irqs, >> sizeof(*interrupt_sorted), > Probably just needs #ifdef SMP around the mallocarray(). I'll test locallyon > a UP kernel config. > -- ___ 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"
intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'
Hi I see the definition of interrupt_sorted is #ifdefed out by #ifdef SMP at line 84. My system is UP so I'm not compiling an SMP kernel. /usr/src/sys/x86/x86/intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'; did you mean 'interrupt_sources'? interrupt_sorted = mallocarray(num_io_irqs, sizeof(*interrupt_sorted), ^~~~ interrupt_sources /usr/src/sys/x86/x86/intr_machdep.c:83:24: note: 'interrupt_sources' declared here static struct intsrc **interrupt_sources; ^ /usr/src/sys/x86/x86/intr_machdep.c:176:54: error: use of undeclared identifier 'interrupt_sorted'; did you mean 'interrupt_sources'? interrupt_sorted = mallocarray(num_io_irqs, sizeof(*interrupt_sorted), ^~~~ interrupt_sources /usr/src/sys/x86/x86/intr_machdep.c:83:24: note: 'interrupt_sources' declared here static struct intsrc **interrupt_sources; ^ 2 errors generated. *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/BRANE *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src -- Ian Freislich -- ___ 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: uchcom update
On 05/22/2018 09:44 AM, Andriy Gapon wrote: Yesterday I committed some changes to uchcom (so far, only in CURRENT). Commits are r333997 - r334002. If you have a CH340/341 based USB<->RS232 adapter and it works for you, could you please test that it still does? If you tried your adapter in the past and it did not work, there is a chance it might start working now. Could you please test that as well? ugen5.4: at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (96mA) ugen5.4.0: uchcom0: It's not made it any worse. I'm not using this adapter by choice - it's a USB to Maxim (Dallas) one-wire bus adapter. The manual used to state that these are possibly the worst chips ever. Is that still the prevailing opinion? Ian -- ___ 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: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted
On 05/30/2018 11:50 AM, Glen Barber wrote: Hi, Could folks please help boot-test the most recent 12.0-CURRENT amd64 memstick images on various hardware? Note, this is not a request to install 12.0-CURRENT, only a boot-test with various system knobs tweaked. The most recent images are available at: https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we would like to get this included in the upcoming 11.2-RELEASE if the change that had been committed addresses several boot issues reported recently. Please help test, and report back (both successes and failures). Coincidentally, I was trying to install these on a very old 10" Dell Lattitude with an Atom N550 CPU. Both images booted to the beastie menu but hung loading the kernel. The only way I could get it to boot was to manually load the kernel at the loader prompt and boot. I was also unsuccessful performing a network install due to what I think was the download filesystem being read only. I was able to install from the bundled distribution. Ian -- ___ 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: r331650 breaks amd64 kernel build
On 03/28/2018 11:11 AM, Ian FREISLICH wrote: > Hi > > (As noted by Oliver Hartman in svn-src-all@) > > r331650 breaks amd64 kernel build as follows: > > --- machdep.o --- > /usr/src/sys/amd64/amd64/machdep.c:520:20: error: use of undeclared identifier > 'T_PROTFLT' ksi.ksi_trapno = T_PROTFLT; > ^ Appears fixed in r331681 Ian -- ___ 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"
r331650 breaks amd64 kernel build
Hi (As noted by Oliver Hartman in svn-src-all@) r331650 breaks amd64 kernel build as follows: --- machdep.o --- /usr/src/sys/amd64/amd64/machdep.c:520:20: error: use of undeclared identifier 'T_PROTFLT' ksi.ksi_trapno = T_PROTFLT; ^ The fix: Index: sys/amd64/amd64/machdep.c === --- sys/amd64/amd64/machdep.c (revision 331680) +++ sys/amd64/amd64/machdep.c (working copy) @@ -128,6 +128,7 @@ #include #include #include +#include #ifdef SMP #include #endif Ian -- ___ 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: Clang-6 and GNUisms.
On 03/12/18 13:54, Dimitry Andric wrote: > On 12 Mar 2018, at 16:03, Dimitry Andric <d...@freebsd.org> wrote: >> On 12 Mar 2018, at 00:56, Ian FREISLICH <ian.freisl...@capeaugusta.com> >> wrote: > ... >>> I haven't got avr-gcc to compile yet. >> No idea about this, is it very different from regular gcc's? As those >> all compile fine now. > For avr-gcc, which is an older version of gcc with some customizations, > a fix similar to https://svnweb.freebsd.org/changeset/ports/458581 is > needed, such as the attached patch This works, thanks. Can you commit to the port, the maintainer hasn't responded to me. Ian -- ___ 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"
Clang-6 and GNUisms.
Hi There's been some fallout in ports land since clang-6 around null pointer arithmetic and casts. I cannot think of a good reason for doing the following but then I've not dabbled in the arcane much: # define __INT_TO_PTR(P) ((P) + (char *) 0) So far I've encountered these in lang/v8 and devel/avr-gcc. I know it just generates warnings, but GNUisms and -Werror abound. Adding -Wno-null-pointer-arithmetic and -Wno-vexing-parse to CFLAGS/CXXFLAGS provides some relief but V8 still fails: /usr/ports/lang/v8/work/v8-3.18.5/out/native/obj.target/v8_base.x64/src/type-info.o../src/stub-cache.cc:1477:33: error: reinterpret_cast from 'nullptr_t' to 'char *' is not allowed : GetCodeWithFlags(flags, reinterpret_cast<char*>(NULL)); ^ I haven't got avr-gcc to compile yet. Ian -- Ian Freislich -- ___ 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: r329501 devd doesn't find USB devices
On 02/18/18 18:49, Warner Losh wrote: > On Sun, Feb 18, 2018 at 4:45 PM, Ian FREISLICH > <ian.freisl...@capeaugusta.com <mailto:ian.freisl...@capeaugusta.com>> > wrote: > > On 02/18/18 18:17, Warner Losh wrote: >> On Sun, Feb 18, 2018 at 4:12 PM, Ian FREISLICH >> <ian.freisl...@capeaugusta.com >> <mailto:ian.freisl...@capeaugusta.com>> wrote: >> >> On 02/18/18 15:09, Warner Losh wrote: >>> On Sat, Feb 17, 2018 at 9:14 PM, Ian FREISLICH >>> <ian.freisl...@capeaugusta.com >>> <mailto:ian.freisl...@capeaugusta.com>> wrote: >>> >>> On 02/17/18 22:48, Warner Losh wrote: >>>> On Feb 17, 2018 8:24 PM, "Ian FREISLICH" >>>> <ian.freisl...@capeaugusta.com >>>> <mailto:ian.freisl...@capeaugusta.com>> wrote: >>>> >>>> Hi >>>> >>>> Since devmatch some of my USB devices no longer get >>>> their drivers >>>> loaded. It's not clear from UPDATING whether I >>>> needed to do anything >>>> beyond building and installing kernel and world as >>>> well as updating >>>> /etc. There was reference to removing >>>> /etc/devd/usb.conf in another >>>> thread but its presence or lack thereof makes no >>>> difference. >>>> >>>> >>>> I assume you've fully updated including /etc. >>> >>> In as much as 'mergemaster -Ui' fully updates /etc >>> >>>> If you can uncomment the devd lines in syslog.conf, >>>> touch /var/log/devd.log and reboot. Once you are up >>>> again, please send me /var/log/devd.conf. >>> >>> Assuming you mean these lines: >>> >>> !devd >>> *.>=notice >>> /var/log/devd.log >>> >>> devd produced zero logs on reboot and restart. >>> >>> >>> There should be a lot of output... one line per device >>> that's attached... Did you create /var/log/devd.log before >>> reboot? Is your /dev/log persistent across boots? >> >> Lots of output after I changed the priority from 'notice' to >> 'debug' in syslogd.conf. Might want to fix that in >> src/etc/syslogd.conf. >> >> 1. Startup: >> >> Feb 18 17:43:44 zen devd: Pushing table >> Feb 18 17:43:44 zen devd: Parsing /etc/devd.conf >> Feb 18 17:43:44 zen devd: Parsing files in /etc/devd >> Feb 18 17:43:44 zen devd: Parsing /etc/devd/devmatch.conf >> Feb 18 17:43:44 zen devd: Parsing /etc/devd/asus.conf >> Feb 18 17:43:44 zen devd: Parsing /etc/devd/hyperv.conf >> Feb 18 17:43:44 zen devd: Parsing /etc/devd/uath.conf >> Feb 18 17:43:44 zen devd: Parsing /etc/devd/ulpt.conf >> Feb 18 17:43:44 zen devd: Parsing /etc/devd/usb.conf >> Feb 18 17:43:44 zen devd: Parsing /etc/devd/zfs.conf >> Feb 18 17:43:44 zen devd: Parsing files in /usr/local/etc/devd >> Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/cups.conf >> Feb 18 17:43:44 zen devd: Parsing >> /usr/local/etc/devd/webcamd.co <http://webcamd.co>nf >> Feb 18 17:43:44 zen devd: Calling daemon >> >> >> 2. Inserting the USB-C NIC: >> >> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS >> subsystem=CDEV type=CREATE cdev=usb/0.6.0' >> Feb 18 18:05:53 zen devd: Pushing table >> Feb 18 18:05:53 zen devd: Processing notify event >> Feb 18 18:05:53 zen devd: Popping table >> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS >> subsystem=CDEV type=CREATE cdev=ugen0.6' >> Feb 18 18:05:53 zen devd: Pushing table >> Feb 18 18:05:53 zen devd: Processing notify event >> Feb 18 18:05:53 zen devd: Popping table >> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS >> subsystem=CDEV type=CREATE cdev=usb/0.6.1' >> Feb 18 18:05:53 zen devd: Pushing table >> Feb 18 18:05:53 zen devd: Processing notify event >>
Re: r329501 devd doesn't find USB devices
-- Ian Freislich (M) +1 404 574 0228 On 02/18/18 18:17, Warner Losh wrote: > > > On Sun, Feb 18, 2018 at 4:12 PM, Ian FREISLICH > <ian.freisl...@capeaugusta.com <mailto:ian.freisl...@capeaugusta.com>> > wrote: > > On 02/18/18 15:09, Warner Losh wrote: >> On Sat, Feb 17, 2018 at 9:14 PM, Ian FREISLICH >> <ian.freisl...@capeaugusta.com >> <mailto:ian.freisl...@capeaugusta.com>> wrote: >> >> On 02/17/18 22:48, Warner Losh wrote: >>> On Feb 17, 2018 8:24 PM, "Ian FREISLICH" >>> <ian.freisl...@capeaugusta.com >>> <mailto:ian.freisl...@capeaugusta.com>> wrote: >>> >>> Hi >>> >>> Since devmatch some of my USB devices no longer get >>> their drivers >>> loaded. It's not clear from UPDATING whether I needed >>> to do anything >>> beyond building and installing kernel and world as well >>> as updating >>> /etc. There was reference to removing >>> /etc/devd/usb.conf in another >>> thread but its presence or lack thereof makes no difference. >>> >>> >>> I assume you've fully updated including /etc. >> >> In as much as 'mergemaster -Ui' fully updates /etc >> >>> If you can uncomment the devd lines in syslog.conf, touch >>> /var/log/devd.log and reboot. Once you are up again, please >>> send me /var/log/devd.conf. >> >> Assuming you mean these lines: >> >> !devd >> *.>=notice /var/log/devd.log >> >> devd produced zero logs on reboot and restart. >> >> >> There should be a lot of output... one line per device that's >> attached... Did you create /var/log/devd.log before reboot? Is >> your /dev/log persistent across boots? > > Lots of output after I changed the priority from 'notice' to > 'debug' in syslogd.conf. Might want to fix that in > src/etc/syslogd.conf. > > 1. Startup: > > Feb 18 17:43:44 zen devd: Pushing table > Feb 18 17:43:44 zen devd: Parsing /etc/devd.conf > Feb 18 17:43:44 zen devd: Parsing files in /etc/devd > Feb 18 17:43:44 zen devd: Parsing /etc/devd/devmatch.conf > Feb 18 17:43:44 zen devd: Parsing /etc/devd/asus.conf > Feb 18 17:43:44 zen devd: Parsing /etc/devd/hyperv.conf > Feb 18 17:43:44 zen devd: Parsing /etc/devd/uath.conf > Feb 18 17:43:44 zen devd: Parsing /etc/devd/ulpt.conf > Feb 18 17:43:44 zen devd: Parsing /etc/devd/usb.conf > Feb 18 17:43:44 zen devd: Parsing /etc/devd/zfs.conf > Feb 18 17:43:44 zen devd: Parsing files in /usr/local/etc/devd > Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/cups.conf > Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/webcamd.conf > Feb 18 17:43:44 zen devd: Calling daemon > > > 2. Inserting the USB-C NIC: > > Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS > subsystem=CDEV type=CREATE cdev=usb/0.6.0' > Feb 18 18:05:53 zen devd: Pushing table > Feb 18 18:05:53 zen devd: Processing notify event > Feb 18 18:05:53 zen devd: Popping table > Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS > subsystem=CDEV type=CREATE cdev=ugen0.6' > Feb 18 18:05:53 zen devd: Pushing table > Feb 18 18:05:53 zen devd: Processing notify event > Feb 18 18:05:53 zen devd: Popping table > Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS > subsystem=CDEV type=CREATE cdev=usb/0.6.1' > Feb 18 18:05:53 zen devd: Pushing table > Feb 18 18:05:53 zen devd: Processing notify event > Feb 18 18:05:53 zen devd: Popping table > Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS > subsystem=CDEV type=CREATE cdev=usb/0.6.2' > Feb 18 18:05:53 zen devd: Pushing table > Feb 18 18:05:53 zen devd: Processing notify event > Feb 18 18:05:53 zen devd: Popping table > Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS > subsystem=CDEV type=CREATE cdev=usb/0.6.3' > Feb 18 18:05:53 zen devd: Pushing table > Feb 18 18:05:53 zen devd: Processing notify event > Feb 18 18:05:53 zen devd: Popping table > Feb 18 18:05:53 zen devd: Processing event '!system=USB > subsystem=DEVICE type=ATTACH ugen=ugen0.6 cdev=ugen0.6 > vendor=0x0bda product=0x8153 devclass=0x00 devsubclass=0x00 > sernum="01" release=0x3000 mode=host port=13 parent=
Re: r329501 devd doesn't find USB devices
On 02/18/18 14:59, Warner Losh wrote: > On Sun, Feb 18, 2018 at 6:32 AM, Ian FREISLICH > <ian.freisl...@capeaugusta.com <mailto:ian.freisl...@capeaugusta.com>> > wrote: > > On 02/18/18 02:23, Hans Petter Selasky wrote: > > On 02/18/18 05:14, Ian FREISLICH wrote: > >> On 02/17/18 22:48, Warner Losh wrote: > >>> On Feb 17, 2018 8:24 PM, "Ian FREISLICH" > >>> <ian.freisl...@capeaugusta.com > <mailto:ian.freisl...@capeaugusta.com> > <mailto:ian.freisl...@capeaugusta.com > <mailto:ian.freisl...@capeaugusta.com>>> > >>> wrote: > >>> > >>> Hi > >>> > >>> Since devmatch some of my USB devices no longer get their > drivers > >>> loaded. It's not clear from UPDATING whether I needed to do > >>> anything > >>> beyond building and installing kernel and world as well as > >>> updating > >>> /etc. There was reference to removing /etc/devd/usb.conf in > >>> another > >>> thread but its presence or lack thereof makes no difference. > >>> > >>> > >>> I assume you've fully updated including /etc. > >> > >> In as much as 'mergemaster -Ui' fully updates /etc > >> > >>> If you can uncomment the devd lines in syslog.conf, touch > >>> /var/log/devd.log and reboot. Once you are up again, please > send me > >>> /var/log/devd.conf. > >> > >> Assuming you mean these lines: > >> > >> !devd > >> *.>=notice /var/log/devd.log > >> > >> devd produced zero logs on reboot and restart. > > > > Can you run: > > > > usbconfig show_ifdrv > > > > Maybe the wrong driver captured your device? > > ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER > (5.0Gbps) pwr=SAVE (0mA) > ugen0.1.0: uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, > addr 1> > ugen0.2: at usbus0, cfg=0 md=HOST > spd=HIGH (480Mbps) pwr=ON (500mA) > ugen0.3: at usbus0, cfg=0 md=HOST > spd=FULL (12Mbps) pwr=ON (100mA) > ugen0.3.0: ubt0: 2.00/0.10, addr 2> > ugen0.4: at usbus0, cfg=0 md=HOST spd=FULL > (12Mbps) pwr=ON (100mA) > ugen0.5: at usbus0, cfg=0 md=HOST > spd=FULL (12Mbps) pwr=ON (100mA) > ugen0.6: at usbus0, cfg=0 md=HOST spd=SUPER > (5.0Gbps) pwr=ON (72mA) > > After loading ums and ukbd: > > ugen0.5: at usbus0, cfg=0 md=HOST > spd=FULL (12Mbps) pwr=ON (100mA) > ugen0.5.0: ukbd0: 1.10/10.01, addr 5> > ugen0.5.1: ums0: 1.10/10.01, addr 5> > > > So what happens if you build these drivers into the kernel vs loading > them? > > Warner -- ___ 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: r329501 devd doesn't find USB devices
On 02/18/18 18:01, Ian FREISLICH wrote: > On 02/18/18 14:59, Warner Losh wrote: >> On Sun, Feb 18, 2018 at 6:32 AM, Ian FREISLICH >> <ian.freisl...@capeaugusta.com >> <mailto:ian.freisl...@capeaugusta.com>> wrote: >> >> On 02/18/18 02:23, Hans Petter Selasky wrote: >> > On 02/18/18 05:14, Ian FREISLICH wrote: >> >> On 02/17/18 22:48, Warner Losh wrote: >> >>> On Feb 17, 2018 8:24 PM, "Ian FREISLICH" >> >>> <ian.freisl...@capeaugusta.com >> <mailto:ian.freisl...@capeaugusta.com> >> <mailto:ian.freisl...@capeaugusta.com >> <mailto:ian.freisl...@capeaugusta.com>>> >> >>> wrote: >> >>> >> >>> Hi >> >>> >> >>> Since devmatch some of my USB devices no longer get >> their drivers >> >>> loaded. It's not clear from UPDATING whether I needed to do >> >>> anything >> >>> beyond building and installing kernel and world as well as >> >>> updating >> >>> /etc. There was reference to removing /etc/devd/usb.conf in >> >>> another >> >>> thread but its presence or lack thereof makes no difference. >> >>> >> >>> >> >>> I assume you've fully updated including /etc. >> >> >> >> In as much as 'mergemaster -Ui' fully updates /etc >> >> >> >>> If you can uncomment the devd lines in syslog.conf, touch >> >>> /var/log/devd.log and reboot. Once you are up again, please >> send me >> >>> /var/log/devd.conf. >> >> >> >> Assuming you mean these lines: >> >> >> >> !devd >> >> *.>=notice /var/log/devd.log >> >> >> >> devd produced zero logs on reboot and restart. >> > >> > Can you run: >> > >> > usbconfig show_ifdrv >> > >> > Maybe the wrong driver captured your device? >> >> ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER >> (5.0Gbps) pwr=SAVE (0mA) >> ugen0.1.0: uhub0: <0x8086 XHCI root HUB, class 9/0, rev >> 3.00/1.00, addr 1> >> ugen0.2: at usbus0, cfg=0 md=HOST >> spd=HIGH (480Mbps) pwr=ON (500mA) >> ugen0.3: at usbus0, cfg=0 md=HOST >> spd=FULL (12Mbps) pwr=ON (100mA) >> ugen0.3.0: ubt0: > 2.00/0.10, addr 2> >> ugen0.4: at usbus0, cfg=0 md=HOST spd=FULL >> (12Mbps) pwr=ON (100mA) >> ugen0.5: at usbus0, cfg=0 md=HOST >> spd=FULL (12Mbps) pwr=ON (100mA) >> ugen0.6: at usbus0, cfg=0 md=HOST spd=SUPER >> (5.0Gbps) pwr=ON (72mA) >> >> After loading ums and ukbd: >> >> ugen0.5: at usbus0, cfg=0 md=HOST >> spd=FULL (12Mbps) pwr=ON (100mA) >> ugen0.5.0: ukbd0: > 1.10/10.01, addr 5> >> ugen0.5.1: ums0: > 1.10/10.01, addr 5> >> >> >> So what happens if you build these drivers into the kernel vs loading >> them? It just works, which is the fix I'm using for now. Ian -- ___ 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: r329501 devd doesn't find USB devices
On 02/18/18 15:09, Warner Losh wrote: > On Sat, Feb 17, 2018 at 9:14 PM, Ian FREISLICH > <ian.freisl...@capeaugusta.com <mailto:ian.freisl...@capeaugusta.com>> > wrote: > > On 02/17/18 22:48, Warner Losh wrote: >> On Feb 17, 2018 8:24 PM, "Ian FREISLICH" >> <ian.freisl...@capeaugusta.com >> <mailto:ian.freisl...@capeaugusta.com>> wrote: >> >> Hi >> >> Since devmatch some of my USB devices no longer get their drivers >> loaded. It's not clear from UPDATING whether I needed to do >> anything >> beyond building and installing kernel and world as well as >> updating >> /etc. There was reference to removing /etc/devd/usb.conf in >> another >> thread but its presence or lack thereof makes no difference. >> >> >> I assume you've fully updated including /etc. > > In as much as 'mergemaster -Ui' fully updates /etc > >> If you can uncomment the devd lines in syslog.conf, touch >> /var/log/devd.log and reboot. Once you are up again, please send >> me /var/log/devd.conf. > > Assuming you mean these lines: > > !devd > *.>=notice /var/log/devd.log > > devd produced zero logs on reboot and restart. > > > There should be a lot of output... one line per device that's > attached... Did you create /var/log/devd.log before reboot? Is your > /dev/log persistent across boots? Lots of output after I changed the priority from 'notice' to 'debug' in syslogd.conf. Might want to fix that in src/etc/syslogd.conf. 1. Startup: Feb 18 17:43:44 zen devd: Pushing table Feb 18 17:43:44 zen devd: Parsing /etc/devd.conf Feb 18 17:43:44 zen devd: Parsing files in /etc/devd Feb 18 17:43:44 zen devd: Parsing /etc/devd/devmatch.conf Feb 18 17:43:44 zen devd: Parsing /etc/devd/asus.conf Feb 18 17:43:44 zen devd: Parsing /etc/devd/hyperv.conf Feb 18 17:43:44 zen devd: Parsing /etc/devd/uath.conf Feb 18 17:43:44 zen devd: Parsing /etc/devd/ulpt.conf Feb 18 17:43:44 zen devd: Parsing /etc/devd/usb.conf Feb 18 17:43:44 zen devd: Parsing /etc/devd/zfs.conf Feb 18 17:43:44 zen devd: Parsing files in /usr/local/etc/devd Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/cups.conf Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/webcamd.conf Feb 18 17:43:44 zen devd: Calling daemon 2. Inserting the USB-C NIC: Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/0.6.0' Feb 18 18:05:53 zen devd: Pushing table Feb 18 18:05:53 zen devd: Processing notify event Feb 18 18:05:53 zen devd: Popping table Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ugen0.6' Feb 18 18:05:53 zen devd: Pushing table Feb 18 18:05:53 zen devd: Processing notify event Feb 18 18:05:53 zen devd: Popping table Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/0.6.1' Feb 18 18:05:53 zen devd: Pushing table Feb 18 18:05:53 zen devd: Processing notify event Feb 18 18:05:53 zen devd: Popping table Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/0.6.2' Feb 18 18:05:53 zen devd: Pushing table Feb 18 18:05:53 zen devd: Processing notify event Feb 18 18:05:53 zen devd: Popping table Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/0.6.3' Feb 18 18:05:53 zen devd: Pushing table Feb 18 18:05:53 zen devd: Processing notify event Feb 18 18:05:53 zen devd: Popping table Feb 18 18:05:53 zen devd: Processing event '!system=USB subsystem=DEVICE type=ATTACH ugen=ugen0.6 cdev=ugen0.6 vendor=0x0bda product=0x8153 devclass=0x00 devsubclass=0x00 sernum="01" release=0x3000 mode=host port=13 parent=ugen0.1' Feb 18 18:05:53 zen devd: Pushing table Feb 18 18:05:53 zen devd: Processing notify event Feb 18 18:05:53 zen devd: Popping table Feb 18 18:05:53 zen devd: Processing event '!system=USB subsystem=INTERFACE type=ATTACH ugen=ugen0.6 cdev=ugen0.6 vendor=0x0bda product=0x8153 devclass=0x00 devsubclass=0x00 sernum="01" release=0x3000 mode=host interface=0 endpoints=3 intclass=0xff intsubclass=0xff intprotocol=0x00' Feb 18 18:05:53 zen devd: Pushing table Feb 18 18:05:53 zen devd: Processing notify event Feb 18 18:05:53 zen devd: Executing '/usr/local/etc/rc.d/webcamd start ugen0.6' Feb 18 18:05:53 zen devd: Popping table Feb 18 18:05:53 zen devd: Processing event '? at bus=0 hubaddr=1 port=13 devaddr=6 interface=0 ugen=ugen0.6 vendor=0x0bda product=0x8153 devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="01" release=0x3000 mode=host intclass=0xff intsubclass=0xff intprotocol=0x00 on uhub0' Feb 18 18:05:53 zen devd: Pushing table Feb 18 18:05:53 zen devd: Pr
Re: r329501 devd doesn't find USB devices
On 02/18/18 02:23, Hans Petter Selasky wrote: > On 02/18/18 05:14, Ian FREISLICH wrote: >> On 02/17/18 22:48, Warner Losh wrote: >>> On Feb 17, 2018 8:24 PM, "Ian FREISLICH" >>> <ian.freisl...@capeaugusta.com <mailto:ian.freisl...@capeaugusta.com>> >>> wrote: >>> >>> Hi >>> >>> Since devmatch some of my USB devices no longer get their drivers >>> loaded. It's not clear from UPDATING whether I needed to do >>> anything >>> beyond building and installing kernel and world as well as >>> updating >>> /etc. There was reference to removing /etc/devd/usb.conf in >>> another >>> thread but its presence or lack thereof makes no difference. >>> >>> >>> I assume you've fully updated including /etc. >> >> In as much as 'mergemaster -Ui' fully updates /etc >> >>> If you can uncomment the devd lines in syslog.conf, touch >>> /var/log/devd.log and reboot. Once you are up again, please send me >>> /var/log/devd.conf. >> >> Assuming you mean these lines: >> >> !devd >> *.>=notice /var/log/devd.log >> >> devd produced zero logs on reboot and restart. > > Can you run: > > usbconfig show_ifdrv > > Maybe the wrong driver captured your device? ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen0.1.0: uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) ugen0.3.0: ubt0: ugen0.4: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) ugen0.5: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) ugen0.6: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA) After loading ums and ukbd: ugen0.5: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) ugen0.5.0: ukbd0: ugen0.5.1: ums0: > Try running: > > usbconfig -d X.Y reset This produces no kernel messages, no difference to drivers. -- ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0300 bDeviceClass = 0x0009 bDeviceSubClass = 0x bDeviceProtocol = 0x0003 bMaxPacketSize0 = 0x0009 idVendor = 0x idProduct = 0x bcdDevice = 0x0100 iManufacturer = 0x0001 <0x8086> iProduct = 0x0002 iSerialNumber = 0x bNumConfigurations = 0x0001 ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x00ef bDeviceSubClass = 0x0002 bDeviceProtocol = 0x0001 bMaxPacketSize0 = 0x0040 idVendor = 0x13d3 idProduct = 0x5755 bcdDevice = 0x1612 iManufacturer = 0x0003 iProduct = 0x0001 iSerialNumber = 0x0002 <0001> bNumConfigurations = 0x0001 ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x00e0 bDeviceSubClass = 0x0001 bDeviceProtocol = 0x0001 bMaxPacketSize0 = 0x0040 idVendor = 0x8087 idProduct = 0x0a2b bcdDevice = 0x0010 iManufacturer = 0x iProduct = 0x iSerialNumber = 0x bNumConfigurations = 0x0001 ugen0.4: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0008 idVendor = 0x04f3 idProduct = 0x0903 bcdDevice = 0x0135 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x bNumConfigurations = 0x0001 ugen0.5: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0040 idVendor = 0x24ae idProduct = 0x2000 bcdDevice = 0x1001 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x bNumConfigurations = 0x0001 ugen0.6: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0300 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0009 idVendor = 0x0bda idProduct = 0x8153 bcdDevice = 0x3000 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0006 <01> bNumConfigurations = 0x0002 ___ 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: r329501 devd doesn't find USB devices
On 02/17/18 22:48, Warner Losh wrote: > On Feb 17, 2018 8:24 PM, "Ian FREISLICH" > <ian.freisl...@capeaugusta.com <mailto:ian.freisl...@capeaugusta.com>> > wrote: > > Hi > > Since devmatch some of my USB devices no longer get their drivers > loaded. It's not clear from UPDATING whether I needed to do anything > beyond building and installing kernel and world as well as updating > /etc. There was reference to removing /etc/devd/usb.conf in another > thread but its presence or lack thereof makes no difference. > > > I assume you've fully updated including /etc. In as much as 'mergemaster -Ui' fully updates /etc > If you can uncomment the devd lines in syslog.conf, touch > /var/log/devd.log and reboot. Once you are up again, please send me > /var/log/devd.conf. Assuming you mean these lines: !devd *.>=notice /var/log/devd.log devd produced zero logs on reboot and restart. Ian -- ___ 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"
r329501 devd doesn't find USB devices
Hi Since devmatch some of my USB devices no longer get their drivers loaded. It's not clear from UPDATING whether I needed to do anything beyond building and installing kernel and world as well as updating /etc. There was reference to removing /etc/devd/usb.conf in another thread but its presence or lack thereof makes no difference. if_ure: ugen0.6: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0300 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0009 idVendor = 0x0bda idProduct = 0x8153 bcdDevice = 0x3000 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0006 <01> bNumConfigurations = 0x0002 ums, ukbd: ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0040 idVendor = 0x24ae idProduct = 0x2000 bcdDevice = 0x1001 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x bNumConfigurations = 0x0001 Ian -- Ian Freislich -- ___ 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: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive
On 02/14/18 03:42, Vladimir Zakharov wrote:
> On Tue, Feb 13, 2018, Bryan Drewery wrote:
>> On 2/13/2018 1:48 AM, Vladimir Zakharov wrote:
>>> On Mon, Feb 12, 2018, Bryan Drewery wrote:
On 2/12/2018 6:54 AM, Vladimir Zakharov wrote:
> Hello, Bryan!
>
> On Fri, Feb 09, 2018, Bryan Drewery wrote:
>> On 2/1/2018 1:10 AM, Vladimir Zakharov wrote:
>>> Hello!
>>>
>>> For some time (about a week) building and installing kernel fails with
>>> the error "Variable OBJTOP is recursive." when going to build/install
>>> module from ports.
>>>
>>> Last successful build was at r328426. Next build at r328527 failed and
>>> still broken at r328649.
>>>
>>> Without PORTS_MODULES building and installing kernel succeeds. Another
>>> workaround: ignore error and build/install module directly from ports.
>>> ...
>> For some reason I cannot recreate this issue.
> It seems, setting WITH_AUTO_OBJ in /etc/src-env.conf causes an error.
> At least, removing it fixes build for me.
>
> Build successful with the following settings:
> # cat /etc/src-env.conf
> WITH_META_MODE=
> #WITH_AUTO_OBJ=
>
Please try this patch (requires a buildkernel).
https://people.freebsd.org/~bdrewery/patches/kernel-portsmodules.diff
>>> Fixed partly:
>>> | buildkernel | installkernel |
>>> r329196 | OK | FAIL(*) |
>>> r329169 + patch | OK | OK|
>>> r329196 + WITH_AUTO_OBJ | FAIL | |
>>> r329169 + WITH_AUTO_OBJ + patch | FAIL | |
>>>
>>> (*) - same error "Variable OBJTOP is recursive".
>>>
>> Thanks, r329232 should fix it.
> Not yet. 'installkernel' still fails (see below). Can be fixed either by
> explicit setting WITHOUT_AUTO_OBJ in /etc/src-env.conf or by applying
> previous patch (s/build/stage/ in kern.post.mk:89).
>
> # svn info
> Path: .
> Working Copy Root Path: /usr/src
> URL: https://svn.freebsd.org/base/head
> Relative URL: ^/head
> Repository Root: https://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 329259
> Node Kind: directory
> Schedule: normal
> Last Changed Author: eadler
> Last Changed Rev: 329259
> Last Changed Date: 2018-02-14 10:59:30 +0300 (Wed, 14 Feb 2018)
>
> # cat /etc/src-env.conf
> WITH_META_MODE=
> #WITH_AUTO_OBJ=
>
> # env | grep MAKE
> MAKEOBJDIRPREFIX=/home/obj
>
> # make -j 4 buildkernel && make installkernel
> ...
> ===> Ports module graphics/drm-next-kmod (all)
> cd ${PORTSDIR:-/usr/ports}/graphics/drm-next-kmod; env -u CC -u CXX -u CPP
> -u MAKESYSPATH -u MAKEOBJDIR MAKEFLAGS="-j 4 -J 15,16 -j 4 -J 15,16 -D
> NO_MODULES_OBJ .MAKE.LEVEL.ENV=MAKELEVEL KERNEL=kernel TARGET=amd64
> TARGET_ARCH=amd64" SYSDIR=/usr/src/sys
> PATH=/home/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/home/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/home/obj/usr/src/amd64.amd64/tmp/legacy/bin:/home/obj/usr/src/amd64.amd64/tmp/usr/sbin:/home/obj/usr/src/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
> SRC_BASE=/usr/src OSVERSION=1200058
> WRKDIRPREFIX=/home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG make -B clean
> build
> ===> Cleaning for drm-next-kmod-g20180117
> ===> License BSD2CLAUSE MIT GPLv2 accepted by the user
> ===> drm-next-kmod-g20180117 depends on file: /usr/local/sbin/pkg - found
> ===> Fetching all distfiles required by drm-next-kmod-g20180117 for building
> ===> Extracting for drm-next-kmod-g20180117
> => SHA256 Checksum OK for FreeBSDDesktop-kms-drm-g20180117-622fdd1_GH0.tar.gz.
> ===> Patching for drm-next-kmod-g20180117
> ===> drm-next-kmod-g20180117 depends on file: /usr/local/bin/ccache - found
> ===> Configuring for drm-next-kmod-g20180117
> ===> Building for drm-next-kmod-g20180117
> [Creating objdir obj...]
> ...
> --
Kernel build for GENERIC-NODEBUG completed on Wed Feb 14 11:09:45 MSK 2018
> --
> --
Installing kernel GENERIC-NODEBUG on Wed Feb 14 11:09:45 MSK 2018
> --
> ...
> kldxref /boot/kernel
> ===> Ports module graphics/drm-next-kmod (install)
> cd ${PORTSDIR:-/usr/ports}/graphics/drm-next-kmod; env -u CC -u CXX -u CPP
> -u MAKESYSPATH -u MAKEOBJDIR MAKEFLAGS=".MAKE.LEVEL.ENV=MAKELEVEL
> KERNEL=kernel MK_AUTO_OBJ=no TARGET=amd64 TARGET_ARCH=amd64"
> SYSDIR=/usr/src/sys
> PATH=/home/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/home/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/home/obj/usr/src/amd64.amd64/tmp/legacy/bin:/home/obj/usr/src/amd64.amd64/tmp/usr/sbin:/home/obj/usr/src/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
>
I2C trackpad
Hey, I recently acquired a new laptop (Asus UX490U) which for the most part works with current except that: 1. Sound output doesn't work. 2. The trackpad doesn't work. I'm not bothered about sound and I haven't investigated that yet. The trackpad not working is a nuisance, but I don't think that there's a short term fix. I think it's connected via an I2C bus on one of two I2C controllers that don't have a driver attached: none2@pci0:0:21:0: class=0x118000 card=0x1c301043 chip=0x9d608086 rev=0x21 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-LP Serial IO I2C Controller' class = dasp none3@pci0:0:21:1: class=0x118000 card=0x1c301043 chip=0x9d618086 rev=0x21 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-LP Serial IO I2C Controller' class = dasp I've done some research and it looks like support is a long way off but I'm hoping someone has a work in progress I can test or hack on. Ian -- Ian Freislich -- ___ 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: Insta-reset-bootloop with r328166 and vm.pmap.pcid_enabled=1
On 01/25/18 17:13, Konstantin Belousov wrote: > On Thu, Jan 25, 2018 at 04:58:04PM -0500, Ian FREISLICH wrote: >> Hi >> >> I cannot for the life of me recall why I had vm.pmap.pcid_enabled=1 set >> in loader.conf, but I did. Most likely very historical reasons. >> >> r328166 and later reset without dropping into the debugger during boot, >> no panic message. > Yes, this is how it is currently behaves. > PCID can be used to optimize PTI, see https://reviews.freebsd.org/D13985. > It is used for very differrent algorithm when PTI=1, comparing with PTI=0. Maybe there should be an "interlock" on these knobs, although judging from the number of reports I'm the only that shot my foot. Ian -- Ian Freislich -- ___ 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"
Insta-reset-bootloop with r328166 and vm.pmap.pcid_enabled=1
Hi I cannot for the life of me recall why I had vm.pmap.pcid_enabled=1 set in loader.conf, but I did. Most likely very historical reasons. r328166 and later reset without dropping into the debugger during boot, no panic message. Ian -- Ian Freislich -- ___ 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: r322076 breaks vtnet connectivity
On 08/11/17 01:48, Jung-uk Kim wrote: On 08/10/2017 21:27, Ian FREISLICH wrote: I have a host on Digital Ocean (qemu) and the change in r322076 breaks my vtnet0 interface. The interface still comes up but does not pass traffic any more. It's not obvious to my why the changes from r322075 to r322076 affect the vtnet interface. Can you please try r322323 or later? Basically, r322076 was incomplete and r322323 corrected the stupid mistake. Thanks, that fixes it. Ian -- Cape Augusta Digital Properties, LLC a Cape Augusta Company *Breach of confidentiality & accidental breach of confidentiality * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. ___ 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"
r322076 breaks vtnet connectivity
Hi I have a host on Digital Ocean (qemu) and the change in r322076 breaks my vtnet0 interface. The interface still comes up but does not pass traffic any more. It's not obvious to my why the changes from r322075 to r322076 affect the vtnet interface. Ian -- Ian Freislich -- Cape Augusta Digital Properties, LLC a Cape Augusta Company *Breach of confidentiality & accidental breach of confidentiality * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. ___ 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"
x2APIC support (Re: How many CPU cores does FreeBSD support?)
Hi I think your issue relates to x2APIC support and I don't think that full support for parsing x2APIC MADT entries and doing interrupts remapping has been committed yet from my very brief search of the source and commit messages. I've copied Andriy Gapon and Konstantin Belousov who participated in another x2APIC thread in September last year. They will probably have a more intelligible response. sys/x86/include/apicvar.h limits APIC IDs as follows: #define MAX_APIC_ID 0xfe #define APIC_ID_ALL 0xff This is why CPUs with an APIC ID above 255 are being ignored in acpica/madt.c sys/x86/x86/mptable.c has this choice piece of code: if (intr->dst_apic_id == 0xff) apic_id = APIC_ID_ALL; else apic_id = intr->dst_apic_id; which for the current value of APIC_ID_ALL can simply be rewritten as: apic_id = intr->dst_apic_id; I do not think it is safe to increase MAX_APIC_ID yet. Ian -- Ian Freislich On 01/04/17 13:53, Eric Joyner wrote: Adding freebsd-current, because that's a good idea. I see these lines in the beginning of dmesg: MADT: Ignoring local APIC ID 256 (too high) [907/911] MADT: Ignoring local APIC ID 260 (too high) [906/911] MADT: Ignoring local APIC ID 264 (too high) [905/911] MADT: Ignoring local APIC ID 268 (too high) [904/911] MADT: Ignoring local APIC ID 272 (too high) [903/911] MADT: Ignoring local APIC ID 276 (too high) [902/911] MADT: Ignoring local APIC ID 280 (too high) [901/911] MADT: Ignoring local APIC ID 272 (too high) [903/911] MADT: Ignoring local APIC ID 276 (too high) [902/911] MADT: Ignoring local APIC ID 280 (too high) [901/911] MADT: Ignoring local APIC ID 276 (too high) [902/911] MADT: Ignoring local APIC ID 280 (too high) MADT: Ignoring local APIC ID 284 (too high) MADT: Ignoring local APIC ID 288 (too high) MADT: Ignoring local APIC ID 292 (too high) MADT: Ignoring local APIC ID 296 (too high) MADT: Ignoring local APIC ID 300 (too high) MADT: Ignoring local APIC ID 257 (too high) MADT: Ignoring local APIC ID 261 (too high) MADT: Ignoring local APIC ID 265 (too high) MADT: Ignoring local APIC ID 269 (too high) MADT: Ignoring local APIC ID 273 (too high) MADT: Ignoring local APIC ID 277 (too high) MADT: Ignoring local APIC ID 281 (too high) MADT: Ignoring local APIC ID 285 (too high) MADT: Ignoring local APIC ID 289 (too high) MADT: Ignoring local APIC ID 293 (too high) MADT: Ignoring local APIC ID 297 (too high) MADT: Ignoring local APIC ID 301 (too high) MADT: Ignoring local APIC ID 258 (too high) MADT: Ignoring local APIC ID 262 (too high) MADT: Ignoring local APIC ID 266 (too high) MADT: Ignoring local APIC ID 270 (too high) MADT: Ignoring local APIC ID 274 (too high) MADT: Ignoring local APIC ID 278 (too high) MADT: Ignoring local APIC ID 282 (too high) MADT: Ignoring local APIC ID 286 (too high) MADT: Ignoring local APIC ID 290 (too high) MADT: Ignoring local APIC ID 294 (too high) MADT: Ignoring local APIC ID 298 (too high) MADT: Ignoring local APIC ID 302 (too high) MADT: Ignoring local APIC ID 255 (too high) MADT: Ignoring local APIC ID 259 (too high) MADT: Ignoring local APIC ID 263 (too high) MADT: Ignoring local APIC ID 267 (too high) MADT: Ignoring local APIC ID 271 (too high) MADT: Ignoring local APIC ID 275 (too high) MADT: Ignoring local APIC ID 279 (too high) MADT: Ignoring local APIC ID 283 (too high) MADT: Ignoring local APIC ID 287 (too high) MADT: Ignoring local APIC ID 291 (too high) MADT: Ignoring local APIC ID 295 (too high) MADT: Ignoring local APIC ID 299 (too high) MADT: Ignoring local APIC ID 303 (too high) Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep 29 01:43:23 UTC 2016 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) SRAT: No CPU found for memory domain 1 VT(efifb): resolution 800x600 CPU: Intel(R) Xeon Phi(TM) CPU 7250 @ 1.40GHz (1396.80-MHz K8-class CPU) Origin="GenuineIntel" Id=0x50671 Family=0x6 Model=0x57 Stepping=1 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x7ff8f39f<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,EST,TM2,SSSE3,FMA,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM> AMD Features2=0x121<LAHF,ABM,Prefetch> Structured Extended Features=0x1c0d23ab<FSGSBASE,TSCADJ,BMI1,AVX2,SMEP,BMI2,ERMS,NFPUSG,AVX512F,RDSEED,ADX,AVX512PF,AVX512ER,AVX512CD> Struct
Re: r299512 breaks dhclient on some networks
On 05/18/16 20:19, Don Lewis wrote > It looks to me like r299512 is changing the format of the client > identifier by inserting the struct hardware hlen field into it. That's > not valid if htype is non-zero the way I interpret RFC 2132. On the > other hand, I would think that the server would interpret the client ID > as an opaque cookie, so I wouldn't think it would make a difference > (other than thinking this is a new client) unless your server is > configured to look for specific client IDs. It's not that the server isn't working. The client is discarding the server's offer for whatever reason. But, r300174 has it working again for me. I can't speak to the correctness of the fix though. Ian -- Ian Freislich -- Cape Augusta Digital Properties, LLC a Cape Augusta Company *Breach of confidentiality & accidental breach of confidentiality * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. ___ 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: r299512 breaks dhclient on some networks
On 05/18/16 19:49, Conrad Meyer wrote: > Hey Ian, > > r299512 incorrectly encoded client identifiers because I misunderstood > the intent of the sizeof()-scaled client_id. I reverted that change > and replaced it with r300174, which I believe fixes the first overrun > more correctly. Just checked and DHCP is working again. > (Coverity may still complain about CID 1305550, but I don't believe > it's valid for 'hlen' to exceed sizeof(hw_addr.haddr).) > > Thanks, > Conrad > > On Wed, May 18, 2016 at 3:49 PM, Ian FREISLICH > <ian.freisl...@capeaugusta.com> wrote: >> Hi >> >> I cannot for the life of me figure out why the change in r299512 breaks >> DHCP on one network I use but not on another network. >> >> The only clue I can find is that the request whose response is ignored >> has the following client ID: >> 1:6:0:22:5f:70:a1:df >> >> The request whose response is use has this client ID: >> 1:0:22:5f:70:a1:df >> >> Here's a dhcpdump of the request/offer that gets ignored. >> >> --- >> >> TIME: 2016-05-18 18:46:39.134 >> IP: 0.0.0.0 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff) >> OP: 1 (BOOTPREQUEST) >> HTYPE: 1 (Ethernet) >> HLEN: 6 >> HOPS: 0 >>XID: 92a34fc3 >> SECS: 0 >> FLAGS: 0 >> CIADDR: 0.0.0.0 >> YIADDR: 0.0.0.0 >> SIADDR: 0.0.0.0 >> GIADDR: 0.0.0.0 >> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00 >> SNAME: . >> FNAME: . >> OPTION: 53 ( 1) DHCP message type 1 (DHCPDISCOVER) >> OPTION: 61 ( 8) Client-identifier 01:06:00:22:5f:70:a1:df >> OPTION: 12 ( 3) Host name zen >> OPTION: 55 ( 9) Parameter Request List 1 (Subnet mask) >> 28 (Broadcast address) >> 2 (Time offset) >> 121 (Classless Static Route) >> 3 (Routers) >> 15 (Domainname) >> 6 (DNS server) >> 12 (Host name) >> 119 (Domain Search) >> >> --- >> >> TIME: 2016-05-18 18:46:39.134 >> IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.80 (00:22:5f:70:a1:df) >> OP: 2 (BOOTPREPLY) >> HTYPE: 1 (Ethernet) >> HLEN: 6 >> HOPS: 0 >>XID: 92a34fc3 >> SECS: 0 >> FLAGS: 0 >> CIADDR: 0.0.0.0 >> YIADDR: 10.0.0.80 >> SIADDR: 10.0.0.1 >> GIADDR: 0.0.0.0 >> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00 >> SNAME: . >> FNAME: . >> OPTION: 53 ( 1) DHCP message type 2 (DHCPOFFER) >> OPTION: 54 ( 4) Server identifier 10.0.0.1 >> OPTION: 51 ( 4) IP address leasetime 259200 (3d) >> OPTION: 1 ( 4) Subnet mask 255.255.255.0 >> OPTION: 3 ( 4) Routers 10.0.0.1 >> OPTION: 6 ( 4) DNS server10.0.0.1 >> --- >> >> >> And here's the request/offer that works (with the r299512 backed out) >> >> --- >> >> TIME: 2016-05-18 18:35:33.817 >> IP: 10.0.0.220 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff) >> OP: 1 (BOOTPREQUEST) >> HTYPE: 1 (Ethernet) >> HLEN: 6 >> HOPS: 0 >>XID: 866cfd85 >> SECS: 4 >> FLAGS: 0 >> CIADDR: 0.0.0.0 >> YIADDR: 0.0.0.0 >> SIADDR: 0.0.0.0 >> GIADDR: 0.0.0.0 >> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00 >> SNAME: . >> FNAME: . >> OPTION: 53 ( 1) DHCP message type 3 (DHCPREQUEST) >> OPTION: 50 ( 4) Request IP address10.0.0.220 >> OPTION: 61 ( 7) Client-identifier 01:00:22:5f:70:a1:df >> OPTION: 12 ( 3) Host name zen >> OPTION: 55 ( 9) Parameter Request List 1 (Subnet mask) >> 28 (Broadcast address) >> 2 (Time offset) >> 121 (Classless Static Route) >> 3 (Routers) >>
r299512 breaks dhclient on some networks
Hi I cannot for the life of me figure out why the change in r299512 breaks DHCP on one network I use but not on another network. The only clue I can find is that the request whose response is ignored has the following client ID: 1:6:0:22:5f:70:a1:df The request whose response is use has this client ID: 1:0:22:5f:70:a1:df Here's a dhcpdump of the request/offer that gets ignored. --- TIME: 2016-05-18 18:46:39.134 IP: 0.0.0.0 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff) OP: 1 (BOOTPREQUEST) HTYPE: 1 (Ethernet) HLEN: 6 HOPS: 0 XID: 92a34fc3 SECS: 0 FLAGS: 0 CIADDR: 0.0.0.0 YIADDR: 0.0.0.0 SIADDR: 0.0.0.0 GIADDR: 0.0.0.0 CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00 SNAME: . FNAME: . OPTION: 53 ( 1) DHCP message type 1 (DHCPDISCOVER) OPTION: 61 ( 8) Client-identifier 01:06:00:22:5f:70:a1:df OPTION: 12 ( 3) Host name zen OPTION: 55 ( 9) Parameter Request List 1 (Subnet mask) 28 (Broadcast address) 2 (Time offset) 121 (Classless Static Route) 3 (Routers) 15 (Domainname) 6 (DNS server) 12 (Host name) 119 (Domain Search) --- TIME: 2016-05-18 18:46:39.134 IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.80 (00:22:5f:70:a1:df) OP: 2 (BOOTPREPLY) HTYPE: 1 (Ethernet) HLEN: 6 HOPS: 0 XID: 92a34fc3 SECS: 0 FLAGS: 0 CIADDR: 0.0.0.0 YIADDR: 10.0.0.80 SIADDR: 10.0.0.1 GIADDR: 0.0.0.0 CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00 SNAME: . FNAME: . OPTION: 53 ( 1) DHCP message type 2 (DHCPOFFER) OPTION: 54 ( 4) Server identifier 10.0.0.1 OPTION: 51 ( 4) IP address leasetime 259200 (3d) OPTION: 1 ( 4) Subnet mask 255.255.255.0 OPTION: 3 ( 4) Routers 10.0.0.1 OPTION: 6 ( 4) DNS server10.0.0.1 --- And here's the request/offer that works (with the r299512 backed out) --- TIME: 2016-05-18 18:35:33.817 IP: 10.0.0.220 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff) OP: 1 (BOOTPREQUEST) HTYPE: 1 (Ethernet) HLEN: 6 HOPS: 0 XID: 866cfd85 SECS: 4 FLAGS: 0 CIADDR: 0.0.0.0 YIADDR: 0.0.0.0 SIADDR: 0.0.0.0 GIADDR: 0.0.0.0 CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00 SNAME: . FNAME: . OPTION: 53 ( 1) DHCP message type 3 (DHCPREQUEST) OPTION: 50 ( 4) Request IP address10.0.0.220 OPTION: 61 ( 7) Client-identifier 01:00:22:5f:70:a1:df OPTION: 12 ( 3) Host name zen OPTION: 55 ( 9) Parameter Request List 1 (Subnet mask) 28 (Broadcast address) 2 (Time offset) 121 (Classless Static Route) 3 (Routers) 15 (Domainname) 6 (DNS server) 12 (Host name) 119 (Domain Search) --- TIME: 2016-05-18 18:35:33.817 IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.220 (00:22:5f:70:a1:df) OP: 2 (BOOTPREPLY) HTYPE: 1 (Ethernet) HLEN: 6 HOPS: 0 XID: 866cfd85 SECS: 0 FLAGS: 0 CIADDR: 0.0.0.0 YIADDR: 10.0.0.220 SIADDR: 10.0.0.1 GIADDR: 0.0.0.0 CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00 SNAME: . FNAME: . OPTION: 53 ( 1) DHCP message type 5 (DHCPACK) OPTION: 54 ( 4) Server identifier 10.0.0.1 OPTION: 51 ( 4) IP address leasetime 259200 (3d) OPTION: 1 ( 4) Subnet mask 255.255.255.0 OPTION: 3 ( 4) Routers 10.0.0.1 OPTION: 6 ( 4) DNS server10.0.0.1 ------- -- Ian Freislich -- Cape Augusta Digital Properties, LLC a Cape Augusta Company *Breach of confidentiality & accidental breach of confidentiality * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify th
Re: r296548 breaks external DP and HDMI on HD4000
Hi Replying to myself... The monitor works with in 1920x1080. Any higher resolution and the monitor displays rapidly changing random colours filled over the entire screen. I'm currently using r298115 with no improvement on the situation. Ian On 03/14/16 13:59, Ian FREISLICH wrote: > Hi > > With r296548 on the following hardware: > > vgapci0@pci0:0:2:0: class=0x03 card=0x15171043 chip=0x01668086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '3rd Gen Core processor Graphics Controller' > class = display > subclass = VGA > cap 05[90] = MSI supports 1 message enabled with 1 message > cap 01[d0] = powerspec 2 supports D0 D3 current D0 > cap 13[a4] = PCI Advanced Features: FLR TP > > I get the following console messages when X starts and my external > monitor (Samsung U28E590) goes into epileptic fit attack mode. > > [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0 > [drm:pid0:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting > [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off > [drm:pid0:intel_cpt_verify_modeset] *ERROR* mode set failed: pipe 0 stuck > [drm:pid1100:ironlake_check_fdi_lanes] *ERROR* WARN ON: > I915_READ(SOUTH_CHICKEN1) & FDI_BC_BIFURCATION_SELECT > [drm:pid1100:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail! > [drm:pid1100:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail! > > The good news is that I no longer need the following hack to turn on the > back light this laptop's LVDS display: > > Index: sys/dev/drm2/i915/intel_display.c > === > --- sys/dev/drm2/i915/intel_display.c (revision 296547) > +++ sys/dev/drm2/i915/intel_display.c (working copy) > @@ -6960,7 +6960,7 @@ > */ > I915_WRITE(BLC_PWM_CPU_CTL2, PWM_ENABLE); > I915_WRITE(BLC_PWM_CPU_CTL, 0); > - I915_WRITE(BLC_PWM_PCH_CTL1, PWM_ENABLE); > + I915_WRITE(BLC_PWM_PCH_CTL1, PWM_ENABLE | (1<<30)); > } > > void intel_modeset_init_hw(struct drm_device *dev) > -- Ian Freislich (M) +1 404 574 0228 -- Cape Augusta Digital Properties, LLC a Cape Augusta Company *Breach of confidentiality & accidental breach of confidentiality * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. ___ 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: r296548 breaks external DP and HDMI on HD4000
Hi, It was running 2560x1440. I'm not sure if the chip can do 4k although tho Xorg probe suggests it might. Maybe the rest of the interface electronics can't support the higher clock rate. r296547 does correctly run the external monitor at 2560x1440. Sadly the monitor is an international flight away from me for the 1.5 months so I can't test anything else until I'm back. Ian On 19 March 2016 01:10:54 Jean-Sébastien Pédron <dumbb...@freebsd.org> wrote: On 14/03/2016 18:59, Ian FREISLICH wrote: Hi Hi! With r296548 on the following hardware: vgapci0@pci0:0:2:0: class=0x03 card=0x15171043 chip=0x01668086 I get the following console messages when X starts and my external monitor (Samsung U28E590) goes into epileptic fit attack mode. [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0 [drm:pid0:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off [drm:pid0:intel_cpt_verify_modeset] *ERROR* mode set failed: pipe 0 stuck [drm:pid1100:ironlake_check_fdi_lanes] *ERROR* WARN ON: I915_READ(SOUTH_CHICKEN1) & FDI_BC_BIFURCATION_SELECT [drm:pid1100:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail! [drm:pid1100:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail! On my Haswell laptop, the external DisplayPort doesn't work either. When using Ultra HD, I get garbage. When using Full HD, the image is correct for a few seconds, then the output connector is disabled (talking about Panel status timeout in dmesg). What resolution do you use with your monitor? If you're using Ultra HD, could you please try Full HD? -- Jean-Sébastien Pédron -- Cape Augusta Digital Properties, LLC a Cape Augusta Company *Breach of confidentiality & accidental breach of confidentiality * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. ___ 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"
r296548 breaks external DP and HDMI on HD4000
Hi With r296548 on the following hardware: vgapci0@pci0:0:2:0: class=0x03 card=0x15171043 chip=0x01668086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '3rd Gen Core processor Graphics Controller' class = display subclass = VGA cap 05[90] = MSI supports 1 message enabled with 1 message cap 01[d0] = powerspec 2 supports D0 D3 current D0 cap 13[a4] = PCI Advanced Features: FLR TP I get the following console messages when X starts and my external monitor (Samsung U28E590) goes into epileptic fit attack mode. [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0 [drm:pid0:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off [drm:pid0:intel_cpt_verify_modeset] *ERROR* mode set failed: pipe 0 stuck [drm:pid1100:ironlake_check_fdi_lanes] *ERROR* WARN ON: I915_READ(SOUTH_CHICKEN1) & FDI_BC_BIFURCATION_SELECT [drm:pid1100:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail! [drm:pid1100:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail! The good news is that I no longer need the following hack to turn on the back light this laptop's LVDS display: Index: sys/dev/drm2/i915/intel_display.c === --- sys/dev/drm2/i915/intel_display.c (revision 296547) +++ sys/dev/drm2/i915/intel_display.c (working copy) @@ -6960,7 +6960,7 @@ */ I915_WRITE(BLC_PWM_CPU_CTL2, PWM_ENABLE); I915_WRITE(BLC_PWM_CPU_CTL, 0); - I915_WRITE(BLC_PWM_PCH_CTL1, PWM_ENABLE); + I915_WRITE(BLC_PWM_PCH_CTL1, PWM_ENABLE | (1<<30)); } void intel_modeset_init_hw(struct drm_device *dev) -- Ian Freislich -- Cape Augusta Digital Properties, LLC a Cape Augusta Company *Breach of confidentiality & accidental breach of confidentiality * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. ___ 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: broken symbolic links in /usr/lib
Glen Barber wrote: On Tue, Jul 28, 2015 at 10:17:38PM +0200, Ian FREISLICH wrote: I found the actual problem. The mount point for /usr was mode 700 even though the root of the mounted filesystem on /usr was mode 755. Did I explain that clearly (quite difficult because two things are the same thing, although they're apparently not)? Your explanation makes sense to me. The cause of this, however is unclear - was this something done locally? This is why I asked about the permissions of '/lib', but based on what you've explained, even asking for the permissions of '/usr' would not have led to a clear answer. I think the cause was when I moved to an SSD in this laptop and created the filesystems on the new disk by hand. So we're clear, '/usr' (unmounted) is 700, but '/usr' (mounted) is 755? Or is this not the case? This is exactly the case. What's confusing is the inconsistent use of the '/usr' (unmounted) and '/usr' (mounted) modes depending on circumstance. ie, non-root can cd and ls to '/usr' (mounted), but not '/usr' (unmounted), but can't resolve a relative symlink in that path. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
broken symbolic links in /usr/lib
Hi I cannot for the life of me figure out why this is so: As non-root: [zen] /usr/lib $ file libgcc_s.so libgcc_s.so: broken symbolic link to ../../lib/libgcc_s.so.1 As root: [zen] /usr/lib # file libgcc_s.so libgcc_s.so: symbolic link to ../../lib/libgcc_s.so.1 Only on one of my machines, all running CURRENT from within a day. The upshot is that I have to be root in order to link code. Any ideas greatly appreciated. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: broken symbolic links in /usr/lib
Glen Barber wrote: On Tue, Jul 28, 2015 at 07:31:56PM +, Glen Barber wrote: On Tue, Jul 28, 2015 at 08:16:16PM +0200, Ian FREISLICH wrote: Hi =20 I cannot for the life of me figure out why this is so: =20 As non-root: [zen] /usr/lib $ file libgcc_s.so libgcc_s.so: broken symbolic link to ../../lib/libgcc_s.so.1 =20 As root: [zen] /usr/lib # file libgcc_s.so=20 libgcc_s.so: symbolic link to ../../lib/libgcc_s.so.1 =20 Only on one of my machines, all running CURRENT from within a day. The upshot is that I have to be root in order to link code. =20 Any ideas greatly appreciated. =20 =20 What are the permissions on /lib/libgcc_s.so.1 ? =20 Probably a better question: What are the permissions on /lib ? Answering both: [zen] /usr/lib # ls -ld /lib drwxr-xr-x 3 root wheel 1536 Jul 28 19:07 /lib [zen] /usr/lib # ls -l /lib/libgcc_s.so.1 -r--r--r-- 1 root wheel 57792 Jul 28 19:07 /lib/libgcc_s.so.1 Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: broken symbolic links in /usr/lib
David Wolfskill wrote: My experience with SU+J is limited (and negative -- in large part, because I tend heavily on dump | restore pipelines to copy file systems, some of which are live at the time (danger mitigated by -L flag for dump). As an aside, mine has been pretty positive, except for once having / moved entirely to /lost+found and encoded as inode numbers. That might be enough for some. If you can take that system down, I suggest: * Reboot to single-user mode. * Disable SU journaling (tunefs -j disable $special) * fsck -p / (at least; possibly elide the -p) * If you want SU+J, re-enable it (tunefs -j enable $special) * While theory says exit at this point should just continue the transition to multi-user mode, I'd be inclined to just reboot watch it to make sure nothing weird happens that you don't know about. * Re-test. So, a couple of fscks found some problems, but none causing this. I found the actual problem. The mount point for /usr was mode 700 even though the root of the mounted filesystem on /usr was mode 755. Did I explain that clearly (quite difficult because two things are the same thing, although they're apparently not)? Seems that for some reason, some but not all actions involving the transition between . and .. on the mount point use either the permissions of the mount point or the permissions of the directory mounted on that mount point. In the past, the permissions in the mounted filesystem have always trumped the mount point, but I have no idea what the spec says. Is this a bug? Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ntpd wierdness.
Hi ntpq/ntpd appear inconsistent since at least r284659, reporting my refclocks as false tick and the other selected for PPS, but not time source: [brane] ~/graphing $ ntpq -c peers remote refid st t when poll reach delay offset jitter == xGPS_ONCORE(0) .GPS.0 l8 16 3770.0000.088 0.003 oGPS_ONCORE(1) .GPS.0 l7 16 3770.0000.087 0.003 +.PPS.1 u 21 64 377 31.6552.514 9.528 *.GPS.1 u5 64 377 31.9132.705 2.684 [brane] ~/graphing $ ntpq -c assoc ind assid status conf reach auth condition last_event cnt === 1 44551 913a yes yes none falseticksys_peer 3 2 44552 973a yes yes none pps.peersys_peer 3 3 44553 963a yes yes none sys.peersys_peer 3 4 44554 9424 yes yes none candidate reachable 2 [brane] ~/graphing $ ntpq -crv associd=0 status=0418 leap_none, sync_uhf_radio, 1 event, no_sys_peer, version=ntpd 4.2.8p2-a (1), processor=amd64, system=FreeBSD/11.0-CURRENT, leap=00, stratum=1, precision=-20, rootdelay=0.000, rootdisp=1.090, refid=GPS, reftime=d945578a.3989f1fd Mon, Jul 6 2015 21:37:46.224, clock=d9455790.a5ebb2cf Mon, Jul 6 2015 21:37:52.648, peer=44552, tc=4, mintc=3, offset=0.089614, frequency=31.102, sys_jitter=0.002181, clk_jitter=0.001, clk_wander=0.001 The Oncore GPS are slightly wierd in they almost always start 32000ms ahead on the first time read from them after reset and then correct themselves resulting in huge jitter at ntpd start, but then with the previous version, the refclocks were always selected as pps.peer and sys.peer. Now, even though the refclocks have settled down, the peer selection seems a little strange. At least not what I'm used to seeing. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CTF: wpa_supplicant/hostapd 2.4 import
Rui Paulo wrote: locally_generated=1 Apr 22 12:28:34 zen kernel: wlan0: link state changed to DOWN Can you send me the log of the previous wpa_supplicant version? Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: Trying to associate with 06:27:22:6c:0b:8f (SSID='quasar' freq=2437 MHz) Apr 6 18:06:38 zen kernel: wlan0: link state changed to UP Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: Associated with 06:27:22:6c:0b:8f Apr 6 18:06:38 zen dhclient[1758]: send_packet: No buffer space available Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=4 - NAK Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21 Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=ZA/ST=Western Cape/O=Freislich Home Network/OU=Freislich Home/CN=freislich.nom.za/emailAddress=c...@freislich.nom.za' Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=ZA/ST=Western Cape/O=Freislich Home Network/OU=Freislich Home/CN=freislich.nom.za/emailAddress=c...@freislich.nom.za' Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=ZA/ST=Western Cape/L=Cape Town/O=Freislich Home Network/OU=Freislich Home/CN=freislich.nom.za/emailAddress=c...@freislich.nom.za' Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: WPA: Key negotiation completed with 06:27:22:6c:0b:8f [PTK=CCMP GTK=CCMP] Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-CONNECTED - Connection to 06:27:22:6c:0b:8f completed [id=7 id_str=] Apr 6 18:06:43 zen dhclient: New IP Address (wlan0): 10.0.0.220 Apr 6 18:06:43 zen dhclient: New Subnet Mask (wlan0): 255.255.255.0 Apr 6 18:06:43 zen dhclient: New Broadcast Address (wlan0): 10.0.0.255 Apr 6 18:06:43 zen dhclient: New Routers (wlan0): 10.0.0.1 Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CTF: wpa_supplicant/hostapd 2.4 import
Rui Paulo wrote:
Hi,
Please test the new wpa_supplicant/hostapd. Here's the patch against FreeBSD
HEAD:
https://people.freebsd.org/~rpaulo/wpa-2.4.diff
EAP never actually completes the association. Authentication
completes but the link never actually comes up. This configuration
worked with the previous wpa_supplicant.
Config:
network={
ssid=quasar
key_mgmt=WPA-EAP
eap=PEAP
identity=zen
password=x
priority=8
}
RADIUS log:
Wed Apr 22 12:28:20 2015 : Auth: Login OK: [zen] (from client AP-PRO-1 port 0
cli 00-22-5F-70-A1-DF)
Client log:
Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: Trying to associate with
00:27:22:6c:0b:8f (SSID='quasar' freq=2437 MHz)
Apr 22 12:28:20 zen kernel: wlan0: link state changed to UP
Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: Associated with
00:27:22:6c:0b:8f
Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-STARTED EAP
authentication started
Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD
vendor=0 method=4 - NAK
Apr 22 12:28:20 zen dhclient[2297]: send_packet: No buffer space available
Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD
vendor=0 method=25
Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-METHOD EAP
vendor 0 method 25 (PEAP) selected
Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-PEER-CERT
depth=1 subject='/C=ZA/ST=Western Cape/O=Freislich Home Network/OU=Freislich
Home/CN=freislich.nom.za/emailAddress=c...@freislich.nom.za'
hash=79d3b2233b7c0e261445f3fe488ef259fdab3c2fbe0727043ff47b0f3f3d22a0
Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-PEER-CERT
depth=1 subject='/C=ZA/ST=Western Cape/O=Freislich Home Network/OU=Freislich
Home/CN=freislich.nom.za/emailAddress=c...@freislich.nom.za'
hash=79d3b2233b7c0e261445f3fe488ef259fdab3c2fbe0727043ff47b0f3f3d22a0
Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-PEER-CERT
depth=0 subject='/C=ZA/ST=Western Cape/L=Cape Town/O=Freislich Home
Network/OU=Freislich
Home/CN=freislich.nom.za/emailAddress=c...@freislich.nom.za'
hash=ea38723d53e84d2574f9edf105cdb904b773479badfedab1f8b9d1abbab0c12e
Apr 22 12:28:20 zen wpa_supplicant[2191]: EAP-MSCHAPV2: Authentication succeeded
Apr 22 12:28:20 zen wpa_supplicant[2191]: EAP-TLV: TLV Result - Success -
EAP-TLV/Phase2 Completed
Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-SUCCESS EAP
authentication completed successfully
Apr 22 12:28:21 zen kernel: wlan0: link state changed to DOWN
Apr 22 12:28:21 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-DISCONNECTED
bssid=00:27:22:6c:0b:8f reason=0
Apr 22 12:28:24 zen wpa_supplicant[2191]: wlan0: Trying to associate with
00:27:22:6c:0b:8f (SSID='quasar' freq=2437 MHz)
Apr 22 12:28:24 zen wpa_supplicant[2191]: wlan0: Associated with
00:27:22:6c:0b:8f
Apr 22 12:28:24 zen kernel: wlan0: link state changed to UP
Apr 22 12:28:24 zen dhclient[2297]: send_packet: No buffer space available
Apr 22 12:28:29 zen last message repeated 2 times
Apr 22 12:28:34 zen wpa_supplicant[2191]: wlan0: Authentication with
00:27:22:6c:0b:8f timed out.
Apr 22 12:28:34 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-DISCONNECTED
bssid=00:27:22:6c:0b:8f reason=3 locally_generated=1
Apr 22 12:28:34 zen kernel: wlan0: link state changed to DOWN
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r277959 breaks X display on IvyBridge mobile GT2 IG
Ian FREISLICH wrote: Adrian Chadd wrote: Hi, There's a invert backlight option in i915, try setting it to 1? This is pretty much all I could find (unless I was looking in the wrong place). It makes no difference. The backlight appears to be disabled. Adrian, do you have any idea how to fix the backlight for my laptop? I ended up reversing out your change r277959 in my local copy to make the backlight work again here. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r277959 breaks X display on IvyBridge mobile GT2 IG
Adrian Chadd wrote:
Hi,
There's a invert backlight option in i915, try setting it to 1?
This is pretty much all I could find (unless I was looking in the
wrong place). It makes no difference. The backlight appears to
be disabled.
Index: intel_display.c
===
--- intel_display.c (revision 278584)
+++ intel_display.c (working copy)
@@ -6938,6 +6938,9 @@
/* Acer Aspire 5734Z must invert backlight brightness */
{ 0x2a42, 0x1025, 0x0459, quirk_invert_brightness },
+
+ /* Asus Zenbook UX31A must invert backlight brightness */
+ { 0x0166, 0x1043, 0x1517, quirk_invert_brightness },
};
static void intel_init_quirks(struct drm_device *dev)
Resulting log message:
Feb 11 11:55:38 zen kernel: info: [drm] applying inverted panel brightness quirk
The flag removed by r278584 is BLM_PCH_OVERRIDE_ENABLE according
to the Linux driver. I think we're not correctly setting or selecting
the PWM channel for backlight control.
-a
On 11 February 2015 at 07:41, Ian FREISLICH i...@capeaugusta.com wrote:
Hi
With this commit my display blanks and never lights up when X starts.
[zen] /usr/src # svn diff -r 277958:277959
Index: sys/dev/drm2/i915/intel_display.c
===
--- sys/dev/drm2/i915/intel_display.c (revision 277958)
+++ sys/dev/drm2/i915/intel_display.c (revision 277959)
@@ -6995,7 +6995,7 @@
*/
I915_WRITE(BLC_PWM_CPU_CTL2, PWM_ENABLE);
I915_WRITE(BLC_PWM_CPU_CTL, 0);
- I915_WRITE(BLC_PWM_PCH_CTL1, PWM_ENABLE | (130));
+ I915_WRITE(BLC_PWM_PCH_CTL1, PWM_ENABLE);
}
void intel_modeset_init_hw(struct drm_device *dev)
vgapci0@pci0:0:2:0: class=0x03 card=0x15171043 chip=0x01668086 rev=
0x09
hdr=0x00
vendor = 'Intel Corporation'
device = '3rd Gen Core processor Graphics Controller'
class = display
subclass = VGA
cap 05[90] = MSI supports 1 message enabled with 1 message
cap 01[d0] = powerspec 2 supports D0 D3 current D0
cap 13[a4] = PCI Advanced Features: FLR TP
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
--
Meditating Guru
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
r277959 breaks X display on IvyBridge mobile GT2 IG
Hi With this commit my display blanks and never lights up when X starts. [zen] /usr/src # svn diff -r 277958:277959 Index: sys/dev/drm2/i915/intel_display.c === --- sys/dev/drm2/i915/intel_display.c (revision 277958) +++ sys/dev/drm2/i915/intel_display.c (revision 277959) @@ -6995,7 +6995,7 @@ */ I915_WRITE(BLC_PWM_CPU_CTL2, PWM_ENABLE); I915_WRITE(BLC_PWM_CPU_CTL, 0); - I915_WRITE(BLC_PWM_PCH_CTL1, PWM_ENABLE | (130)); + I915_WRITE(BLC_PWM_PCH_CTL1, PWM_ENABLE); } void intel_modeset_init_hw(struct drm_device *dev) vgapci0@pci0:0:2:0: class=0x03 card=0x15171043 chip=0x01668086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '3rd Gen Core processor Graphics Controller' class = display subclass = VGA cap 05[90] = MSI supports 1 message enabled with 1 message cap 01[d0] = powerspec 2 supports D0 D3 current D0 cap 13[a4] = PCI Advanced Features: FLR TP Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
r277959 breaks X display on IvyBridge mobile GT2 IG
Hi With this, my display blanks and never lights up when X starts. [zen] /usr/src # svn diff -r 277958:277959 Index: sys/dev/drm2/i915/intel_display.c === --- sys/dev/drm2/i915/intel_display.c (revision 277958) +++ sys/dev/drm2/i915/intel_display.c (revision 277959) @@ -6995,7 +6995,7 @@ */ I915_WRITE(BLC_PWM_CPU_CTL2, PWM_ENABLE); I915_WRITE(BLC_PWM_CPU_CTL, 0); - I915_WRITE(BLC_PWM_PCH_CTL1, PWM_ENABLE | (130)); + I915_WRITE(BLC_PWM_PCH_CTL1, PWM_ENABLE); } vgapci0@pci0:0:2:0: class=0x03 card=0x15171043 chip=0x01668086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '3rd Gen Core processor Graphics Controller' class = display subclass = VGA cap 05[90] = MSI supports 1 message enabled with 1 message cap 01[d0] = powerspec 2 supports D0 D3 current D0 cap 13[a4] = PCI Advanced Features: FLR TP void intel_modeset_init_hw(struct drm_device *dev) Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory
Hiroki Sato wrote: ia Hiroki Sato wrote: ia Hm, how about the attached one? ia ia I think the cause is just a race when length of the sysctl's output ia is changed in kernel after the buffer allocation in userspace, not ia memory shortage. Size of the routing table can quickly change. ia ia You are correct. It's growing at about 9000 entries per second (I ia wish it were faster). ia ia This is what the output looks like now. I guess I'm not the average ia case. Can you try the attached patch? It will attempt to enlarge the buffer every retry. I think the routing table grows too fast. It still fails. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory
Hi While recieving my routing table I used to be able to check how far it got by counting the output netstat -rn. It takes about 2 seconds to recieve the routes from my route-server, but over a minute to update the kernel routing table. I'm now getting this error until zebra completes route insertion. [firewall1.jnb1] ~ $ netstat -rn |wc -l netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory 1 [firewall1.jnb1] ~ $ netstat -rn |wc -l 480446 Is there a sysctl that controls this? There's lots of free memory (14GB). I've tuned other limits to stop dummynet crashing which may have affected this, but in the absence of any documentation of which mbuf sysctls affect dummynet I'm shooting in the dark: net.inet.ip.fw.one_pass=0 net.inet.ip.dummynet.io_fast=1 net.inet.ip.dummynet.hash_size=1024 net.pf.states_hashsize=1048576 kern.ipc.nmbclusters=1048576 kern.ipc.maxmbufmem=10737418240 kern.ipc.nmbufs=13045170 Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory
Hiroki Sato wrote: ia While recieving my routing table I used to be able to check how far ia it got by counting the output netstat -rn. It takes about 2 seconds ia to recieve the routes from my route-server, but over a minute to ia update the kernel routing table. ia ia I'm now getting this error until zebra completes route insertion. ia ia [firewall1.jnb1] ~ $ netstat -rn |wc -l ia netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory ia1 ia [firewall1.jnb1] ~ $ netstat -rn |wc -l ia 480446 Perhaps does the attached patch fix this? Sadly, not. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory
Hiroki Sato wrote: Hm, how about the attached one? I think the cause is just a race when length of the sysctl's output is changed in kernel after the buffer allocation in userspace, not memory shortage. Size of the routing table can quickly change. You are correct. It's growing at about 9000 entries per second (I wish it were faster). This is what the output looks like now. I guess I'm not the average case. [firewall1.jnb1] ~ # netstat -rn |wc -l netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory 1 [firewall1.jnb1] ~ # netstat -rn |wc -l netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying 314032 [firewall1.jnb1] ~ # netstat -rn |wc -l netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying 332293 [firewall1.jnb1] ~ # netstat -rn |wc -l netstat: Routing table grew, retrying netstat: Routing table grew, retrying 340368 [firewall1.jnb1] ~ # netstat -rn |wc -l netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying 374400 [firewall1.jnb1] ~ # netstat -rn |wc -l netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory 1 [firewall1.jnb1] ~ # netstat -rn |wc -l 480073 Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
sshd sandbox failure
Hi Since the openssh update in recent -CURRENT, I get these in my auth.log until I disable sandbox UsePrivilegeSeparation in sshd_config. Feb 3 10:02:14 firewall1 sshd[90062]: fatal: ssh_sandbox_child: failed to limit the network socket [preauth] Is there something that I missed during the update? Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libstdc++ fallout? mongodb fails to build.
Florent Peterschmitt wrote: Le 20/09/2013 10:04, Ian FREISLICH a =E9crit : Hi Is this libstdc++ fallout? You can try these patchs: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/182110 I am sorry that I did not see your message until today. This fixes the build. Thanks very much. Ian -- Meditating Guru Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
libstdc++ fallout? mongodb fails to build.
Hi Is this libstdc++ fallout? The system is AMD64 with all ports successfully rebuilt except for mongodb. In file included from src/mongo/shell/dbshell.cpp:26: In file included from src/mongo/base/initializer.h:21: In file included from src/mongo/base/configuration_variable_manager.h:24: src/mongo/platform/unordered_map.h:51:16: error: no member named 'tr1' in namespace 'std' using std::tr1::unordered_map; ~^ In file included from src/mongo/shell/dbshell.cpp:26: In file included from src/mongo/base/initializer.h:24: In file included from src/mongo/base/initializer_dependency_graph.h:26: src/mongo/platform/unordered_set.h:51:16: error: no member named 'tr1' in namespace 'std' using std::tr1::unordered_set; ~^ 2 errors generated. scons: *** [build/freebsd/cc_cc/cxx_c++/ssl/use-system-pcre/use-system-snappy/use-system-v8/usev8/mongo/shell/dbshell.o] Error 1 scons: building terminated because of errors. *** Error code 2 Stop. make[1]: stopped in /usr/ports/databases/mongodb *** Error code 1 Stop. make: stopped in /usr/ports/databases/mongodb Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
r253351 implicit definition of 'critical_exit'.
Hi Recent change: - # svn log ./sys/sys/sf_buf.h |less r253351 | ae | 2013-07-15 08:16:57 +0200 (Mon, 15 Jul 2013) | 6 lines Introduce new structure sfstat for collecting sendfile's statistics and remove corresponding fields from struct mbstat. Use PCPU counters and SFSTAT_INC() macro for update these statistics. - Includes sys/counter.h in sys/sf_buf.h. sys/counter.h uses macros defined in sys/systm.h resulting in implicit definitions of critical_exit and others and then errors in conflicting types for critical_exit later when sys/system.h is includd _after_ sys/sf_buf.h in sys/i386/i386/uio_machdep.c. I haven't checked amd64 yet, but this patch fixes the build: Index: /usr/src/sys/i386/i386/uio_machdep.c === --- /usr/src/sys/i386/i386/uio_machdep.c(revision 253361) +++ /usr/src/sys/i386/i386/uio_machdep.c(working copy) @@ -44,8 +44,8 @@ #include sys/mutex.h #include sys/proc.h #include sys/sched.h +#include sys/systm.h #include sys/sf_buf.h -#include sys/systm.h #include sys/uio.h #include vm/vm.h However, sys/system.h coul equally be included in sys/sf_buf.h before sys/counter.h. I don't know which is the correct fix. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ports with daemons on uninstall...
Walter Hurry wrote: On Mon, 15 Jul 2013 08:34:05 -0500, Mark Felder wrote: As long as this behavior only happens during pkg installs and never with ports, I'm OK. The worst is when a coworker forgets that the mysql port stops the daemon and my coworker upgrades with portmaster... the daemon is off the entire time mysql slowly compiles... I'm not familiar with portmaster, since I use portupgrade. That does the build first, then the deinstall old/install new. Seems a sensible approach anyway, in case the build fails. Doesn't portmaster work similarly? Try doing a 'portupgrade -f isc-dhcp41-server' and watch it leave dhcpd not running. I eventually made the following change so that it wouldn't leave my system in a broken state: /usr/ports/net/isc-dhcp41-server # make clean === Cleaning for isc-dhcp41-server-4.1.e_7,2 [fw2.smmt] /usr/ports/net/isc-dhcp41-server # svn diff Index: pkg-plist === --- pkg-plist (revision 323024) +++ pkg-plist (working copy) @@ -1,6 +1,4 @@ @comment $FreeBSD$ -@unexec %D/etc/rc.d/isc-dhcpd forcestop 2/dev/null || true -%%IPV6%%@unexec %D/etc/rc.d/isc-dhcpd6 forcestop 2/dev/null || true @unexec if cmp -s %D/etc/dhcpd.conf.sample %D/etc/dhcpd.conf; then rm -f %D/etc/dhcpd.conf; fi etc/dhcpd.conf.sample @exec if [ ! -f %D/etc/dhcpd.conf ] ; then cp -p %D/%F %B/dhcpd.conf; fi I don't mind it stopping the daemon, but if it's going to automatically stop it, it should automatically start it too. It's also not consistent - random sample of two: exim and quagga just leave the daemon running. I'm just asking if there's a stated project guideline for what should happen because at the moment it's hard to know what to expect. Maybe its as simple as an install exec that does a 'service foo start'. If it's a first install it will fail because foo_enable=yes won't be set in /etc/rc.conf. Personally, I'd rather that the package management system ports,pkg,etc doesn't take liberties with my running daemons. If I want to kill them off, I'll kill them off, but there have been several times where I've left uninstalled things running while the system was in flux during an upgrade. It was nice to be able to do that. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Ports with daemons on uninstall...
Hi I have to ask if there's a standard for the way ports should handle their daemons when the port is uninstalled. I've encountered 3 varients of ports behaviour on uninstall: 1. Do nothing 2. Stop the daemon 3. Ask if the daemon should be stopped #1 closely followed by #3 are the least irritating when it comes to portupgrade because you can at least have the service running while upgrading. At least with #3 the upgrade gets paused until the propmpt is answered and you're then aware that some service will go away immediately so you can be prepared to restart it. #2 is extremely irritating because upgrading with portupgrade etc kills the service. For instance isc-dhcpd* does this which means that for some time, dhcp may be unavailable. It could be less irritating if it would automatically start the service, but that can have its own problems. Does the project have a preferred method for handling running daenmons on uninstall? I know that Linux will even start daemons on install. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Filesystem wedges caused by r251446
Konstantin Belousov wrote: On Fri, Jul 12, 2013 at 11:34:18PM +0200, Ian FREISLICH wrote: (kgdb) print runningbufreq $1 = 1 (kgdb) print runningbufspace $2 = 0 (kgdb) print lorunningspace $3 = 4587520 (kgdb) print hirunningspace $4 = 4194304 This is extremely weird. The hirunningspace is less then lorunningspace, am I right ? This causes the runningbufspace machinery to never wake up Yes. This state of affairs doesn't happen on r251445 and further testing on my side shows it doesn't hapen on all my amd64 servers. It appears that this particular server type (Dell R200) running amd64 with geom_mirror is affected. I will have to test further by destroying the mirror and removing it from the kernel and see if I can still reproduce the issue. Perhaps r251446 exposes insufficient locking on opperations affecting these variables. FWIW, I cannot reproduce the problem if the mirror is rebuilding. I just verified on the 4G VM on amd64, my numbers for lo is 4587520, for high 6881280. Verify your tuning and kernel options, which you should have provided with the original report, I think. Sorry about that (and I'm relieved:) I had originally compiled with CPUTYPE?=opteron which is incorrect for this CPU. However the problem persists with CPUTYPE?=core2, but I'm not sure how much of a difference this makes with clang. Also, I have another affected host that's compiled with gcc and the correct CPUTYPE so I doubt it's the compiler. I've attached make.conf, kernelconfig and dmesg.boot. You'll notice it's r251446M - which is a result of your patch. Ian -- Ian Freislich cpu HAMMER ident FIREWALL options SCHED_ULE options INET#InterNETworking options FFS #Berkeley Fast Filesystem options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options SOFTUPDATES #Enable FFS soft updates support options PSEUDOFS#Pseudo-filesystem framework options PROCFS options GEOM_PART_GPT options GEOM_LABEL options GEOM_MIRROR options GEOM_GATE # Userland services. options COMPAT_43 options COMPAT_43TTY# BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD32 options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options COMPAT_FREEBSD5 #Compatible with FreeBSD4 options COMPAT_FREEBSD6 #Compatible with FreeBSD4 options COMPAT_FREEBSD7 #Compatible with FreeBSD4 options COMPAT_LINUX32 options LINPROCFS options LINSYSFS options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options CONSPEED=115200 options PRINTF_BUFR_SIZE=128 device pf device pflog device pfsync options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. options KDB_TRACE options KDB_UNATTENDED options ALT_BREAK_TO_DEBUGGER options DEBUG_LOCKS options DEBUG_VFS_LOCKS options DIAGNOSTIC makeoptions DEBUG=-g # To make an SMP kernel, the next two are needed options SMP # Symmetric MultiProcessor Kernel device cpufreq device acpi device pci device smb device smbus device ichsmb # ATA controllers device mfi device scbus # SCSI bus (required for ATA/SCSI) device ahci# AHCI-compatible SATA controllers device ata device ada # Direct Access (disks) device da # Direct Access (disks) device cd # CD device pass# Passthrough device (direct ATA/SCSI access) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device kbdmux device psm # PS/2 mouse device vga # VGA video card driver device sc device agp # support several AGP chipsets # Serial (COM) ports device uart device
Re: Filesystem wedges caused by r251446
Konstantin Belousov wrote: Yes. This state of affairs doesn't happen on r251445 and further testing on my side shows it doesn't hapen on all my amd64 servers. It appears that this particular server type (Dell R200) running amd64 with geom_mirror is affected. I will have to test further by destroying the mirror and removing it from the kernel and see if I can still reproduce the issue. Perhaps r251446 exposes insufficient locking on opperations affecting these variables. No. The lorunningspace is constant for the system lifetime. It can only be changed by the sysctl vfs.lorunningspace. Look into /etc/sysctl.conf or scripts which apply sysctl settings. Wipes egg from face. /etc/sysctl.conf: vfs.hirunningspace=4194304 So, then did r251446 actually start using this value or did other values get significantly tuned up? I recall now setting this nearly a year ago when we did our ZFS tuning and it was a four fold increase on the defaults. Sorry for the noise. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Filesystem wedges caused by r251446
Konstantin Belousov wrote: So, then did r251446 actually start using this value or did other values get significantly tuned up? I recall now setting this nearly a year ago when we did our ZFS tuning and it was a four fold increase on the defaults. r251446 optimized the wakeups by only doing wakeups when runningbufspace actually crossed the lorunningspace. Before, wakeups were performed always on the runningbufspace changes. For ZFS, these settings are completely irrelevant, ZFS does not use buffer cache. A year is so long ago... It might have been tuning for our postgres servers. It might be worth while putting in a sanity check that doesn't allow hirunningspace to be set lower than lorunningspace. Thanks for your patience. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Filesystem wedges caused by r251446
John Baldwin wrote: On Thursday, July 11, 2013 6:54:35 am Ian FREISLICH wrote: John Baldwin wrote: On Thursday, July 04, 2013 5:03:29 am Ian FREISLICH wrote: Konstantin Belousov wrote: Care to provide any useful information ? http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers- handbook/kerneldebug-deadlocks.html Well, the system doesn't deadlock it's perfectly useable so long as you don't touch the file that's wedged. A lot of the time the userland process is unkillable, but often it is killable. How do I get from from the PID to where the FS is stuck in the kernel? Use kgdb. 'proc pid', then 'bt'. So, I setup a remote kbgd session, but I still can't figure out how to get at the information we need. (kgdb) proc 5176 only supported for core file target In the mean time, I'll just force it to make a core dump from ddb. However, I can't reacreate the issue while the mirror (gmirror) is rebuilding, so we'll have to wait for that to finish. Sorrry, just run 'sudo kgdb' on the box itself. You can inspect the running kernel without having to stop it. So, this machine's installworld *always* stalls installing clang. The install can be stopped (ctrl-c) leaving behind this process: root23147 0.0 0.0 9268 1512 1 D 7:51PM 0:00.01 install -s -o root -g wheel -m 555 clang /usr/bin/clang This is the backtrace from gdb. I suspect frame 4. (kgdb) proc 23147 [Switching to thread 117 (Thread 100059)]#0 sched_switch ( td=0xfe000c012920, newtd=0x0, flags=value optimized out) at /usr/src/sys/kern/sched_ule.c:1954 1954cpuid = PCPU_GET(cpuid); Current language: auto; currently minimal (kgdb) bt #0 sched_switch (td=0xfe000c012920, newtd=0x0, flags=value optimized out) at /usr/src/sys/kern/sched_ule.c:1954 #1 0x8047539e in mi_switch (flags=260, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:487 #2 0x804acbea in sleepq_wait (wchan=0x0, pri=0) at /usr/src/sys/kern/subr_sleepqueue.c:620 #3 0x80474ee9 in _sleep (ident=value optimized out, lock=0x80a20300, priority=84, wmesg=0x8071129a wdrain, sbt=value optimized out, pr=0, flags=value optimized out) at /usr/src/sys/kern/kern_synch.c:249 #4 0x804e6523 in waitrunningbufspace () at /usr/src/sys/kern/vfs_bio.c:564 #5 0x804e6073 in bufwrite (bp=value optimized out) at /usr/src/sys/kern/vfs_bio.c:1226 #6 0x804f05ed in cluster_wbuild (vp=0xfe008fec4000, size=32768, start_lbn=136, len=value optimized out, gbflags=value optimized out) at /usr/src/sys/kern/vfs_cluster.c:1002 #7 0x804efbc3 in cluster_write (vp=0xfe008fec4000, bp=0xff80f83da6f0, filesize=4456448, seqcount=127, gbflags=value optimized out) at /usr/src/sys/kern/vfs_cluster.c:592 #8 0x805c1032 in ffs_write (ap=0xff8121c81850) at /usr/src/sys/ufs/ffs/ffs_vnops.c:801 #9 0x8067fe21 in VOP_WRITE_APV (vop=value optimized out, ---Type return to continue, or q return to quit--- a=value optimized out) at vnode_if.c:999 #10 0x80511eca in vn_write (fp=0xfe006a5f7410, uio=0xff8121c81a90, active_cred=0x0, flags=value optimized out, td=0x0) at vnode_if.h:413 #11 0x8050eb3a in vn_io_fault (fp=0xfe006a5f7410, uio=0xff8121c81a90, active_cred=0xfe006a6ca000, flags=0, td=0xfe000c012920) at /usr/src/sys/kern/vfs_vnops.c:983 #12 0x804b506a in dofilewrite (td=0xfe000c012920, fd=5, fp=0xfe006a5f7410, auio=0xff8121c81a90, offset=value optimized out, flags=0) at file.h:290 #13 0x804b4cde in sys_write (td=0xfe000c012920, uap=value optimized out) at /usr/src/sys/kern/sys_generic.c:460 #14 0x8061807a in amd64_syscall (td=0xfe000c012920, traced=0) at subr_syscall.c:134 #15 0x806017ab in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #16 0x0044e75a in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Any other process attempting to for instance stat /usr/bin/clang also gets stuck: root23198 0.0 0.0 8056 1780 1 D+7:58PM 0:00.00 stat /usr/bin/clang #0 sched_switch (td=0x80a67b20, newtd=0x0, flags=value optimized out) at /usr/src/sys/kern/sched_ule.c:1954 1954cpuid = PCPU_GET(cpuid); (kgdb) proc 23198 [Switching to thread 107 (Thread 100131)]#0 sched_switch ( td=0xfe000ce9a000, newtd=0x0, flags=value optimized out) at /usr/src/sys/kern/sched_ule.c:1954 1954cpuid = PCPU_GET(cpuid); Current language: auto; currently minimal (kgdb) bt #0 sched_switch (td=0xfe000ce9a000, newtd=0x0, flags=value optimized out) at /usr/src/sys/kern/sched_ule.c:1954 #1 0x8047539e in mi_switch (flags=260, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:487 #2 0x804acbea
Re: Filesystem wedges caused by r251446
Konstantin Belousov wrote: --rMuTkhzRlt+HYtLC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 12, 2013 at 08:11:36PM +0200, Ian FREISLICH wrote: John Baldwin wrote: On Thursday, July 11, 2013 6:54:35 am Ian FREISLICH wrote: John Baldwin wrote: On Thursday, July 04, 2013 5:03:29 am Ian FREISLICH wrote: Konstantin Belousov wrote: =20 Care to provide any useful information ? =20 http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers- handbook/kerneldebug-deadlocks.html =20 Well, the system doesn't deadlock it's perfectly useable so long as you don't touch the file that's wedged. A lot of the time the userland process is unkillable, but often it is killable. How do I get from from the PID to where the FS is stuck in the kernel? =20 Use kgdb. 'proc pid', then 'bt'. =20 So, I setup a remote kbgd session, but I still can't figure out how to get at the information we need. =20 (kgdb) proc 5176 only supported for core file target =20 In the mean time, I'll just force it to make a core dump from ddb. However, I can't reacreate the issue while the mirror (gmirror) is rebuilding, so we'll have to wait for that to finish. =20 Sorrry, just run 'sudo kgdb' on the box itself. You can inspect the ru= nning kernel without having to stop it. =20 So, this machine's installworld *always* stalls installing clang. The install can be stopped (ctrl-c) leaving behind this process: =20 root23147 0.0 0.0 9268 1512 1 D 7:51PM 0:00.01 install -= s -o root -g wheel -m 555 clang /usr/bin/clang =20 This is the backtrace from gdb. I suspect frame 4. =20 (kgdb) proc 23147 [Switching to thread 117 (Thread 100059)]#0 sched_switch ( td=3D0xfe000c012920, newtd=3D0x0, flags=3Dvalue optimized out) at /usr/src/sys/kern/sched_ule.c:1954 1954cpuid =3D PCPU_GET(cpuid); Current language: auto; currently minimal (kgdb) bt #0 sched_switch (td=3D0xfe000c012920, newtd=3D0x0,=20 flags=3Dvalue optimized out) at /usr/src/sys/kern/sched_ule.c:1954 #1 0x8047539e in mi_switch (flags=3D260, newtd=3D0x0) at /usr/src/sys/kern/kern_synch.c:487 #2 0x804acbea in sleepq_wait (wchan=3D0x0, pri=3D0) at /usr/src/sys/kern/subr_sleepqueue.c:620 #3 0x80474ee9 in _sleep (ident=3Dvalue optimized out,=20 lock=3D0x80a20300, priority=3D84, wmesg=3D0x8071129a = wdrain,=20 sbt=3Dvalue optimized out, pr=3D0, flags=3Dvalue optimized out) at /usr/src/sys/kern/kern_synch.c:249 #4 0x804e6523 in waitrunningbufspace () at /usr/src/sys/kern/vfs_bio.c:564 #5 0x804e6073 in bufwrite (bp=3Dvalue optimized out) at /usr/src/sys/kern/vfs_bio.c:1226 #6 0x804f05ed in cluster_wbuild (vp=3D0xfe008fec4000, size= =3D32768,=20 start_lbn=3D136, len=3Dvalue optimized out, gbflags=3Dvalue optimi= zed out) at /usr/src/sys/kern/vfs_cluster.c:1002 #7 0x804efbc3 in cluster_write (vp=3D0xfe008fec4000,=20 bp=3D0xff80f83da6f0, filesize=3D4456448, seqcount=3D127,=20 gbflags=3Dvalue optimized out) at /usr/src/sys/kern/vfs_cluster.c:5= 92 #8 0x805c1032 in ffs_write (ap=3D0xff8121c81850) at /usr/src/sys/ufs/ffs/ffs_vnops.c:801 #9 0x8067fe21 in VOP_WRITE_APV (vop=3Dvalue optimized out,=20 ---Type return to continue, or q return to quit---=20 a=3Dvalue optimized out) at vnode_if.c:999 #10 0x80511eca in vn_write (fp=3D0xfe006a5f7410,=20 uio=3D0xff8121c81a90, active_cred=3D0x0, flags=3Dvalue optimized= out,=20 td=3D0x0) at vnode_if.h:413 #11 0x8050eb3a in vn_io_fault (fp=3D0xfe006a5f7410,=20 uio=3D0xff8121c81a90, active_cred=3D0xfe006a6ca000, flags=3D0= ,=20 td=3D0xfe000c012920) at /usr/src/sys/kern/vfs_vnops.c:983 #12 0x804b506a in dofilewrite (td=3D0xfe000c012920, fd=3D5,= =20 fp=3D0xfe006a5f7410, auio=3D0xff8121c81a90,=20 offset=3Dvalue optimized out, flags=3D0) at file.h:290 #13 0x804b4cde in sys_write (td=3D0xfe000c012920,=20 uap=3Dvalue optimized out) at /usr/src/sys/kern/sys_generic.c:460 #14 0x8061807a in amd64_syscall (td=3D0xfe000c012920, traced= =3D0) at subr_syscall.c:134 #15 0x806017ab in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #16 0x0044e75a in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb)=20 Please apply (mostly debugging) patch below, then reproduce the issue. I need the backtrace of the 'main' hung process, assuming it is stuck in the waitrunningbufspace(). Also, from the same kgdb session, print runningbufreq, runningbufspace and lorunningspace
Re: Filesystem wedges caused by r251446
John Baldwin wrote: On Thursday, July 04, 2013 5:03:29 am Ian FREISLICH wrote: Konstantin Belousov wrote: Care to provide any useful information ? http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers- handbook/kerneldebug-deadlocks.html Well, the system doesn't deadlock it's perfectly useable so long as you don't touch the file that's wedged. A lot of the time the userland process is unkillable, but often it is killable. How do I get from from the PID to where the FS is stuck in the kernel? Use kgdb. 'proc pid', then 'bt'. So, I setup a remote kbgd session, but I still can't figure out how to get at the information we need. (kgdb) proc 5176 only supported for core file target In the mean time, I'll just force it to make a core dump from ddb. However, I can't reacreate the issue while the mirror (gmirror) is rebuilding, so we'll have to wait for that to finish. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Filesystem wedges caused by r251446
Hi I've been experiencing process wedges writing files. It occurs reliably under heavy IO activity, perhaps with large files but I'm not entirely sure what the trigger is. The symptom is that during an installworld, it reliably hangs the install process on /usr/bin/clang (sometimes it hangs earlier at the mtree on /usr) The problem leaves the filesystem in a state where it cannot be cleanly unmounted. A binary search pins the offending commit on r251446. The major differences between the working system and the broken one are, CPU, RAM and arch (i386/amd64) they are otherwise identical Dell R200 servers. Working: CPU: Intel(R) Core(TM)2 Duo CPU E4600 @ 2.40GHz (2400.14-MHz 686-class CPU) RAM:2G Arch: i386 Broken: CPU: Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz (2666.82-MHz K8-class CPU) RAM:4G Arch: amd64 The compiler, gcc, clang (trunk or release) has no effect. Working CPU: FreeBSD 10.0-CURRENT #6 r252384: Sun Jun 30 08:36:31 SAST 2013 ianf@fw2:/usr/obj/usr/src/sys/FIREWALL i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: Intel(R) Core(TM)2 Duo CPU E4600 @ 2.40GHz (2400.14-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6fd Family = 0x6 Model = 0xf Stepping = 13 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2010NX,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics real memory = 2147483648 (2048 MB) avail memory = 2076581888 (1980 MB) Broken on: FreeBSD 10.0-CURRENT #19 r251445: Thu Jul 4 08:39:21 SAST 2013 ianf@fw1:/usr/obj/usr/src/sys/FIREWALL amd64 FreeBSD clang version 3.3 (trunk 178860) 20130405 CPU: Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz (2666.82-MHz K8-class CPU) Origin = GenuineIntel Id = 0x10676 Family = 0x6 Model = 0x17 Stepping = 6 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x8e39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1 AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3970727936 (3786 MB) Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Filesystem wedges caused by r251446
Konstantin Belousov wrote: Care to provide any useful information ? http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html Well, the system doesn't deadlock it's perfectly useable so long as you don't touch the file that's wedged. A lot of the time the userland process is unkillable, but often it is killable. How do I get from from the PID to where the FS is stuck in the kernel? Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: network.subr (r252360) changes break ifconfig_aliasX
Hiroki Sato wrote: ia I can't figure out how to use rc.conf to configure my interfaces ia after these recent charges. My use case is that I have interfaces ia to configure but I don't need to put an IP address on them. I do ia need to change the MAC address though. Please try r252426. Thanks. That fixes it. BTW, nice new features in network.subr. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
network.subr (r252360) changes break ifconfig_aliasX
Hi I can't figure out how to use rc.conf to configure my interfaces after these recent charges. My use case is that I have interfaces to configure but I don't need to put an IP address on them. I do need to change the MAC address though. What I have been doing is probably wrong, but it worked up until r252360: lagg0: link state changed to DOWN /etc/rc: WARNING: $ifconfig_lagg0_alias0 needs inet keyword for an IPv4 address. ifconfig: ether: bad value But, there is no ip address for this interface. The config looks like: cloned_interfaces=lagg0 \ vlan2 vlan3 vlan4 vlan5 vlan6 vlan7 vlan8 vlan9 vlan14 vlan15 vlan19 \ vlan20 vlan21 vlan22 vlan23 vlan24 vlan25 vlan26 vlan27 vlan30 \ vlan33 vlan37 vlan39 vlan40 vlan41 vlan44 vlan45 vlan999 \ ifconfig_igb0=up ifconfig_igb1=up ifconfig_igb2=up ifconfig_igb3=up ifconfig_lagg0=up laggproto lacp laggport igb0 laggport igb1 laggport igb2 laggport igb3 ifconfig_lagg0_alias0=ether 00:1e:c9:53:3e:15 # Neotel ifconfig_vlan2=vlandev lagg0 vlan 2 #should probably be create_args ifconfig_vlan2_alias0=inet 41.161.56.4/29 ifconfig_vlan2_alias1=inet 41.154.2.106/29 ifconfig_vlan2_alias2=inet 196.46.25.156/25 ifconfig_vlan2_alias3=inet 41.161.56.2/29 vhid 2 pass XXX advskew 20 ifconfig_vlan2_alias4=inet 41.154.2.105/29 vhid 2 pass XXX advskew 20 ifconfig_vlan2_alias5=inet 196.46.25.155/25 vhid 2 pass XXX advskew 20 etc. I've tried create_args but I still get the following error: ifconfig: ether: bad value and, I cannot use ifconfig_lagg0 to set the MAC address because the rc system just seems to ignore the configured string. I can however 'ifconfig lagg0 ether 00:1e:c9:53:3e:15' from the cammand line, so there's something in the rc scripts that's mangling the argument. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: network.subr (r252360) changes break ifconfig_aliasX
Ian FREISLICH wrote: What I have been doing is probably wrong, but it worked up until r252360: I see from the commit log that it was actually 252015 that broke my router. -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: usb ACM device doesn't work
Hans Petter Selasky wrote: On 06/22/13 20:54, Ian FREISLICH wrote: Daniel O'Connor wrote: On 22/06/2013, at 4:10, Ian FREISLICH i...@clue.co.za wrote: I bought a relay control board that has a USB interface. It presents a serial port to Linux on /dev/ttyACMx. However when I plug it into my FreeBSD host, it detects as follows: ugen0.2: KMT at usbus0 umodem0: KMT USB CDC COM, class 2/0, rev 1.10/1.00, addr 1 on usbus0 umodem0: data interface 1, has no CM over data, has no break and I cannot communicate with it. Any ideas how to communicate with it? Have you tried anything? It should create /dev/cuaUx and /dev/ttyUx (where x is 0 in your case) I'w sorry, I should have been more specific. I have a device that controls a bunch of relays with commands issued to it over a serial port. This serial port is CDC-ACM on a USB interface. The device uses a PIC microcontroller and PICKIT2 from Microchip Technology Inc (vendorID 0x04d8). Linux correctly detects the device with CM over data and I'm able to communicate with it on /dev/ttyACM0 and the TX/RX LEDs on the device blink when transferring data. FreeBSD on the other hand detects it as having no CM over data and while I can open /dev/cuaU0 and write data to it, the RX/TX lights on the device don't blink and reads time out. As previously stated I cannot communicate with it. I tried adding the quirk UQ_ASSUME_CM_OVER_DATA, but then the terminal program locks up and won't exit until I pull the USB cable. The same happens when I force the CM over Data capability in the umodem driverwhen attaching the device, so there's some issue with our CDC/ACM support or Linux is working harder to make non-compliant usb hardware work. Also, our usbdevs is incorrect in listing vedor 0x04d8 as I-Tuner Networks. It is in fact licensed to Microchip Tochnology Inc. which then sub-licenses productIDs royalty free to third parties providing certain conditions are met. See: http://ww1.microchip.com/downloads/en/DeviceDoc/APPLICATION%20FOR%20SUBLICE NSE%20TO%20USB%20VID%20revised%2012110.pdf I don't have the knowledge to fix the FreeBSD USD driver and for the $45 it cost me it's not worth the effort to reinstall the host I'm using with linux. If there's no fix forthcoming I'll just get the EIA-485 version of the device with no hard feelings. Ian Hi Ian, Have you tried using usbdump to capture the USB traffic? It might be something like clear-stall which fails, and make the device broken: usbdump -i usbusX -f Y -vvv -s 65536 I can't see anything obvious. As I plug the device in: 10:23:59.519700 usbus0.2 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 80 06 00 01 00 00 08 00 -- -- -- -- -- -- -- -- || frame[1] READ 8 bytes flags 0x10 PROXY_BUFFER|0 status 0xca1a3 OPEN|TRANSFERRING|STARTED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0 10:23:59.521660 usbus0.2 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 8 bytes 12 01 10 01 02 00 00 08 -- -- -- -- -- -- -- -- || flags 0x10 PROXY_BUFFER|0 status 0xca1a1 OPEN|STARTED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0 10:23:59.521694 usbus0.2 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 80 06 00 01 00 00 12 00 -- -- -- -- -- -- -- -- || frame[1] READ 18 bytes flags 0x10 PROXY_BUFFER|0 status 0xea1a3 OPEN|TRANSFERRING|STARTED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOING_CALLBACK|0 10:23:59.522736 usbus0.2 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=20,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 18 bytes 12 01 10 01 02 00 00 08 D8 04 F9 FE 00 01 01 02 || 0010 00 01 -- -- -- -- -- -- -- -- -- -- -- -- -- -- |.. | flags 0x10 PROXY_BUFFER|0 status 0xea1a1 OPEN|STARTED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOING_CALLBACK|0 10:23:59.522769 usbus0.2 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 80 06 00 03 00 00 02 00 -- -- -- -- -- -- -- -- || frame[1] READ 2 bytes flags 0x10 PROXY_BUFFER|0 status 0xca1a3 OPEN|TRANSFERRING|STARTED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0 10:23:59.523344 usbus0.2 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 2 bytes 04 03 -- -- -- -- -- -- -- -- -- -- -- -- -- -- |.. | flags 0x10 PROXY_BUFFER|0 status 0xca1a1 OPEN|STARTED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0 10:23:59.523371 usbus0.2 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 80 06 00 03 00 00 04 00
Re: usb ACM device doesn't work
Hans Petter Selasky wrote: On 06/23/13 10:33, Ian FREISLICH wrote: status 0xea1a1 OPEN|STARTED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SET UP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOING_CALLBACK|0 10:29:19.904434 usbus0.2 SUBM-BULK-EP=0002,SPD=FULL,NFR=1,SLEN=4,IVAL=0 frame[0] WRITE 1 bytes 6F -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- |o | flags 0x9 FORCE_SHORT_XFER|PIPE_BOF|0 status 0x4a023 OPEN|TRANSFERRING|STARTED|BDMA_ENABLE|BDMA_SETUP|CAN_CANC EL_IMMED|0 If you don't get a DONE-BULK-EP=0002, then the device does not receive the data. It is blocking the write. Did you set the correct baud rate? I did. It's 9600. Also, what does usbconfig -d X.Y dump_device_desc dump_curr_config_desc say ? [zen] ~ # usbconfig -d ugen0.2 dump_device_desc ugen0.2: USB CDC COM KMT at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (0mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x0002 bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0008 idVendor = 0x04d8 idProduct = 0xfef9 bcdDevice = 0x0100 iManufacturer = 0x0001 KMT iProduct = 0x0002 USB CDC COM iSerialNumber = 0x no string bNumConfigurations = 0x0001 [zen] ~ # usbconfig -d ugen0.2 dump_curr_config_desc ugen0.2: USB CDC COM KMT at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (0mA) Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0043 bNumInterfaces = 0x0002 bConfigurationValue = 0x0001 iConfiguration = 0x no string bmAttributes = 0x00c0 bMaxPower = 0x Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0001 bInterfaceClass = 0x0002 bInterfaceSubClass = 0x0002 bInterfaceProtocol = 0x0001 iInterface = 0x no string Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x00 RAW dump: 0x00 | 0x05, 0x24, 0x00, 0x10, 0x01 Additional Descriptor bLength = 0x04 bDescriptorType = 0x24 bDescriptorSubType = 0x02 RAW dump: 0x00 | 0x04, 0x24, 0x02, 0x02 Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x06 RAW dump: 0x00 | 0x05, 0x24, 0x06, 0x00, 0x01 Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x01 RAW dump: 0x00 | 0x05, 0x24, 0x01, 0x00, 0x01 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 IN bmAttributes = 0x0003 INTERRUPT wMaxPacketSize = 0x0008 bInterval = 0x00fa bRefresh = 0x bSynchAddress = 0x Interface 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0001 bAlternateSetting = 0x bNumEndpoints = 0x0002 bInterfaceClass = 0x000a bInterfaceSubClass = 0x bInterfaceProtocol = 0x iInterface = 0x no string Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0002 OUT bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0040 bInterval = 0x0001 bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0082 IN bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0040 bInterval = 0x0001 bRefresh = 0x bSynchAddress = 0x -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: usb ACM device doesn't work
Daniel O'Connor wrote: On 22/06/2013, at 4:10, Ian FREISLICH i...@clue.co.za wrote: I bought a relay control board that has a USB interface. It presents a serial port to Linux on /dev/ttyACMx. However when I plug it into my FreeBSD host, it detects as follows: ugen0.2: KMT at usbus0 umodem0: KMT USB CDC COM, class 2/0, rev 1.10/1.00, addr 1 on usbus0 umodem0: data interface 1, has no CM over data, has no break and I cannot communicate with it. Any ideas how to communicate with it? Have you tried anything? It should create /dev/cuaUx and /dev/ttyUx (where x is 0 in your case) I'w sorry, I should have been more specific. I have a device that controls a bunch of relays with commands issued to it over a serial port. This serial port is CDC-ACM on a USB interface. The device uses a PIC microcontroller and PICKIT2 from Microchip Technology Inc (vendorID 0x04d8). Linux correctly detects the device with CM over data and I'm able to communicate with it on /dev/ttyACM0 and the TX/RX LEDs on the device blink when transferring data. FreeBSD on the other hand detects it as having no CM over data and while I can open /dev/cuaU0 and write data to it, the RX/TX lights on the device don't blink and reads time out. As previously stated I cannot communicate with it. I tried adding the quirk UQ_ASSUME_CM_OVER_DATA, but then the terminal program locks up and won't exit until I pull the USB cable. The same happens when I force the CM over Data capability in the umodem driverwhen attaching the device, so there's some issue with our CDC/ACM support or Linux is working harder to make non-compliant usb hardware work. Also, our usbdevs is incorrect in listing vedor 0x04d8 as I-Tuner Networks. It is in fact licensed to Microchip Tochnology Inc. which then sub-licenses productIDs royalty free to third parties providing certain conditions are met. See: http://ww1.microchip.com/downloads/en/DeviceDoc/APPLICATION%20FOR%20SUBLICENSE%20TO%20USB%20VID%20revised%2012110.pdf I don't have the knowledge to fix the FreeBSD USD driver and for the $45 it cost me it's not worth the effort to reinstall the host I'm using with linux. If there's no fix forthcoming I'll just get the EIA-485 version of the device with no hard feelings. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
usb ACM device doesn't work
Hi I bought a relay control board that has a USB interface. It presents a serial port to Linux on /dev/ttyACMx. However when I plug it into my FreeBSD host, it detects as follows: ugen0.2: KMT at usbus0 umodem0: KMT USB CDC COM, class 2/0, rev 1.10/1.00, addr 1 on usbus0 umodem0: data interface 1, has no CM over data, has no break and I cannot communicate with it. Any ideas how to communicate with it? This is the output of 'usbconfig -d ugen0.2 dump_curr_config_desc': ugen0.2: USB CDC COM KMT at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (0mA) Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0043 bNumInterfaces = 0x0002 bConfigurationValue = 0x0001 iConfiguration = 0x no string bmAttributes = 0x00c0 bMaxPower = 0x Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0001 bInterfaceClass = 0x0002 bInterfaceSubClass = 0x0002 bInterfaceProtocol = 0x0001 iInterface = 0x no string Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x00 RAW dump: 0x00 | 0x05, 0x24, 0x00, 0x10, 0x01 Additional Descriptor bLength = 0x04 bDescriptorType = 0x24 bDescriptorSubType = 0x02 RAW dump: 0x00 | 0x04, 0x24, 0x02, 0x02 Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x06 RAW dump: 0x00 | 0x05, 0x24, 0x06, 0x00, 0x01 Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x01 RAW dump: 0x00 | 0x05, 0x24, 0x01, 0x00, 0x01 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 IN bmAttributes = 0x0003 INTERRUPT wMaxPacketSize = 0x0008 bInterval = 0x00fa bRefresh = 0x bSynchAddress = 0x Interface 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0001 bAlternateSetting = 0x bNumEndpoints = 0x0002 bInterfaceClass = 0x000a bInterfaceSubClass = 0x bInterfaceProtocol = 0x iInterface = 0x no string Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0002 OUT bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0040 bInterval = 0x0001 bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0082 IN bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0040 bInterval = 0x0001 bRefresh = 0x bSynchAddress = 0x Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Panic in tcp_input
0x80420814 in fork_exit ( callout=0x804236c0 ithread_loop, arg=0xfe002e0431a0, frame=0xff846b258c00) at /usr/src/sys/kern/kern_fork.c:991 #25 0x805f5d7e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:602 #26 0x in ?? () Current language: auto; currently minimal (kgdb) -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic in tcp_input
Andre Oppermann wrote: On 19.06.2013 11:10, Ian FREISLICH wrote: Hi I'm seeing this panic quite regularly now. Most recent sighting on r251858. This panic message is not very informative and very hard to extract any meaningful hints. Do you have a core dump and matching debug kernel? I do. If you can send me your public ssh key in private email, I can give you access to the server in question. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic in tcp_input
Gleb Smirnoff wrote: A This seems to be a fallout of the recent UMA changes and its interaction A with the per-cpu counter(9) system. A A Adding in and handing over to Gleb and Jeff as they touched this area last . Ian has reported this panic several days before Jeff's changes :( Do you want me to try to find the revision of origin? I have a verified sighting at r251615 and I'm pretty sure I've seen it earlier than that. Subjectively, it seems to have got a lot worse lately. Maybe the recent UMA changes have exposed some latent issue? Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Recurring panic
Hi
I have the following recurring panic on all my heavily network
loaded -CURRENT routers. The current process is always different.
Gleb, can you please chime in with what you've managed to uncover.
Unread portion of the kernel message buffer:
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 21363 (kgdb)
trap number = 12
panic: page fault
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xff846b4de530
panic() at panic+0x13d/frame 0xff846b4de630
trap_fatal() at trap_fatal+0x290/frame 0xff846b4de690
trap_pfault() at trap_pfault+0x21f/frame 0xff846b4de6f0
trap() at trap+0x2b4/frame 0xff846b4de830
calltrap() at calltrap+0x8/frame 0xff846b4de830
--- trap 0xc, rip = 0x8044872d, rsp = 0xff846b4de8f0, rbp =
0xff846b4de910 ---
__mtx_lock_sleep() at __mtx_lock_sleep+0x5d/frame 0xff846b4de910
selfdfree() at selfdfree+0xef/frame 0xff846b4de930
sys_poll() at sys_poll+0x332/frame 0xff846b4dead0
amd64_syscall() at amd64_syscall+0x572/frame 0xff846b4debf0
Xfast_syscall() at Xfast_syscall+0xf7/frame 0xff846b4debf0
--- syscall (209, FreeBSD ELF64, sys_poll), rip = 0x80160670a, rsp =
0x7fffcc68, rbp = 0 ---
Uptime: 3d5h49m17s
Dumping 2580 out of 16368 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
#0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:264
264 if (textdump textdump_pending) {
(kgdb) #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:264
#1 0x8045a424 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:447
#2 0x8045a927 in panic (fmt=value optimized out)
at /usr/src/sys/kern/kern_shutdown.c:754
#3 0x8061e950 in trap_fatal (frame=0xc, eva=value optimized out)
at /usr/src/sys/amd64/amd64/trap.c:872
#4 0x8061ecbf in trap_pfault (frame=0xff846b4de840, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:789
#5 0x8061f074 in trap (frame=0xff846b4de840)
at /usr/src/sys/amd64/amd64/trap.c:463
#6 0x806088ef in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:228
#7 0x8044872d in __mtx_lock_sleep (c=0xff8006e551e8,
tid=18446741875506397184, opts=value optimized out,
file=value optimized out, line=0) at /usr/src/sys/kern/kern_mutex.c:425
#8 0x804a574f in selfdfree (stp=value optimized out,
sfp=0xfe02bbf92690) at /usr/src/sys/kern/sys_generic.c:1524
#9 0x804a6e82 in sys_poll (td=0xfe0030e1c000,
uap=0xff846b4deb70) at /usr/src/sys/kern/sys_generic.c:1369
#10 0x8061e2b2 in amd64_syscall (td=0xfe0030e1c000, traced=0)
at subr_syscall.c:134
#11 0x80608bd7 in Xfast_syscall ()
at /usr/src/sys/amd64/amd64/exception.S:387
#12 0x00080160670a in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic: pfsync_insert_state: st-sync_state == PFSYNC_S_NONE
=0x80427330 ithread_loop, arg=0xfe003088f0e0, frame=0xff846b3c3c00) at /usr/src/sys/kern/kern_fork.c:991 #23 0x805ff39e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:602 #24 0x in ?? () Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: in_pcblookup_local (?)
Peter Wemm wrote: offending revision. I've started a binary search. I'll let you know what that turns up. Thanks, and sorry for getting my Ian's mixed up. :-/ -- John Baldwin There's been two separate machines, at least twice each on this exact panic / trace. Always with doing a 'svn update'. Rolling back to April 5th 249172 solves it. (There's nothing particular about that rev, except it was top-of-tree when the last update was done). I see a number locking changes in the area. Note that this is UDP, most likely a dns lookup. I'll work to confirm this here. I was a little slow in bisecting because I spent 2 days trying to figure out what revision caused PF to rapidly expire its entire state table which prevented testing this condition. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
LOR: two vfs_bio.c:3070, ufs_dirhash.c:284 and vfs_mount.c:851, vfs_subr.c:2167
Hi I'm getting these two LORs at boot time, they don't seem to be known on http://ipv4.sources.zabbadoz.net/freebsd/lor.html lock order reversal: 1st 0xff83e37ee938 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3070 2nd 0xfe0030283800 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xff846b756410 _witness_debugger() at _witness_debugger+0x65/frame 0xff846b756430 witness_checkorder() at witness_checkorder+0x857/frame 0xff846b7564e0 _sx_xlock() at _sx_xlock+0x6e/frame 0xff846b756510 ufsdirhash_acquire() at ufsdirhash_acquire+0x33/frame 0xff846b756530 ufsdirhash_add() at ufsdirhash_add+0x19/frame 0xff846b756560 ufs_direnter() at ufs_direnter+0x976/frame 0xff846b756630 ufs_makeinode() at ufs_makeinode+0x296/frame 0xff846b7567f0 VOP_CREATE_APV() at VOP_CREATE_APV+0x8c/frame 0xff846b756820 vn_open_cred() at vn_open_cred+0x2da/frame 0xff846b756970 kern_openat() at kern_openat+0x1de/frame 0xff846b756ad0 amd64_syscall() at amd64_syscall+0x26c/frame 0xff846b756bf0 Xfast_syscall() at Xfast_syscall+0xf7/frame 0xff846b756bf0 --- syscall (5, FreeBSD ELF64, sys_open), rip = 0x800b6f99a, rsp = 0x7fffd84 lock order reversal: 1st 0xfe003082f068 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:851 2nd 0xfe032a133240 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2167 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xff846b408410 _witness_debugger() at _witness_debugger+0x65/frame 0xff846b408430 witness_checkorder() at witness_checkorder+0x857/frame 0xff846b4084e0 __lockmgr_args() at __lockmgr_args+0xda4/frame 0xff846b4085b0 vop_stdlock() at vop_stdlock+0x39/frame 0xff846b4085d0 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x97/frame 0xff846b408600 _vn_lock() at _vn_lock+0x5e/frame 0xff846b408680 vget() at vget+0x63/frame 0xff846b4086d0 devfs_allocv() at devfs_allocv+0x13c/frame 0xff846b408730 devfs_root() at devfs_root+0x4d/frame 0xff846b408770 vfs_donmount() at vfs_donmount+0xa55/frame 0xff846b408a90 sys_nmount() at sys_nmount+0x6d/frame 0xff846b408ad0 amd64_syscall() at amd64_syscall+0x26c/frame 0xff846b408bf0 Xfast_syscall() at Xfast_syscall+0xf7/frame 0xff846b408bf0 --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800a96daa, rsp = 0x7fffccc8, rbp = 0x7fffcce0 --- Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: in_pcblookup_local (?)
John Baldwin wrote: On Thursday, May 02, 2013 7:25:08 am Robert N. M. Watson wrote: On 2 May 2013, at 11:42, Glen Barber wrote: Hmm. Perhaps it would be worthwhile for me to rebuild the current kernel with DDB support. It looks like the machine has panicked a few times over the last two weeks or so, but based on the timestamps of the crash dumps and nagios complaints, happened during the middle of the night when I would not have really noticed, or otherwise would have just blamed my ISP. Two of the panics are ath(4) related. One looks similar to the one referenced in this thread, similarly triggered by a CFEngine process. In that case, the backtrace looks like: #4 0x808cdbb3 at calltrap+0x8 #5 0x807371d8 at in_pcb_lport+0x128 #6 0x8073745a at in_pcbbind_setup+0x16a #7 0x80737d8e at in_pcbconnect_setup+0x71e #8 0x80737df9 at in_pcbconnect_mbuf+0x59 #9 0x807bf29f at udp_connect+0x11f #10 0x80680615 at kern_connectat+0x275 Regarding DDB though, it would be rather difficult to access the machine if it drops to a DDB debugger session, since the machine acts as my firewall. Thanks -- will take a look at the attached. FWIW, though, I'm worried by the number of panics you are seeing, especiall y given that they involve multiple subsystems, and in particular, John's observation about a potentially corrupted pointer. This makes me wonder whether (a) you are experiencing hardware faults -- it would be worth running some memory/cpu/etc tests and (b) if we might be seeing a software memory corruption bug of some sort. Other users have reported this (Ian Lepore), and Peter Wemm can now reproduce these at will as well, so I think this is a software bug. What might be easiest if we can't figure this out from the crashdump is just to bisect the offending revision. I've started a binary search. I'll let you know what that turns up. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic: in_pcblookup_local (?)
Hi I've been getting the following panic on recent current r249717. Sadly the crashdump is useless. Fatal trap 9: general protection fault while in kernel mode cpuid = 15; apic id = 0f instruction pointer = 0x20:0x80546fbc stack pointer = 0x28:0xff846b60 frame pointer = 0x28:0xff846b6777b0 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 = 4361 (zabbix_agentd) trap number = 9 panic: general protection fault cpuid = 15 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xff846b677410 panic() at panic+0x13d/frame 0xff846b677510 trap_fatal() at trap_fatal+0x290/frame 0xff846b677570 trap() at trap+0xff/frame 0xff846b6776b0 calltrap() at calltrap+0x8/frame 0xff846b6776b0 --- trap 0x9, rip = 0x80546fbc, rsp = 0xff846b60, rbp = 0xff846b6777b0 --- in_pcblookup_local() at in_pcblookup_local+0x5c/frame 0xff846b6777b0 in_pcb_lport() at in_pcb_lport+0x109/frame 0xff846b677820 in_pcbbind_setup() at in_pcbbind_setup+0x16a/frame 0xff846b6778a0 in_pcbconnect_setup() at in_pcbconnect_setup+0x71e/frame 0xff846b677990 in_pcbconnect_mbuf() at in_pcbconnect_mbuf+0x59/frame 0xff846b6779e0 udp_connect() at udp_connect+0x11e/frame 0xff846b677a30 kern_connectat() at kern_connectat+0x1f5/frame 0xff846b677a90 sys_connect() at sys_connect+0x41/frame 0xff846b677ad0 amd64_syscall() at amd64_syscall+0x572/frame 0xff846b677bf0 Xfast_syscall() at Xfast_syscall+0xf7/frame 0xff846b677bf0 --- syscall (98, FreeBSD ELF64, sys_connect), rip = 0x80127104a, rsp = 0x7fff97a8, rbp = 0x8014f68d4 --- Uptime: 20m13s Dumping 1688 out of 16368 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset: Restarting BSP cpu_reset_proxy: Stopped CPU 15 Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ip_output.c:625: warning: cast discards qualifier
Hi /usr/src/sys/netinet/ip_output.c: In function 'ip_output': /usr/src/sys/netinet/ip_output.c:625: warning: cast discards qualifiers from pointer target type /usr/src/sys/netinet/ip_output.c:659: warning: cast discards qualifiers from pointer target type *** [ip_output.o] Error code 1 gw is defined 'const'. @625: error = (*ifp-if_output)(ifp, m, (struct sockaddr *)gw, ro) if_output arg3 needs to be protoyped const or gw needs to not be declared const. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
'service named reload' with non-default system directories.
Hi
I often run named outside of the system default directories so that
amongst other things a mergemaster fumble doesn't break my name
servers. This however breaks rndc because it is not imbued with
the clue of where to find its key.
/etc/rc.d/named does create the key file in the correct place
according to the configured chroot directory. The reload section
just doesn't tell rndc where to find it.
Can I suggest for a minimal change:
--- /usr/src/etc/rc.d/named 2013-04-15 20:17:58.0 +0200
+++ /etc/rc.d/named 2013-04-24 16:16:52.0 +0200
@@ -109,7 +109,7 @@
named_reload()
{
- ${command%/named}/rndc reload
+ ${command%/named}/rndc -k ${named_confdir}/rndc.key reload
}
find_pidfile()
A more invasive change:
The bind9 reference suggests that named loading rndc.key is for
backwards compatibility.
Since the rndc.key feature is only intended to allow the
backward-compatible usage of BIND 8 configuration files, this
feature does not have a high degree of configurability. You
cannot easily change the key name or the size of the secret, so
you should make a rndc.conf with your own key if you wish to
change those things.
So, I 'include path/to/rndc.key;' in named.conf, add a controls
section that uses this named key and I use the following rndc.conf:
---named.conf---
include /etc/namedb/rndc.key;
controls {
inet 127.0.0.1 allow { 127.0.0.1; } keys { rndc-key; };
};
---named.conf---
---rndc.conf---
include /etc/namedb/rndc.key;
options {
default-server localhost;
default-key rndc-key;
};
server localhost {
key rndc-key;
};
---rndc.conf---
And the following version of the above patch:
--- /usr/src/etc/rc.d/named 2013-04-15 20:17:58.0 +0200
+++ /etc/rc.d/named 2013-04-24 16:16:52.0 +0200
@@ -109,7 +109,7 @@
named_reload()
{
- ${command%/named}/rndc reload
+ ${command%/named}/rndc -c ${named_confdir}/rndc.conf reload
}
find_pidfile()
this will allow the rc system to reload and stop named (without a
kill) no matter what the configured chroot is.
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 'service named reload' with non-default system directories.
Sean Bruno wrote:
Would we need a change to /etc/defaults/rc.conf to set ${named_confdir}
to the default location if not set?
I'm not sure. It's derived:
load_rc_config $name
# Updating the following variables requires that rc.conf be loaded first
#
required_dirs=$named_chrootdir# if it is set, it must exist
named_confdir=${named_chrootdir}${named_conf%/*}
I don't think that I did a particularly good job of making it work
for all instances. It's more of an opening move to get this working
properly wherever the admin chooses to put the named chroot. I'm
still expecting comments from Doug Barton.
Also, there already appears to be a ${named_conf} that points to
whatever named.conf specified (defaults to /etc/namedb/named.conf). Is
this complementary to what you're poking at?
This is specifically rndc (not named) that fails to find its key
or config if you choose to use a chrootdir that isn't the default.
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
amd64 buildworld lib32 flags fail
Hi I have some amd64 systems that fail cleaning up lib32 and some that don't. I have to chflags noschg these files before starting a buildworld. I can't figure out what the difference is between the systems that work and those that don't. -- Rebuilding the temporary build tree -- rm -rf /usr/obj/usr/src/tmp rm -rf /usr/obj/usr/src/lib32 rm: /usr/obj/usr/src/lib32/usr/lib32/libc.so.7: Operation not permitted rm: /usr/obj/usr/src/lib32/usr/lib32/libcrypt.so.5: Operation not permitted rm: /usr/obj/usr/src/lib32/usr/lib32/libthr.so.3: Operation not permitted rm: /usr/obj/usr/src/lib32/usr/lib32/librt.so.1: Operation not permitted rm: /usr/obj/usr/src/lib32/usr/lib32: Directory not empty rm: /usr/obj/usr/src/lib32/usr: Directory not empty rm: /usr/obj/usr/src/lib32: Directory not empty *** [_worldtmp] Error code 1 Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: amd64 buildworld lib32 flags fail
Konstantin Belousov wrote: rm: /usr/obj/usr/src/lib32: Directory not empty *** [_worldtmp] Error code 1 =20 Maybe you buildworld is jailed? This is the usual consequence of the install -S usage, e.g. by setting INSTALL=install -CS in the make.conf. Ah, thanks. That would be the difference, except that I have: INSTALL=install Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
mirror site ftp3.za.freebsd.org
Hi For quite some time this mirror site has been unreachable. AFAICT, my ex colleagues who used to maintain it have moved on and it's now been left unmaintained. I left there in 2004 and Mark Murray who set it up left shortly thereafter. Perhaps it should be dropped from the mirror list. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: using multiple interfaces for same Network Card
Yasir hussan wrote: --20cf3005141ab7271904d7be84ff Yes, i want to use them as vlan interface, Does any one has used *vlandev*, after seen this http://www.cyberciti.biz/faq/howto-configure-freebsd-vlans-with-ifconfig-comm and/i tried to use it as ifconfig vlan11 create 10.10.11.1 255.255.255.0 vlan 11 vlandev arge0 ifconfig vlan12 create 10.10.12.1 255.255.255.0 vlan 12 vlandev arge0 ifconfig vlan13 create 10.10.13.1 255.255.255.0 vlan 13 vlandev arge0 ifconfig vlan14 create 10.10.14.1 255.255.255.0 vlan 14 vlandev arge0 you want: ifconfig vlan11 create vlan 11 vlandev arge0 inet 10.10.11.1 netmask 255.255.255.0 or ifconfig vlan11 create vlan 11 vlandev arge0 inet 10.10.11.1/24 Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: using multiple interfaces for same Network Card
Yasir hussan wrote: Thanks for notic but all the elebration was for make alias on one interface but i want to have multiple interface, i can no where that some one would have tring to creating new interfaces and using them, or may be i am missing something, just send its solution if have, solution should be for I still think you're confusing Linux semantics with FreeBSD semantics. On linux you would have: eth0 Link encap:Ethernet HWaddr 00:1E:C9:53:0B:61 inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::21e:c9ff:fe53:b61/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:211328068 errors:0 dropped:0 overruns:0 frame:0 TX packets:368394006 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:34065846811 (31.7 GiB) TX bytes:476377525764 (443.6 GiB) Interrupt:169 Memory:e600-e6011100 eth0:1Link encap:Ethernet HWaddr 00:1E:C9:53:0B:61 inet addr:10.0.1.1 Bcast:10.0.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:169 Memory:e600-e6011100 On FreeBSD you would have: re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE ether 54:04:a6:96:0c:1e inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255 inet 10.0.1.1 netmask 0xff00 broadcast 10.0.1.255 media: Ethernet autoselect (1000baseT full-duplex) status: active These are both the same thing. Is there any particular reason that you want multiple interfaces? I can't see a use for it beyond it's what I'm used to seeing unless they're VLAN interfaces. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Centrino Advanced-N 6235 wireless
Hi I have one of these Advanced controlers in my laptop. It's up for grabs for an interested developer after this coming week-end. I need to de-solder the w.FL connectors to to put them on a supported non-Intel card to get working wifi. I will replace the on-card connectors with u.FL. iwn0@pci0:2:0:0:class=0x028000 card=0x40608086 chip=0x088e8086 rev=0x24 hdr=0x00 vendor = 'Intel Corporation' device = 'Centrino Advanced-N 6235' class = network Contact me in private email if you're interested. The issues are: 1. Need the latest Intel firmware (iwlwifi-6000g2b-18.168.6.1) to get anything approaching connectivity. 2. The 2.4GHz radio will absolutely not use a 20MHz channel if the AP will do 40MHz. 3. 40MHz channels don't work. 4. Random disconnects every 30 minutes or so requiring a wlan0 destroy/create to recover. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Unable to build audio/sox: undefined reference to 'open_memstream'
Hi I get this error building building sox on amd64, but not i386. CC is gcc on both systems. I can't figure out what the configure options difference is between the two hosts that has it fail on the amd64 system. All the dependencies have the same options configured. /bin/sh ../libtool --silent --tag=CC --silent --mode=link cc -Wconversion -I/usr/local/include -O2 -pipe -march=nocona -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -Wall -W -Wmissing-prototypes -Wstrict-prototypes -pedantic -fopenmp -version-info 1:0:0 -lltdl -L/usr/local/lib -pthread -o libsox.la -rpath /usr/local/lib libsox_la-adpcms.lo libsox_la-aiff.lo libsox_la-cvsd.lo libsox_la-g711.lo libsox_la-g721.lo libsox_la-g723_24.lo libsox_la-g723_40.lo libsox_la-g72x.lo libsox_la-vox.lo libsox_la-raw.lo libsox_la-formats.lo libsox_la-formats_i.lo libsox_la-skelform.lo libsox_la-xmalloc.lo libsox_la-getopt.lo libsox_la-getopt1.lo libsox_la-util.lo libsox_la-libsox.lo libsox_la-libsox_i.lo libsox_la-sox-fmt.lo libsox_la-bend.lo libsox_la-biquad.lo libsox_la-biquads.lo libsox_la-chorus.lo libsox_la-compand.lo libsox_la-crop.lo libsox_la-compandt.lo libsox_la-contrast.lo libsox_la-dcshift.lo libsox_la-delay.lo libsox_la-dft_filter.lo libsox_la-dither.lo libsox_la-divid e.lo libsox_la-earwax.lo libsox_la-echo.lo libsox_la-echos.lo libsox_la-effects.lo libsox_la-effects_i.lo libsox_la-effects_i_dsp.lo libsox_la-fade.lo libsox_la-fft4g.lo libsox_la-filter.lo libsox_la-fir.lo libsox_la-firfit.lo libsox_la-flanger.lo libsox_la-gain.lo libsox_la-input.lo libsox_la-ladspa.lo libsox_la-loudness.lo libsox_la-mcompand.lo libsox_la-mixer.lo libsox_la-noiseprof.lo libsox_la-noisered.lo libsox_la-output.lo libsox_la-overdrive.lo libsox_la-pad.lo libsox_la-pan.lo libsox_la-phaser.lo libsox_la-rate.lo libsox_la-remix.lo libsox_la-repeat.lo libsox_la-reverb.lo libsox_la-reverse.lo libsox_la-silence.lo libsox_la-sinc.lo libsox_la-skeleff.lo libsox_la-speed.lo libsox_la-speexdsp.lo libsox_la-splice.lo libsox_la-stat.lo libsox_la-stats.lo libsox_la-stretch.lo libsox_la-swap.lo libsox_la-synth.lo libsox_la-tempo.lo libsox_la-tremolo.lo libsox_la-trim.lo libsox_la-vad.lo libsox_la-vol.lo libsox_la-spectrogram.lo libsox_la-raw-fmt.lo libsox_la -s1-fmt.lo libsox_la-s2-fmt.lo libsox_la-s3-fmt.lo libsox_la-s4-fmt.lo libsox_la-u1-fmt.lo libsox_la-u2-fmt.lo libsox_la-u3-fmt.lo libsox_la-u4-fmt.lo libsox_la-al-fmt.lo libsox_la-la-fmt.lo libsox_la-ul-fmt.lo libsox_la-lu-fmt.lo libsox_la-8svx.lo libsox_la-aiff-fmt.lo libsox_la-aifc-fmt.lo libsox_la-au.lo libsox_la-avr.lo libsox_la-cdr.lo libsox_la-cvsd-fmt.lo libsox_la-dvms-fmt.lo libsox_la-dat.lo libsox_la-hcom.lo libsox_la-htk.lo libsox_la-maud.lo libsox_la-prc.lo libsox_la-sf.lo libsox_la-smp.lo libsox_la-sounder.lo libsox_la-soundtool.lo libsox_la-sphere.lo libsox_la-tx16w.lo libsox_la-voc.lo libsox_la-vox-fmt.lo libsox_la-ima-fmt.lo libsox_la-adpcm.lo libsox_la-ima_rw.lo libsox_la-wav.lo libsox_la-wve.lo libsox_la-xa.lo libsox_la-nulfile.lo libsox_la-f4-fmt.lo libsox_la-f8-fmt.lo libsox_la-gsrt.lo libsox_la-alsa.lolibsox_la-ao.lo libsox_la-ffmpeg.lo libsox_la-flac.lo libsox_la-gsm.lo libsox_la-lpc10.lo libsox_la-mp3.lo libsox_la-oss.lo lib sox_la-vorbis.lo libsox_la-sndfile.lo libsox_la-caf.lo libsox_la-mat4.lo libsox_la-mat5.lo libsox_la-paf.lo libsox_la-fap.lo libsox_la-w64.lo libsox_la-xi.lo libsox_la-pvf.lo libsox_la-sd2.lo -lpng -lz -lmagic -lgomp -lgsm ../lpc10/liblpc10.la -lasound-lao -lavformat -lavcodec -L/usr/local/lib -lavutil -lFLAC -lvorbisenc -lvorbisfile -lvorbis -logg -lgsm -lmad -lid3tag -lz -lmp3lame -lvorbisenc -lvorbisfile -lvorbis -logg -L/usr/local/lib -lsndfile -lm /bin/sh ../libtool --silent --tag=CC --silent --mode=link cc -Wconversion -O2 -pipe -march=nocona -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -Wall -W -Wmissing-prototypes -Wstrict-prototypes -pedantic -fopenmp -avoid-version -module -L/usr/local/lib -pthread -o sox sox.o libsox.la -lm ./.libs/libsox.so: undefined reference to `open_memstream' *** [sox] Error code 1 Stop in /usr/ports/audio/sox/work/sox-14.3.2/src. *** [all-recursive] Error code 1 Stop in /usr/ports/audio/sox/work/sox-14.3.2. *** [do-build] Error code 1 Stop in /usr/ports/audio/sox. *** [build] Error code 1 Stop in /usr/ports/audio/sox. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: uath panic on insert.
Hans Petter Selasky wrote: On Friday 08 February 2013 22:43:17 Ian FREISLICH wrote: Hans Petter Selasky wrote: Hi, Your problem should be fixed by: http://svnweb.freebsd.org/changeset/base/246565 Please test and report back if it doesn't. It doesn't panic anymore. Thanks. There's a new problem though: uath0: Atheros Communications Inc USB WLAN Device, rev 2.00/0.01, addr 5 on usbus1 wlan1: Ethernet address: 00:11:95:d3:4a:af Hi, Can you try this patch: http://svnweb.freebsd.org/changeset/base/246570 ugen1.5: Atheros Communications Inc at usbus1 Atheros Communications Inc USB WLAN Device, rev 2.00/0.01, addr 5 on usbus1 Ethernet address: 00:11:95:d3:4a:af uath_cmdsend: empty inactive queue could not init Tx queues, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 at uhub2, port 2, addr 5 (disconnected) --- uath_cmdsend: empty inactive queue uath_cmdsend: empty inactive queue ugen1.5: Atheros Communications Inc at usbus1 (disconnected) The card still disconnects after attempting to scan unsupported frequencies. The sequence above happens when I 'ifconfig wlan1 up'. Also, the uath driver reports 2.4GHz and 5GHz as supported channels for this chip but it's a D-Link DWL-G132 which is a 2.4GHz device. Is this a problem for Adrian to look at? Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 7+ days of dogfood
Steve Kargl wrote: Firefox segfaults after ~10 seconds. Chrome gets stuck in a uwait state and never becomes responsive. Libreoffice displays its splash screen and immediately segfaults. Xorg does not start because it cannot load the xf86-video-driver (unless it is explicitly recompiled with /usr/bin/gcc). Once I got Xorg working, there were a few silent reboots (ie., nothing in /var/log/message, no core file, etc). snip KERNCONF=MOBILE CPUTYPE?=core2 #DISABLE_MAKE_JOBS=YES WITHOUT_CLANG=YES WITH_GCC=YES Shouldn't this be WITHOUT_CLANG_IS_CC=yes? I must say that my experience of -CURRENT dogfood has been entirely different. I can't remember the last time I didn't run -CURRENT as my desktop. I also have run -CURRENT in production for the last several years although it's a ruating load, not a compute load. Others might not agree with what I'm about to say. 1. WITHOUT_CLANG_IS_CC=yes I don't think clang is ready for prime time in FreeBSD, or FreeBSD isn't ready to use clang in prime time. I got a new laptop (ASUS UX31A) and found that a lot of the ports I needed to install didn't compile or core dumped. (Sorry I didn't report these to the project). This option sorted that problem out. However you will need to rebuild everything including world and kernel with gcc before you start building ports with gcc or you will still have problems. 2. MALLOC_PRODUCTION=yes Maybe it's the placebo effect. Binaries are smaller in memory and things seem faster 3. xorg, firefox18, WITH_NEW_XORG=yes, WITH_KMS=yes I've found that HAL is a waste of time with X. It's hit and miss when it comes to reporting hardware to X, better to just not use it. Xorg has always worked well for me. My new laptop required that I use the new xorg port to get anything resembling decent performance. Getting KMS to work was a bit unsettling and X only seems to work when it's launched by hand from a real terminal. xdm won't start from /etc/ttys with NEW_XORG, but I can live with that. I've just upgraded firefox-18.0 to firefox-18.0.2 without a hitch. I have flash working without a hitch. Even the acroread plugin works for viewing PDFs in browser. 4. Sound. I've had less success with this, but I think my problems would be the same on 8 and 9. It seems common for HDA these days to put the useful sound bits on different devices: pcm0: Realtek ALC269 (Internal Analog) (play/rec) default pcm1: Realtek ALC269 (Left Analog Headphones) (play) pcm2: Intel Panther Point (HDMI/DP 8ch) (play) So my headphone jack doesn't work. On my other laptor, the builtin mic doesn't work because it's on pcm1 and there's not a way to make pcm1 the default input device and pcm0 the default output device. I need to spend some time with a verbose boot and see if I can figure out the audio routing. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
uath panic on insert.
Hi I get this panic on insertion of a uath USB dongle. On amd-64: uath0: Atheros Communications Inc USB WLAN Device, rev 2.00/0.01, addr 3 on us bus1 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x20:0x80628f6a stack pointer = 0x28:0xff8112ee3750 frame pointer = 0x28:0xff8112ee37b0 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 = 14 (usbus1) trap number = 12 panic: page fault cpuid = 1 Uptime: 7s Dumping 237 out of 3971 MB:..7%..14%..21%..34%..41%..54%..61%..75%..81%..95% Reading symbols from /boot/kernel/acpi_asus_wmi.ko...Reading symbols from /boot/kernel/acpi_asus_wmi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_asus_wmi.ko Reading symbols from /boot/kernel/acpi_wmi.ko...Reading symbols from /boot/kernel/acpi_wmi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_wmi.ko Reading symbols from /boot/kernel/if_uath.ko...Reading symbols from /boot/kernel/if_uath.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_uath.ko #0 doadump (textdump=value optimized out) at pcpu.h:229 229 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=value optimized out) at pcpu.h:229 #1 0x in ?? () The i386 panic is only slightly more useful: ugen4.3: Atheros Communications Inc at usbus4 uath0: Atheros Communications Inc USB WLAN Device, rev 2.00/0.01, addr 3 on us bus4 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x20:0xc08ae31f stack pointer = 0x28:0xebbf8adc frame pointer = 0x28:0xebbf8b10 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 14 (usbus4) trap number = 12 panic: page fault cpuid = 0 Uptime: 16s Physical memory: 2027 MB Dumping 85 MB: 70 54 38 22 6 Reading symbols from /boot/kernel/acpi_video.ko...Reading symbols from /boot/ker nel/acpi_video.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_video.ko Reading symbols from /boot/kernel/ohci.ko...Reading symbols from /boot/kernel/oh ci.ko.symbols...done. done. Loaded symbols for /boot/kernel/ohci.ko Reading symbols from /boot/kernel/xhci.ko...Reading symbols from /boot/kernel/xh ci.ko.symbols...done. done. Loaded symbols for /boot/kernel/xhci.ko Reading symbols from /boot/kernel/if_uath.ko...Reading symbols from /boot/kernel /if_uath.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_uath.ko Reading symbols from /boot/kernel/u3g.ko...Reading symbols from /boot/kernel/u3g .ko.symbols...done. done. Loaded symbols for /boot/kernel/u3g.ko #0 doadump (textdump=1) at pcpu.h:249 249 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:249 #1 0xc06a69d5 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:446 #2 0xc06a6c32 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:753 #3 0xc08b05ac in trap_fatal (frame=0xebbf8a9c, eva=0) at /usr/src/sys/i386/i386/trap.c:1046 #4 0xc08b06a2 in trap_pfault (frame=0xebbf8a9c, usermode=0, eva=0) at /usr/src/sys/i386/i386/trap.c:899 #5 0xc08b1476 in trap (frame=0xebbf8a9c) at /usr/src/sys/i386/i386/trap.c:556 #6 0xc089b0dc in calltrap () at /usr/src/sys/i386/i386/exception.s:169 #7 0xc08ae31f in bzero () at /usr/src/sys/i386/i386/support.s:56 Previous frame inner to this frame (corrupt stack?) (kgdb) Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: uath panic on insert.
Hans Petter Selasky wrote: On Friday 08 February 2013 19:21:24 Ian FREISLICH wrote: Uptime: 7s Dumping 237 out of 3971 MB:..7%..14%..21%..34%..41%..54%..61%..75%..81%..95% Reading symbols from /boot/kernel/acpi_asus_wmi.ko...Reading symbols from /boot/kernel/acpi_asus_wmi.ko.symbols...done. do Maybe you can also look into /var/crash for more information? This is from /var/crash. The vmcore is quite badly corrupted. [new] /var/crash # kgdb -c vmcore.4 /boot/kernel/kernel 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 0x8041a3e4 in doadump () (kgdb) I've just noticed that I had USB_DEBUG=yes set. I'm trying a kernel without that set just in case that tickles an issue. It's been ages (2 years or more) since I used this card so a binary search is nearly out of the question. I'm trying to ressurect it because I got a new laptop with a totally useless new iwn(4) Centrino Advanced-N 6235 card in it that can't do 40MHz channels and can't stay connected to a 20MHz channel for longer than 15 minutes at a stretch. And, the antenna cables have w-FL connectors so I can't just replace it with a good old AR9285. I'm not sure I'll be able to desolder the w-FL connectors and move them to my Atheros card without destroying them. I'll try to capture some more useful debugging data, but it blows up pretty badly when the card is inserted. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
-iface option to route(8) is broken
Hi Adding routes using the -iface option to route(8) doesn't work any more. This was useful to select a specific interface for a route when the remote gateway has the same IP address. Are there plans to restore this functionality? tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1492 options=8LINKSTATE inet 41.135.82.18 -- 41.135.70.1 netmask 0x Opened by PID 2387 [router] ~ # route add 41.154.2.53 -iface tun0 route: bad address: tun0 It also doesn't work on ngX PPP interfaces. ng1: flags=88d1UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST metric 0 mtu 1490 inet 197.87.27.111 -- 41.135.70.1 netmask 0x ng2: flags=88d1UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST metric 0 mtu 1490 inet 41.135.82.120 -- 41.135.70.1 netmask 0x [router] ~ # route add 41.154.2.53 -iface ng2 route: bad address: ng2 [router] ~ # route add 41.154.2.53 -interface ng2 route: bad address: ng2 Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
route add ... -iface fails
Hi This used to work on tunX, but no more. tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1492 options=8LINKSTATE inet 41.135.82.18 -- 41.135.70.1 netmask 0x Opened by PID 2387 [router] ~ # route add 41.154.2.53 -iface tun0 route: bad address: tun0 It also doesn't work on ngX PPP interfaces. ng2: flags=88d1UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST metric 0 mtu 1490 inet 41.135.82.120 -- 41.135.70.1 netmask 0x [router] ~ # route add 41.154.2.53 -iface ng2 route: bad address: ng2 [router] ~ # route add 41.154.2.53 -interface ng2 route: bad address: ng2 I have several PPP conections on several ADSL lines with the same provider that doesn't do multi link PPP, so I need to be able to set the destination interface. Ian -- Meditating Guru Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ixgbe(4) and SFP+ (un)supported module
Hi
I've just had this card installed in our servers:
ix0@pci0:12:0:0:class=0x02 card=0x7a118086 chip=0x10fb8086 rev=0x01
hdr=0x00
vendor = 'Intel Corporation'
device = '82599EB 10-Gigabit SFI/SFP+ Network Connection'
class = network
subclass = ethernet
cap 01[40] = powerspec 3 supports D0 D3 current D0
cap 05[50] = MSI supports 1 message, 64 bit, vector masks
cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled
cap 10[a0] = PCI-Express 2 endpoint max data 512(512) FLR link x8(x8)
speed 2.5(5.0)
cap 03[e0] = VPD
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
ecap 0003[140] = Serial 1 90e2ba2b92e8
ecap 000e[150] = ARI 1
ecap 0010[160] = SRIOV 1
Which yielded the following error initializing the driver:
ix0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.5.0 port 0xbcc
ix0: Using MSIX interrupts with 9 vectors
ix0: Unsupported SFP+ Module
device_attach: ix0 attach returned 5
ix0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.5.0 port 0xbce
ix0: Using MSIX interrupts with 9 vectors
ix0: Unsupported SFP+ Module
device_attach: ix0 attach returned 5
ix0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.5.0 port 0xbcc
ix0: Using MSIX interrupts with 9 vectors
ix0: Unsupported SFP+ Module
device_attach: ix0 attach returned 5
ix0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.5.0 port 0xbce
ix0: Using MSIX interrupts with 9 vectors
ix0: Unsupported SFP+ Module
device_attach: ix0 attach returned 5
The README in /usr/src/sys/dev/ixgbe claims that the module we have,
AFBR-703SDZ-IN is supported. I had to make the following change
to get the driver to attach. I get the feeling it's not the
correct fix however:
[firewall2.jnb1] /usr/src/sys/dev/ixgbe # svn diff
Index: ixgbe_phy.c
===
--- ixgbe_phy.c (revision 243808)
+++ ixgbe_phy.c (working copy)
@@ -955,7 +955,7 @@
u8 oui_bytes[3] = {0, 0, 0};
u8 cable_tech = 0;
u8 cable_spec = 0;
- u16 enforce_sfp = 0;
+ u16 enforce_sfp = 1;
DEBUGFUNC(ixgbe_identify_sfp_module_generic);
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ixgbe(4) and SFP+ (un)supported module
Jack Vogel wrote: Look again closely, AFBR-703SDZ-IN2 and AFBR-703SDDZ-IN1 are supported, AFBR-703SDZ-IN is not. Sorry, that was a cutpasto. We have the AFBR-703SDZ-IN2. The full detail from the box according the guy on site is: AFBR-703SDZ-IN2 (INTEL)FTLX8571D3BCL Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: netisr panic?
Ian FREISLICH wrote:
Gleb Smirnoff wrote:
On Sat, Nov 17, 2012 at 05:07:54PM +0200, Ian FREISLICH wrote:
I I have this consistently with:
I
I FreeBSD firewall2.jnb1.gp-online.net 10.0-CURRENT FreeBSD 10.0-CURRENT #
30
r243156: Fri Nov 16 20:12:33 SAST 2012 i...@firewall2.jnb1.gp-online.net
:/
usr/obj/usr/src/sys/FIREWALL amd64
Pretty sure this is a new version of wrong byte order panic, which
no longer can happen in HEAD.
Can you please try this patch?
It survived the night, which it hasn't managed before. I'll keep you posted.
Jubilation short lived:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xc
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x8050f494
stack pointer = 0x28:0xff84637a19d0
frame pointer = 0x28:0xff84637a1a10
code segment= base 0x0, limit 0xf, type 0x1b
Fatal trap 12: page fault while in kernel mode
= DPL 0, pres 1, long 1, def32 0, gran 1
cpuid = 7; apic id = 07
processor eflags= fault virtual address = 0xc
interrupt enabled, fault code = supervisor read data, page not present
resume, IOPL = 0
instruction pointer = 0x20:0x8050f494
stack pointer = 0x28:0xff846386c9d0
current process = 11 (irq261: igb0:que 0)
frame pointer = 0x28:0xff846386ca10
trap number = 12
code segment= base 0x0, limit 0xf, type 0x1b
panic: page fault
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
panic() at panic+0x1ce
trap_fatal() at trap_fatal+0x290
trap_pfault() at trap_pfault+0x21f
trap() at trap+0x2b4
calltrap() at calltrap+0x8
--- trap 0xc, rip = 0x8050f494, rsp = 0xff84637a19d0, rbp =
0xff84637a1a10 ---
ether_nh_input() at ether_nh_input+0x94
netisr_dispatch_src() at netisr_dispatch_src+0x212
igb_rxeof() at igb_rxeof+0x384
igb_msix_que() at igb_msix_que+0xfa
intr_event_execute_handlers() at intr_event_execute_handlers+0xfd
ithread_loop() at ithread_loop+0x9e
fork_exit() at fork_exit+0x11e
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff84637a1cb0, rbp = 0 ---
Uptime: 19h5m45s
Dumping 2654 out of 16368 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
#0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:266
266 if (textdump textdump_pending) {
(kgdb) #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:266
#1 0x8044ae64 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:449
#2 0x8044b3e7 in panic (fmt=0x1 Address 0x1 out of bounds)
at /usr/src/sys/kern/kern_shutdown.c:637
#3 0x80605b30 in trap_fatal (frame=0xc, eva=value optimized out)
at /usr/src/sys/amd64/amd64/trap.c:872
#4 0x80605e9f in trap_pfault (frame=0xff84637a1920, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:789
#5 0x80606254 in trap (frame=0xff84637a1920)
at /usr/src/sys/amd64/amd64/trap.c:463
#6 0x805efecf in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:228
#7 0x8050f494 in ether_nh_input (m=0xfe004f3bde00)
at /usr/src/sys/net/if_ethersubr.c:484
#8 0x8051a562 in netisr_dispatch_src (proto=9,
source=value optimized out, m=value optimized out)
at /usr/src/sys/net/netisr.c:1013
#9 0x80318844 in igb_rxeof (que=0xfe000a183a00, count=499,
done=0x0) at /usr/src/sys/dev/e1000/if_igb.c:4688
#10 0x8032183a in igb_msix_que (arg=value optimized out)
at /usr/src/sys/dev/e1000/if_igb.c:1596
#11 0x8042082d in intr_event_execute_handlers (
p=value optimized out, ie=0xfe000a109e00)
at /usr/src/sys/kern/kern_intr.c:1272
#12 0x8042205e in ithread_loop (arg=0xfe000a1a16e0)
at /usr/src/sys/kern/kern_intr.c:1285
#13 0x8041d48e in fork_exit (
callout=0x80421fc0 ithread_loop, arg=0xfe000a1a16e0,
frame=0xff84637a1c00) at /usr/src/sys/kern/kern_fork.c:995
#14 0x805f038e in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:602
#15 0x in ?? ()
--
Meditating Guru
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: netisr panic?
Gleb Smirnoff wrote: On Sat, Nov 17, 2012 at 05:07:54PM +0200, Ian FREISLICH wrote: I I have this consistently with: I I FreeBSD firewall2.jnb1.gp-online.net 10.0-CURRENT FreeBSD 10.0-CURRENT #30 r243156: Fri Nov 16 20:12:33 SAST 2012 i...@firewall2.jnb1.gp-online.net:/ usr/obj/usr/src/sys/FIREWALL amd64 Pretty sure this is a new version of wrong byte order panic, which no longer can happen in HEAD. Can you please try this patch? It survived the night, which it hasn't managed before. I'll keep you posted. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
netisr panic?
Hi
I have this consistently with:
FreeBSD firewall2.jnb1.gp-online.net 10.0-CURRENT FreeBSD 10.0-CURRENT #30
r243156: Fri Nov 16 20:12:33 SAST 2012
i...@firewall2.jnb1.gp-online.net:/usr/obj/usr/src/sys/FIREWALL amd64
Fatal trap 12: page fault while in kernel mode
cpuid = 4; apic id = 04
fault virtual address = 0xc
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x8050f534
stack pointer = 0x28:0xff846384e9c0
frame pointer = 0x28:0xff846384ea00
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 = 11 (irq266: igb1:que 0)
trap number = 12
panic: page fault
cpuid = 4
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
panic() at panic+0x1ce
trap_fatal() at trap_fatal+0x290
trap_pfault() at trap_pfault+0x21f
trap() at trap+0x2b4
calltrap() at calltrap+0x8
--- trap 0xc, rip = 0x8050f534, rsp = 0xff846384e9c0, rbp =
0xff846384ea00 ---
ether_nh_input() at ether_nh_input+0x94
netisr_dispatch_src() at netisr_dispatch_src+0x212
igb_rxeof() at igb_rxeof+0x3f0
igb_msix_que() at igb_msix_que+0xfa
intr_event_execute_handlers() at intr_event_execute_handlers+0xfd
ithread_loop() at ithread_loop+0x9e
fork_exit() at fork_exit+0x11e
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff846384ecb0, rbp = 0 ---
Uptime: 2h2m15s
Dumping 1241 out of 16368 MB:..2%..11%..21%..31%..42%..51%..61%..71%..82%..91%
#0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:266
266 if (textdump textdump_pending) {
(kgdb) #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:266
#1 0x8044af04 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:449
#2 0x8044b487 in panic (fmt=0x1 Address 0x1 out of bounds)
at /usr/src/sys/kern/kern_shutdown.c:637
#3 0x80605bd0 in trap_fatal (frame=0xc, eva=value optimized out)
at /usr/src/sys/amd64/amd64/trap.c:872
#4 0x80605f3f in trap_pfault (frame=0xff846384e910, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:789
#5 0x806062f4 in trap (frame=0xff846384e910)
at /usr/src/sys/amd64/amd64/trap.c:463
#6 0x805eff6f in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:228
#7 0x8050f534 in ether_nh_input (m=0xfe012521e700)
at /usr/src/sys/net/if_ethersubr.c:484
#8 0x8051a602 in netisr_dispatch_src (proto=9,
source=value optimized out, m=value optimized out)
at /usr/src/sys/net/netisr.c:1013
#9 0x803188b0 in igb_rxeof (que=0xfe000a183800, count=499,
done=0x0) at /usr/src/sys/dev/e1000/if_igb.c:4688
#10 0x803218da in igb_msix_que (arg=value optimized out)
at /usr/src/sys/dev/e1000/if_igb.c:1596
#11 0x804208cd in intr_event_execute_handlers (
p=value optimized out, ie=0xfe000a19f100)
at /usr/src/sys/kern/kern_intr.c:1272
#12 0x804220fe in ithread_loop (arg=0xfe000a1c6660)
at /usr/src/sys/kern/kern_intr.c:1285
#13 0x8041d52e in fork_exit (
callout=0x80422060 ithread_loop, arg=0xfe000a1c6660,
frame=0xff846384ec00) at /usr/src/sys/kern/kern_fork.c:995
#14 0x805f042e in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:602
#15 0x in ?? ()
--
Meditating Guru
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: netisr panic?
Adrian Chadd wrote:
It's a NULL ponter deref. This is my line 484 in if_ethersubr.c:
eh = mtod(m, struct ether_header *);
.. if that's yours, see if eh is NULL?
(kgdb) frame 7
#7 0x8050f534 in ether_nh_input (m=0xfe012521e700)
at /usr/src/sys/net/if_ethersubr.c:484
484 eh = mtod(m, struct ether_header *);
(kgdb) print eh
No symbol eh in current context.
(kgdb) print *m
$2 = {m_hdr = {mh_next = 0x100, mh_nextpkt = 0x100,
mh_data = 0x0, mh_len = 60, mh_flags = 4259842, mh_type = 0,
pad = \000\000\000\000\000}, M_dat = {MH = {MH_pkthdr = {
rcvif = 0xfe000a1c2000, header = 0x, len = 60, flowid = 0,
csum_flags = 3840, csum_data = 65535, tso_segsz = 0, PH_vt = {
vt_vtag = 4, vt_nrecs = 4}, tags = {slh_first = 0x3c00}},
MH_dat = {MH_ext = {
ext_buf = 0x69e54986 Address 0x69e54986 out of
bounds, ext_free = 0x10602, ext_arg1 = 0xc0007, ext_arg2 = 0x100,
ext_size = 2048, ref_cnt = 0xfe0125236d8c, ext_type = 6},
MH_databuf =
\000\000\000\000\206Iåi\002\006\001\000\000\000\000\000\000\000\a\000\000\000\f\000\000\001\000\000\000\000\000\000\000\b\000\000\000\000\000\000\214m#%\001þÿÿ\006,
'\0' repeats 118 times}},
M_databuf = \000
\034\n\000þÿÿ\000\000\000\000\000\000\000\000\000\000\000\000\017\000\000ÿÿ\000\000\000\000\004\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\206Iåi\002\006\001\000\000\000\000\000\000\000\a\000\000\000\f\000\000\001\000\000\000\000\000\000\000\b\000\000\000\000\000\000\214m#%\001þÿÿ\006,
'\0' repeats 118 times}}
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
