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 typeATTACH;
match intclass0x07;
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 nwhiteh...@freebsd.org schrieb: On 09/16/14 14:50, O. Hartmann wrote: Am Tue, 16 Sep 2014 00:09:01 -0700 Nathan Whitehorn nwhiteh...@freebsd.org schrieb: On 09/15/14 22:51, O. Hartmann wrote: Am Mon, 15 Sep 2014 17:39:26 -0700 Nathan Whitehorn nwhiteh...@freebsd.org 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 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
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 a...@freebsd.org 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: Huawei E3272 tester needed
On Tue, 16 Sep 2014 22:43:34 +0200 Maciej Milewski m...@dat.pl wrote: On 16.09.2014 22:18, Milan Obuch wrote: On Tue, 16 Sep 2014 21:55:50 +0200 Maciej Milewski m...@dat.pl wrote: On 16.09.2014 16:52, Milan Obuch wrote: On Tue, 16 Sep 2014 09:40:45 +0200 Nick Hibma n...@van-laarhoven.org 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: HUAWEI Mobile HUAWEI Technology 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 HUAWEI Technology iProduct = 0x0001 HUAWEI Mobile 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: HUAWEI Mobile HUAWEI Technology 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 Huawei Configuration bmAttributes = 0x0080 bMaxPower = 0x00fa Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0002 bInterfaceClass = 0x0008 bInterfaceSubClass = 0x0006 bInterfaceProtocol = 0x0050 iInterface = 0x no string Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0001 OUT bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0200 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 IN bmAttributes = 0x0002 BULK 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 Thanks, that's working, verbatim: usb_modeswitch -v 12d1 -p 1f01 -V 012d1 -P 014db -M 55534243123456780a11062100 -W After that, if_cdce and uether kernel modules are automatically loaded and dhclient ue0 successfully acquires IP address. And it is working in 9.2-STABLE, 10.0-STABLE systems I tested with no modification to sources, so this is a good solution for me. 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: Fwd: usb printer vs cups
On 17/09/2014 09:21, Hans Petter Selasky wrote: 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. The problem is that my printer does not work if I also do not change permissions on /dev/usbctl. But I do not really want /dev/usbctl to be owned by cups as there can be other services / users that need access to usbctl. Is there anything smarter than mucking with device ownership? In other words, I have no problem granting cups user or group a full access to all USB devices. I have a problem with changing owner or group of USB devices to cups, because that interferes with other accesses to those devices. -- 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: Huawei E3272 tester needed
On Wed, 17 Sep 2014 07:11:26 +0200 Hans Petter Selasky h...@selasky.org wrote: On 09/16/14 22:52, Milan Obuch wrote: On Tue, 16 Sep 2014 22:35:19 +0200 Hans Petter Selasky h...@selasky.org wrote: On 09/16/14 22:18, Milan Obuch wrote: On Tue, 16 Sep 2014 21:55:50 +0200 Maciej Milewski m...@dat.pl wrote: On 16.09.2014 16:52, Milan Obuch wrote: On Tue, 16 Sep 2014 09:40:45 +0200 Nick Hibma n...@van-laarhoven.org 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 Well, I missed somehow usb_quirk module, but even with this module loaded, no change in behavior was seen. Thanks to other suggestion I verified solution with usb_modeswitch working, even on stock 9.2 and 10.0 systems. Anyway, if you would like me to test something else, just drop me a note. 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/17/14 09:06, Milan Obuch wrote: On Wed, 17 Sep 2014 07:11:26 +0200 Hans Petter Selasky h...@selasky.org wrote: On 09/16/14 22:52, Milan Obuch wrote: On Tue, 16 Sep 2014 22:35:19 +0200 Hans Petter Selasky h...@selasky.org wrote: On 09/16/14 22:18, Milan Obuch wrote: On Tue, 16 Sep 2014 21:55:50 +0200 Maciej Milewski m...@dat.pl wrote: On 16.09.2014 16:52, Milan Obuch wrote: On Tue, 16 Sep 2014 09:40:45 +0200 Nick Hibma n...@van-laarhoven.org 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 Well, I missed somehow usb_quirk module, but even with this module loaded, no change in behavior was seen. Thanks to other suggestion I verified solution with usb_modeswitch working, even on stock 9.2 and 10.0 systems. Anyway, if you would like me to test something else, just drop me a note. Hi, This quirk should be done by the u3g module. Can you make a patch for U3G in sys/dev/usb/serial/u3g.c ? See existing quirks. Else we'll add the one from modeswitch. --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: Fwd: usb printer vs cups
On 17/09/2014 10:04, Andriy Gapon wrote: On 17/09/2014 09:21, Hans Petter Selasky wrote: Instead make cups-base install the attached devd configuration file in /usr/local/etc/devd/ which does the needed chown for printers only. The problem is that my printer does not work if I also do not change permissions on /dev/usbctl. But I do not really want /dev/usbctl to be owned by cups as there can be other services / users that need access to usbctl. Actually I take this back. My /dev/usbctl was not world readable as it should be by default. Not sure why I changed its permissions from 0644 to 0660, probably a litle bit of paranoia. Now that I changed the permissions to 0664 and installed your script printing works without problems. Thanks! Is there anything smarter than mucking with device ownership? In other words, I have no problem granting cups user or group a full access to all USB devices. I have a problem with changing owner or group of USB devices to cups, because that interferes with other accesses to those devices. -- 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
[RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD
Hi all, I have recently worked, during my master’s thesis with the supervision of Prof. Luigi Rizzo, on a project to add GSO (Generic Segmentation Offload) support in FreeBSD. I will present this project at EuroBSDcon 2014, in Sofia (Bulgaria) on September 28, 2014. Following is a brief description of our project: The use of large frames makes network communication much less demanding for the CPU. Yet, backward compatibility and slow links requires the use of 1500 byte or smaller frames. Modern NICs with hardware TCP segmentation offloading (TSO) address this problem. However, a generic software version (GSO) provided by the OS has reason to exist, for use on paths with no suitable hardware, such as between virtual machines or with older or buggy NICs. Much of the advantage of TSO comes from crossing the network stack only once per (large) segment instead of once per 1500-byte frame. GSO does the same both for segmentation (TCP) and fragmentation (UDP) by doing these operations as late as possible. Ideally, this could be done within the device driver, but that would require modifications to all drivers. A more convenient, similarly effective approach is to segment just before the packet is passed to the driver (in ether_output()). Our preliminary implementation supports TCP and UDP on IPv4/IPv6; it only intercepts packets large than the MTU (others are left unchanged), and only when GSO is marked as enabled for the interface. Segments larger than the MTU are not split in tcp_output(), udp_output(), or ip_output(), but marked with a flag (contained in m_pkthdr.csum_flags), which is processed by ether_output() just before calling the device driver. ether_output(), through gso_dispatch(), splits the large frame as needed, creating headers and possibly doing checksums if not supported by the hardware. In experiments agains an LRO-enabled receiver (otherwise TSO/GSO are ineffective) we have seen the following performance, taken at different clock speeds (because at top speeds the 10G link becomes the bottleneck): Testing enviroment (all with Intel 10Gbit NIC) Sender: FreeBSD 11-CURRENT - CPU i7-870 at 2.93 GHz + Turboboost Receiver: Linux 3.12.8 - CPU i7-3770K at 3.50GHz + Turboboost Benchmark tool: netperf 2.6.0 --- TCP/IPv4 packets (checksum offloading enabled) --- Freq. TSO GSO none Speedup [GHz] [Gbps] [Gbps] [Gbps] GSO-none 2.93 9347 9298 8308 12 % 2.53 9266 9401 6771 39 % 2.00 9408 9294 5499 69 % 1.46 9408 8087 4075 98 % 1.05 9408 5673 2884 97 % 0.45 6760 2206 1244 77 % --- TCP/IPv6 packets (checksum offloading enabled) --- Freq. TSO GSO none Speedup [GHz] [Gbps] [Gbps] [Gbps] GSO-none 2.93 7530 6939 4966 40 % 2.53 5133 7145 4008 78 % 2.00 5965 6331 3152101 % 1.46 5565 5180 2348121 % 1.05 8501 3607 1732108 % 0.45 3665 1505651131 % --- UDP/IPv4 packets (9K) --- Freq. GSO none Speedup [GHz] [Gbps] [Gbps] GSO-none 2.93 9440 8084 17 % 2.53 7772 6649 17 % 2.00 6336 5338 19 % 1.46 4748 4014 18 % 1.05 3359 2831 19 % 0.45 1312 1120 17 % --- UDP/IPv6 packets (9K) --- Freq. GSO none Speedup [GHz] [Gbps] [Gbps] GSO-none 2.93 7281 6197 18 % 2.53 5953 5020 19 % 2.00 4804 4048 19 % 1.46 3582 3004 19 % 1.05 2512 2092 20 % 0.45 998826 21 % We tried to change as little as possible the network stack to add GSO support. To avoid changing API/ABI, we temporarily used spare fields in struct tcpcb (TCP Control Block) and struct ifnet to store some information related to GSO (enabled, max burst size, etc.). The code that performs the segmentation/fragmentation is contained in the file gso.[h|c] in sys/net. We used 4 bit in m_pkthdr.csum_flags (CSUM_GSO_MASK) to encode the packet type (TCP/IPv4, TCP/IPv6, etc) to prevent access to the TCP/IP/Ethernet headers of each packet. In ether_output_frame(), if the packet requires the GSO ((m-m_pkthdr.csum_flags CSUM_GSO_MASK) != 0), it is segmented or fragmented, and then they are sent to the device driver. At https://github.com/stefano-garzarella/freebsd-gso you can find the kernel patches for FreeBSD-current, FreeBSD 10-stable, FreeBSD 9-stable, a simple application (gso-stats.c) that prints the GSO statistics and picobsd images with GSO support. At https://github.com/stefano-garzarella/freebsd-gso-src you can get the FreeBSD source with GSO patch (various branch for FreeBSD current,
Re: Huawei E3272 tester needed
On 17.09.2014 09:02, Milan Obuch wrote: On Tue, 16 Sep 2014 22:43:34 +0200 Maciej Milewski m...@dat.pl wrote: On 16.09.2014 22:18, Milan Obuch wrote: 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 Thanks, that's working, verbatim: usb_modeswitch -v 12d1 -p 1f01 -V 012d1 -P 014db -M 55534243123456780a11062100 -W After that, if_cdce and uether kernel modules are automatically loaded and dhclient ue0 successfully acquires IP address. And it is working in 9.2-STABLE, 10.0-STABLE systems I tested with no modification to sources, so this is a good solution for me. Regards, Milan Glad to hear that helped, can you follow Hans suggestion for trying already defined quirks? It's posiible that there is one working. -- 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: CURRENT: EFI boot failure
On 16 September 2014 17:50, O. Hartmann ohart...@zedat.fu-berlin.de wrote: ... hw.vga.textmode=1 hw.vty=sc (tried also hw.vty=vt). ... One clarification for the archives: there's no tunable hw.vty, it's kern.vty. From vt(4): kern.vty When both vt and sc(4) have been compiled into the kernel, the one to use for the system console can be selected by setting this value to ‘vt’ or ‘sc’. If this value is not set, sc(4) is used. Although I see that needs an update, since the situation is now: If this value is not set, sc(4) is used, unless the system is booted via UEFI. In the UEFI-boot case vt(4) is used. (Tracked in PR 193710) ___ 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: Cam panic on r271170
On 9/16/2014 9:28 PM, Bryan Drewery wrote: 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 I also had this one recently: #8 0x80d1a162 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #9 0x802e52c4 in xpt_path_periph (path=0xdeadc0dedeadc0de) at /usr/src/sys/cam/cam_xpt.c:3738 #10 0x802dfe62 in cam_periph_error (ccb=0xf8003e0b6000, camflags=CAM_FLAG_NONE, sense_flags=0, save_ccb=0x0) at /usr/src/sys/cam/cam_periph.c:1602 #11 0x803057e4 in adadone (periph=0xf8003e09b700, done_ccb=0xf8003e0b6000) at /usr/src/sys/cam/ata/ata_da.c:1877 #12 0x802e6e44 in xpt_done_process (ccb_h=0xf8003e0b6000) at /usr/src/sys/cam/cam_xpt.c:5245 #13 0x80394d59 in ahci_ch_intr_direct (arg=value optimized out) at /usr/src/sys/dev/ahci/ahci.c:1132 #14 0x80390ff1 in ahci_intr (data=value optimized out) at /usr/src/sys/dev/ahci/ahci.c:417 #15 0x808ea5d3 in intr_event_execute_handlers (p=value optimized out, ie=0xf8000f725d00) at /usr/src/sys/kern/kern_intr.c:1252 #16 0x808eafb6 in ithread_loop (arg=0xf8000f6dea60) at /usr/src/sys/kern/kern_intr.c:1265 #17 0x808e7fc4 in fork_exit (callout=0x808eaf10 ithread_loop, arg=0xf8000f6dea60, frame=0xfe1245083c00) at /usr/src/sys/kern/kern_fork.c:977 #18 0x80d1a69e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:605 -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD
Hi! Cool! How many flows were you testing with? Just one or two? It's for outbound, so it's not _as_ big a deal as it is for inbound, but it'd still be nice to know. -a On 17 September 2014 01:27, Stefano Garzarella stefanogarzare...@gmail.com wrote: Hi all, I have recently worked, during my master’s thesis with the supervision of Prof. Luigi Rizzo, on a project to add GSO (Generic Segmentation Offload) support in FreeBSD. I will present this project at EuroBSDcon 2014, in Sofia (Bulgaria) on September 28, 2014. Following is a brief description of our project: The use of large frames makes network communication much less demanding for the CPU. Yet, backward compatibility and slow links requires the use of 1500 byte or smaller frames. Modern NICs with hardware TCP segmentation offloading (TSO) address this problem. However, a generic software version (GSO) provided by the OS has reason to exist, for use on paths with no suitable hardware, such as between virtual machines or with older or buggy NICs. Much of the advantage of TSO comes from crossing the network stack only once per (large) segment instead of once per 1500-byte frame. GSO does the same both for segmentation (TCP) and fragmentation (UDP) by doing these operations as late as possible. Ideally, this could be done within the device driver, but that would require modifications to all drivers. A more convenient, similarly effective approach is to segment just before the packet is passed to the driver (in ether_output()). Our preliminary implementation supports TCP and UDP on IPv4/IPv6; it only intercepts packets large than the MTU (others are left unchanged), and only when GSO is marked as enabled for the interface. Segments larger than the MTU are not split in tcp_output(), udp_output(), or ip_output(), but marked with a flag (contained in m_pkthdr.csum_flags), which is processed by ether_output() just before calling the device driver. ether_output(), through gso_dispatch(), splits the large frame as needed, creating headers and possibly doing checksums if not supported by the hardware. In experiments agains an LRO-enabled receiver (otherwise TSO/GSO are ineffective) we have seen the following performance, taken at different clock speeds (because at top speeds the 10G link becomes the bottleneck): Testing enviroment (all with Intel 10Gbit NIC) Sender: FreeBSD 11-CURRENT - CPU i7-870 at 2.93 GHz + Turboboost Receiver: Linux 3.12.8 - CPU i7-3770K at 3.50GHz + Turboboost Benchmark tool: netperf 2.6.0 --- TCP/IPv4 packets (checksum offloading enabled) --- Freq. TSO GSO none Speedup [GHz] [Gbps] [Gbps] [Gbps] GSO-none 2.93 9347 9298 8308 12 % 2.53 9266 9401 6771 39 % 2.00 9408 9294 5499 69 % 1.46 9408 8087 4075 98 % 1.05 9408 5673 2884 97 % 0.45 6760 2206 1244 77 % --- TCP/IPv6 packets (checksum offloading enabled) --- Freq. TSO GSO none Speedup [GHz] [Gbps] [Gbps] [Gbps] GSO-none 2.93 7530 6939 4966 40 % 2.53 5133 7145 4008 78 % 2.00 5965 6331 3152101 % 1.46 5565 5180 2348121 % 1.05 8501 3607 1732108 % 0.45 3665 1505651131 % --- UDP/IPv4 packets (9K) --- Freq. GSO none Speedup [GHz] [Gbps] [Gbps] GSO-none 2.93 9440 8084 17 % 2.53 7772 6649 17 % 2.00 6336 5338 19 % 1.46 4748 4014 18 % 1.05 3359 2831 19 % 0.45 1312 1120 17 % --- UDP/IPv6 packets (9K) --- Freq. GSO none Speedup [GHz] [Gbps] [Gbps] GSO-none 2.93 7281 6197 18 % 2.53 5953 5020 19 % 2.00 4804 4048 19 % 1.46 3582 3004 19 % 1.05 2512 2092 20 % 0.45 998826 21 % We tried to change as little as possible the network stack to add GSO support. To avoid changing API/ABI, we temporarily used spare fields in struct tcpcb (TCP Control Block) and struct ifnet to store some information related to GSO (enabled, max burst size, etc.). The code that performs the segmentation/fragmentation is contained in the file gso.[h|c] in sys/net. We used 4 bit in m_pkthdr.csum_flags (CSUM_GSO_MASK) to encode the packet type (TCP/IPv4, TCP/IPv6, etc) to prevent access to the TCP/IP/Ethernet headers of each packet. In ether_output_frame(), if the packet requires the GSO ((m-m_pkthdr.csum_flags CSUM_GSO_MASK) != 0), it is segmented or fragmented, and then they are sent to the device driver. At
Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD
Hi Adrian, the results that I sent, regard just one flow, but I can try with two simultaneous flows and I'll send you the results. Thanks, Stefano 2014-09-17 19:27 GMT+02:00 Adrian Chadd adr...@freebsd.org: Hi! Cool! How many flows were you testing with? Just one or two? It's for outbound, so it's not _as_ big a deal as it is for inbound, but it'd still be nice to know. -a On 17 September 2014 01:27, Stefano Garzarella stefanogarzare...@gmail.com wrote: Hi all, I have recently worked, during my master’s thesis with the supervision of Prof. Luigi Rizzo, on a project to add GSO (Generic Segmentation Offload) support in FreeBSD. I will present this project at EuroBSDcon 2014, in Sofia (Bulgaria) on September 28, 2014. Following is a brief description of our project: The use of large frames makes network communication much less demanding for the CPU. Yet, backward compatibility and slow links requires the use of 1500 byte or smaller frames. Modern NICs with hardware TCP segmentation offloading (TSO) address this problem. However, a generic software version (GSO) provided by the OS has reason to exist, for use on paths with no suitable hardware, such as between virtual machines or with older or buggy NICs. Much of the advantage of TSO comes from crossing the network stack only once per (large) segment instead of once per 1500-byte frame. GSO does the same both for segmentation (TCP) and fragmentation (UDP) by doing these operations as late as possible. Ideally, this could be done within the device driver, but that would require modifications to all drivers. A more convenient, similarly effective approach is to segment just before the packet is passed to the driver (in ether_output()). Our preliminary implementation supports TCP and UDP on IPv4/IPv6; it only intercepts packets large than the MTU (others are left unchanged), and only when GSO is marked as enabled for the interface. Segments larger than the MTU are not split in tcp_output(), udp_output(), or ip_output(), but marked with a flag (contained in m_pkthdr.csum_flags), which is processed by ether_output() just before calling the device driver. ether_output(), through gso_dispatch(), splits the large frame as needed, creating headers and possibly doing checksums if not supported by the hardware. In experiments agains an LRO-enabled receiver (otherwise TSO/GSO are ineffective) we have seen the following performance, taken at different clock speeds (because at top speeds the 10G link becomes the bottleneck): Testing enviroment (all with Intel 10Gbit NIC) Sender: FreeBSD 11-CURRENT - CPU i7-870 at 2.93 GHz + Turboboost Receiver: Linux 3.12.8 - CPU i7-3770K at 3.50GHz + Turboboost Benchmark tool: netperf 2.6.0 --- TCP/IPv4 packets (checksum offloading enabled) --- Freq. TSO GSO none Speedup [GHz] [Gbps] [Gbps] [Gbps] GSO-none 2.93 9347 9298 8308 12 % 2.53 9266 9401 6771 39 % 2.00 9408 9294 5499 69 % 1.46 9408 8087 4075 98 % 1.05 9408 5673 2884 97 % 0.45 6760 2206 1244 77 % --- TCP/IPv6 packets (checksum offloading enabled) --- Freq. TSO GSO none Speedup [GHz] [Gbps] [Gbps] [Gbps] GSO-none 2.93 7530 6939 4966 40 % 2.53 5133 7145 4008 78 % 2.00 5965 6331 3152101 % 1.46 5565 5180 2348121 % 1.05 8501 3607 1732108 % 0.45 3665 1505651131 % --- UDP/IPv4 packets (9K) --- Freq. GSO none Speedup [GHz] [Gbps] [Gbps] GSO-none 2.93 9440 8084 17 % 2.53 7772 6649 17 % 2.00 6336 5338 19 % 1.46 4748 4014 18 % 1.05 3359 2831 19 % 0.45 1312 1120 17 % --- UDP/IPv6 packets (9K) --- Freq. GSO none Speedup [GHz] [Gbps] [Gbps] GSO-none 2.93 7281 6197 18 % 2.53 5953 5020 19 % 2.00 4804 4048 19 % 1.46 3582 3004 19 % 1.05 2512 2092 20 % 0.45 998826 21 % We tried to change as little as possible the network stack to add GSO support. To avoid changing API/ABI, we temporarily used spare fields in struct tcpcb (TCP Control Block) and struct ifnet to store some information related to GSO (enabled, max burst size, etc.). The code that performs the segmentation/fragmentation is contained in the file gso.[h|c] in sys/net. We used 4 bit in m_pkthdr.csum_flags (CSUM_GSO_MASK) to encode the packet type
Re: Cam panic on r271170
Could you try turning on memguard for the CAM CCB malloc area? That should locate the problem quite quickly. ___ 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: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD
On 09/17/14 20:18, Stefano Garzarella wrote: Hi Adrian, the results that I sent, regard just one flow, but I can try with two simultaneous flows and I'll send you the results. Thanks, Stefano Hi Stefano, You might have seen the discussion about TSO. Is it so that the proposed GSO feature only looks at the ifp-if_hw_tsomax field, and ignores hardware limits regarding maximum segment size and maximum segment count? --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: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient
On Tuesday, September 16, 2014 12:42:36 PM Mateusz Guzik wrote: 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 a...@freebsd.org 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. Yes, unbound is multi-threaded and your comment is the first potential explanation that makes sense so far. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 signature.asc Description: This is a digitally signed message part.
Re: Leaving the Desktop Market
Dear lists, I'm sorry for 2L8 reply though,I have transrated this thread into japanese in [1]. I wonder if every mail transrated correctly so please check it if you understand japanese especially by japanese lists. BTW ML mails should be obeyed by FreeBSD Copyright but it's derivative work would be going to? Regards [1] http://www.openedu.org/dkp/archive/mail/current/20140331-0517/maillist.html --- Kazuhiko Kiriyama k...@openedu.org At Mon, 31 Mar 2014 22:46:45 -0700, Eitan Adler wrote: Hi all, Some of you may have seen my posts entitled Story of a Laptop User and Story of a Desktop User. For those of you who did not, it can be a worthwhile read to see what life is like when using FreeBSD as a desktop. In short, it is an educational experience. While FreeBSD can be coerced to do the right thing, it is rarely there by default and often doesn't work as well as we would expect. The following are issues I haven't brought up in the past: Battery life sucks: it’s almost as if powerd wasn't running. Windows can run for five hours on my laptop while FreeBSD can barely make it two hours. I wonder what the key differences are? Likely it’s that we focus so much on performance that no one considers power. ChromeOS can run for 12 hours on some hardware; why can't we make FreeBSD run for 16? Sound configuration lacks key documentation: how can I automatically change between headphones and external speakers? You can't even do that in middle of a song at all! Trust me that you never want to be staring at an HDA pin configuration. I'll bet you couldn't even get sound streaming to other machines working if you tried. FreeBSD lacks vendor credibility: CUDA is unsupported. Dropbox hasn't released a client for FreeBSD. Nvidia Optimus doesn't function on FreeBSD. Can you imagine telling someone to purchase a laptop with the caveat: but you won't be able to use your graphics card? In any case, half of our desktop support is emulation: flash and opera only works because of the linuxulator. There really isn't any reason for vendors to bother supporting FreeBSD if we are just going to ape Linux anyways. That is why on this date I propose that we cease competing on the desktop market. FreeBSD should declare 2014 to be year of the Linux desktop and start to rip out the pieces of the OS not needed for server or embedded use. Some of you may point to PCBSD and say that we have a chance, but I must ask you: how does one flavor stand up to the thousands in the Linux world? Eitan Adler ___ 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
