Return to Japanese full version
Return to system page(Japanese page)
Return to top page(Japanese page)
After stage support in above mentioned revision,
x11/nvidia-driver began displaying options dialog excessive times.
This is because of ordering violation in port Makefile.
Applying this patch to r342061 of x11/nvidia-driver/Makefile fixes for me.
Or you can use this patched Makefile.
I found this problem has been described additionally in ports/186465,
but I'm not using "PORTS_MODULES=" function.
So, I have not tested the situation.
If anyone reading this page can try and confirmed fix, please follow up to ports/186465.
Update: Nov.24,2013
After my previous update below,
japanese/mozc-tool became broken again with removal of WITH_LIBICONV_COMPAT option in base by r258230.
This is already fixed by Boris Samorodov in r334202.
This was a configure error,
mentioned Boris in freebsd-stable ML with patch.
But there can be some ports having hard dependency upon libiconv I haven't encountered yet.
Currently,
it seems that iconv-related issues are considered as almost "Show Stopper",
and progress for iconv and libc++ are in point of no return.
If you notice any issue for them,
please let RE team and developers know in freebsd-stable ML or freebsd-current ML.
Of course,
send-pr and then post to ML would be best.
But at present,
ML would be more noticeable for developers.
In above mentioned mozc-tool case,
Boris had done very quick response.
The issue below is fixed as r332611 few hours after I updated this file in Nov.03, 2013.
Currently (Nov.03, 2013), japanese/mozc-* doesn't build in FreeBSD stable/10.
Reading error messages, I figured out that japanese/mozc-server/files/patch-base_compiler_specific.h is no longer needed for stable/10 and later with clang + libc++.
But the patch is needed for stable/9 and earlier, and possibly stable/10 and later with gcc4.2.1 + libstdc++.
So, the patch should be conditionally applied, but I can't figured out how.
At least,
OSVERSION of 1000054 should not be proper boundary condition,
because anyone can use gcc4.2.1 + libstdc++ by setting WITH_GCC and WITH_GNUCXX options in src.conf.
The patch I submitted with kern/182963 is committed to head as r257841 at Fri Nov 8 08:44:10 UTC 2013 and to stable/10 as r258123 at Thu Nov 14 09:19:50 UTC 2013 respectively.
At this moment (Sun Nov 17 2013 JST) releng/10 haven't been created,
so smbfs should be usable in 10.0-RELEASE as stable/9 and before.
One more news.
WITH_LIBICONV_COMPAT option was removed from stable/10 by r258230.
With this change, all ports requiring libiconv.so.3, at least japanese/mozc-tool does not build or run in stable/10 anymore.
As commented to my revert request by Glen Barber, this issue is known to developers and they're working on solutions.
So we must wait until the solution comes in.
Currently (Oct.27, 2013), smbfs is broken in above version of FreeBSD.
As I already opened a thread in The FreeBSD Forums and send-pr'ed as kern/182963, the root cause is r255138 committed to head before branching stable/10.
In r255138, sb_timeo in struct sockbuf is changed from int to sbintime_t, but smbfs does not follow the change in sys/netsmb/smb_trantcp.c.
As sb_timeo is used in only sources below, it would be safe reverting r255138.
The last one is using sb_timeo for copy-only operation and should not be affected anyway.
But because r255138 is for better precision, fixing leftovers rather than reverting would be better for future.
So, applying diff below fixes the problem for me.
Index: /usr/src/sys/netsmb/smb_trantcp.c
===================================================================
--- /usr/src/sys/netsmb/smb_trantcp.c (revision 256425)
+++ /usr/src/sys/netsmb/smb_trantcp.c (working copy)
@@ -155,8 +155,8 @@
SOCKBUF_LOCK(&so->so_rcv);
soupcall_set(so, SO_RCV, nb_upcall, nbp);
SOCKBUF_UNLOCK(&so->so_rcv);
- so->so_rcv.sb_timeo = (5 * hz);
- so->so_snd.sb_timeo = (5 * hz);
+ so->so_rcv.sb_timeo = (5 * SBT_1S);
+ so->so_snd.sb_timeo = (5 * SBT_1S);
error = soreserve(so, nbp->nbp_sndbuf, nbp->nbp_rcvbuf);
if (error)
goto bad;
The diff can be downloaded here as smb_trantcp.c.diff.
As "5 * hz" in original source means "5 seconds", I modified it for the same meaning for sbintime style.
The macro "SBT_1S" is defined in sys/sys/time.h (included indirectly via sys/param.h or /sys/proc.h),
meaning "1 second" for sbintime format.
I didn't mention the actual timeout value of "5 seconds" is reasonable or not,
as smbfs before r255138 worked fine for me.
After my PR kern/182963,
I found another PR misc/183153 is newly registered by Dominic Fandrey.
I can't determine that Dominic's patch is reasonable or not (it's beyond my ability),
but it also can be fixed by rebuilding world with defining
WITH_LIBICONV_COMPAT=YES
in /etc/src.conf.
I think making above option as default and allowing opt-out should be better,
because
If you have any question,
please join The FreeBSD Forums and visit the related thread in it.
Discussing there is better because
An update introduced to /usr/src/usr.bin/yacc/skeleton.c by r254626 breaks buildworld.
It's already reverted by r254669, but world installed with above-mentioned revisions needs workaround.
First, update to latest src tree (at least, r254669 ot later).
Second, rebuild and install in /usr/src/usr.bin/yacc. (It has its own, standalone Makefile.)
That's all. Now, you can buildworld as usual.
Additional information in Sep. 1st, 2013.
In Thu Aug 29 09:33:12 UTC 2013, r255017, which allows users to manipulate active flag of GPT slice in protective MBR, is MFCed to stable/9.
Unfortunately, it didn't help my ThinkPad T420 with UEFI BIOS version 1.36, but Chris Torek's method is kept on usable after r255017.
Also, I could confirm setting active flag to first (dummy) slice in PMBR is no longer mandatory for Chris's method after r255017.
Someone should noticed darcsis's post to The FreeBSD Forums(March 31st, 2013, 15:23, #12 in thread) reporting "T430 is OK".
And Alexandr's post to freebsd-fs ML in Jul 4 10:42:32 UTC 2013 reporting ThinkPad E530 with BIOS 2.52 from 04/23/2013 is OK, but half-year ago it could'nt.
Possibly, latest T420 BIOS may be fixed as well, as newer dated one is already uploaded.
But I have'nt tried yet, as this T420 is currently my only workable PC and sometimes updating BIOS causes working PC non-bootable.
Another news.
Chris Torek's post to freebsd-i386 ML.
It's tricky. But yes, I confirmed GPT partitioned ThinkPad T420 can boot this way, without needs to modifying loader.
But I'd better complimentig what Chris would omitted.
Many of you will think "Why 1st slice must have type 0x00? Isn't setting 2nd blank slice as active sufficient?", like me.
So I tried, and failed. I could'nt figure out why, but Chris was exactly right.
Failed configuration is shown below. USB memstick attached as /dev/da0 with memstick.img of FreeBSD 9.0-Beta3 i386.
******* Working on device /dev/da0 *******
parameters extracted from in-core disklabel are:
cylinders=243 heads=255 sectors/track=63 (16065 blks/cyl)
parameters to be used for BIOS calculations are:
cylinders=243 heads=255 sectors/track=63 (16065 blks/cyl)
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 238 (0xee),(EFI GPT)
start 1, size 1096244 (535 Meg), flag 0
beg: cyl 0/ head 1/ sector 1;
end: cyl 202/ head 254/ sector 1
The data for partition 2 is:
sysid 0 (0000),(unused)
start 0, size 0 (0 Meg), flag 80 (active)
beg: cyl 0/ head 0/ sector 0;
end: cyl 0/ head 0/ sector 0
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
But please beware! Chris's method is to make abnormal MBR (same as "deleted slice is active").
I can't figure out which workaround is generally better, so I'll keep my method below.
In February 18, 2013, Apple Boot Camp support is MFC'ed to stable/9 branch as r246938.
With this MFC, /usr/sys/boot/common/part.c is updated.
But don't panic.
It does NOT affect my changes below.
It's still applied fine and boots OK.
If you're using svn to update /usr/src,
svn will merge the update cleanly to your working copy.
February 24, 2013: Additional important note for informations about loader below.
Every time I purchase new ThinkPad,
what I do first is to replace HDD not to boot pre-installed Windoze.
So, I've NOT tested hybrid installation with Windoze (and currently other OS'es, too).
Beware changing partition ID as below can cause other OS
(and FreeBSD with genuine loader)
not boot up!
In Novemver 18, 2012, a lot of MFC's are introduced to stable/9 branch as r243243.
After this MFC, fixes for /boot/loader has changed.
These changes is not introduced to upcoming 9.1-Release.
So, anyone willing to install 9.1-Release should apply old fixes.
For anyone using 9-STABLE, please apply new quick-and-dirty fix below before updating to r243243 or later.
I assume you have working FreeBSD 9-STABLE computer,
because target environment cannot boot FreeBSD without my fix.
Also,
I don't write methods for changing partition ID,
because it's RISKY operation and you shall EXACTLY know what you are doing.
svn diff /usr/src/sys/boot/common/part.c
Index: sys/boot/common/part.c
===================================================================
--- sys/boot/common/part.c (revision 243669)
+++ sys/boot/common/part.c (working copy)
@@ -634,7 +634,16 @@
break;
}
#ifdef LOADER_GPT_SUPPORT
- if (dp[i].dp_typ == DOSPTYP_PMBR) {
+
+/*
+ * Quick hack for Lenovo UEFI BIOS because it cannot boot from freebsd-boot
+ * partition in GPT slice having partition ID 0xee, but 0xef.
+ * Intentionally put magic No. here, because defining symbol in sys/diskmbr.h
+ * could have possibility of side effect to sbin/fdisk, usr/sbin/boot0cfg,
+ * usr/lib/libdisk.a, lib/geom/part.so because they include it.
+ */
+
+ if (dp[i].dp_typ == DOSPTYP_PMBR || dp[i].dp_typ == 0xef) {
table->type = PTABLE_GPT;
DEBUG("PMBR detected");
}
Note that pmbr and gptboot (I cannot test gptzfsboot) seems not to be affected.
Only loader needs fixing.
If someone send-pr above, please modify above for NOT using direct value 0xef here.
It should be defined in /usr/src/sys/sys/diskmbr.h something like
#define DOSPTYP_PMBR_LENUEFI 0xef /* quirks: GPT Protective MBR for Lenovo UEFI*/
and using defined symbol in /usr/src/sys/boot/common/part.c.
Some more infomation is described in Japanese full version.
I could'nt boot FreeBSD 9 (9.0-Beta, RC, then STABLE) installed in GPT partitions
of ThinkPad T420(4177-CTO), neither via gpart'ed partition nor via Disk1 installer.
Note that non-Disk1 gpart was proceeded in older ThinkPad running 8-STABLE environment with corresponding timing.
It's NOT a FreeBSD bug, but problematic spec of ThinkPad UEFI BIOS.
GPT includes dummy MBR style partition header in order NOT to be recognized as empty by old BIOSes that supports MBR partitions only.
In GPT specification, the dummy partition type shall be 0xEE as FreeBSD gpart does.
But ThinkPad UEFI BIOS cannot find partition type 0xEE as bootable.
Note that boot either from CDROM or MBR partitioned HDD is available.
Also, boot from GPT partitioned HDD is available in older (Non-UEFI) ThinkPad.
I found very very important hint in a post in The FreeBSD Forums.
The post is #2 dated October 7th, 2011, 04:31 of above-linked thread.
Of course, GPT loader of FreeBSD recognizes as bootable only if dummy partition type is 0xEE.
Force changing dummy partition type to 0xEF and modifying FreeBSD loader as below made FreeBSD in GPT partition of ThinkPad bootable.
Of course, writing gptboot, pmbr as described in gpart man page and installing loader to /boot are required.
diff /usr/src/sys/boot/common/disk.c.orig /usr/src/sys/boot/common/disk.c
536a537,538
> else if (dp[i].dp_typ == 0xef)
> part++;
diff /usr/src/sys/boot/i386/libi386/biosdisk.c.orig /usr/src/sys/boot/i386/libi386/biosdisk.c
885a886,887
> else if (dp[i].dp_typ == 0xef)
> part++;
diff /usr/src/sys/boot/uboot/lib/disk.c.orig /usr/src/sys/boot/uboot/lib/disk.c
275a276,277
> else if (dp[i].dp_typ == 0xef)
> part += 1;
Above changes was also effective for USB memsticks.
Currently, I'm ill and I cannot actively support things.
So, I can't send-pr or posting to ML, Forum and so on.
All I can do now is writhing this document.
And I know these problems are NOT of FreeBSD, and if merging to FreeBSD or other OSes, these should be treated as something QUIRKS.
In other hand, Lenovo does not support FreeBSD officially, so Lenovo has no responsibility for fixing their UEFI BIOSes if their supporting OSes has no problem.
I'm pleased if someone takes over above and send-pr.
Note that gpart and bsdinstall shoud be strongly wanted to support dummy partition type 0xEF for GPT if my modifications are merged.
Also, note that partition type 0xEF is for EFI System Partition.
Deleting or commenting out the line below in GENERIC makes ACPI in ThinkPad T420 NOT WORKING.
makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols
Formerly, I disabled all debugging lines in GENERIC.
If above line isn't active, booting with ACPI enabled made ThinkPad completely hang up, without panic or coredump.
Booting ACPI disabled in loader menu helps booting, but even CPU is recognized via ACPI, so CORE i7 with dual core was recognized as single core.
Unfortunately, modifications below (inspired by above mentioned thread in The FreeBSD Forums, post #4 dated October 7th, 2011, 06:27) did not help.
diff /usr/src/sys/dev/acpi_support/acpi_ibm.c.orig /usr/src/sys/dev/acpi_support/acpi_ibm.c
293c293
< static char *ibm_ids[] = {"IBM0068", NULL};
---
> static char *ibm_ids[] = {"IBM0068", "LEN0068", "TP-83", NULL};
Return to Japanese full version
Return to system page(Japanese page)
Return to top page(Japanese page)