Re: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI
Am Tue, 16 Sep 2014 08:40:25 -0700 Adrian Chadd adr...@freebsd.org schrieb: Ah, jumbo frames. Maybe you got lucky and some ethernet drivers default to accepting larger frames even if the MTU is 1500. -a After all, I managed to get the NIC up and running. But the culprit is that I have to take the NIC down and then up to make it working once the system has bootet. That is annoying. Lucckily, I can provide better informations since the box s now attached to the network. Here we go: LAN: re0@pci0:4:0:0: class=0x02 card=0x502817aa chip=0x816810ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0x3000, size 256, enabled bar [18] = type Memory, range 64, base 0xf1d04000, size 4096, enabled bar [20] = type Memory, range 64, base 0xf1d0, size 16384, 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 IRQ 1 max data 128(128) link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) cap 11[b0] = MSI-X supports 4 messages, enabled Table in map 0x20[0x0], PBA in map 0x20[0x800] cap 03[d0] = VPD ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[160] = Serial 1 0100684ce000 ecap 0018[170] = LTR 1 ecap 001e[178] = unknown 1 PCI-e errors = Correctable Error Detected Corrected = Receiver Error WiFi (supposed to be Intel ): none2@pci0:5:0:0: class=0x028000 card=0x42628086 chip=0x08b28086 rev=0x73 hdr=0x00 vendor = 'Intel Corporation' class = network bar [10] = type Memory, range 64, base 0xf1c0, size 8192, enabled cap 01[c8] = powerspec 3 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[40] = PCI-Express 2 endpoint max data 128(128) FLR link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 ac7ba1a06fd6 ecap 0018[14c] = LTR 1 ecap 000b[154] = Vendor 1 ID 51966 The WiFi NIC isn't recognized by any driver in CURRENT (11.0-CURRENT #5 r271728: Thu Sep 18 01:18:25 CEST 2014 amd64) Maybe this is of help. Oliver signature.asc Description: PGP signature
Re: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI
On 09/18/14 09:58, O. Hartmann wrote:
Am Tue, 16 Sep 2014 08:40:25 -0700
Adrian Chadd adr...@freebsd.org schrieb:
Ah, jumbo frames. Maybe you got lucky and some ethernet drivers
default to accepting larger frames even if the MTU is 1500.
-a
After all, I managed to get the NIC up and running. But the culprit is that I
have to
take the NIC down and then up to make it working once the system has bootet.
That is
annoying. Lucckily, I can provide better informations since the box s now
attached to the
network. Here we go:
I have a similar situation with my nick on a tower system.
I need to change at least one flag on the card to have it working, I can
also just set the flag to the value it already has.
I'm using a small startup script which actually does this:
start_cmd=ifconfig ${refix_if} tso
LAN:
re0@pci0:4:0:0: class=0x02 card=0x502817aa chip=0x816810ec rev=0x10
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller'
class = network
subclass = ethernet
bar [10] = type I/O Port, range 32, base 0x3000, size 256, enabled
bar [18] = type Memory, range 64, base 0xf1d04000, size 4096, enabled
bar [20] = type Memory, range 64, base 0xf1d0, size 16384, 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 IRQ 1 max data 128(128) link x1(x1)
speed 2.5(2.5) ASPM disabled(L0s/L1)
cap 11[b0] = MSI-X supports 4 messages, enabled
Table in map 0x20[0x0], PBA in map 0x20[0x800]
cap 03[d0] = VPD
ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected
ecap 0002[140] = VC 1 max VC0
ecap 0003[160] = Serial 1 0100684ce000
ecap 0018[170] = LTR 1
ecap 001e[178] = unknown 1
PCI-e errors = Correctable Error Detected
Corrected = Receiver Error
re0@pci0:3:0:0: class=0x02 card=0x11c01734 chip=0x816810ec rev=0x07
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller'
class = network
subclass = ethernet
bar [10] = type I/O Port, range 32, base 0xd000, size 256, enabled
bar [18] = type Prefetchable Memory, range 64, base 0xf2104000,
size 4096, enabled
bar [20] = type Prefetchable Memory, range 64, base 0xf210,
size 16384, 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 IRQ 1 max data 128(128) link x1(x1)
speed 2.5(2.5) ASPM disabled(L0s/L1)
cap 11[b0] = MSI-X supports 4 messages, enabled
Table in map 0x20[0x0], PBA in map 0x20[0x800]
cap 03[d0] = VPD
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
ecap 0002[140] = VC 1 max VC0
ecap 0003[160] = Serial 1 01000401
PCI-e errors = Correctable Error Detected
Unsupported Request Detected
Corrected = Advisory Non-Fatal Error
it's similar hardware, same chip, different revision. I already reported
this on net@ but no patch could really solve the issue.
--
Guido Falsi m...@madpilot.net
___
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 Thu, 18 Sep 2014 10:17:08 +0200
Guido Falsi m...@madpilot.net schrieb:
On 09/18/14 09:58, O. Hartmann wrote:
Am Tue, 16 Sep 2014 08:40:25 -0700
Adrian Chadd adr...@freebsd.org schrieb:
Ah, jumbo frames. Maybe you got lucky and some ethernet drivers
default to accepting larger frames even if the MTU is 1500.
-a
After all, I managed to get the NIC up and running. But the culprit is that
I have to
take the NIC down and then up to make it working once the system has
bootet. That is
annoying. Lucckily, I can provide better informations since the box s now
attached to
the network. Here we go:
I have a similar situation with my nick on a tower system.
I need to change at least one flag on the card to have it working, I can
also just set the flag to the value it already has.
I'm using a small startup script which actually does this:
start_cmd=ifconfig ${refix_if} tso
LAN:
re0@pci0:4:0:0: class=0x02 card=0x502817aa chip=0x816810ec rev=0x10
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller'
class = network
subclass = ethernet
bar [10] = type I/O Port, range 32, base 0x3000, size 256, enabled
bar [18] = type Memory, range 64, base 0xf1d04000, size 4096, enabled
bar [20] = type Memory, range 64, base 0xf1d0, size 16384, 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 IRQ 1 max data 128(128) link x1(x1)
speed 2.5(2.5) ASPM disabled(L0s/L1)
cap 11[b0] = MSI-X supports 4 messages, enabled
Table in map 0x20[0x0], PBA in map 0x20[0x800]
cap 03[d0] = VPD
ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected
ecap 0002[140] = VC 1 max VC0
ecap 0003[160] = Serial 1 0100684ce000
ecap 0018[170] = LTR 1
ecap 001e[178] = unknown 1
PCI-e errors = Correctable Error Detected
Corrected = Receiver Error
re0@pci0:3:0:0: class=0x02 card=0x11c01734 chip=0x816810ec rev=0x07
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller'
class = network
subclass = ethernet
bar [10] = type I/O Port, range 32, base 0xd000, size 256, enabled
bar [18] = type Prefetchable Memory, range 64, base 0xf2104000,
size 4096, enabled
bar [20] = type Prefetchable Memory, range 64, base 0xf210,
size 16384, 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 IRQ 1 max data 128(128) link x1(x1)
speed 2.5(2.5) ASPM disabled(L0s/L1)
cap 11[b0] = MSI-X supports 4 messages, enabled
Table in map 0x20[0x0], PBA in map 0x20[0x800]
cap 03[d0] = VPD
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
ecap 0002[140] = VC 1 max VC0
ecap 0003[160] = Serial 1 01000401
PCI-e errors = Correctable Error Detected
Unsupported Request Detected
Corrected = Advisory Non-Fatal Error
it's similar hardware, same chip, different revision. I already reported
this on net@ but no patch could really solve the issue.
Hello.
Well, it seems the same here with taht specific NIC. Changing ANYTHING, even
already
enabled features, or bringing the NIC down and then up seem to solve this
problem.
I guess, I file a PR to make this issue memorized.
Regards,
Oliver
signature.asc
Description: PGP signature
UEFI/CURRENT: vt() and nVidia BLOB: not working on nVidia GT 740M
Running FreeBSD 11.0-CURRENT #5 r271728: Thu Sep 18 01:18:25 CEST 2014 amd64 on a Lenovo ThinkPad Edge E540 laptop with built-in nVidida GT 740M GPU (NV208M) doesn't bring up X11 even with most recent nVidia BLOB 343.13. The system has been installed from a most recent FBSD CURRENT USB drive image and uses UEFI and newcons/vt(). IN UEFI Firmware, the primary GPU selected is the nVidia GT 740M in favour of the Intel iGPU HD4600 of the Haswell CPU. While the system works well with console only after UEFI boot, I can not start X11 having driver nvidia enabled, the portion in xorg.conf reflecting this is as follows: Section Device Identifier Card0 VendorName nVidia BoardName GT740M Driver nvidia BusID PCI:1:0:0 EndSection When starting X, the screen goes blank and black with a stuck mousepointer showing up and a green (colour defined in my console) carret showing in the left hand upper corner of the screen - and nothing happens anymore. Using driver nv from the regular xorg installation from the ports (having set WITH_NEW_XORG= YES WITH_KMS= YES WITH_GALLIUM= YES in /etc/make.conf) fails with the error, that the driver doesn't recognises the GPU type. The only working solution is the very slow and unusable x11-drivers/xf86-video-scfb unaccelerated software framebuffer. I'd like to use the accelerated nVidia GPU with the BLOB as I do on all other FreeBSD boxes I use (systems still without UEFI and graphical vt()). What am I doing wrong here? Has someone successfully bootet FBSD CURRENT via EUFI and nVidia accelerated GPU via nVidia's BLOB? Thanks in advance, Oliver signature.asc Description: PGP signature
Panic - uma_zfree_arg - zone argument is NULL
Hi, Is this a known issue? Happens when invoking a program over and over again in a loop in from a shell. --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: Panic - uma_zfree_arg - zone argument is NULL
On 09/18/14 13:57, Hans Petter Selasky wrote: Hi, Is this a known issue? Happens when invoking a program over and over again in a loop in from a shell. --HPS Backtrace got stripped: FreeBSD 10.0-RELEASE panic: page fault Unread portion of the kernel message buffer: fault virtual address = 0xd8 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80b07863 stack pointer = 0x28:0xfe085d63b3b0 frame pointer = 0x28:0xfe085d63b420 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 5386 (sh) trap number = 12 panic: page fault cpuid = 21 KDB: stack backtrace: #0 0x808e7dc0 at kdb_backtrace+0x60 #1 0x808af8a5 at panic+0x155 #2 0x80c8e882 at trap_fatal+0x3a2 #3 0x80c8eb59 at trap_pfault+0x2c9 #4 0x80c8e2e6 at trap+0x5e6 #5 0x80c75582 at calltrap+0x8 #6 0x80898d25 at free+0x75 #7 0x8085c869 at elf64_load_file+0x379 #8 0x8085c23e at exec_elf64_imgact+0xa9e #9 0x80879f50 at kern_execve+0x690 #10 0x808796a7 at sys_execve+0x37 #11 0x80c8f177 at amd64_syscall+0x357 #12 0x80c7586b at Xfast_syscall+0xfb Uptime: 1h51m46s #0 doadump (textdump=value optimized out) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=value optimized out) at pcpu.h:219 #1 0x808af520 in kern_reboot (howto=260) at /10_release/sys/kern/kern_shutdown.c:447 #2 0x808af8e4 in panic (fmt=value optimized out) at /10_release/sys/kern/kern_shutdown.c:754 #3 0x80c8e882 in trap_fatal (frame=value optimized out, eva=value optimized out) at /10_release/sys/amd64/amd64/trap.c:882 #4 0x80c8eb59 in trap_pfault (frame=0xfe085d63b300, usermode=0) at /10_release/sys/amd64/amd64/trap.c:699 #5 0x80c8e2e6 in trap (frame=0xfe085d63b300) at /10_release/sys/amd64/amd64/trap.c:463 #6 0x80c75582 in calltrap () at /10_release/sys/amd64/amd64/exception.S:232 #7 0x80b07863 in uma_zfree_arg (zone=0x0, item=0xf800114ee000, udata=0x81484760) at /10_release/sys/vm/uma_core.c:2519 #8 0x80898d25 in free (addr=value optimized out, mtp=0x8138df70) at /10_release/sys/kern/kern_malloc.c:596 #9 0x8085c869 in elf64_load_file (p=value optimized out, file=value optimized out, addr=0xfe085d63b588, entry=0xfe085d63b790, pagesize=4096) at /10_release/sys/kern/imgact_elf.c:709 #10 0x8085c23e in exec_elf64_imgact (imgp=0xfe085d63b760) at /10_release/sys/kern/imgact_elf.c:944 #11 0x80879f50 in kern_execve (td=0xf800114db000, args=0xfe085d63b958, mac_p=0x0) at /10_release/sys/kern/kern_exec.c:501 #12 0x808796a7 in sys_execve (td=value optimized out, uap=value optimized out) at /10_release/sys/kern/kern_exec.c:213 #13 0x80c8f177 in amd64_syscall (td=0xf800114db000, traced=0) at subr_syscall.c:134 #14 0x80c7586b in Xfast_syscall () at /10_release/sys/amd64/amd64/exception.S:391 #15 0x000800d38d5a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) --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
Freebsd 11 usb image zfs on root install on DN2820FYKH
Has anyone got freebsd booting on an intel NUC DN2820FYKH? It installs fine just wont boot (doesnt see boot loader). I'm doing legacy not efi mode. I'm starting to bang my head against the wall on this one. Time to leave it for a bit i think ___ 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
Hi Hans, I saw the discussion about TSO, but the GSO is a software implementation unrelated with the hardware. Furthermore, if the TSO is enabled (and supported by the NIC), the GSO is not executed, because is useless. After the execution of the GSO, the packets, that are passed to the device driver, are smaller (or equal) than MTU, so the TSO is unnecessary. For this reason the GSO doesn't look neither ifp-if_hw_tsomax nor hardware segment limits. The GSO is very useful when you can't use the TSO. Cheers, Stefano 2014-09-17 22:27 GMT+02:00 Hans Petter Selasky h...@selasky.org: 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 -- *Stefano Garzarella* stefano.garzare...@gmail.com ___ 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: UEFI/CURRENT: vt() and nVidia BLOB: not working on nVidia GT 740M
On 09/18/14 04:18, O. Hartmann wrote: Running FreeBSD 11.0-CURRENT #5 r271728: Thu Sep 18 01:18:25 CEST 2014 amd64 on a Lenovo ThinkPad Edge E540 laptop with built-in nVidida GT 740M GPU (NV208M) doesn't bring up X11 even with most recent nVidia BLOB 343.13. The system has been installed from a most recent FBSD CURRENT USB drive image and uses UEFI and newcons/vt(). IN UEFI Firmware, the primary GPU selected is the nVidia GT 740M in favour of the Intel iGPU HD4600 of the Haswell CPU. While the system works well with console only after UEFI boot, I can not start X11 having driver nvidia enabled, the portion in xorg.conf reflecting this is as follows: Section Device Identifier Card0 VendorName nVidia BoardName GT740M Driver nvidia BusID PCI:1:0:0 EndSection When starting X, the screen goes blank and black with a stuck mousepointer showing up and a green (colour defined in my console) carret showing in the left hand upper corner of the screen - and nothing happens anymore. Using driver nv from the regular xorg installation from the ports (having set WITH_NEW_XORG= YES WITH_KMS= YES WITH_GALLIUM= YES in /etc/make.conf) fails with the error, that the driver doesn't recognises the GPU type. The only working solution is the very slow and unusable x11-drivers/xf86-video-scfb unaccelerated software framebuffer. I'd like to use the accelerated nVidia GPU with the BLOB as I do on all other FreeBSD boxes I use (systems still without UEFI and graphical vt()). What am I doing wrong here? Has someone successfully bootet FBSD CURRENT via EUFI and nVidia accelerated GPU via nVidia's BLOB? Thanks in advance, Oliver I'm using UEFI and the blob every day without issue. However, that is with an add-in card. It's possible that X11 or the nVidia driver is trying to reinitialize the card through the (potentially non-existant) video BIOS, which fails. Is there any option like NoInt10 you can turn on in X configuration? -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
Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD
On Thu, Sep 18, 2014 at 7:16 AM, Stefano Garzarella stefanogarzare...@gmail.com wrote: I saw the discussion about TSO, but the GSO is a software implementation unrelated with the hardware. Furthermore, if the TSO is enabled (and supported by the NIC), the GSO is not executed, because is useless. After the execution of the GSO, the packets, that are passed to the device driver, are smaller (or equal) than MTU, so the TSO is unnecessary. For this reason the GSO doesn't look neither ifp-if_hw_tsomax nor hardware segment limits. The GSO is very useful when you can't use the TSO. How does GSO affect IPFW, specifically the libalias(3)-based, in-kernel NAT? The ipfw(8) man page mentions that it doesn't play nicely with hardware-based TSO, and that one should disable TSO when using IPFW NAT. Will the software-based GSO play nicely with IPFW NAT? Will it make any difference to packet throughput through IPFW? Or is it still way too early in development to be worrying about such things? :) -- Freddie Cash fjwc...@gmail.com ___ 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: UEFI/CURRENT: vt() and nVidia BLOB: not working on nVidia GT 740M
Am Thu, 18 Sep 2014 07:19:45 -0700 Nathan Whitehorn nwhiteh...@freebsd.org schrieb: On 09/18/14 04:18, O. Hartmann wrote: Running FreeBSD 11.0-CURRENT #5 r271728: Thu Sep 18 01:18:25 CEST 2014 amd64 on a Lenovo ThinkPad Edge E540 laptop with built-in nVidida GT 740M GPU (NV208M) doesn't bring up X11 even with most recent nVidia BLOB 343.13. The system has been installed from a most recent FBSD CURRENT USB drive image and uses UEFI and newcons/vt(). IN UEFI Firmware, the primary GPU selected is the nVidia GT 740M in favour of the Intel iGPU HD4600 of the Haswell CPU. While the system works well with console only after UEFI boot, I can not start X11 having driver nvidia enabled, the portion in xorg.conf reflecting this is as follows: Section Device Identifier Card0 VendorName nVidia BoardName GT740M Driver nvidia BusID PCI:1:0:0 EndSection When starting X, the screen goes blank and black with a stuck mousepointer showing up and a green (colour defined in my console) carret showing in the left hand upper corner of the screen - and nothing happens anymore. Using driver nv from the regular xorg installation from the ports (having set WITH_NEW_XORG= YES WITH_KMS= YES WITH_GALLIUM= YES in /etc/make.conf) fails with the error, that the driver doesn't recognises the GPU type. The only working solution is the very slow and unusable x11-drivers/xf86-video-scfb unaccelerated software framebuffer. I'd like to use the accelerated nVidia GPU with the BLOB as I do on all other FreeBSD boxes I use (systems still without UEFI and graphical vt()). What am I doing wrong here? Has someone successfully bootet FBSD CURRENT via EUFI and nVidia accelerated GPU via nVidia's BLOB? Thanks in advance, Oliver I'm using UEFI and the blob every day without issue. However, that is with an add-in card. It's possible that X11 or the nVidia driver is trying to reinitialize the card through the (potentially non-existant) video BIOS, which fails. Is there any option like NoInt10 you can turn on in X configuration? -Nathan I tried Option NoInt10 Option PrimaryInt both in all combinations possible without any success. It is good to hear that at least one successful run of the BLOB with UEFI/vt can be reported, so the problem might be of a minor issue - hopefully. The GPU is a dedicated PCIe GPU for the notebook, combined with the HD4600 which can be used via nVidia's Optimus switching - if software supports it. In the UEFI, I selected the nVidia dedicated GPU as the primary one. The way the dead screen shows up reminds me of a dead end screen: the left-hand top carret and the console's mousepointer (at the position it was on the console) look like as the whole output is now delegated towards another output socket. The keyboard works surprisingly NOT as expected, since I have to switch this Lenovo FN key for Ctrl - which then allows me to switch back to the console and terminate the X server or xdm. I need to figure out what name's the sockets have (on the Dell Latitude I have, they are called DPS-0 to DPS-2 for the internal display, the HDMI and the DisplayPort socket and VGA-0 for the VGA socket). Will report back ... Oliver signature.asc Description: PGP signature
Re: CURRENT: EFI boot failure
On 09/17/2014 00:54, Nathan Whitehorn wrote: Try xf86-video-scfb instead? I also had the same problem (mentioned in another thread called Problems starting X on Mac using vesa, radeon or intel drivers when running FreeBSD-CURRENT in EFI), and following your suggestion to install the xf86-video-scfb driver is working for me using a Radeon HD 6770M and a built-in Intel HD 3000 graphics card. Neither the Intel or Radeon driver worked for me in EFI mode, but the driver you mentioned seems to work without problems. :) So thank you for that tip. :) Have a good night or day, everyone. :) ___ 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 Wed, Sep 17, 2014 at 4:27 AM, Stefano Garzarella
stefanogarzare...@gmail.com wrote:
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.
My initial impression is that this is a layering violation. Code like
this gives me pause:
+ eh = mtod(m, struct ether_vlan_header *);
+ if (eh-evl_encap_proto == htons(ETHERTYPE_VLAN)) {
+ eh_len = ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN;
+ } else {
+ eh_len = ETHER_HDR_LEN;
+ }
+
+ return gso_dispatch(ifp, m, eh_len);
If someone adds QinQ support, this code must be updated. When vxlan
support comes in, we must update this code or else the outer UDP
packet gets fragmented instead of the inner TCP payload being
segmented. As more tunneling protocols get added to FreeBSD, the
dispatch code for GSO gets uglier and uglier.
It seems to me that the real problem that we are trying to solve is a
lack of batching in the kernel. Currently the network stack operates
on the mbuf (packet) boundary. It seems to me that we could introduce
a packet group concept that is guaranteed to have the same L3 and L2
endpoint. In the transmit path, we would initially have a single
(potentially oversized) packet in the group. When TCP segments the
packet, it would add each packet to the packet group and pass it down
the stack. Because we guarantee that the endpoints are the same for
every packet in the group, the L3 code can do a single routing table
lookup and the L2 code can do a single l2table lookup for the entire
group.
The disadvantages of packet groups would be that:
a) You have touch a lot more code in a lot more places to take
advantage of the concept.
b) TSO inherently has the same layering problems. If we're going to
solve the problem for tunneling protocols then GSO might well be able
to take advantage of them.
___
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 02:05:41 +0200 O. Hartmann ohart...@zedat.fu-berlin.de schrieb: 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? after today's make world (revision 271800) and two days of normal operation, I run into the same situation as described above! This is more than annoying! The screen show simply FreeBSD EFI boot block Loader path: /boot/loader.efi and nothing happens forever. Usually, the loader/console shows up. This time the system gets stuck as I reported earlier. I can not afford another two days of installing the laptop again. How can I get rid of this immature EFI and run the system in the traditional way? It seems two immature systems meet each other, vt() and EFI and this ends up in a desaster. What is the fallback procedure? How to save the system and circumvent this problem? Is there a way to interrupt the boot process and drop out into some kind of emergency screen/console? BTW, I temporarily fixed this issu by copying the USB drive image's loader.efi into boot. This seems to be a bug in the compiler/compiling loader.efi. signature.asc Description: PGP signature
Re: Freebsd 11 usb image zfs on root install on DN2820FYKH
hmm, got it working by downgrading to v32 firmware. It seems the is a bug in intels wonderful uefi code, which of course the blame freebsd for 8/ On 18 September 2014 13:05, krad kra...@gmail.com wrote: Has anyone got freebsd booting on an intel NUC DN2820FYKH? It installs fine just wont boot (doesnt see boot loader). I'm doing legacy not efi mode. I'm starting to bang my head against the wall on this one. Time to leave it for a bit i think ___ 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
Poudriere code moved to https://github.com/freebsd/poudriere
Hi, Poudriere's code no longer is based in fossil. It has moved to https://github.com/freebsd/poudriere. Fossil will not be kept synced. Please submit patches as pull requests and issues on github going forward (rather than the old fossil site). This conversion is not compatible with the existing repository that I had on github.com/bdrewery/poudriere. The one I had was only a convenience and did not have tickets/commit-hashes converted. The new conversion does have these migrated. There are no hashes in common. Any checkouts you have will need to have customizations rebased onto the new repository. If you have no modifications to your own local repository than you can just recheckout to the new one. Given the old had a 'trunk' head then this should work: # git remote add upstream https://github.com/freebsd/poudriere.git # git remote update upstream # git checkout -b master upstream/master If you have made modifications then you will need to rebase onto the new one. Look in your 'git log' and find the last upstream commit which I will call UPSTREAM_COMMIT. Then rebase all of your work onto the new master: # git remote add upstream https://github.com/freebsd/poudriere.git # git remote update upstream # git rebase --onto upstream/master UPSTREAM_COMMIT Don't forget to git push -f to your own remote if needed. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
