Re: CURRENT: EFI boot failure
Am Mon, 15 Sep 2014 17:39:26 -0700 Nathan Whitehorn schrieb: > > On 09/15/14 17:36, Allan Jude wrote: > > On 2014-09-15 20:05, O. Hartmann wrote: > >> Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop works > >> for UEFI > >> fine. After I updated the sources to r271649, recompiled world and kernel > >> (as well > >> as installed), now I get stuck with the screen message: > >> > FreeBSD EFI boot block > >> Loader path: /boot/loader.efi > >> > >> and nothing happens. After a couple of minutes, the system reboots. > >> > >> What happened and how can this problem be solved? > >> > > You might need to update the boot1.efi file on the UEFI partition (small > > FAT partition on the disk) > > > > I am not sure how 'in sync' boot1.efi (on the fat partiton) and > > loader.efi have to be. > > > > https://wiki.freebsd.org/UEFI > > > > boot1.efi is designed never to need updating. (It also hasn't changed > since April) > -Nathan But it has changed bytesize when I recompiled world with recent sources compared to the boot.efi size from the USB image I installed from (revision see above). 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. 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. Oliver signature.asc Description: PGP signature
Re: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI
Hi, Try updating to the latest -HEAD. It at least makes dhclient behave better. -a On 15 September 2014 18:19, Kevin Oberman wrote: > On Mon, Sep 15, 2014 at 2:38 PM, O. Hartmann > wrote: > >> >> Trying to install and run FreeBSD 11.0-CURRENT >> (FreeBSD-11.0-CURRENT-amd64-20140903-r270990-memstick.img) on a new Lenovo >> E540 notebook >> fails in activating the NIC (Realtek RTL8111/8168B, driver re[0]). The NIC >> shows up as >> active and with carrier when issuing "ifconfig re0". >> >> From a desktop machine, I tried to ping the system in question and I get a >> result with >> missing packets: >> >> ping: sendto: Host is down >> ping: sendto: Host is down >> ping: sendto: Host is down >> 64 bytes from 192.168.0.130: icmp_seq=26 ttl=64 time=0.114 ms >> 64 bytes from 192.168.0.130: icmp_seq=41 ttl=64 time=0.130 ms >> 64 bytes from 192.168.0.130: icmp_seq=60 ttl=64 time=0.119 ms >> 64 bytes from 192.168.0.130: icmp_seq=80 ttl=64 time=0.119 ms >> 64 bytes from 192.168.0.130: icmp_seq=100 ttl=64 time=0.105 ms >> 64 bytes from 192.168.0.130: icmp_seq=116 ttl=64 time=0.135 ms >> 64 bytes from 192.168.0.130: icmp_seq=136 ttl=64 time=0.091 ms >> >> DHCP configuration fails, since no DHCP offer is discovered. >> >> I swapped the switches, the cabling and I had always the same results. I >> used another >> Laptop, Dell Latitude E6510 with the same configuration (/etc/rc.conf) and >> that system >> gets DHCP offer and is online. >> >> Since the notebook is brandnew, the last thing I'll "suspect" is a >> defective NIC, so I'll >> ask whether this phenomenon is known - or, if not, the results >> definititely would >> indicate a broken NIC. >> >> Another point is the WiFI adaptor. This notebook is supposed to have a >> WiFi NIC, but it >> doesn't get revealed by FreeBSD (I tried iwn/iwi without success). >> >> pciconf output below, sorry for the messy shape, it is a copy-and-paste >> from that immature >> vt() terminal. >> >> Has anyone successfully installed that type of Notebook with FreeBSD >> CURRENT using NIC >> and Wifi? >> >> Please CC me. >> >> >> Regards >> oh >> >> >> [...] >> >> none1@pci0:3:0:0: class=0xff card=0x502817aa chip=0x522710ec >> rev=0x01 hdr=0x00 >> >> >> vendor = 'Realtek Semiconductor Co., Ltd.' >> >> >> bar [10] = type Memory, range 32, base 0xf1e0, size 4096, enabled >> >> >> cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 >> >> >> cap 05[50] = MSI supports 1 message, 64 bit >> >> >> cap 10[70] = PCI-Express 2 endpoint max data 128(128) link x1(x1) >> >> >> speed 2.5(2.5) ASPM L0s/L1(L0s/L1) >> >> >> ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected >> >> >> ecap 0003[140] = Serial 1 0001004ce000 >> >> >> re0@pci0:4:0:0: class=0x02 card=0x502817aa chip=0x816810ec rev=0x10 >> hdr=0x00 >> >> >> subclass = ethernet >> >> >> cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current >> D0 >> di sabled(L0s/L1) >> >> >> cap 11[b0] = MSI-X supports 4 messages, enabled >> >> ecap 0001[100] = AER 2 0 fatal 0 non-fatal 4 corrected >> >> >> >> ecap 001e[178] = unknown 1 >> >> >> class = network >> >> >> cap 05[d0] = MSI supports 1 message, 64 bit >> >> >> ecap 0003[140] = Serial 1 ac7ba1a06fd6 >> > > I can't comment on the WiFi, I have little Asus box using an 8111/8168B and > it works fine with the driver in 10.1-BETA. The driver in 10.0 recognizes > the device, but did not work. I do notice that your NIC has a rev of 0x10 > while mine is 0x0c. > -- > Kevin Oberman, Network Engineer, Retired > ___ > 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: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI
On Mon, Sep 15, 2014 at 2:38 PM, O. Hartmann wrote: > > Trying to install and run FreeBSD 11.0-CURRENT > (FreeBSD-11.0-CURRENT-amd64-20140903-r270990-memstick.img) on a new Lenovo > E540 notebook > fails in activating the NIC (Realtek RTL8111/8168B, driver re[0]). The NIC > shows up as > active and with carrier when issuing "ifconfig re0". > > From a desktop machine, I tried to ping the system in question and I get a > result with > missing packets: > > ping: sendto: Host is down > ping: sendto: Host is down > ping: sendto: Host is down > 64 bytes from 192.168.0.130: icmp_seq=26 ttl=64 time=0.114 ms > 64 bytes from 192.168.0.130: icmp_seq=41 ttl=64 time=0.130 ms > 64 bytes from 192.168.0.130: icmp_seq=60 ttl=64 time=0.119 ms > 64 bytes from 192.168.0.130: icmp_seq=80 ttl=64 time=0.119 ms > 64 bytes from 192.168.0.130: icmp_seq=100 ttl=64 time=0.105 ms > 64 bytes from 192.168.0.130: icmp_seq=116 ttl=64 time=0.135 ms > 64 bytes from 192.168.0.130: icmp_seq=136 ttl=64 time=0.091 ms > > DHCP configuration fails, since no DHCP offer is discovered. > > I swapped the switches, the cabling and I had always the same results. I > used another > Laptop, Dell Latitude E6510 with the same configuration (/etc/rc.conf) and > that system > gets DHCP offer and is online. > > Since the notebook is brandnew, the last thing I'll "suspect" is a > defective NIC, so I'll > ask whether this phenomenon is known - or, if not, the results > definititely would > indicate a broken NIC. > > Another point is the WiFI adaptor. This notebook is supposed to have a > WiFi NIC, but it > doesn't get revealed by FreeBSD (I tried iwn/iwi without success). > > pciconf output below, sorry for the messy shape, it is a copy-and-paste > from that immature > vt() terminal. > > Has anyone successfully installed that type of Notebook with FreeBSD > CURRENT using NIC > and Wifi? > > Please CC me. > > > Regards > oh > > > [...] > > none1@pci0:3:0:0: class=0xff card=0x502817aa chip=0x522710ec > rev=0x01 hdr=0x00 > > > vendor = 'Realtek Semiconductor Co., Ltd.' > > > bar [10] = type Memory, range 32, base 0xf1e0, size 4096, enabled > > > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > > > cap 05[50] = MSI supports 1 message, 64 bit > > > cap 10[70] = PCI-Express 2 endpoint max data 128(128) link x1(x1) > > > speed 2.5(2.5) ASPM L0s/L1(L0s/L1) > > > ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected > > > ecap 0003[140] = Serial 1 0001004ce000 > > > re0@pci0:4:0:0: class=0x02 card=0x502817aa chip=0x816810ec rev=0x10 > hdr=0x00 > > > subclass = ethernet > > > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current > D0 > di sabled(L0s/L1) > > > cap 11[b0] = MSI-X supports 4 messages, enabled > > ecap 0001[100] = AER 2 0 fatal 0 non-fatal 4 corrected > > > > ecap 001e[178] = unknown 1 > > > class = network > > > cap 05[d0] = MSI supports 1 message, 64 bit > > > ecap 0003[140] = Serial 1 ac7ba1a06fd6 > I can't comment on the WiFi, I have little Asus box using an 8111/8168B and it works fine with the driver in 10.1-BETA. The driver in 10.0 recognizes the device, but did not work. I do notice that your NIC has a rev of 0x10 while mine is 0x0c. -- Kevin Oberman, Network Engineer, Retired ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT: EFI boot failure
On 09/15/14 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 ___ 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 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 -- Allan Jude signature.asc Description: OpenPGP digital signature
CURRENT: EFI boot failure
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? signature.asc Description: PGP signature
Re: libthr and main thread stack size
On Aug 8, 2014, at 5:22 AM, Konstantin Belousov wrote: … > Below is the patch which adds environment variable LIBPTHREAD_BIGSTACK_MAIN. > Setting it to any value results in the main thread stack left as is, and > other threads allocate stack below the area of RLIMIT_STACK. Try it. > I do not want to set this behaviour as default. Is there a reason this should not be the default? Looking at the getrlimit() page on the OpenGroup’s site they say: RLIMIT_STACK This is the maximum size of the initial thread's stack, in bytes. The implementation does not automatically grow the stack beyond this limit. If this limit is exceeded, SIGSEGV shall be generated for the thread. If the thread is blocking SIGSEGV, or the process is ignoring or catching SIGSEGV and has not made arrangements to use an alternate stack, the disposition of SIGSEGV shall be set to SIG_DFL before it is generated. Does posix say something different? I ran into this issue when debugging a segfault on Postgres when running an (arguably quite bogus) query that should have fit within both the configured stack rlimit and Postgres’ configured stack limit. The Postgres backend is really just single threaded, but happens to pull in libpthread due to the threading support in some of the libraries it uses. The segfault definitely violates POLA. — Justin signature.asc Description: Message signed with OpenPGP using GPGMail
11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI
Trying to install and run FreeBSD 11.0-CURRENT (FreeBSD-11.0-CURRENT-amd64-20140903-r270990-memstick.img) on a new Lenovo E540 notebook fails in activating the NIC (Realtek RTL8111/8168B, driver re[0]). The NIC shows up as active and with carrier when issuing "ifconfig re0". From a desktop machine, I tried to ping the system in question and I get a result with missing packets: ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down 64 bytes from 192.168.0.130: icmp_seq=26 ttl=64 time=0.114 ms 64 bytes from 192.168.0.130: icmp_seq=41 ttl=64 time=0.130 ms 64 bytes from 192.168.0.130: icmp_seq=60 ttl=64 time=0.119 ms 64 bytes from 192.168.0.130: icmp_seq=80 ttl=64 time=0.119 ms 64 bytes from 192.168.0.130: icmp_seq=100 ttl=64 time=0.105 ms 64 bytes from 192.168.0.130: icmp_seq=116 ttl=64 time=0.135 ms 64 bytes from 192.168.0.130: icmp_seq=136 ttl=64 time=0.091 ms DHCP configuration fails, since no DHCP offer is discovered. I swapped the switches, the cabling and I had always the same results. I used another Laptop, Dell Latitude E6510 with the same configuration (/etc/rc.conf) and that system gets DHCP offer and is online. Since the notebook is brandnew, the last thing I'll "suspect" is a defective NIC, so I'll ask whether this phenomenon is known - or, if not, the results definititely would indicate a broken NIC. Another point is the WiFI adaptor. This notebook is supposed to have a WiFi NIC, but it doesn't get revealed by FreeBSD (I tried iwn/iwi without success). pciconf output below, sorry for the messy shape, it is a copy-and-paste from that immature vt() terminal. Has anyone successfully installed that type of Notebook with FreeBSD CURRENT using NIC and Wifi? Please CC me. Regards oh [...] none1@pci0:3:0:0: class=0xff card=0x502817aa chip=0x522710ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' bar [10] = type Memory, range 32, base 0xf1e0, size 4096, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint max data 128(128) link x1(x1) speed 2.5(2.5) ASPM L0s/L1(L0s/L1) ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 0001004ce000 re0@pci0:4:0:0: class=0x02 card=0x502817aa chip=0x816810ec rev=0x10 hdr=0x00 subclass = ethernet cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 di sabled(L0s/L1) cap 11[b0] = MSI-X supports 4 messages, enabled ecap 0001[100] = AER 2 0 fatal 0 non-fatal 4 corrected ecap 001e[178] = unknown 1 class = network cap 05[d0] = MSI supports 1 message, 64 bit ecap 0003[140] = Serial 1 ac7ba1a06fd6 signature.asc Description: PGP signature
Re: Driver-specific debugging in buildkernel?
On Sunday, September 14, 2014 07:56:16 PM Thomas Mueller wrote: > I want to build a kernel with debugging for a specific device, rather than > for everything. > > Device of interest is re (Ethernet driver), also rsu (USB wlan adapter). > > I looked in Makefiles, also NOTES files, found some DEBUG options but > nothing really general that could be applied to any desired device in > kernel or module. > > Then I would need to know how to find this debugging information. There isn't a generic "debugging for driver X" knob. You can enable global debugging (e.g. INVARIANTS). Some drivers may have their own internal knobs, but most drivers depend on the global knobs. If you are debugging a driver as a module, you can build the kernel with INVARIANT_SUPPORT and just the driver with INVARIANTS. However, drivers invariably make calls into other subsystems in the kernel and that setup will not include checking for driver misbehavior in its interfacing with those subsystems, so I would generally recommend just enabling INVARIANTS globally. -- John Baldwin ___ 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: resource_list_alloc: resource entry is busy
On Friday, September 12, 2014 10:03:26 PM Marcin Cieslak wrote: > On Fri, 12 Sep 2014, John Baldwin wrote: > >> Please note I originally loaded "i915.ko", not "i915kms.ko" > > > > Oh, that is probably your problem. X loaded i915kms automatically and > > i915 and i915kms do not get along. i915 had already allocated the IRQ > > when i915kms tried to alloc the same IRQ causing the issue. > > Would that be possible to fail with EBUSY or something instead of panic? Yes, though in this case you probably will end up with a black screen and an apparent hang due to how KMS works which wouldn't be a lot better. :( -- John Baldwin ___ 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: Xorg causes panics with "multiple" drivers (Was: panic: resource_list_alloc: resource entry is busy)
On Saturday, September 13, 2014 10:57:53 AM d...@gmx.com wrote:
> John Baldwin wrote on 09/12/2014 23:06:
> > X loaded i915kms automatically and
> > i915 and i915kms do not get along. i915 had already allocated the IRQ
> > when i915kms tried to alloc the same IRQ causing the issue.
>
> Who is to blame? The user who tried to manually load an unsupported
> combination of modules, or the system, which should have handled things
> gracefully (whether by automatically unloading the first driver, or
> producing a soft-error upon loading the 2nd driver)?
>
> On a side-note, I also had a "resource_list_alloc: resource entry is busy"
> panic right after switching from the 10.0-supported Xorg to the "new" Xorg;
> I exited Xorg, enabled "FreeBSD_new_Xorg", ran "pkg upgrade", then ran
> "startx", and got the panic. Surely this wasn't my fault!
I can turn the panic into a resource allocation failure, but specifically with
KMS I am unsure if it will actually be better. It depends on when the driver
does this IRQ allocation. You may very well end up with a black screen and a
seemingly "hung" system (though it would not actually be hung).
I do think we should fix i915kms to fail fast if i915 is loaded, or more
likely I think we should probably look at removing the old i915 driver from
HEAD entirely so that 11 doesn't ship with it. It won't work with the Xorg we
are shipping with 11, so it's really dead code at this point.
The proposed diff would be:
Index: subr_bus.c
===
--- subr_bus.c (revision 271627)
+++ subr_bus.c (working copy)
@@ -3301,7 +3301,10 @@ resource_list_alloc(struct resource_list *rl, devi
rle->flags |= RLE_ALLOCATED;
return (rle->res);
}
- panic("resource_list_alloc: resource entry is busy");
+ device_printf(bus,
+ "resource entry %#x type %d for child %s is busy\n", *rid,
+ type, device_get_nameunit(child));
+ return (NULL);
}
if (isdefault) {
--
John Baldwin
___
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"
