Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient
On Fri, Sep 12, 2014 at 09:29:56PM -0700, Peter Wemm wrote: > On Thursday, September 11, 2014 12:38:02 PM Patrick Kelsey wrote: > > On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov wrote: > > > On 09.09.2014 21:53, Patrick Kelsey wrote: > > > > I don't think it is worth the trouble, as given the larger pattern of > > > > libc routines requiring multiple capsicum rights, it seems one will in > > > > general have to have libc implementation knowledge when using it in > > > > concert with capsicum. For example, consider the limitfd() routine in > > > > kdump.c, which provides rights for the TIOCGETA ioctl to be used on > > > > stdout so the eventual call to isatty() via printf() will work as > > > > > > intended. > > > > > > > I think the above kdump example is a good one for the subtle issues that > > > > can arise when using capsicum with libc. That call to isatty() is via a > > > > widely-used internal libc routine __smakebuf(). __smakebuf() also calls > > > > __swhatbuf(), which in turn calls _fstat(), all to make sure that output > > > > to a tty is line buffered by default. It would appear that programs > > > > that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT > > > > could be disabling the normally default line buffering when stdout is a > > > > tty. kdump goes the distance, but dhclient does not (restricting stdout > > > > to CAP_WRITE only). > > > > > > > > In any event, the patch attached to my first message is seeming like the > > > > way to go. > > > > > > Well, then commit it (if capsicum team agrees). > > > > Will do - thanks for the feedback. > > > > -Patrick > > Is there any possibility that this is related to the problem we've recently > hit in the freebsd.org cluster with this month's refresh? > > After running for a while: > Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 0: validator > Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 1: iterator > Sep 10 11:44:29 ns2 unbound: [65258:3] fatal error: event_dispatch returned > error -1, errno is Capabilities insufficient > > Sep 10 16:21:16 ns2 unbound: [28212:0] warning: did not exit gracefully last > time (65258) > Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 0: validator > Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 1: iterator > Sep 11 10:23:49 ns2 unbound: [28213:5] fatal error: event_dispatch returned > error -1, errno is Capabilities insufficient > > Sep 11 13:48:46 ns2 unbound: [79419:0] warning: did not exit gracefully last > time (28213) > Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 0: validator > Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 1: iterator > Sep 11 18:42:56 ns2 unbound: [79420:6] fatal error: event_dispatch returned > error -1, errno is Capabilities insufficient > > I believe this jail was started from the boot process. If I restart the jail > by hand from a ssh session the problem goes away. > > This is unbound from ports and I don't have any more details than this. This > is new this month. > Is this thingy multithreaded? Currently there is a race in the kernel where fd is visible before relevant capabilities are installed. This can result in an error like this one for weird processes. I got a patch for this: http://lists.freebsd.org/pipermail/freebsd-arch/2014-August/015788.html but it got stalled on 'memory barrier' discussion. I'll try to ping people to move it forward. IIRC there was a report of unbound failing this way, apparently fixed with aforementioned patch. -- Mateusz Guzik ___ 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: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI
Am Mon, 15 Sep 2014 18:25:34 -0700 Adrian Chadd schrieb: > Hi, > > Try updating to the latest -HEAD. It at least makes dhclient behave better. > > > -a > > > On 15 September 2014 18:19, Kevin Oberman wrote: > > On Mon, Sep 15, 2014 at 2:38 PM, O. Hartmann > > wrote: > > > >> > >> Trying to install and run FreeBSD 11.0-CURRENT > >> (FreeBSD-11.0-CURRENT-amd64-20140903-r270990-memstick.img) on a new Lenovo > >> E540 notebook > >> fails in activating the NIC (Realtek RTL8111/8168B, driver re[0]). The NIC > >> shows up as > >> active and with carrier when issuing "ifconfig re0". > >> > >> From a desktop machine, I tried to ping the system in question and I get a > >> result with > >> missing packets: > >> > >> ping: sendto: Host is down > >> ping: sendto: Host is down > >> ping: sendto: Host is down > >> 64 bytes from 192.168.0.130: icmp_seq=26 ttl=64 time=0.114 ms > >> 64 bytes from 192.168.0.130: icmp_seq=41 ttl=64 time=0.130 ms > >> 64 bytes from 192.168.0.130: icmp_seq=60 ttl=64 time=0.119 ms > >> 64 bytes from 192.168.0.130: icmp_seq=80 ttl=64 time=0.119 ms > >> 64 bytes from 192.168.0.130: icmp_seq=100 ttl=64 time=0.105 ms > >> 64 bytes from 192.168.0.130: icmp_seq=116 ttl=64 time=0.135 ms > >> 64 bytes from 192.168.0.130: icmp_seq=136 ttl=64 time=0.091 ms > >> > >> DHCP configuration fails, since no DHCP offer is discovered. > >> > >> I swapped the switches, the cabling and I had always the same results. I > >> used another > >> Laptop, Dell Latitude E6510 with the same configuration (/etc/rc.conf) and > >> that system > >> gets DHCP offer and is online. > >> > >> Since the notebook is brandnew, the last thing I'll "suspect" is a > >> defective NIC, so I'll > >> ask whether this phenomenon is known - or, if not, the results > >> definititely would > >> indicate a broken NIC. > >> > >> Another point is the WiFI adaptor. This notebook is supposed to have a > >> WiFi NIC, but it > >> doesn't get revealed by FreeBSD (I tried iwn/iwi without success). > >> > >> pciconf output below, sorry for the messy shape, it is a copy-and-paste > >> from that immature > >> vt() terminal. > >> > >> Has anyone successfully installed that type of Notebook with FreeBSD > >> CURRENT using NIC > >> and Wifi? > >> > >> Please CC me. > >> > >> > >> Regards > >> oh > >> > >> > >> [...] > >> > >> none1@pci0:3:0:0: class=0xff card=0x502817aa chip=0x522710ec > >> rev=0x01 hdr=0x00 > >> > >> > >> vendor = 'Realtek Semiconductor Co., Ltd.' > >> > >> > >> bar [10] = type Memory, range 32, base 0xf1e0, size 4096, enabled > >> > >> > >> cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > >> > >> > >> cap 05[50] = MSI supports 1 message, 64 bit > >> > >> > >> cap 10[70] = PCI-Express 2 endpoint max data 128(128) link x1(x1) > >> > >> > >> speed 2.5(2.5) ASPM L0s/L1(L0s/L1) > >> > >> > >> ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected > >> > >> > >> ecap 0003[140] = Serial 1 0001004ce000 > >> > >> > >> re0@pci0:4:0:0: class=0x02 card=0x502817aa chip=0x816810ec rev=0x10 > >> hdr=0x00 > >> > >> > >> subclass = ethernet > >> > >> > >> cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current > >> D0 > >> di sabled(L0s/L1) > >> > >> > >> cap 11[b0] = MSI-X supports 4 messages, enabled > >> > >> ecap 0001[100] = AER 2 0 fatal 0 non-fatal 4 corrected > >> > >> > >> > >> ecap 001e[178] = unknown 1 > >> > >> > >> class = network > >> > >> > >> cap 05[d0] = MSI supports 1 message, 64 bit > >> > >> > >> ecap 0003[140] = Serial 1 ac7ba1a06fd6 > >> > > > > I can't comment on the WiFi, I have little Asus box using an 8111/8168B and > > it works fine with the driver in 10.1-BETA. The driver in 10.0 recognizes > > the device, but did not work. I do notice that your NIC has a rev of 0x10 > > while mine is 0x0c. > > -- > > Kevin Oberman, Network Engineer, Retired In my local network (the laptop is working/getting installed in) I use jumbo frames on several server system including the gateway (also FBSD CURRENT). After I manually set mtu > 1500 (in my case: mtu 6121) the NIC worked as expected. My lab's Dell Latitude E6510 laptop (em0) works without setting explicit jumbo frames. This is a kind of weird ... Thanks for your patience. Oliver signature.asc Description: PGP signature
Re: Huawei E3272 tester needed
On Tue, 16 Sep 2014 09:40:45 +0200 Nick Hibma wrote: > Hi, > > Is there someone who is able to test support for the Huawei E3272 > card with CURRENT after 269584? I have not been able to confirm that > it works. > > Thanks in advance. > > Nick > Hi, I did fresh svn update, rebuilt world+kernel, but it does not work for me... >From log: ugen1.3: at usbus1 umass1: on usbus1 cd2 at umass-sim1 bus 1 scbus7 target 0 lun 0 cd2: Removable CD-ROM SCSI-2 device cd2: 40.000MB/s transfers cd2: cd present [65536 x 2048 byte records] cd2: quirks=0x10<10_BYTE_ONLY> (cd2:umass-sim1:1:0:0): READ(10). CDB: 28 00 00 00 ff ff 00 00 01 00 (cd2:umass-sim1:1:0:0): CAM status: SCSI Status Error (cd2:umass-sim1:1:0:0): SCSI status: Check Condition (cd2:umass-sim1:1:0:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read error) (cd2:umass-sim1:1:0:0): Info: 0x (cd2:umass-sim1:1:0:0): Error 5, Unretryable error (cd2:umass-sim1:1:0:0): cddone: got error 0x5 back ugen1.3: at usbus1 (disconnected) umass1: at uhub1, port 6, addr 3 (disconnected) cd2 at umass-sim1 bus 1 scbus7 target 0 lun 0 cd2: detached (cd2:umass-sim1:1:0:0): Periph destroyed I tried attach/detach device beore and after loading u3g (just in case...) and if_cdce kernel modules, but I saw no changes. >From 'usbconfig dump_device_desc': ugen1.3: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0040 idVendor = 0x12d1 idProduct = 0x1f01 bcdDevice = 0x0102 iManufacturer = 0x0002 iProduct = 0x0001 iSerialNumber = 0x0004 bNumConfigurations = 0x0001 If anything else is important, let me know. Regards, Milan > The change: > > Author: n_hibma > Date: Tue Aug 5 12:08:50 2014 > New Revision: 269584 > URL: http://svnweb.freebsd.org/changeset/base/269584 > > Log: > Add support for Huawei E3272 modems which are supported by the CDC > ethernet class. > > Note: This is untested as I do not have a device like this. That is > reflected in the MFC timeout. > > PR: 192345 > Submitted by:rozhuk.im gmail.com > MFC after: 4 weeks > > Modified: > head/sys/dev/usb/net/if_cdce.c > head/sys/dev/usb/usbdevs > ___ 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: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI
Ah, jumbo frames. Maybe you got lucky and some ethernet drivers default to accepting larger frames even if the MTU is 1500. -a ___ 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"
Daily head port building regression logs
Hi, I am planning to enable daily head build logs of ports to current@. The idea is that only new regressions will generate 1 mail with a list of failures. This list will only include *new* failures. It will not nag every day if some port is still broken. This will only work well if the ports tree used is stable and not causing the failures due to updates. We have a quarterly tree that is similar to a stable branch that we update less often. I will use this branch for the builds. I will not enable the actual mails until it has been tested to ensure it is not noisy and full of false-positives. This should help capture userland build regressions that are missed due to not exp-running changes in src. The caveat here is that the host kernel these builds are going on will remain on the normal monthly update cycle. This hopefully won't cause too many false-positives. I can always disable them temporarily or permanently should there be noise. It may be that this system will need to have its host auto updated daily as well. I'd rather not get into a constant brick-and-fix cycle though. -- Regards, Bryan Drewery on behalf of portmgr@ signature.asc Description: OpenPGP digital signature
New spam on all my current machine consoles
HV_KVP: open /dev/hv_kvp_dev failed; error: 2 No such file or directory I assume that there is missing error handling in or logic here somewhere as every one of my machines is spamming my consoles on startup with this new message. sean ___ 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: New spam on all my current machine consoles
> On Sep 16, 2014, at 11:40, Sean Bruno wrote: > > HV_KVP: open /dev/hv_kvp_dev failed; error: 2 No such file or directory > > I assume that there is missing error handling in or logic here somewhere > as every one of my machines is spamming my consoles on startup with this > new message. uname -a? ___ 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: New spam on all my current machine consoles
On Tue, 2014-09-16 at 11:45 -0700, Garrett Cooper wrote: > > On Sep 16, 2014, at 11:40, Sean Bruno wrote: > > > > HV_KVP: open /dev/hv_kvp_dev failed; error: 2 No such file or directory > > > > I assume that there is missing error handling in or logic here somewhere > > as every one of my machines is spamming my consoles on startup with this > > new message. > > uname -a? FreeBSD redbuild01.nyi.freebsd.org 11.0-CURRENT FreeBSD 11.0-CURRENT #9 r271631: Mon Sep 15 16:38:04 UTC 2014 sbr...@redbuild01.nyi.freebsd.org:/usr/obj/usr/src/sys/REDBUILD amd64 sean ___ 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: New spam on all my current machine consoles
On Tue, Sep 16, 2014 at 11:40:15AM -0700, Sean Bruno wrote: > HV_KVP: open /dev/hv_kvp_dev failed; error: 2 No such file or directory > > I assume that there is missing error handling in or logic here somewhere > as every one of my machines is spamming my consoles on startup with this > new message. This is after r271493. The hv_kvpd lacks 'NO' entry in the /etc/defaults/rc.conf. pgpCZ1eQiGXvD.pgp Description: PGP signature
Re: New spam on all my current machine consoles
On Tue, 2014-09-16 at 21:57 +0300, Konstantin Belousov wrote: > On Tue, Sep 16, 2014 at 11:40:15AM -0700, Sean Bruno wrote: > > HV_KVP: open /dev/hv_kvp_dev failed; error: 2 No such file or directory > > > > I assume that there is missing error handling in or logic here somewhere > > as every one of my machines is spamming my consoles on startup with this > > new message. > > This is after r271493. The hv_kvpd lacks 'NO' entry > in the /etc/defaults/rc.conf. Right, something like this should be added? Index: rc.conf === --- rc.conf (revision 271679) +++ rc.conf (working copy) @@ -684,6 +684,8 @@ jail_parallel_start="NO" # Start jails in the background jail_list="" # Space separated list of names of jails +hv_kvpd_enable="NO"# Start the Hyper-V key-value Pair Driver hv_kvp(4) + ## ### Define source_rc_confs, the mechanism used by /etc/rc.* ## ### scripts to source rc_conf_files overrides safely. ## ___ 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: New spam on all my current machine consoles
On Tue, Sep 16, 2014 at 12:08:54PM -0700, Sean Bruno wrote: > On Tue, 2014-09-16 at 21:57 +0300, Konstantin Belousov wrote: > > On Tue, Sep 16, 2014 at 11:40:15AM -0700, Sean Bruno wrote: > > > HV_KVP: open /dev/hv_kvp_dev failed; error: 2 No such file or directory > > > > > > I assume that there is missing error handling in or logic here somewhere > > > as every one of my machines is spamming my consoles on startup with this > > > new message. > > > > This is after r271493. The hv_kvpd lacks 'NO' entry > > in the /etc/defaults/rc.conf. > > Right, something like this should be added? Yes, assuming it indeed solves the issue. > > Index: rc.conf > === > --- rc.conf (revision 271679) > +++ rc.conf (working copy) > @@ -684,6 +684,8 @@ > jail_parallel_start="NO" # Start jails in the background > jail_list="" # Space separated list of names of jails > > +hv_kvpd_enable="NO" # Start the Hyper-V key-value Pair Driver hv_kvp(4) > + > ## > ### Define source_rc_confs, the mechanism used by /etc/rc.* ## > ### scripts to source rc_conf_files overrides safely.## > pgpS10wRpPqV6.pgp Description: PGP signature
Re: New spam on all my current machine consoles
On Tue, 2014-09-16 at 22:27 +0300, Konstantin Belousov wrote: > On Tue, Sep 16, 2014 at 12:08:54PM -0700, Sean Bruno wrote: > > On Tue, 2014-09-16 at 21:57 +0300, Konstantin Belousov wrote: > > > On Tue, Sep 16, 2014 at 11:40:15AM -0700, Sean Bruno wrote: > > > > HV_KVP: open /dev/hv_kvp_dev failed; error: 2 No such file or directory > > > > > > > > I assume that there is missing error handling in or logic here somewhere > > > > as every one of my machines is spamming my consoles on startup with this > > > > new message. > > > > > > This is after r271493. The hv_kvpd lacks 'NO' entry > > > in the /etc/defaults/rc.conf. > > > > Right, something like this should be added? > Yes, assuming it indeed solves the issue. > > > > > > Index: rc.conf > > === > > --- rc.conf (revision 271679) > > +++ rc.conf (working copy) > > @@ -684,6 +684,8 @@ > > jail_parallel_start="NO" # Start jails in the background > > jail_list="" # Space separated list of names of jails > > > > +hv_kvpd_enable="NO"# Start the Hyper-V key-value Pair Driver > > hv_kvp(4) > > + > > ## > > ### Define source_rc_confs, the mechanism used by /etc/rc.* ## > > ### scripts to source rc_conf_files overrides safely. ## > > Hopefully, I didn't make things worse? https://svnweb.freebsd.org/base?view=revision&revision=271688 sean ___ 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: Huawei E3272 tester needed
On 16.09.2014 16:52, Milan Obuch wrote: > On Tue, 16 Sep 2014 09:40:45 +0200 > Nick Hibma wrote: > >> Hi, >> >> Is there someone who is able to test support for the Huawei E3272 >> card with CURRENT after 269584? I have not been able to confirm that >> it works. >> >> Thanks in advance. >> >> Nick >> > Hi, > > I did fresh svn update, rebuilt world+kernel, but it does not work for > me... > > From log: > > ugen1.3: at usbus1 > umass1: > on usbus1 > cd2 at umass-sim1 bus 1 scbus7 target 0 lun 0 > cd2: Removable CD-ROM SCSI-2 device > cd2: 40.000MB/s transfers > cd2: cd present [65536 x 2048 byte records] > cd2: quirks=0x10<10_BYTE_ONLY> > (cd2:umass-sim1:1:0:0): READ(10). CDB: 28 00 00 00 ff ff 00 00 01 00 > (cd2:umass-sim1:1:0:0): CAM status: SCSI Status Error > (cd2:umass-sim1:1:0:0): SCSI status: Check Condition > (cd2:umass-sim1:1:0:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read > error) > (cd2:umass-sim1:1:0:0): Info: 0x > (cd2:umass-sim1:1:0:0): Error 5, Unretryable error > (cd2:umass-sim1:1:0:0): cddone: got error 0x5 back > > ugen1.3: at usbus1 (disconnected) > umass1: at uhub1, port 6, addr 3 (disconnected) > cd2 at umass-sim1 bus 1 scbus7 target 0 lun 0 > cd2: detached > (cd2:umass-sim1:1:0:0): Periph destroyed > > I tried attach/detach device beore and after loading u3g (just in > case...) and if_cdce kernel modules, but I saw no changes. > > From 'usbconfig dump_device_desc': > > ugen1.3: at usbus1, cfg=0 md=HOST spd=HIGH > (480Mbps) pwr=ON (500mA) > > bLength = 0x0012 > bDescriptorType = 0x0001 > bcdUSB = 0x0200 > bDeviceClass = 0x > bDeviceSubClass = 0x > bDeviceProtocol = 0x > bMaxPacketSize0 = 0x0040 > idVendor = 0x12d1 > idProduct = 0x1f01 > bcdDevice = 0x0102 > iManufacturer = 0x0002 > iProduct = 0x0001 > iSerialNumber = 0x0004 > bNumConfigurations = 0x0001 > > If anything else is important, let me know. > > Regards, > Milan Try ejecting first this cd2 drive by cdcontrol eject or camcontrol eject. I had such scenario with other usb device and that helped. -- Pozdrawiam, Maciej Milewski ___ 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: Huawei E3272 tester needed
On Tue, 16 Sep 2014 21:55:50 +0200 Maciej Milewski wrote: > On 16.09.2014 16:52, Milan Obuch wrote: > > On Tue, 16 Sep 2014 09:40:45 +0200 > > Nick Hibma wrote: > > > >> Hi, > >> > >> Is there someone who is able to test support for the Huawei E3272 > >> card with CURRENT after 269584? I have not been able to confirm > >> that it works. > >> > >> Thanks in advance. > >> > >> Nick > >> > > Hi, > > > > I did fresh svn update, rebuilt world+kernel, but it does not work > > for me... [ snip ] > > I tried attach/detach device beore and after loading u3g (just in > > case...) and if_cdce kernel modules, but I saw no changes. > > > > From 'usbconfig dump_device_desc': > > > > ugen1.3: at usbus1, cfg=0 md=HOST > > spd=HIGH (480Mbps) pwr=ON (500mA) > > > > bLength = 0x0012 > > bDescriptorType = 0x0001 > > bcdUSB = 0x0200 > > bDeviceClass = 0x > > bDeviceSubClass = 0x > > bDeviceProtocol = 0x > > bMaxPacketSize0 = 0x0040 > > idVendor = 0x12d1 > > idProduct = 0x1f01 > > bcdDevice = 0x0102 > > iManufacturer = 0x0002 > > iProduct = 0x0001 > > iSerialNumber = 0x0004 > > bNumConfigurations = 0x0001 > > > > If anything else is important, let me know. > > > > Regards, > > Milan > > Try ejecting first this cd2 drive by cdcontrol eject or camcontrol > eject. I had such scenario with other usb device and that helped. > Nothing. # camcontrol eject cd2 Unit stopped successfully, Media ejected That's all. No new device created, neither in /dev directory nor in ifconfig listing. Nothing in console log. >From 'usbconfig dump_all_config_desc': ugen1.3: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0020 bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x0003 bmAttributes = 0x0080 bMaxPower = 0x00fa Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0002 bInterfaceClass = 0x0008 bInterfaceSubClass = 0x0006 bInterfaceProtocol = 0x0050 iInterface = 0x Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0001 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Regards, Milan ___ 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: Huawei E3272 tester needed
On 09/16/14 22:18, Milan Obuch wrote: On Tue, 16 Sep 2014 21:55:50 +0200 Maciej Milewski wrote: On 16.09.2014 16:52, Milan Obuch wrote: On Tue, 16 Sep 2014 09:40:45 +0200 Nick Hibma wrote: Hi, Is there someone who is able to test support for the Huawei E3272 card with CURRENT after 269584? I have not been able to confirm that it works. Thanks in advance. Nick Hi, I did fresh svn update, rebuilt world+kernel, but it does not work for me... [ snip ] Hi, According to the modeswitch: usbconfig -d X.Y add_quirk UQ_MSC_EJECT_HUAWEISCSI2 Then re-plug the device. --HPS ___ 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: Huawei E3272 tester needed
On 16.09.2014 22:18, Milan Obuch wrote: > On Tue, 16 Sep 2014 21:55:50 +0200 > Maciej Milewski wrote: > >> On 16.09.2014 16:52, Milan Obuch wrote: >>> On Tue, 16 Sep 2014 09:40:45 +0200 >>> Nick Hibma wrote: >>> Hi, Is there someone who is able to test support for the Huawei E3272 card with CURRENT after 269584? I have not been able to confirm that it works. Thanks in advance. Nick >>> Hi, >>> >>> I did fresh svn update, rebuilt world+kernel, but it does not work >>> for me... > [ snip ] > >>> I tried attach/detach device beore and after loading u3g (just in >>> case...) and if_cdce kernel modules, but I saw no changes. >>> >>> From 'usbconfig dump_device_desc': >>> >>> ugen1.3: at usbus1, cfg=0 md=HOST >>> spd=HIGH (480Mbps) pwr=ON (500mA) >>> >>> bLength = 0x0012 >>> bDescriptorType = 0x0001 >>> bcdUSB = 0x0200 >>> bDeviceClass = 0x >>> bDeviceSubClass = 0x >>> bDeviceProtocol = 0x >>> bMaxPacketSize0 = 0x0040 >>> idVendor = 0x12d1 >>> idProduct = 0x1f01 >>> bcdDevice = 0x0102 >>> iManufacturer = 0x0002 >>> iProduct = 0x0001 >>> iSerialNumber = 0x0004 >>> bNumConfigurations = 0x0001 >>> >>> If anything else is important, let me know. >>> >>> Regards, >>> Milan >> Try ejecting first this cd2 drive by cdcontrol eject or camcontrol >> eject. I had such scenario with other usb device and that helped. >> > Nothing. > > # camcontrol eject cd2 > Unit stopped successfully, Media ejected > > That's all. No new device created, neither in /dev directory nor in > ifconfig listing. Nothing in console log. > > From 'usbconfig dump_all_config_desc': > > ugen1.3: at usbus1, cfg=0 md=HOST spd=HIGH > (480Mbps) pwr=ON (500mA) > > Configuration index 0 > > bLength = 0x0009 > bDescriptorType = 0x0002 > wTotalLength = 0x0020 > bNumInterfaces = 0x0001 > bConfigurationValue = 0x0001 > iConfiguration = 0x0003 > bmAttributes = 0x0080 > bMaxPower = 0x00fa > > Interface 0 > bLength = 0x0009 > bDescriptorType = 0x0004 > bInterfaceNumber = 0x > bAlternateSetting = 0x > bNumEndpoints = 0x0002 > bInterfaceClass = 0x0008 > bInterfaceSubClass = 0x0006 > bInterfaceProtocol = 0x0050 > iInterface = 0x > > Endpoint 0 > bLength = 0x0007 > bDescriptorType = 0x0005 > bEndpointAddress = 0x0001 > bmAttributes = 0x0002 > wMaxPacketSize = 0x0200 > bInterval = 0x > bRefresh = 0x > bSynchAddress = 0x > > Endpoint 1 > bLength = 0x0007 > bDescriptorType = 0x0005 > bEndpointAddress = 0x0081 > bmAttributes = 0x0002 > wMaxPacketSize = 0x0200 > bInterval = 0x > bRefresh = 0x > bSynchAddress = 0x > > Regards, > Milan Your device has different idProduct than this added in patch. It might be caused by different configuration of the device/different provider who sells devices. I know that some devices might show up as HiLink mode(cdce) or serial mode(u3g). And this might be changed by flashing different firmware or sometimes by using usb_modeswitch(under linux not sure if it works under freebsd). Example is here: https://forum.pfsense.org/index.php?topic=48780.20;wap2 -- Pozdrawiam, Maciej Milewski ___ 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: Huawei E3272 tester needed
On Tue, 16 Sep 2014 22:35:19 +0200 Hans Petter Selasky wrote: > On 09/16/14 22:18, Milan Obuch wrote: > > On Tue, 16 Sep 2014 21:55:50 +0200 > > Maciej Milewski wrote: > > > >> On 16.09.2014 16:52, Milan Obuch wrote: > >>> On Tue, 16 Sep 2014 09:40:45 +0200 > >>> Nick Hibma wrote: > >>> > Hi, > > Is there someone who is able to test support for the Huawei E3272 > card with CURRENT after 269584? I have not been able to confirm > that it works. > > Thanks in advance. > > Nick > > >>> Hi, > >>> > >>> I did fresh svn update, rebuilt world+kernel, but it does not work > >>> for me... > > > > [ snip ] > > > > Hi, > > According to the modeswitch: > > usbconfig -d X.Y add_quirk UQ_MSC_EJECT_HUAWEISCSI2 > > Then re-plug the device. > > --HPS > Well, again, no change: #usbconfig -d 1.3 add_quirk UQ_MSC_EJECT_HUAWEISCSI2 Adding quirk 'UQ_MSC_EJECT_HUAWEISCSI2' failed, continuing. Did I do it right? Something is surely wrong. By the way, from uname: 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271671M The only modified file is modules/drm2/Makefile because for some reason radeonkms does not currently build, so I excluded is as a fast workaround. Milan ___ 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"
zpool: multiple IDs, CURRENT drops all pools after reboot
On of my backup drives dedicated to a ZPOOL is faulting and showing up multiple ID. The only working ID is id: 257822624560506537. FreeBSD CURRENT with three ZFS disks and only 4GB of RAM is very "flaky" regarding this issue: today, tow times the whole poolset vanishes after a reboot. Giving the box 8 GB total and rebooting doens't show the problem, it gets more frequent when reducing the RAM to 4GB (FreeBSD 11.0-CURRENT #2 r271684: Tue Sep 16 20:41:47 CEST 2014). This is a bit spooky. Below the faulted harddrive. I guess the drive/pool below shown triggers somehow the loss of all other pools (I have to import the other pools, which do not have any defects, but they they drop out after a reboot and vanish). Is there a way getting rid of the faulty IDs without destroying the pool? Regards, Oliver root@thor: [/etc] zpool import pool: BACKUP00 id: 9337833315545958689 state: FAULTED status: One or more devices contains corrupted data. action: The pool cannot be imported due to damaged devices or data. The pool may be active on another system, but can be imported using the '-f' flag. see: http://illumos.org/msg/ZFS-8000-5E config: BACKUP00 FAULTED corrupted data 8544670861382329237 UNAVAIL corrupted data pool: BACKUP00 id: 257822624560506537 state: ONLINE action: The pool can be imported using its name or numeric identifier. config: BACKUP00ONLINE ada3p1ONLINE signature.asc Description: PGP signature
Re: CURRENT: EFI boot failure
Am Tue, 16 Sep 2014 00:09:01 -0700 Nathan Whitehorn schrieb: > > On 09/15/14 22:51, O. Hartmann wrote: > > Am Mon, 15 Sep 2014 17:39:26 -0700 > > Nathan Whitehorn schrieb: > > > >> On 09/15/14 17:36, Allan Jude wrote: > >>> On 2014-09-15 20:05, O. Hartmann wrote: > Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop works > for UEFI > fine. After I updated the sources to r271649, recompiled world and > kernel (as well > as installed), now I get stuck with the screen message: > > >> FreeBSD EFI boot block > Loader path: /boot/loader.efi > > and nothing happens. After a couple of minutes, the system reboots. > > What happened and how can this problem be solved? > > >>> You might need to update the boot1.efi file on the UEFI partition (small > >>> FAT partition on the disk) > >>> > >>> I am not sure how 'in sync' boot1.efi (on the fat partiton) and > >>> loader.efi have to be. > >>> > >>> https://wiki.freebsd.org/UEFI > >>> > >> boot1.efi is designed never to need updating. (It also hasn't changed > >> since April) > >> -Nathan > > > > But it has changed bytesize when I recompiled world with recent sources > > compared to > > the boot.efi size from the USB image I installed from (revision see above). > > Probably compiler updates or something? I really wouldn't worry about it > too much. I'd worry more about loader, since we know boot1 could use the > console but loader doesn't show up. Well, I have to worry about because the system is stuck and completely unusable. I installed the system from the very same USB drive image as mentioned above again. Then, after the newtork issue has been fixed, I was able to update sources and built world. As long as I do not attempt to use to use X, everything is fine. > > > How to update bootcode on UEFI layout? I created a GPT partition with type > > efi (1 GB) > > as well as a 512KB partition typed freebsd-boot. > > How did you set it up in the first place? If you have a FreeBSD-only > system partition (like the installer sets up), you just dd > /boot/boot1.efifat to the EFI partition. Otherwise, it's FAT and you > copy /boot/boot1.efi to somewhere your boot manager can find it. The setup was plain and vanilla. I used the installer of the USB image (see above). Creating GPT partition scheme and two partitions of type "efi" and "freebsd-boot", first 1MB, latter 512KB. All other partitions are freebsd-ufs, exept freebsd-swap. In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi? What is the difference? Is the efi partition FAT? > > > I'm new to EFI and the way the notebook now behaves is really strange. > > While the USB > > drive image used to boot with new console enabled, it now boots again with > > the old > > console and 800x640 resolution. This might indicate some minor but very > > effective > > mistake I made. > > > > The EFI boot block finds the first UFS partition -- on any disk -- and > tries to boot from it. If you have multiple FreeBSD disks connected, > that will very likely result in madness. > -Nathan It is one disk, dedicated to FreeBSD (a laptop disk). Is there any documentation readable for non-developer for that matter? I'm curious about how EFI works on FreeBSD. Oliver signature.asc Description: PGP signature
Re: CURRENT: EFI boot failure
Am Mon, 15 Sep 2014 20:36:23 -0400 Allan Jude schrieb: > On 2014-09-15 20:05, O. Hartmann wrote: > > > > Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop works > > for UEFI > > fine. After I updated the sources to r271649, recompiled world and kernel > > (as well as > > installed), now I get stuck with the screen message: > > > >>> FreeBSD EFI boot block > >Loader path: /boot/loader.efi > > > > and nothing happens. After a couple of minutes, the system reboots. > > > > What happened and how can this problem be solved? > > > > You might need to update the boot1.efi file on the UEFI partition (small > FAT partition on the disk) > > I am not sure how 'in sync' boot1.efi (on the fat partiton) and > loader.efi have to be. > > https://wiki.freebsd.org/UEFI > Is it boot1.efi or is it boot1.efifat? signature.asc Description: PGP signature
Re: zpool: multiple IDs, CURRENT drops all pools after reboot
On of my backup drives dedicated to a ZPOOL is faulting and showing up multiple ID. The only working ID is id: 257822624560506537. FreeBSD CURRENT with three ZFS disks and only 4GB of RAM is very "flaky" regarding this issue: today, tow times the whole poolset vanishes after a reboot. Giving the box 8 GB total and rebooting doens't show the problem, it gets more frequent when reducing the RAM to 4GB (FreeBSD 11.0-CURRENT #2 r271684: Tue Sep 16 20:41:47 CEST 2014). This is a bit spooky. Below the faulted harddrive. I guess the drive/pool below shown triggers somehow the loss of all other pools (I have to import the other pools, which do not have any defects, but they they drop out after a reboot and vanish). Is there a way getting rid of the faulty IDs without destroying the pool? Regards, Oliver root@thor: [/etc] zpool import pool: BACKUP00 id: 9337833315545958689 state: FAULTED status: One or more devices contains corrupted data. action: The pool cannot be imported due to damaged devices or data. The pool may be active on another system, but can be imported using the '-f' flag. see: http://illumos.org/msg/ZFS-8000-5E config: BACKUP00 FAULTED corrupted data 8544670861382329237 UNAVAIL corrupted data pool: BACKUP00 id: 257822624560506537 state: ONLINE action: The pool can be imported using its name or numeric identifier. config: BACKUP00ONLINE ada3p1ONLINE Might be a long shot but check out the patches on: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 Specifically: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147070 And if that doesn't work: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147286 The second has all the changes from the first with the addition of some changes which dynamically size the max dirty data. These changes are in discussion and its likely the additions in the second patch aren't the right direction but they have been reported to show good improvements under high memory pressure for certain workloads, so would be interesting to see if they help with your problem. All that said you shouldnt end up with corrupt data no matter what. Are there any other symptoms? Has memory been checked for faults etc? Regards Steve ___ 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: CURRENT: EFI boot failure
On 16 September 2014 17:03, O. Hartmann wrote: > > In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi? What > is the > difference? Is the efi partition FAT? An EFI system partition (ESP) is a FAT-formatted partition with a specific GPT or MBR identifier and file system hierarchy; EFI firmware will try to load /EFI/BOOT/BOOTX64.EFI from the ESP. boot1.efi is an EFI application - that is, a PECOFF format binary. It searches for a UFS filesystem and loads loader.efi from that. It is intended to simplify the UEFI boot process, so that loader.efi, the .4th files, loader.conf etc. do not all need to be installed in the ESP. boot1.efifat is a FAT filesystem image that contains a copy of boot1.efi as /EFI/BOOT/BOOTX64.EFI. It exists so that the installer can treat it as opaque bootcode, like other boot schemes. It's certainly possible to create a partition, use newfs_msdos to format it, and copy in boot1.efi instead. > It is one disk, dedicated to FreeBSD (a laptop disk). Is there any > documentation readable > for non-developer for that matter? I'm curious about how EFI works on FreeBSD. Better user-facing documentation is in progress; for now the best source is probably the wik. ___ 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: CURRENT: EFI boot failure
Am Tue, 16 Sep 2014 00:09:01 -0700 Nathan Whitehorn schrieb: > > On 09/15/14 22:51, O. Hartmann wrote: > > Am Mon, 15 Sep 2014 17:39:26 -0700 > > Nathan Whitehorn schrieb: > > > >> On 09/15/14 17:36, Allan Jude wrote: > >>> On 2014-09-15 20:05, O. Hartmann wrote: > Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop works > for UEFI > fine. After I updated the sources to r271649, recompiled world and > kernel (as well > as installed), now I get stuck with the screen message: > > >> FreeBSD EFI boot block > Loader path: /boot/loader.efi > > and nothing happens. After a couple of minutes, the system reboots. > > What happened and how can this problem be solved? > > >>> You might need to update the boot1.efi file on the UEFI partition (small > >>> FAT partition on the disk) > >>> > >>> I am not sure how 'in sync' boot1.efi (on the fat partiton) and > >>> loader.efi have to be. > >>> > >>> https://wiki.freebsd.org/UEFI > >>> > >> boot1.efi is designed never to need updating. (It also hasn't changed > >> since April) > >> -Nathan > > > > But it has changed bytesize when I recompiled world with recent sources > > compared to > > the boot.efi size from the USB image I installed from (revision see above). > > Probably compiler updates or something? I really wouldn't worry about it > too much. I'd worry more about loader, since we know boot1 could use the > console but loader doesn't show up. > > > How to update bootcode on UEFI layout? I created a GPT partition with type > > efi (1 GB) > > as well as a 512KB partition typed freebsd-boot. > > How did you set it up in the first place? If you have a FreeBSD-only > system partition (like the installer sets up), you just dd > /boot/boot1.efifat to the EFI partition. Otherwise, it's FAT and you > copy /boot/boot1.efi to somewhere your boot manager can find it. > > > I'm new to EFI and the way the notebook now behaves is really strange. > > While the USB > > drive image used to boot with new console enabled, it now boots again with > > the old > > console and 800x640 resolution. This might indicate some minor but very > > effective > > mistake I made. > > > > The EFI boot block finds the first UFS partition -- on any disk -- and > tries to boot from it. If you have multiple FreeBSD disks connected, > that will very likely result in madness. > -Nathan > ___ > 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" After I managed to install the OS and updated to the most recent world, it took two days to have all the installations prepared. Now I'm about the configure X11 and run into another very annoying situation. The Laptop is a Lenovo ThinkPad Edge E540 equipted with the following CPU/iGPU and dedicated GPU: CPU Intel i5-4200M (Haswell) at 2.5 GHz with iGPU Intel HD Graphics 4600 GPU: nVidia GT 740M mobile GPU. EFI Version 2.31 EFI Firmware: Lenovo (rev. 05648) In the Firmware/EFI/BIOS the primary GPU is selected to be the nVidia GT 740M. Boot is EFI only, no CSM support. With CSM support enabled a VGA screen with 640x400 pixel shows up. Non UEFI options doesn't boot this system at all! Any attempt to bring up the nVidia GPU (starting X for testing) ends up in a blank screen, stuck mousepointer, no keyboard. I even can not switch to another console! When X server started the first time on tty9, I can switch to another console. But the moment I switch back to ttyv9 everything is frozen and as described above. When the system boots, I do not see a loader! Where is the loader I'm used to see when I have the chance to switch to single user mode, console or switch off ACPI? Because I need X11 up (and it should be running on the nVidia GPU for performance reasons), I tried to get back to the legacy "sc" console in textmode since I read about several issues and immature vt() system, so I put those lines in the /boot/loader.conf: hw.vga.textmode=1 hw.vty=sc (tried also hw.vty=vt). But with either of those lines in the loader thing get more annoying and nasty: The system doesn't show even a console, it is stuck with this sparse EFI boot message, last lines are dimensions x stride masks 0xfff [...] and the rest of the screen is blank. System remains unusable, the HDD is working and obviously booting the system but incapable of presenting a screen. When booting the USB drive image, this initial EFI message gets overwritten (no screen blanking, the kernel messages starts writing over this message like in the first days of computers ...). In the case described above that doesn't happen at all. After I deleted.commented out the lines hw.vga.textmode=1 hw.vty=sc in loader.conf the system is booting again - and clears the initial EFI messages before dumping t
Re: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI
Am Tue, 16 Sep 2014 08:40:25 -0700 Adrian Chadd schrieb: > Ah, jumbo frames. Maybe you got lucky and some ethernet drivers > default to accepting larger frames even if the MTU is 1500. > > > -a It is not the jumbo frame that makes this specific NIC work, I have to set the mtu explicitely to make it work. To make this notebook work in different departments, I need to use DHCP. At the moment I have to set the mtu manually, disbaling and reenabling the NIC (ifconfig re0 down, ifconfig re0 mtu , ifconfig re0 up). This seems to be strange. After that, the NIC seems to work as expected and the Laptop has connection. Oliver signature.asc Description: PGP signature
Re: CURRENT: EFI boot failure
Am Tue, 16 Sep 2014 17:32:12 -0400 Ed Maste schrieb: > On 16 September 2014 17:03, O. Hartmann wrote: > > > > In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi? What > > is the > > difference? Is the efi partition FAT? > > An EFI system partition (ESP) is a FAT-formatted partition with a > specific GPT or MBR identifier and file system hierarchy; EFI firmware > will try to load /EFI/BOOT/BOOTX64.EFI from the ESP. > > boot1.efi is an EFI application - that is, a PECOFF format binary. It > searches for a UFS filesystem and loads loader.efi from that. It is > intended to simplify the UEFI boot process, so that loader.efi, the > .4th files, loader.conf etc. do not all need to be installed in the > ESP. Thank you very much for the explanation. Well, since I never see the loader screen as we are used to, were is that gone? There are no boot options anymore (like single user mode, ACPI off et cetera). Is this intended? Besides, checking both boot1.efi and loader.efi with file() shows something like loader.efi: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows. So both are PECOFF format files? > > boot1.efifat is a FAT filesystem image that contains a copy of > boot1.efi as /EFI/BOOT/BOOTX64.EFI. It exists so that the installer > can treat it as opaque bootcode, like other boot schemes. It's > certainly possible to create a partition, use newfs_msdos to format > it, and copy in boot1.efi instead. All right, here you lost me ... sorry. The partition created by the installes with type "efi" is then the /EFI/ partition, which then contains a folder BOOT and in which the boot1.efi is located? As I understand, I can manually mount this partition as FAT and copy boot1.efi as BOOTX64.EFI into it? This knowledge could come in handy if something goes very bad. > > > It is one disk, dedicated to FreeBSD (a laptop disk). Is there any > > documentation > > readable for non-developer for that matter? I'm curious about how EFI works > > on > > FreeBSD. > > Better user-facing documentation is in progress; for now the best > source is probably the wik. Thank you. signature.asc Description: PGP signature
Re: CURRENT: EFI boot failure
On 17/09/2014 00:32, Ed Maste wrote: > On 16 September 2014 17:03, O. Hartmann wrote: >> >> In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi? What >> is the >> difference? Is the efi partition FAT? > > An EFI system partition (ESP) is a FAT-formatted partition with a > specific GPT or MBR identifier and file system hierarchy; EFI firmware > will try to load /EFI/BOOT/BOOTX64.EFI from the ESP. A very useful read about how EFI boot process works and how different OSes boot on top of it: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html > boot1.efi is an EFI application - that is, a PECOFF format binary. It > searches for a UFS filesystem and loads loader.efi from that. It is > intended to simplify the UEFI boot process, so that loader.efi, the > .4th files, loader.conf etc. do not all need to be installed in the > ESP. > > boot1.efifat is a FAT filesystem image that contains a copy of > boot1.efi as /EFI/BOOT/BOOTX64.EFI. It exists so that the installer > can treat it as opaque bootcode, like other boot schemes. It's > certainly possible to create a partition, use newfs_msdos to format > it, and copy in boot1.efi instead. > >> It is one disk, dedicated to FreeBSD (a laptop disk). Is there any >> documentation readable >> for non-developer for that matter? I'm curious about how EFI works on >> FreeBSD. > > Better user-facing documentation is in progress; for now the best > source is probably the wik. > ___ > 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" > -- Andriy Gapon ___ 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: CURRENT: EFI boot failure
Am Wed, 17 Sep 2014 01:25:07 +0300 Andriy Gapon schrieb: > On 17/09/2014 00:32, Ed Maste wrote: > > On 16 September 2014 17:03, O. Hartmann wrote: > >> > >> In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi? > >> What is the > >> difference? Is the efi partition FAT? > > > > An EFI system partition (ESP) is a FAT-formatted partition with a > > specific GPT or MBR identifier and file system hierarchy; EFI firmware > > will try to load /EFI/BOOT/BOOTX64.EFI from the ESP. > > A very useful read about how EFI boot process works and how different OSes > boot > on top of it: > http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html Great! > > > boot1.efi is an EFI application - that is, a PECOFF format binary. It > > searches for a UFS filesystem and loads loader.efi from that. It is > > intended to simplify the UEFI boot process, so that loader.efi, the > > .4th files, loader.conf etc. do not all need to be installed in the > > ESP. > > > > boot1.efifat is a FAT filesystem image that contains a copy of > > boot1.efi as /EFI/BOOT/BOOTX64.EFI. It exists so that the installer > > can treat it as opaque bootcode, like other boot schemes. It's > > certainly possible to create a partition, use newfs_msdos to format > > it, and copy in boot1.efi instead. > > > >> It is one disk, dedicated to FreeBSD (a laptop disk). Is there any > >> documentation > >> readable for non-developer for that matter? I'm curious about how EFI > >> works on > >> FreeBSD. > > > > Better user-facing documentation is in progress; for now the best > > source is probably the wik. > > ___ > > 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" > > > > signature.asc Description: PGP signature
Re: zpool: multiple IDs, CURRENT drops all pools after reboot
Am Tue, 16 Sep 2014 22:06:36 +0100 "Steven Hartland" schrieb: > > On of my backup drives dedicated to a ZPOOL is faulting and showing up > > multiple ID. > > The only working ID is id: 257822624560506537. > > > > FreeBSD CURRENT with three ZFS disks and only 4GB of RAM is very "flaky" > > regarding > > this issue: today, tow times the whole poolset vanishes after a reboot. > > Giving the > > box 8 GB total and rebooting doens't show the problem, it gets more > > frequent when > > reducing the RAM to 4GB (FreeBSD 11.0-CURRENT #2 r271684: Tue Sep 16 > > 20:41:47 CEST > > 2014). This is a bit spooky. > > > > Below the faulted harddrive. I guess the drive/pool below shown triggers > > somehow the > > loss of all other pools (I have to import the other pools, which do not > > have any > > defects, but they they drop out after a reboot and vanish). > > > > Is there a way getting rid of the faulty IDs without destroying the pool? > > > > Regards, > > > > Oliver > > > > root@thor: [/etc] zpool import > >pool: BACKUP00 > > id: 9337833315545958689 > > state: FAULTED > > status: One or more devices contains corrupted data. > > action: The pool cannot be imported due to damaged devices or data. > > The pool may be active on another system, but can be imported using > > the '-f' flag. > >see: http://illumos.org/msg/ZFS-8000-5E > > config: > > > > BACKUP00 FAULTED corrupted data > > 8544670861382329237 UNAVAIL corrupted data > > > >pool: BACKUP00 > > id: 257822624560506537 > > state: ONLINE > > action: The pool can be imported using its name or numeric identifier. > > config: > > > > BACKUP00ONLINE > > ada3p1ONLINE > > > > Might be a long shot but check out the patches on: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 > > Specifically: > https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147070 > > And if that doesn't work: > https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147286 > > The second has all the changes from the first with the addition > of some changes which dynamically size the max dirty data. > > These changes are in discussion and its likely the additions > in the second patch aren't the right direction but they > have been reported to show good improvements under high > memory pressure for certain workloads, so would be interesting > to see if they help with your problem. > > All that said you shouldnt end up with corrupt data no matter > what. > > Are there any other symptoms? Has memory been checked for > faults etc? > > Regards > Steve The reason why my desktop has only 4 GB left is that I discovered memory corruption when equipted with 8 GB - there occured a strange bit flip. I can not assure that by ripping off 4 GB (2 times 2GB, it is an old C2D/P45 based box) the problem has gone. I susepct a dying chipset - when overheated (at the moment BIOS shows 80 degrees Celsius), the problem is more frequent. But, besindes data corruption, with 4 GB left and 2 disks put together as a striped JBOD with another disk as the backup device (the faulty one) is a pain in the ass since the box starts swapping immediately when some action on the ZFS drives take place. The plan is to keep that craveyward alive for the next 2 months until I can afford a new system ;-) But anyway, I'll try the patches. Thanks, Oliver signature.asc Description: PGP signature
Re: zpool: multiple IDs, CURRENT drops all pools after reboot
On 17 Sep, O. Hartmann wrote: > Am Tue, 16 Sep 2014 22:06:36 +0100 > "Steven Hartland" schrieb: >> All that said you shouldnt end up with corrupt data no matter >> what. >> >> Are there any other symptoms? Has memory been checked for >> faults etc? >> >> Regards >> Steve > > The reason why my desktop has only 4 GB left is that I discovered memory > corruption when > equipted with 8 GB - there occured a strange bit flip. I can not assure that > by ripping > off 4 GB (2 times 2GB, it is an old C2D/P45 based box) the problem has gone. > I susepct > a dying chipset - when overheated (at the moment BIOS shows 80 degrees > Celsius), the > problem is more frequent. You might want to try relaxing the memory timing in the BIOS. In particular, try adding some cycles to CAS Latency. I've had a couple of systems with ECC RAM that had excessive ECC errors with the default RAM timing that got much better when I increased CAS Latency. You might also want to try rigging an extra fan to blow on the RAM and/or chipset. ___ 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: CURRENT: EFI boot failure
On 09/16/14 14:50, O. Hartmann wrote: Am Tue, 16 Sep 2014 00:09:01 -0700 Nathan Whitehorn schrieb: On 09/15/14 22:51, O. Hartmann wrote: Am Mon, 15 Sep 2014 17:39:26 -0700 Nathan Whitehorn schrieb: On 09/15/14 17:36, Allan Jude wrote: On 2014-09-15 20:05, O. Hartmann wrote: Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop works for UEFI fine. After I updated the sources to r271649, recompiled world and kernel (as well as installed), now I get stuck with the screen message: FreeBSD EFI boot block Loader path: /boot/loader.efi and nothing happens. After a couple of minutes, the system reboots. What happened and how can this problem be solved? You might need to update the boot1.efi file on the UEFI partition (small FAT partition on the disk) I am not sure how 'in sync' boot1.efi (on the fat partiton) and loader.efi have to be. https://wiki.freebsd.org/UEFI boot1.efi is designed never to need updating. (It also hasn't changed since April) -Nathan But it has changed bytesize when I recompiled world with recent sources compared to the boot.efi size from the USB image I installed from (revision see above). Probably compiler updates or something? I really wouldn't worry about it too much. I'd worry more about loader, since we know boot1 could use the console but loader doesn't show up. How to update bootcode on UEFI layout? I created a GPT partition with type efi (1 GB) as well as a 512KB partition typed freebsd-boot. How did you set it up in the first place? If you have a FreeBSD-only system partition (like the installer sets up), you just dd /boot/boot1.efifat to the EFI partition. Otherwise, it's FAT and you copy /boot/boot1.efi to somewhere your boot manager can find it. I'm new to EFI and the way the notebook now behaves is really strange. While the USB drive image used to boot with new console enabled, it now boots again with the old console and 800x640 resolution. This might indicate some minor but very effective mistake I made. The EFI boot block finds the first UFS partition -- on any disk -- and tries to boot from it. If you have multiple FreeBSD disks connected, that will very likely result in madness. -Nathan ___ 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" After I managed to install the OS and updated to the most recent world, it took two days to have all the installations prepared. Now I'm about the configure X11 and run into another very annoying situation. The Laptop is a Lenovo ThinkPad Edge E540 equipted with the following CPU/iGPU and dedicated GPU: CPU Intel i5-4200M (Haswell) at 2.5 GHz with iGPU Intel HD Graphics 4600 GPU: nVidia GT 740M mobile GPU. EFI Version 2.31 EFI Firmware: Lenovo (rev. 05648) In the Firmware/EFI/BIOS the primary GPU is selected to be the nVidia GT 740M. Boot is EFI only, no CSM support. With CSM support enabled a VGA screen with 640x400 pixel shows up. Non UEFI options doesn't boot this system at all! Any attempt to bring up the nVidia GPU (starting X for testing) ends up in a blank screen, stuck mousepointer, no keyboard. I even can not switch to another console! When X server started the first time on tty9, I can switch to another console. But the moment I switch back to ttyv9 everything is frozen and as described above. Try xf86-video-scfb instead? When the system boots, I do not see a loader! Where is the loader I'm used to see when I have the chance to switch to single user mode, console or switch off ACPI? There is no beastie menu for UEFI, and will not be, since it UEFI's terminal emulation does not provide the required features. You can boot single user from the loader command line, however, with boot -s, for example. The interface is identical to what you get if you choose "Loader prompt" in the usual menu. Because I need X11 up (and it should be running on the nVidia GPU for performance reasons), I tried to get back to the legacy "sc" console in textmode since I read about several issues and immature vt() system, so I put those lines in the /boot/loader.conf: hw.vga.textmode=1 hw.vty=sc (tried also hw.vty=vt). But with either of those lines in the loader thing get more annoying and nasty: The system doesn't show even a console, it is stuck with this sparse EFI boot message, last lines are dimensions x stride masks 0xfff [...] and the rest of the screen is blank. System remains unusable, the HDD is working and obviously booting the system but incapable of presenting a screen. When booting the USB drive image, this initial EFI message gets overwritten (no screen blanking, the kernel messages starts writing over this message like in the first days of computers ...). In the case described above that doesn't happen at all. syscons does not support UEFI systems at all.
Re: CURRENT: EFI boot failure
On 16 September 2014 18:25, O. Hartmann wrote: > > Besides, checking both boot1.efi and loader.efi with file() shows something > like > loader.efi: PE32+ executable (EFI application) x86-64 (stripped to external > PDB), for MS > Windows. So both are PECOFF format files? That is correct. >> >> boot1.efifat is a FAT filesystem image that contains a copy of >> boot1.efi as /EFI/BOOT/BOOTX64.EFI. It exists so that the installer >> can treat it as opaque bootcode, like other boot schemes. It's >> certainly possible to create a partition, use newfs_msdos to format >> it, and copy in boot1.efi instead. > > All right, here you lost me ... sorry. The partition created by the installes > with type > "efi" is then the /EFI/ partition, which then contains a folder BOOT and in > which the > boot1.efi is located? > As I understand, I can manually mount this partition as FAT and copy > boot1.efi as > BOOTX64.EFI into it? This knowledge could come in handy if something goes > very bad. Sorry, not quite; an ESP is a separate partition formatted with FAT. The file system in that partition has EFI/ in the root directory, BOOT/ under that, and BOOTX64.EFI in there. We don't (yet) mount the ESP inside of FreeBSD by default. At least some Linuxes do mount the ESP at /boot/efi, so you end up with /boot/efi/EFI/BOOT/BOOTX64.EFI. We might start doing something similar when fleshing out dual-boot configuration support. boot1.efifat is a copy (image) of the ESP, as it exists on the disk. You can see what's inside: # mdconfig -a -f /boot/boot1.efifat md0 # mount_msdosfs /dev/md0 /mnt # ls -l /mnt/efi/boot/BOOTx64.efi -rwxr-xr-x 1 root wheel 65536 Apr 26 20:43 /mnt/efi/boot/BOOTx64.efi # umount /mnt # mdconfig -d -u 0 ___ 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: CURRENT: EFI boot failure
On 16 September 2014 18:54, Nathan Whitehorn wrote: > > On 09/16/14 14:50, O. Hartmann wrote: >> >> When the system boots, I do not see a loader! Where is the loader I'm used >> to see when I >> have the chance to switch to single user mode, console or switch off ACPI? > > > There is no beastie menu for UEFI, and will not be, since it UEFI's terminal > emulation does not provide the required features. You can boot single user > from the loader command line, however, with boot -s, for example. The > interface is identical to what you get if you choose "Loader prompt" in the > usual menu. As Nathan says there's no beastie menu, but you should still see the loader. If you get a "Hit [Enter] to boot immediately, or any other key for command prompt." message, you're seeing the loader. There is an additional complication that affects some systems, where we do not switch to text mode. In this case you truly won't see the loader. This is described in the link Andriy provided (along with a workaround), and we have a patch in progress for this. So far this mainly known to affect MacBooks. ___ 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"
Cam panic on r271170
I've been getting this quite frequently on head recently. I have dumps if anyone is interested in more information. Fatal trap 9: general protection fault while in kernel mode cpuid = 10; Memory modified after free 0xf8003e0b0800(2040) val= @ 0xf8003e0b0808 apanic: Most recently used by CAM CCB cpuid = 6 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe124735b4c0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe124735b570 vpanic() at vpanic+0x189/frame 0xfe124735b5f0 panic() at panic+0x43/frame 0xfe124735b650 mtrash_ctor() at mtrash_ctor+0x8a/frame 0xfe124735b680 uma_zalloc_arg() at uma_zalloc_arg+0x4f1/frame 0xfe124735b6f0 malloc() at malloc+0x192/frame 0xfe124735b740 xpt_run_allocq() at xpt_run_allocq+0xb5/frame 0xfe124735b780 adastrategy() at adastrategy+0x117/frame 0xfe124735b7b0 g_io_request() at g_io_request+0x3b7/frame 0xfe124735b810 g_part_start() at g_part_start+0x2b7/frame 0xfe124735b890 g_io_request() at g_io_request+0x3b7/frame 0xfe124735b8f0 g_io_request() at g_io_request+0x3b7/frame 0xfe124735b950 vdev_geom_io_start() at vdev_geom_io_start+0x137/frame 0xfe124735b970 zio_vdev_io_start() at zio_vdev_io_start+0x49f/frame 0xfe124735b9d0 zio_execute() at zio_execute+0x204/frame 0xfe124735ba30 vdev_queue_io_done() at vdev_queue_io_done+0x180/frame 0xfe124735ba80 zio_vdev_io_done() at zio_vdev_io_done+0x11d/frame 0xfe124735bac0 zio_execute() at zio_execute+0x204/frame 0xfe124735bb20 taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xfe124735bb80 taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame 0xfe124735bbb0 fork_exit() at fork_exit+0x84/frame 0xfe124735bbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe124735bbf0 --- trap 0, rip = 0, rsp = 0xfe124735bcb0, rbp = 0 --- KDB: enter: panic [ thread pid 0 tid 100571 ] Stopped at kdb_enter+0x3e: movq$0,kdb_why -- Regards, Bryan Drewery ___ 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: Huawei E3272 tester needed
On 09/16/14 22:52, Milan Obuch wrote: On Tue, 16 Sep 2014 22:35:19 +0200 Hans Petter Selasky wrote: On 09/16/14 22:18, Milan Obuch wrote: On Tue, 16 Sep 2014 21:55:50 +0200 Maciej Milewski wrote: On 16.09.2014 16:52, Milan Obuch wrote: On Tue, 16 Sep 2014 09:40:45 +0200 Nick Hibma wrote: Hi, Is there someone who is able to test support for the Huawei E3272 card with CURRENT after 269584? I have not been able to confirm that it works. Thanks in advance. Nick Hi, I did fresh svn update, rebuilt world+kernel, but it does not work for me... [ snip ] Hi, According to the modeswitch: usbconfig -d X.Y add_quirk UQ_MSC_EJECT_HUAWEISCSI2 Then re-plug the device. --HPS Well, again, no change: #usbconfig -d 1.3 add_quirk UQ_MSC_EJECT_HUAWEISCSI2 Adding quirk 'UQ_MSC_EJECT_HUAWEISCSI2' failed, continuing. Did I do it right? Something is surely wrong. By the way, from uname: 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271671M The only modified file is modules/drm2/Makefile because for some reason radeonkms does not currently build, so I excluded is as a fast workaround. Hi, Did you kldload usb_quirk And does: usbconfig dump_quirk_names yield something? --HPS ___ 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"
Fwd: usb printer vs cups
Soliciting help. Forwarded Message >From my experience I think that cupsd executes backend tools with all uids and gids set to cups and no supplementary groups. In the case of USB printers the backends need to access /dev/usbctl and /dev/usb/foobar that corresponds to a printer. That means that the access to those devices must be somehow granted to cups:cups. How do people solve this? What kind of permissions / configuration do you use? P.S. Maybe I over-generalized the issue to all USB printers. My personal experience is with an HP printer handled by hplip / hplip-plugin. -- Andriy Gapon ___ 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: Fwd: usb printer vs cups
On 09/17/14 08:00, Andriy Gapon wrote:
Soliciting help.
Forwarded Message
From my experience I think that cupsd executes backend tools with all uids and
gids set to cups and no supplementary groups. In the case of USB printers the
backends need to access /dev/usbctl and /dev/usb/foobar that corresponds to a
printer. That means that the access to those devices must be somehow granted to
cups:cups.
How do people solve this? What kind of permissions / configuration do you use?
P.S.
Maybe I over-generalized the issue to all USB printers. My personal experience
is with an HP printer handled by hplip / hplip-plugin.
Hi,
The /usr/ports/print/cups-base should be updated.
The pkg-message should not say that:
# FreeBSD 8.x
add path 'usb*' mode 0770 group cups
add path 'ugen*' mode 0660 group cups
add path 'usb/0.2.*' mode 0660 group cups
Is needed. This is wrong.
Instead make cups-base install the attached devd configuration file in
/usr/local/etc/devd/ which does the needed chown for printers only.
--HPS
# Generic USB printer devices
notify 100 {
match "system" "USB";
match "subsystem" "INTERFACE";
match "type""ATTACH";
match "intclass""0x07";
match "intsubclass" "0x01";
match "intprotocol" "(0x01|0x02|0x03)";
action "chown cups:cups /dev/$cdev";
};
___
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: CURRENT: EFI boot failure
Am Tue, 16 Sep 2014 15:54:31 -0700 Nathan Whitehorn schrieb: > > On 09/16/14 14:50, O. Hartmann wrote: > > Am Tue, 16 Sep 2014 00:09:01 -0700 > > Nathan Whitehorn schrieb: > > > >> On 09/15/14 22:51, O. Hartmann wrote: > >>> Am Mon, 15 Sep 2014 17:39:26 -0700 > >>> Nathan Whitehorn schrieb: > >>> > On 09/15/14 17:36, Allan Jude wrote: > > On 2014-09-15 20:05, O. Hartmann wrote: > >> Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop > >> works for UEFI > >> fine. After I updated the sources to r271649, recompiled world and > >> kernel (as > >> well as installed), now I get stuck with the screen message: > >> > FreeBSD EFI boot block > >> Loader path: /boot/loader.efi > >> > >> and nothing happens. After a couple of minutes, the system reboots. > >> > >> What happened and how can this problem be solved? > >> > > You might need to update the boot1.efi file on the UEFI partition (small > > FAT partition on the disk) > > > > I am not sure how 'in sync' boot1.efi (on the fat partiton) and > > loader.efi have to be. > > > > https://wiki.freebsd.org/UEFI > > > boot1.efi is designed never to need updating. (It also hasn't changed > since April) > -Nathan > >>> But it has changed bytesize when I recompiled world with recent sources > >>> compared to > >>> the boot.efi size from the USB image I installed from (revision see > >>> above). > >> Probably compiler updates or something? I really wouldn't worry about it > >> too much. I'd worry more about loader, since we know boot1 could use the > >> console but loader doesn't show up. > >> > >>> How to update bootcode on UEFI layout? I created a GPT partition with > >>> type efi (1 > >>> GB) as well as a 512KB partition typed freebsd-boot. > >> How did you set it up in the first place? If you have a FreeBSD-only > >> system partition (like the installer sets up), you just dd > >> /boot/boot1.efifat to the EFI partition. Otherwise, it's FAT and you > >> copy /boot/boot1.efi to somewhere your boot manager can find it. > >> > >>> I'm new to EFI and the way the notebook now behaves is really strange. > >>> While the USB > >>> drive image used to boot with new console enabled, it now boots again > >>> with the old > >>> console and 800x640 resolution. This might indicate some minor but very > >>> effective > >>> mistake I made. > >>> > >> The EFI boot block finds the first UFS partition -- on any disk -- and > >> tries to boot from it. If you have multiple FreeBSD disks connected, > >> that will very likely result in madness. > >> -Nathan > >> ___ > >> 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" > > After I managed to install the OS and updated to the most recent world, it > > took two > > days to have all the installations prepared. Now I'm about the configure > > X11 and run > > into another very annoying situation. > > > > The Laptop is a Lenovo ThinkPad Edge E540 equipted with the following > > CPU/iGPU and > > dedicated GPU: > > > > CPU Intel i5-4200M (Haswell) at 2.5 GHz with iGPU Intel HD Graphics 4600 > > > > GPU: nVidia GT 740M mobile GPU. > > > > EFI Version 2.31 > > EFI Firmware: Lenovo (rev. 05648) > > > > In the Firmware/EFI/BIOS the primary GPU is selected to be the nVidia GT > > 740M. Boot is > > EFI only, no CSM support. With CSM support enabled a VGA screen with > > 640x400 pixel > > shows up. Non UEFI options doesn't boot this system at all! > > > > Any attempt to bring up the nVidia GPU (starting X for testing) ends up in > > a blank > > screen, stuck mousepointer, no keyboard. I even can not switch to another > > console! > > When X server started the first time on tty9, I can switch to another > > console. But the > > moment I switch back to ttyv9 everything is frozen and as described above. > > Try xf86-video-scfb instead? > > > When the system boots, I do not see a loader! Where is the loader I'm used > > to see > > when I have the chance to switch to single user mode, console or switch off > > ACPI? > > There is no beastie menu for UEFI, and will not be, since it UEFI's > terminal emulation does not provide the required features. You can boot > single user from the loader command line, however, with boot -s, for > example. The interface is identical to what you get if you choose > "Loader prompt" in the usual menu. Good to know. > > > Because I need X11 up (and it should be running on the nVidia GPU for > > performance > > reasons), I tried to get back to the legacy "sc" console in textmode since > > I read > > about several issues and immature vt() system, so I put those lines in > > the /boot/loader.conf: > > > > hw.vga.textmode=1 > > hw.vty=sc > > > > (tried also hw.vty=vt). > > > > But with either of
Re: usb printer vs cups
There are a couple of similar issues currently. The other one that comes to
mind is that every X11 application that needs to use OpenGL (or similar) must
open /dev/dri/{something}, but the default permissions only permit root.
The correct solution is probably to ship a devfs.conf that puts these devices
in the a sensible group. For USB printers, we should probably have a printers
group and make cupsd run with that group (or set the GUI of cups and printers
to the same number if that's too difficult).
David
On 17 Sep 2014, at 07:00, Andriy Gapon wrote:
>
> Soliciting help.
>
> Forwarded Message
>
> From my experience I think that cupsd executes backend tools with all uids and
> gids set to cups and no supplementary groups. In the case of USB printers the
> backends need to access /dev/usbctl and /dev/usb/foobar that corresponds to a
> printer. That means that the access to those devices must be somehow granted
> to
> cups:cups.
> How do people solve this? What kind of permissions / configuration do you
> use?
>
> P.S.
> Maybe I over-generalized the issue to all USB printers. My personal
> experience
> is with an HP printer handled by hplip / hplip-plugin.
> --
> Andriy Gapon
>
>
> ___
> 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"
___
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: CURRENT: EFI boot failure
On 09/15/14 22:51, O. Hartmann wrote: Am Mon, 15 Sep 2014 17:39:26 -0700 Nathan Whitehorn schrieb: On 09/15/14 17:36, Allan Jude wrote: On 2014-09-15 20:05, O. Hartmann wrote: Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop works for UEFI fine. After I updated the sources to r271649, recompiled world and kernel (as well as installed), now I get stuck with the screen message: FreeBSD EFI boot block Loader path: /boot/loader.efi and nothing happens. After a couple of minutes, the system reboots. What happened and how can this problem be solved? You might need to update the boot1.efi file on the UEFI partition (small FAT partition on the disk) I am not sure how 'in sync' boot1.efi (on the fat partiton) and loader.efi have to be. https://wiki.freebsd.org/UEFI boot1.efi is designed never to need updating. (It also hasn't changed since April) -Nathan But it has changed bytesize when I recompiled world with recent sources compared to the boot.efi size from the USB image I installed from (revision see above). Probably compiler updates or something? I really wouldn't worry about it too much. I'd worry more about loader, since we know boot1 could use the console but loader doesn't show up. How to update bootcode on UEFI layout? I created a GPT partition with type efi (1 GB) as well as a 512KB partition typed freebsd-boot. How did you set it up in the first place? If you have a FreeBSD-only system partition (like the installer sets up), you just dd /boot/boot1.efifat to the EFI partition. Otherwise, it's FAT and you copy /boot/boot1.efi to somewhere your boot manager can find it. I'm new to EFI and the way the notebook now behaves is really strange. While the USB drive image used to boot with new console enabled, it now boots again with the old console and 800x640 resolution. This might indicate some minor but very effective mistake I made. The EFI boot block finds the first UFS partition -- on any disk -- and tries to boot from it. If you have multiple FreeBSD disks connected, that will very likely result in madness. -Nathan ___ 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"
Huawei E3272 tester needed
Hi, Is there someone who is able to test support for the Huawei E3272 card with CURRENT after 269584? I have not been able to confirm that it works. Thanks in advance. Nick The change: Author: n_hibma Date: Tue Aug 5 12:08:50 2014 New Revision: 269584 URL: http://svnweb.freebsd.org/changeset/base/269584 Log: Add support for Huawei E3272 modems which are supported by the CDC ethernet class. Note: This is untested as I do not have a device like this. That is reflected in the MFC timeout. PR:192345 Submitted by: rozhuk.im gmail.com MFC after: 4 weeks Modified: head/sys/dev/usb/net/if_cdce.c head/sys/dev/usb/usbdevs ___ 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: libthr and main thread stack size
On Mon, Sep 15, 2014 at 03:47:41PM -0600, Justin T. Gibbs wrote: > On Aug 8, 2014, at 5:22 AM, Konstantin Belousov wrote: > > ? > > > Below is the patch which adds environment variable > > LIBPTHREAD_BIGSTACK_MAIN. Setting it to any value results in the > > main thread stack left as is, and other threads allocate stack > > below the area of RLIMIT_STACK. Try it. I do not want to set this > > behaviour as default. > > Is there a reason this should not be the default? Looking at the > getrlimit() page on the OpenGroup?s site they say: > > RLIMIT_STACK This is the maximum size of the initial thread's stack, > in bytes. The implementation does not automatically grow the stack > beyond this limit. If this limit is exceeded, SIGSEGV shall be > generated for the thread. If the thread is blocking SIGSEGV, or the > process is ignoring or catching SIGSEGV and has not made arrangements > to use an alternate stack, the disposition of SIGSEGV shall be set to > SIG_DFL before it is generated. > > Does posix say something different? > > I ran into this issue when debugging a segfault on Postgres when > running an (arguably quite bogus) query that should have fit within > both the configured stack rlimit and Postgres? configured stack limit. > The Postgres backend is really just single threaded, but happens > to pull in libpthread due to the threading support in some of the > libraries it uses. The segfault definitely violates POLA. > > ? Justin I am conservative to not disturb the address space layout in single go. If enough people test this setting, I can consider flipping the default to the reverse. I am still curious why the things were done in this way, but nobody replied. pgpTZsjgorg00.pgp Description: PGP signature
Re: CURRENT: EFI boot failure
On 16 Sep 2014, at 00:05 , O. Hartmann wrote: > > Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop works for > UEFI fine. > After I updated the sources to r271649, recompiled world and kernel (as well > as > installed), now I get stuck with the screen message: > >>> FreeBSD EFI boot block > Loader path: /boot/loader.efi > > and nothing happens. After a couple of minutes, the system reboots. The reboot comes from the EFI watchdog. > What happened and how can this problem be solved? One important thing for the people looking into this will be to know what hardware and if possible firmware revision you have. — Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 ___ 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"
