atomic in i386 Current after CLANG 6 upgrade
Hy all, I've already received a couple of messages from pkg-fallout about build failure on head-i386-default [1] [2] both pointing to the same errors, about missing intrinsic symbols related to __atomic_* The clang documentation about C11 atomic builtins [3] stats that __atomic_* are GCC extension and Clang provides them. It seems to me that this specific GCC-compatible builtin are enabled on amd64, but not on i386. Is there a way to enable GCC compatible __atomic_ builtin also on i386? Or should I provide patches to adopt _c11_atomic_* instead of __atomic_* for every ports that need it ? Thanks in advance! Best regards, pizzamg [1] http://beefy11.nyi.freebsd.org/data/head-i386-default/p458948_s327953/logs/librdkafka-0.11.3.log [2] http://beefy11.nyi.freebsd.org/data/head-i386-default/p458948_s327953/logs/stress-ng-0.09.09.log [3] https://clang.llvm.org/docs/LanguageExtensions.html#langext-c11-atomic ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[SOLVED] Re: pcie Realtek 8168G issues (re driver)(minnowboard)
Hi all, I've managed to get the Realtek 8168g running. It's actually a driver bug, the command register enables rx and tx too early. Apparently, it's OK for many Realtek chips, but not for 3 kind of them, as stated by the Realtek developer, who submitted this patch to Linux (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d6e572911a4cb2b9fcd1c26a38d5317a3971f2fd) I updated the Bugzilla entry https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535 The patch (moving one line, sich!) works on this hardware, but I don't know how much portable it is. Thanks for all your tips. Best regards, Luca Pizzamiglio On Wed, Feb 25, 2015 at 3:59 PM, Luca Pizzamiglio luca.pizzamig...@gmail.com wrote: Hi, thanks you all for the replies. Unfortunately, the network chip is still not working and I updated the PR (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535) with the last tests. It seems that received packets are not transferred to mbuf or they are transferred, but later, after the mbuf is already freed; moreover, the ring entries are written without looping, overwriting and messing up the whole kernel memory. It looks like a DMA issues, but Apparently it seems a hardware error, but using a Linux distro, it works :( Has someone maybe any other ideas? In the meanwhile I'll get another board with the same chip :O Best regards, Luca On Tue, Feb 17, 2015 at 7:31 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Am Tue, 17 Feb 2015 18:32:22 +0100 Luca Pizzamiglio luca.pizzamig...@gmail.com schrieb: Hi Ben, thanks for the tip! tso was already disabled. I tried anyway and unfortunately it crashes as before. I filled a bug report (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535) and marius@ is giving me a big help on it. Best regards, Luca On Fri, Feb 13, 2015 at 7:34 PM, Ben Perrault ben.perra...@gmail.com wrote: Luca, I've had the same issue with this interface on both PCIe boards and embedded in a handful of Lenovo products. The one, fairly ugly workaround I've found that makes it work well enough is disable tso ( i.e. ifconfig re0 down ifconfig re0 -tso ifconfig re0 up ). This also seems to stop the panics under current. I'm not sure it will work for you - but it has on everyone of those interfaces I've dealt with. Good luck, -bp On Feb 13, 2015, at 8:06 AM, Luca Pizzamiglio luca.pizzamig...@gmail.com wrote: Hi, I'm Luca, I've some issues using a PCIe Realtek Ethernet board: re0@pci0:3:0:0: class=0x02 card=0x012310ec chip=0x816810ec rev=0x0c 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 0x1000, size 256, enabled bar [18] = type Memory, range 64, base 0x9050, size 4096, enabled bar [20] = type Prefetchable Memory, range 64, base 0x9040, 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 Table in map 0x20[0x0], PBA in map 0x20[0x800] cap 03[d0] = VPD ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[160] = Serial 1 0100684ce000 ecap 0018[170] = LTR 1 Rx and Tx don't work. After some minutes the interface is activated I get kernel panic. I've already tried to disable MSIx and MSI. It seems a DMA problem, rx fill the 256 descriptors and the nothing else until the panic. netstat -s shows now new packets. I filled a bug report with more infos: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535 could someone kindly pointing some ideas? Best regards, Luca ___ 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 In September 2014 I filed allready a bug acoording to strange behaviour with a Lenovo ThinkPad E540 with a Realtek chip: Bug 193743 - RTL8111/8168B PCI Express Gigabit Ethernet controller: doesn't work properly, problems getting UP automatically ___ 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: pcie Realtek 8168G issues (re driver)
Hi, thanks you all for the replies. Unfortunately, the network chip is still not working and I updated the PR (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535) with the last tests. It seems that received packets are not transferred to mbuf or they are transferred, but later, after the mbuf is already freed; moreover, the ring entries are written without looping, overwriting and messing up the whole kernel memory. It looks like a DMA issues, but Apparently it seems a hardware error, but using a Linux distro, it works :( Has someone maybe any other ideas? In the meanwhile I'll get another board with the same chip :O Best regards, Luca On Tue, Feb 17, 2015 at 7:31 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Am Tue, 17 Feb 2015 18:32:22 +0100 Luca Pizzamiglio luca.pizzamig...@gmail.com schrieb: Hi Ben, thanks for the tip! tso was already disabled. I tried anyway and unfortunately it crashes as before. I filled a bug report (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535) and marius@ is giving me a big help on it. Best regards, Luca On Fri, Feb 13, 2015 at 7:34 PM, Ben Perrault ben.perra...@gmail.com wrote: Luca, I've had the same issue with this interface on both PCIe boards and embedded in a handful of Lenovo products. The one, fairly ugly workaround I've found that makes it work well enough is disable tso ( i.e. ifconfig re0 down ifconfig re0 -tso ifconfig re0 up ). This also seems to stop the panics under current. I'm not sure it will work for you - but it has on everyone of those interfaces I've dealt with. Good luck, -bp On Feb 13, 2015, at 8:06 AM, Luca Pizzamiglio luca.pizzamig...@gmail.com wrote: Hi, I'm Luca, I've some issues using a PCIe Realtek Ethernet board: re0@pci0:3:0:0: class=0x02 card=0x012310ec chip=0x816810ec rev=0x0c 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 0x1000, size 256, enabled bar [18] = type Memory, range 64, base 0x9050, size 4096, enabled bar [20] = type Prefetchable Memory, range 64, base 0x9040, 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 Table in map 0x20[0x0], PBA in map 0x20[0x800] cap 03[d0] = VPD ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[160] = Serial 1 0100684ce000 ecap 0018[170] = LTR 1 Rx and Tx don't work. After some minutes the interface is activated I get kernel panic. I've already tried to disable MSIx and MSI. It seems a DMA problem, rx fill the 256 descriptors and the nothing else until the panic. netstat -s shows now new packets. I filled a bug report with more infos: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535 could someone kindly pointing some ideas? Best regards, Luca ___ 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 In September 2014 I filed allready a bug acoording to strange behaviour with a Lenovo ThinkPad E540 with a Realtek chip: Bug 193743 - RTL8111/8168B PCI Express Gigabit Ethernet controller: doesn't work properly, problems getting UP automatically ___ 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: pcie Realtek 8168G issues (re driver)
Hi Ben, thanks for the tip! tso was already disabled. I tried anyway and unfortunately it crashes as before. I filled a bug report (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535) and marius@ is giving me a big help on it. Best regards, Luca On Fri, Feb 13, 2015 at 7:34 PM, Ben Perrault ben.perra...@gmail.com wrote: Luca, I've had the same issue with this interface on both PCIe boards and embedded in a handful of Lenovo products. The one, fairly ugly workaround I've found that makes it work well enough is disable tso ( i.e. ifconfig re0 down ifconfig re0 -tso ifconfig re0 up ). This also seems to stop the panics under current. I'm not sure it will work for you - but it has on everyone of those interfaces I've dealt with. Good luck, -bp On Feb 13, 2015, at 8:06 AM, Luca Pizzamiglio luca.pizzamig...@gmail.com wrote: Hi, I'm Luca, I've some issues using a PCIe Realtek Ethernet board: re0@pci0:3:0:0: class=0x02 card=0x012310ec chip=0x816810ec rev=0x0c 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 0x1000, size 256, enabled bar [18] = type Memory, range 64, base 0x9050, size 4096, enabled bar [20] = type Prefetchable Memory, range 64, base 0x9040, 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 Table in map 0x20[0x0], PBA in map 0x20[0x800] cap 03[d0] = VPD ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[160] = Serial 1 0100684ce000 ecap 0018[170] = LTR 1 Rx and Tx don't work. After some minutes the interface is activated I get kernel panic. I've already tried to disable MSIx and MSI. It seems a DMA problem, rx fill the 256 descriptors and the nothing else until the panic. netstat -s shows now new packets. I filled a bug report with more infos: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535 could someone kindly pointing some ideas? Best regards, Luca ___ 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
pcie Realtek 8168G issues (re driver)
Hi, I'm Luca, I've some issues using a PCIe Realtek Ethernet board: re0@pci0:3:0:0: class=0x02 card=0x012310ec chip=0x816810ec rev=0x0c 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 0x1000, size 256, enabled bar [18] = type Memory, range 64, base 0x9050, size 4096, enabled bar [20] = type Prefetchable Memory, range 64, base 0x9040, 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 Table in map 0x20[0x0], PBA in map 0x20[0x800] cap 03[d0] = VPD ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[160] = Serial 1 0100684ce000 ecap 0018[170] = LTR 1 Rx and Tx don't work. After some minutes the interface is activated I get kernel panic. I've already tried to disable MSIx and MSI. It seems a DMA problem, rx fill the 256 descriptors and the nothing else until the panic. netstat -s shows now new packets. I filled a bug report with more infos: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535 could someone kindly pointing some ideas? Best regards, Luca ___ 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
Memory modified after free Kernel panic with current (r278031)
Hallo, I'm still fighting with MinnowBoard... When I set the network interface I get a bunch of Memory modified after free messages. If I wait long enough (a couple of minutes) I get a kernel panic. Here an example with the dmesg (https://pastebin.mozilla.org/8657938) I've tested it using 10.1-STABLE, same messages after ifconfig, but the kernel panic is different. Here a verbose example of it (https://pastebin.mozilla.org/8658082) On 10, I see really often the value 0x3201c040 causing segmentation fault (!), but I don't know where it comes from. I'm still debugging it, but it could be that the init procedure of re(4) cannot correctly stop the device (a normal Realtek 8168) and the dma address are rewritten by receiving packets. Has someone some tip/ideas? thanks in advance for the help Best regards, pizzamig ___ 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 boot fail on higher resolutions (Re: Acer E3-112 and UEFI)
On a Minnowboard I've the same behavior, 800x600 it boots, at 1024x768 it crash, using a DVI display. best regards, pizzamig On Wed, Feb 4, 2015 at 2:04 PM, Jakob Alvermark ja...@alvermark.net wrote: On 31 dec 2014, at 16:24, Jakob Alvermark wrote: On Tue, December 30, 2014 17:00, Nathan Whitehorn wrote: On 12/30/14 06:40, Jakob Alvermark wrote: Hi, Have been playing with this machine for a while now. It is a quad core Pentium N3540 (ValleyView/Bay Trail), 8 GB RAM. It came with a Broadcom WiFi card which I swapped for an Intel which is supported by FreeBSD. Also swapped the hard drive for an SSD. When first trying to boot FreeBSD with UEFI it would not boot. It stops after the loader is trying to start the kernel. My workaround now is using refind, http://www.rodsbooks.com/refind/ to set the screen resolution to 800x600. (Native is 1366x768) Only then will it boot using UEFI. I tried setting it to 1024x768, then it crashes. If it helps I can get the backtrace. [Not sure what's going on here] A follow up on this: I tried this on my desktop machine (AMD FX-8350, Radeon HD 5450) to see if it has the issue, and it has! I went on to try it on my desktop machine at work (Core i3-4130, Radeon HD 4350) and it boots! On the Acer, resolution set to 1024x768: FreeBSD EFI boot block Loader path: /boot/loader.efi Consoles: EFI console Image base: 0x7502f000 EFI version: 2.40 EFI Firmware: INSYDE Corp. (rev 21522.39) --- Start @ 0x802e1000 ... EFI framebuffer information: addr, size 0x8000, 0x30 dimensions 1024 x 768 stride 1024 masks 0x00ff, 0xff00, 0x00ff, 0xff00 --- kernel trap12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x13 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80a20834 stack pointer = 0x28:0x81604170 frame pointer = 0x28:0x81604290 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 0 () [ thread pid 0 tid 0] Stopped at kvprintf+0xd4:movzbl (%r14),%eax On the home desktop resolution 1024x768: FreeBSD EFI boot block Loader path: /boot/loader.efi Consoles: EFI console Image base: 0xb08ac000 EFI version: 2.31 EFI Firmware: American Megatrends (rev 4.653) --- Start @ 0x802e1000 ... EFI framebuffer information: addr, size 0xc000, 0x30 dimensions 1024 x 768 stride 1024 masks 0x00ff, 0xff00, 0x00ff, 0xff00 --- kernel trap12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x13 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80a20654 stack pointer = 0x28:0x81603d70 frame pointer = 0x28:0x81603e90 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 0 () [ thread pid 0 tid 0] Stopped at kvprintf+0xd4:movzbl (%r14),%eax On the work desktop: FreeBSD EFI boot block Loader path: /boot/loader.efi Consoles: EFI console Image base: 0xbb7aa000 EFI version: 2.31 EFI Firmware: American Megatrends (rev 4.654) --- Start @ 0x802e1000 ... EFI framebuffer information: addr, size 0xe000, 0x30 dimensions 1024 x 768 stride 1024 masks 0x00ff, 0xff00, 0x00ff, 0xff00 And then it boots normally. Does anyone have any clues on what's going on here? (This all typed manually from screenshots taken with my phone, there might be typos.) Thanks, Jakob ___ 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: UEFI boot hangs with MINNOWBOARD
Hi Ed, I've got a running MinnowBoard. All problems are not FreeBSD related, but with DVI display. Setting a fixed resolution instead of a Auto solved the problem. Thanks for the help Best regards, pizzamig PS I'll try to get a GetMemoryMap() / ExitBootServices() retry next week On Fri, Jan 30, 2015 at 6:35 PM, Ed Maste ema...@freebsd.org wrote: On 30 January 2015 at 10:57, Luca Pizzamiglio luca.pizzamig...@gmail.com wrote: Hi, I'm testing CURRENT on a MINNOWBOARD (http://www.elinux.org/Minnowboard:MinnowMax): Dual-core atom E3825 CPU EFI Version: 2.4.0 EFI: EDK II boot1.efi starts, it can found the ufs partition with loader.efi loader.efi fails at BT-ExitBootServices() (elf64_exec() of sys/boot/amd64/efi/elf64_freebsd.c) Which revision are you testing, and do you have any local changes? I built a plain -current USB stick image a while back and had no trouble, when using the HDMI output. I don't recall the revision at the moment, but will try again soon. Serial console won't work because the UARTs are not quite 16550-compatible. We do need a GetMemoryMap() / ExitBootServices() retry though. ___ 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 boot hangs with MINNOWBOARD
Hi Ed, thanks for the reply I tested the last available memstick (r277486) of CURRENT to install FreeBSD, but it didn't finish the boot process. The boot process hangs after showing the framebuffer information ( bi_load_efi_data() in bootinfo.c). I'm using a DVI monitor with a mini-HDMI-DVI cable. With a very hold DVI monitor I cannot see anything. Then I moved to a recent DVI monitor, but it hanged as well. Then I recompiled CURRENT (updated to Thursday) and added several printf to the EFI section (both boot1.efi and loader.efi). I also updated the UEFI of the board to the most recent one, without luck. I'll come back on Wednesday, I'll recompile everything removing all my printf and let's see what happen. Is the display so relevant? Thanks again for the help, it's really appreciated! Best regards, pizzamig On 1/30/15, Ed Maste ema...@freebsd.org wrote: On 30 January 2015 at 12:35, Ed Maste ema...@freebsd.org wrote: I built a plain -current USB stick image a while back and had no trouble, when using the HDMI output. I don't recall the revision at the moment, but will try again soon. Serial console won't work because the UARTs are not quite 16550-compatible. I just checked on a build at r277612 (a week old) and had no trouble. For reference the not-yet-working UARTs are: none7@pci0:0:30:3: class=0x078000 card=0x72708086 chip-0x0f0a8086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'ValleyView LPIO1 HSUART Controller' class = simple comms none8@pci0:0:30:4: class=0x078000 card=0x72708086 chip-0x0f0c8086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'ValleyView LPIO1 HSUART Controller' class = simple comms -- - ___ 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
UEFI boot hangs with MINNOWBOARD
Hi, I'm testing CURRENT on a MINNOWBOARD (http://www.elinux.org/Minnowboard:MinnowMax): Dual-core atom E3825 CPU EFI Version: 2.4.0 EFI: EDK II boot1.efi starts, it can found the ufs partition with loader.efi loader.efi fails at BT-ExitBootServices() (elf64_exec() of sys/boot/amd64/efi/elf64_freebsd.c) ExitBootServices() fails with error code 2 (INVALID_PARAMETER). The documentation of this function (http://wiki.phoenix.com/wiki/index.php/EFI_BOOT_SERVICES#ExitBootServices.28.29) states that the mapKey is wrong and GetMemoryMap() should be recall and then ExitBootServices() again. I've tried to implement it, but it fails again. My main problem is that I don't know which parameter should I pass to GetMemoryMap() I gave a look to this discussion (http://www.gossamer-threads.com/lists/linux/kernel/1733014) about retry ExitBootServices() on failure about eboot in Linux: they do a retry (only one) and they call also a FreePoll(). Do you have any tips, suggestions or something that could help to get FreeBSD boot on this apparently standard board? Best regards, Luca Pizzamiglio PS: should we implement the ExitBootServices() retry? ___ 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: [CFT] Xorg Upgrade 7.5.2
Running on: * Intel Sandybridge (+ optimus, disabled) on FreeBSD 9.0 * NVidia GTS 450 on FreeBSD 8.2 Not unkwonw problem. Usual problem on Intel Sandybridge (tty switch, KMS patch issues on FreeBSD 9 and optimus incompatibility (/dev/dri/card1)). Tested with KDE 4.7.4 and desktop effect activated. Not all effect are available using openGL. AFAIK KDE 4.8 is able to use more OpenGL effects using the same library. Thanks for the great job you've done! Best regards, Luca On 02/06/12 02:45, Martin Wilke wrote: Knock knock... The X11 Team is pleased to announce the next round of Xorg updates. Note that this is experimental so you really have to know what you are doing, read UPDATING in the repository, and follow our exact instructions. We are specifically looking for feedback from Intel, ATI and NVIDIA users. Summary of changes: xf86-video-nouveau has been removed along with the WITHOUT_NOUVEAU knob. We suggest switching to the nvidia blob. KMS Support [1]: Unfortunately, the intel KMS driver will only work for the latest FreeBSD 9-STABLE or 10-CURRENT users. The patch for HEAD current is named all.13.1.patch. The higher the version the newer the patch is. Other needed patches are already available in the Xorg update. HEAD Users: Get the latest patchset from Kib here: http://people.freebsd.org/~kib/drm/ 9-STABLE Users: 'meowthink' is currently maintaining the backport to 9 STABLE. Make sure you have the latest FreeBSD 9-STABLE source. Get the patch from here: https://docs.google.com/leaf?id=0BxbPi2OX4_B-NWY3NWU3MzEtNDBjYy00NTljLThlZGItMWFlYjIyYjI4Yjk3hl=en_US Rebuild your Kernel and reboot. Known issuse: There will be a patch reject in the sys/dev/drm/i915_suspend.c file. The solution is to manually undo the expansion of the $FreeBSD: $ tag, so it only saysis $FreeBSD$. Checkout Xorg Development Repo: You will need to install devel/subversion in order to checkout the xorg repo. Next, you will need to add WITH_NEW_XORG=yes in your /etc/make.conf if you want to try out the new Xorg and mesa. Intel users: note that if you are not qualified for the KMS patch, you shouldn't use WITH_NEW_XORG=yes because the old intel driver doesn't build with the new X server. If you are qualified, you should also set WITH_KMS=yes in /etc/make.conf. svn co https://trillian.chruetertee.ch/svn/ports/tags/xorg_7_5_2 A small merge script to merge the svn checkout into the real portstree can be found here: http://people.freebsd.org/~miwi/xorg/xorgmerge The script is a modified version of the old kdemerge script. Please set the KDEDIR variable to the path of your X.org ports. After merging, run one of the following command, depending on which tool you use to manage your installed packages. portupgrade -af \* portmaster -a After installing these, you will have to rebuild all xf86-* ports. We will bump all related ports during the commit to the ports tree. Roadmap: Our current plan is to let the CFT running until the last weekend of February. We hope to get a lot feedback to solve as many problems as possible. So please help us to get the best xorg update ever in! Links: http://wiki.freebsd.org/Intel_GPU [1] http://wiki.freebsd.org/Xorg http://miwi.bsdcrew.de/2012/02/working-on-xorg-stuff/ Your FreeBSD Xorg Team PS: Please reply to the x11@ mailing list. Cross posted due to the potentially disruptive nature of the change and need to get a wide variety of testers. ___ 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
