Re: [r306298]: buildworld fails with OFED: nm: 'log.pico': No such file or directory
On September 24, 2016 at 11:14:38 AM, O. Hartmann (ohart...@zedat.fu-berlin.de) wrote: Am Sat, 24 Sep 2016 10:33:26 -0700 Marcel Moolenaar <mar...@xcllnt.net> schrieb: > On September 24, 2016 at 10:26:44 AM, O. Hartmann > (ohart...@zedat.fu-berlin.de) wrote: > > Recent sources of CURRENT (r306298) fail to build while WITH OFED is > selected: > That’s me. Looking into it. > > It has been resolved by commit Thanks for confirming. I was still waiting for my build to complete... signature.asc Description: Message signed with OpenPGP using AMPGpg
Re: [r306298]: buildworld fails with OFED: nm: 'log.pico': No such file or directory
On September 24, 2016 at 10:26:44 AM, O. Hartmann (ohart...@zedat.fu-berlin.de) wrote: Recent sources of CURRENT (r306298) fail to build while WITH OFED is selected: That’s me. Looking into it. signature.asc Description: Message signed with OpenPGP using AMPGpg
HEADSUP: *.So renamed to *.pico
All, FreeBSD can now be compiled on a case-insensitive file system. For this to happen, relocatable objects compiled with -fpic (aka shared objects) were renamed from *.So to *.pico so that they don’t clash with shared libraries that have extension *.so. You may want to avoid using an incremental build (after updating the source tree) or otherwise first rename all *.So files to *.pico. FYI, — Marcel Moolenaar mar...@xcllnt.net ___ 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"
Re: hint.uart.1 in device.hints causes freeze at boot
> On Feb 26, 2016, at 7:48 AM, Lundberg, Johannes > <johan...@brilliantservice.co.jp> wrote: > > Hi > > Not sure if it's ok to cross post but I wasn't sure which list to send to. > > On Intel Atom X5-Z8300 SoC (CherryTrail) the install memstick image (amd64) > halts during boot because of uart.1 settings in device hints. I have found that FreeBSD’s default device.hints file has fallen behind on reality and is indeed causing problems on more modern H/W, like the H/W you mention. > > I'm sure it is there for a reason so what is the alternative actions? Is > the solution to get a bootable Atom SoC image to create yet another > distribution or can the installer choose the proper device.hints > dynamically during boot? FreeBSD should really get rid of any default hints by now; or at least limit the hints to what is absolutely certain to be needed or to be correct. -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: r286615: /usr/libexec/ftpd broken!
On Aug 18, 2015, at 7:46 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Am Tue, 18 Aug 2015 07:35:25 -0700 Marcel Moolenaar mar...@xcllnt.net schrieb: On Aug 17, 2015, at 10:15 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Port security/heimdal installs its own ftpd with its appropriate manpages. Ugh :-( It would have been so nice if man(1) would have told you that there were 2 ftpd manpages and that you need to specify which one you want. That should raise an eyebrow right away... A hint came from this list, so I checked via locate the existence of multiple ftpd and ftpd.8[.gz] - and yes, I found several. I circumvent the problem by applying to man the option -M/usr/share/man which brought up the the correct manpage. I think distinct sections would be nice: 1-9 base system 1P-9P ports/packages 1L-9L local manpages. And if it would not be hard ebough, I figured, that deleting port security/heimdal didn't erase the manpage on the particular machine I tested with :-/ Cached manpage, I presume? -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: r286615: /usr/libexec/ftpd broken!
On Aug 17, 2015, at 10:15 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Port security/heimdal installs its own ftpd with its appropriate manpages. Ugh :-( It would have been so nice if man(1) would have told you that there were 2 ftpd manpages and that you need to specify which one you want. That should raise an eyebrow right away... -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Appending to message buffer while in ddb
On Aug 3, 2015, at 12:59 PM, Eric Badger eric_bad...@dell.com wrote: Hi there, Since r226435, output from kernel printf/log functions is not appended to the message buffer when in ddb. The commit message doesn't call this out specifically; instead it appears to have been to address double printing to the console while in ddb. I noticed this because a ddb script which previously resulted in some things ending up in a textdump's msgbuf.txt no longer does so. It may be that the answer is use db_printf in ddb, which is ok, but I thought I'd check anyway to see if the aforementioned change was indeed intentional, since I wasn't able to dig up any discussion about it. It’s a direct consequence. -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ls is broken for non-C locales due to libxo
On Jun 16, 2015, at 9:53 PM, Andrey Chernov a...@freebsd.org wrote: Should be no any %FF, but single char in pre libxo ls or nothing in post libxo one. Use LANG=ru_RU.KOI8-R before touch command. It looks like you create file with name %FF instead. No difference: fbsdvm64% env LANG=ru_RU.KOI8-R touch `env LANG=ru_RU.KOI8-R printf \377` fbsdvm64% ls -al total 8 -rw-r--r-- 1 marcel staff0 Jun 17 06:56 %FF drwxr-xr-x 3 marcel staff 102 Jun 17 06:56 . drwxr-xr-x 12 marcel staff 408 Jun 17 06:55 .. -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ls is broken for non-C locales due to libxo
On Jun 17, 2015, at 9:35 AM, Andrey Chernov a...@freebsd.org wrote: Signed PGP part On 17.06.2015 16:58, Marcel Moolenaar wrote: On Jun 16, 2015, at 9:53 PM, Andrey Chernov a...@freebsd.org wrote: Should be no any %FF, but single char in pre libxo ls or nothing in post libxo one. Use LANG=ru_RU.KOI8-R before touch command. It looks like you create file with name %FF instead. No difference: fbsdvm64% env LANG=ru_RU.KOI8-R touch `env LANG=ru_RU.KOI8-R printf \377` fbsdvm64% ls -al total 8 -rw-r--r-- 1 marcel staff0 Jun 17 06:56 %FF drwxr-xr-x 3 marcel staff 102 Jun 17 06:56 . drwxr-xr-x 12 marcel staff 408 Jun 17 06:55 .. The original bug was fixed in r284494 by kan@ In any case, what you demonstrates is very strange and can be display (console,xterm,etc.) bug or probably libxio bug, because ls alone _never_ use %xx encoding, it should print '?' for invalid character or just character itself for valid ones. Good point. I’ll try various things (esp. compare against 10). -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ls is broken for non-C locales due to libxo
On Jun 16, 2015, at 8:46 PM, Andrey Chernov a...@freebsd.org wrote: Signed PGP part On 17.06.2015 6:23, Marcel Moolenaar wrote: Date/time is fixed. I don?t know how to reproduce the filename problem, so make sure sources are up-to-date and if still a problem, provide me with a way to reproduce. touch `printf \377` env LANG=ru_RU.KOI8-R ls -l | od -bc | grep 377 fbsdvm64% touch `printf \377”` fbsdvm64% ls -l | head -2 total 96 -rw-r--r-- 1 marcel staff 0 Jun 16 21:25 %FF fbsdvm64% env LANG=ru_RU.KOI8-R ls -l | head -2 total 96 -rw-r--r-- 1 marcel staff 0 16 ??? 21:25 %FF So, what’s wrong? -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ls is broken for non-C locales due to libxo
On Jun 16, 2015, at 7:42 PM, Andrey Chernov a...@freebsd.org wrote: On 17.06.2015 5:18, Andrey Chernov wrote: Recent -current, LANG=ru_RU.KOI8-R locale. ls -t eats whole date column, just ls eats whole filenames with printable national characters inside. Long live libxo. I mean ls -l. To be precise, for 8bit non-C locales at least: ls -lt: skip date column and eat filename with even single 8bit character inside. ls -l: just eat filename as above. Date/time is fixed. I don’t know how to reproduce the filename problem, so make sure sources are up-to-date and if still a problem, provide me with a way to reproduce. Thanks, -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
nagios vs w/uptime
[Moving to current@] On Feb 10, 2015, at 11:52 AM, Peter Wemm pe...@wemm.org wrote: Surprises: * nagios doesn't like w / uptime anymore. libxo perhaps? Seems most likely, although I haven’t seen any differences in output in my (admittedly limited) testing. In what way does Nagios not like w/uptime? Any concrete errors, output or misbehavior? Ideally: can you reproduce the problem? -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Poor state of the build infrastructure.
On Sep 24, 2014, at 12:54 PM, John Baldwin j...@freebsd.org wrote: On Tuesday, September 23, 2014 09:29:48 AM Marcel Moolenaar wrote: What is going on here? Are we still in some kind of flux and people aren't done yet or is this the intended state by virtue of noone having anything left on there TODO list? Sorry to ask a dumb question, but are you sure you did the make buildworld first? Shouldn't that have errored if it couldn't build crt1? The root cause problem was that MAKEOBJDIRPREFIX was not set to whatever it was set to during buildworld. That was easy enough to figure out when a bunch of things don't add up. But neither problem mentioned in the email had anything to do with MAKEOBJDIRPREFIX. Having to set the COMPILER_TYPE as part of an install is a bug. Entering a powerpc buildenv and having a compiler that builds for the host (or maybe just some default) is a regression. The only thing the FreeBSD build is good at, really, is building in /usr/src for the host. The rest is just not up to par and I think it harms FreeBSD beyond belief. -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Poor state of the build infrastructure.
On Sep 24, 2014, at 4:47 PM, Justin Hibbits chmeeed...@gmail.com wrote: It should probably error out instead, since the build environment isn't sane at this point. I ran into this probably a few weeks back. The only thing the FreeBSD build is good at, really, is building in /usr/src for the host. The rest is just not up to par and I think it harms FreeBSD beyond belief. I have no problems building outside of /usr/src. It's not a problem in the sense that it cannot be done, but just think about having to share a machine with a bunch of people and you don't own the machine. You quickly realize that without MAKEOBJDIRPREFIX or with files in /etc (like /etc/make.conf) that you can't tweak, you quick;y realize how error prone everything and how much time you end up wasting. -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Poor state of the build infrastructure.
Things have regressed from last I tried (which is a while). After a clean buildworld for PowerPC I can't install it: # make installworld TARGET_ARCH=powerpc TARGET=powerpc __MAKE_CONF=/dev/null DESTDIR=/tank/scratch/powerpc mkdir -p /tmp/install.pjtGQ4J8 : make[2]: /tank/scratch/marcelm/head/share/mk/bsd.compiler.mk line 37: Unable to determine compiler type for cc. Consider setting COMPILER_TYPE. *** Error code 1 And look at share/mk/bsd.compiler.mk. Its comments with typos doesn't even fit 80 character. While technically speaking, not a problem, it does leave the impression of low quality. This has the unfortunate side-effect of deepening the low quality perception caused by not being able to do an installworld in the first place. So, ok. I add COMPILER_TYPE=fuckthat to the command line and guess what: # make installworld TARGET_ARCH=powerpc TARGET=powerpc __MAKE_CONF=/dev/null DESTDIR=/tank/scratch/powerpc COMPILER_TYPE=fuckthat mkdir -p /tmp/install.pFqalBOs : Making hierarchy : Installing everything : === lib/csu/powerpc (install) install -o root -g wheel -m 444 crt1.o crti.o crtn.o Scrt1.o gcrt1.o /tank/scratch/powerpc/usr/lib install: crt1.o: No such file or directory *** Error code 71 What??? Ok, let's check if things were build properly: % make buildenv __MAKE_CONF=/dev/null TARGET=powerpc TARGET_ARCH=powerpc $ cd lib/csu/powerpc $ make : cc -O2 -pipe ... -c crti.S crti.S:34:13: error: unexpected token in memory operand stwu 1,-16(1) ^ crti.S:35:2: error: invalid instruction mnemonic 'mflr' mflr 0 ^~~~ crti.S:36:12: error: unexpected token in memory operand stw 31,12(1) ^ crti.S:37:11: error: unexpected token in memory operand stw 0,20(1) ^ crti.S:38:2: error: invalid instruction mnemonic 'mr' mr 31,1 ^~ crti.S:45:13: error: unexpected token in memory operand stwu 1,-16(1) ^ crti.S:46:2: error: invalid instruction mnemonic 'mflr' mflr 0 ^~~~ crti.S:47:12: error: unexpected token in memory operand stw 31,12(1) ^ crti.S:48:11: error: unexpected token in memory operand stw 0,20(1) ^ crti.S:49:2: error: invalid instruction mnemonic 'mr' mr 31,1 ^~ *** Error code 1 Grrr... $ which cc /usr/bin/cc $ cc -v FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: x86_64-unknown-freebsd10.1 Thread model: posix Selected GCC installation: So, now even the very questionable but fundamentally non-broken make buildenv isn't working anymore. How is anyone going to develop for anything but the host this way. Granted we seriously sucked in this regard to begin with but we seem to have regressed to the point of having absolutely no working support whatsoever. What is going on here? Are we still in some kind of flux and people aren't done yet or is this the intended state by virtue of noone having anything left on there TODO list? -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: mkimg used to create gpt image, problem booting
On Aug 25, 2014, at 12:48 AM, Andrey V. Elsukov bu7c...@yandex.ru wrote: On 25.08.2014 03:55, Marcel Moolenaar wrote: Though, w/ people dd'ing images onto disks, and using growfs to grow as necessary, we might want to allocate a few more more than the minimum... I do agree that we want to keep sizes to a minimum... One thing I can maybe do is simply fill the empty sectors that are there because of alignment. If you add -P 4K to mkimg, then the first partition will by 4K aligned and you have about 5 sectors unused between the end of the GPT table and the first sector of the first partition. I may as well extend the table to cover those unued sectors. IMHO, mkimg should behave like gpart and create images in gpart-compatible way. It already does. There's s difference between behaving like something else or behaving exactly identical to that something. The same applies to compatible. It is not the same as identical. There is no compatibility issue. mkimg follows the GPT specification (modulo bugs) and gpart happily groks the partition table. Some users may want to copy the partition layout from the image to real hardware and they will not be able to do it. I'm inclined to say that generally speaking this is not possible. The GPT has metadata in the first few sectors *and* the last few sectors and LBAs of these sectors are part of the metadata. You cannot blindly copy an image onto a physical medium unless the image and the physical medium are of exactly the same size. Odds are they are not. To reliably transfer or convert an image (e.g. RAW-VHD) one must modify the image as part of the process. Not a hard rule, but best to assume as a rule of thumb. This seems to warrant a utility all by itself. Also, now FreeBSD 11.0 uses different first usable LBA. By default it is 4k aligned. And this creates some incompatibility with older versions. You can't do `gpart restore` and get the same table, as you had on older system. It sounds restore is broken then. The restore command cannot ever assume anything about the GPT. Including the tool that created the GPT. In order to restore a GPT, it must be properly backed-up. The backup header and table should suffice most of the time for that purpose as it's a replica, but as soon as meta-data is missing and the restore command has to guess, things will go wrong. -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: mkimg used to create gpt image, problem booting
On Aug 24, 2014, at 2:11 AM, Andrey V. Elsukov bu7c...@yandex.ru wrote:
On 24.08.2014 06:14, Craig Rodrigues wrote:
I did some further debugging inside the loader by doing the following.
- I added CFLAGS += -DPART_DEBUG to sys/boot/common/Makefile.inc
- I added DEBUG() statements all over sys/boot/common/part.c
I observed that in sys/boot/common/part.c in the ptbl_gptread() function,
that in this section:
305 ent = (struct gpt_ent *)tbl;
306 size = MIN(hdr.hdr_entries * hdr.hdr_entsz,
307 MAXTBLSZ * table-sectorsize);
308 for (i = 0; i size / hdr.hdr_entsz; i++, ent++) {
309 if (uuid_equal(ent-ent_type, gpt_uuid_unused,
NULL))
310 continue;
ent-ent_type is all 0's, which matches gpt_uuid_unused, so it bails
out of the loop and never adds the gpt partitions to the list of partitions
that the loader can access.
Yes, the problem is in the ptable_gptread() function. I'll commit the fix.
Actually, no. There is *a* problem in that function:
The function does not respect hdr.hdr_entsz when it
needs the next entry. It simply uses ent++, which
is fixed our definition of struct gpt_ent and may
not match the definition of the writer.
I don't see how the loader is responsible for *the*
problem. All I see in qemu is that the loader, when
it reads a sector, isn't getting the actual sector
data that's in the image.
Just do a ktrace on qemu and you'll see what I mean.
YMMV of course,
--
Marcel Moolenaar
mar...@xcllnt.net
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: mkimg used to create gpt image, problem booting
On Aug 24, 2014, at 9:59 AM, Craig Rodrigues rodr...@freebsd.org wrote: On Sun, Aug 24, 2014 at 2:11 AM, Andrey V. Elsukov bu7c...@yandex.ru wrote: Yes, the problem is in the ptable_gptread() function. I'll commit the fix. Should mkimg be changed to create a partition table with 128 entries by default, to match older versions of FreeBSD which do not have this fix? Maybe. 128 is the suggested default. It's not a hard lower limit. Technically speaking, it's perfectly fine to create just enough entries to fill a single sector. Then again, code makes all kinds of assumptions or has all kinds of bugs -- just like the logic in the loader apparently. By having mkimg create a large table, even if it's knows up front that it doesn't have to may prevent broken code from tripping over, bit it surely bloats the image for no reason. -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: mkimg used to create gpt image, problem booting
On Aug 24, 2014, at 4:31 PM, John-Mark Gurney j...@funkthat.com wrote: With mkimg, you know exactly how many partitions you are creating , so you don't need to specify 128 as the number of partitions. Though, w/ people dd'ing images onto disks, and using growfs to grow as necessary, we might want to allocate a few more more than the minimum... I do agree that we want to keep sizes to a minimum... One thing I can maybe do is simply fill the empty sectors that are there because of alignment. If you add -P 4K to mkimg, then the first partition will by 4K aligned and you have about 5 sectors unused between the end of the GPT table and the first sector of the first partition. I may as well extend the table to cover those unued sectors. However, this is a pretty side-ways way to end up with a GPT table that has some extra room. Maybe having scheme- specific options for this kind of thing is not bad. At least EBR and APM have the same problem and the BSD disk label can also be created with more than just 8 partitions. Related: o Is there a need to create images with empty space at the end of in between partitions? o Is there a need to create partitions with specific indices (i.e. index 6 for a typical 'f' partition)? Answers to these questions could help figure this out... -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: mkimg used to create gpt image, problem booting
On Aug 23, 2014, at 12:00 PM, Craig Rodrigues rodr...@freebsd.org wrote: I ran the following crazy experiment, just to see what would happen: dd if=/dev/md1s2 of=/dev/md0s2 bs=8192 I then tried to boot the first image with QEMU, and it booted successfully, with my UFS file system that I had previously created with makefs. I'm not sure where to look for the problem. I notice that in the non-working image, the offset starts at block 3, while in the working image, the offset starts at block 34. Is that enough to make things not boot? Could be. Try the -P option to mkimg. It sets the underlying (unexposed) physical sector size while still working with the visible 512 bytes sectors. The net effect is that for the GPT scheme things get aligned to the physical sector size and that it also causes the image size to be rounded. You can also try emitting vmdk directly to see if that makes a difference. vmdk also has the side- effect of rounding the image to the grain size. -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: mkimg used to create gpt image, problem booting
On Aug 22, 2014, at 9:49 AM, Craig Rodrigues rodr...@freebsd.org wrote: (5) Tried to boot the image with qemu: qemu-system-x86_64 -m 2048 -hda /tmp/foo1.img *snip* If I mdconfig the foo1.img disk image, and do a gpart show, I see: = 3 1784944 md0 GPT (872M) 3 321 freebsd-boot (16K) 35 17849122 freebsd-ufs (872M) Any idea what I am doing wrong? To the best of my knowledge, qemu is the thing you're doing wrong :-) I have so far not been able to boot an image created by mkimg with a FreeBSD-hosted qemu. o VMware and VirtualBox are fine. o A non-FreeBSD hosted qemu also works fine. If your host is running -current, make sure to set MALLOC_CONF=junk:false. It improves behaviour on FreeBSD for boot0/boo1. HTH (probably not), -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
NIC driver API committed
All, A new NIC driver API has been committed that allows us to make the ifnet structure an abstract type. The abstract type being 'if_t'. The miibus(4), fxp(4), em(4) and bxe(4) drivers have been converted to use the API already. Other drivers will follow in the coming weeks. The conversion is mechanical and does not change the behavior of the drivers. As such, there's no user-visible impact. If you do run into a problem after upgrading and you're using any of the converted drivers, please let me know. It is always possible that the conversion introduces a bug. To test whether the conversion introduced the problem, revert any of the following revisions depending on the driver that gives you the problem: r266974 miibus(4) r266977 fxp(4) r266978 em(4) r266979 bxe(4) If you find yourself reverting r266974, please also revert the other 3 revisions as they depend on r266974. FYI, -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
HEADSUP: uart(4) and serial console change
All, With r264175, the uart(4) driver will no longer prevent changing the baudrate nor the CLOCAL or HUPCL control flags. What this means is that if you have a serial console on which getty(8) is started, the settings you have in /etc/ttys will now actually take effect! To preserve the previous behaviour, change your /etc/ttys line for the serial console to (for serial consoles on ttyu0): ttyu0 /usr/libexec/getty 3wire vt100 on secure You can replace 3wire to std once you've validated that you have a carrier signal. Otherwise setting the terminal type/class to std will result in the getty(8) process getting blocked. With a carrier signal, you'll be logged out as soon as carrier drops (i.e. when you disconnect from the console). This is a nice feature if security is not unimportant to you. To change the baudrate on the fly, change the terminal type/class to any of the 3wire. or std. types, where is the baudrate. And don't forget to SIGHUP init(8) after making changes, otherwise the changes don't take effect! FYI, -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Build failure due to block_abi.h
David, The definition of DECLARE_BLOCK seems to trip over GCC 4.2.1 here at Juniper. This is how we run the compiler: /volume/fwtools/gcc/jnpr/4.2.1/amd64-juniper-junos.5/bin/amd64-juniper-junos-gcc -O2 -pipe -I/b/marcelm/fbsd-head/src/lib/libc/include -I/b/marcelm/fbsd-head/src/lib/libc/../../include -I/b/marcelm/fbsd-head/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/b/marcelm/fbsd-head/src/lib/libc/../../contrib/gdtoa -I/b/marcelm/fbsd-head/src/lib/libc/../../contrib/libc-vis -DINET6 -I/b/marcelm/fbsd-head/obj/amd64/lib/libc -I/b/marcelm/fbsd-head/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/b/marcelm/fbsd-head/src/lib/libc/../../contrib/jemalloc/include -I/b/marcelm/fbsd-head/src/lib/libc/../../contrib/tzcode/stdtime -I/b/marcelm/fbsd-head/src/lib/libc/stdtime -I/b/marcelm/fbsd-head/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/b/marcelm/fbsd-head/src/lib/libc/rpc -DNS_CACHING -DSYMBOL_VERSIONING -D__ELF__ -Dunix -D__unix -D__unix__-D__FreeBSD__=9 --sysroot /volume/sisyphus/occam/sysroot/projects_tp5/20131031.611483/amd64 -fno-builtin-printf -g -nostdinc -isystem/b/marcelm/fbsd-head/obj/stage/amd64/usr/include -isystem/b/marcelm/fbsd-head/obj/stage/amd64/include -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -I/b/marcelm/fbsd-head/src/lib/libutil -I/b/marcelm/fbsd-head/src/lib/msun/src -I/b/marcelm/fbsd-head/src/lib/msun/x86 -c /b/marcelm/fbsd-head/src/lib/libc/stdlib/atexit.c -o atexit.o whatever set of flags we use here at Juniper: This is the error: Building /b/marcelm/fbsd-head/obj/amd64/lib/libc/atexit.o cc1: warnings being treated as errors /b/marcelm/fbsd-head/src/lib/libc/stdlib/atexit.c:144: warning: anonymous struct declared inside parameter list /b/marcelm/fbsd-head/src/lib/libc/stdlib/atexit.c:144: warning: its scope is only this definition or declaration, which is probably not what you want *** Error code 1 This hurdle is a bit higher than the hurdles I normally run into when syncing with ^/head, so I could use your expertise. We need to continue to be able to build the sources with compilers outside of the tree as much as possible and I haven't found a way yet (one I don't dislike to be precise) to get this blocks stuff to compile. It's a huge blocker right now. Thanks, -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Build failure due to block_abi.h
On Apr 4, 2014, at 4:13 PM, David Chisnall thera...@freebsd.org wrote: It turns out that tomorrow happened 12 minutes after this email... The attached diff lets it build with -Werror for me with FreeBSD clang and gcc (with -fblocks and -fno-blocks) and with ports gcc 4.7.3 and doesn't clutter the code. Please can you test it with Juniper's gcc? It compiles fine and I immediatelt applied the fix to Juniper's tree. Thanks for the quick turn-around! -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
LLVM bug WRT temporary files?
Guys,
I'm running into a build break that relates to the temporary files
that LLVM creates:
svl-junos-j019% cc --version
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
Target: arm--freebsd10.0-gnueabi
Thread model: posix
On a build machine /tmp/b is a directory and created by user X.
I am doing a buildworld on that machine as user Y (Y=marcelm) and
I don't have permissions in /tmp/b. The build gets to usr.bin/awk
and it has a source file called b.c
The build fails with:
--- b.o ---
cc -O -pipe -DHAS_ISBLANK -I.
-I/b/marcelm/buildbot/FreeBSD_arm_arm/build/usr.bin/awk/../../contrib/one-true-awk
-DFOPEN_MAX=64 -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror
-Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
-Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum
-Wno-knr-promoted-parameter -Wno-parentheses -c
/b/marcelm/buildbot/FreeBSD_arm_arm/build/usr.bin/awk/../../contrib/one-true-awk/b.c
cc: error: unable to make temporary file: /tmp/b: can't make unique filename:
Permission denied
*** [b.o] Error code 1
Running truss shows:
access(/b/marcelm/buildbot/FreeBSD_arm_arm/build/usr.bin/awk/../../contrib/one-true-awk/b.c,0)
= 0 (0x0)
stat(/tmp/b,{ mode=drwxr-xr-x ,inode=235520,size=512,blksize=16384 }) = 0
(0x0)
open(/dev/random,O_RDONLY,00) = 3 (0x3)
read(3,\M^S\M^H\^S65S'*\M-T\M-r\^A9\M-K...,128) = 128 (0x80)
close(3) = 0 (0x0)
stat(/tmp/b,{ mode=drwxr-xr-x ,inode=235520,size=512,blksize=16384 }) = 0
(0x0)
open(/tmp/b/B8owDb,O_RDWR|O_CREAT|O_EXCL,0600) ERR#13 'Permission denied'
Now, if I compile another file, I get:
access(/b/marcelm/buildbot/FreeBSD_arm_arm/build/usr.bin/awk/../../contrib/one-true-awk/lex.c,0)
= 0 (0x0)
stat(/tmp/lex,0x7fffbab0) ERR#2 'No such file or
directory'
open(/dev/random,O_RDONLY,00) = 3 (0x3)
read(3,\^F\r\M-J\M-5Z\M-fK\^E\M-2'\M-1...,128) = 128 (0x80)
close(3) = 0 (0x0)
stat(/tmp,{ mode=drwxrwxrwt ,inode=2,size=9728,blksize=16384 }) = 0 (0x0)
open(/tmp/lex-pDQnPA,O_RDWR|O_CREAT|O_EXCL,0600) = 3 (0x3)
close(3) = 0 (0x0)
So for some reason when /tmp/basename exists and is a directory, then the
compiler wants to create a temporary file underneath that directory. That
looks like a bug to me. Do people concur and thus shall I file a PR?
--
Marcel Moolenaar
mar...@xcllnt.net
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: LLVM bug WRT temporary files?
On Feb 13, 2014, at 9:42 AM, David Chisnall david.chisn...@cl.cam.ac.uk wrote: This looks like a bug, please file an llvm PR. The offending code seems to be createUniqueEntity() in lib/Support/Unix/Path.inc, which does... something. Something weird and convoluted that seems to try to implement mkstemp() / mkdtemp() in an incomprehensible way. Will do. Thanks David, -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r250991 - in head: [malloc weak symbols]
On Jun 3, 2013, at 11:29 AM, Marcel Moolenaar mar...@xcllnt.net wrote: * Even if the python code is wrong, is this one of those things that's going to keep biting us going forward? Interactions between dlopen/dlsym/rtld/library dependencies/embedded malloc replacements/etc has been accumulated a large number of casualties over the years. Possibly. We do not seem to have ever had weak symbols for malloc() et al. Any shared library that exports malloc() and/or friends is potentially causing breakages. Those are breakages only seen on FreeBSD, I would think. I can do some analysis if people prefer. All it takes is the complete set of packages and run nm on any ELF files to see if malloc() or friends is defined as a global symbol to havea protential problem. With a bit of scripting we can come up with a list of candidates. We can go from there... Ok, this is what I found: Total packages: 23105 (stable-9-latest) Packages with ELF files:12492 Packages with malloc definitions: 60 malloc in shared libraries: 24 boehm-gc-redirect-7.1.tbz: ./lib/libgc-redirect.so.1 dlmalloc-2.8.4.tbz: ./lib/libdlmalloc.so.2 dmalloc-5.5.2.tbz: ./lib/libdmalloc.so.1 ./lib/libdmallocth.so.1 ./lib/libdmallocthcxx.so.1 ./lib/libdmallocxx.so.1 electricfence-2.2.2_2.tbz: ./lib/libefence.so.0 gcc-4.2.5.20090325_5.tbz: ./lib/gcc42/libmudflap.so.0 ./lib/gcc42/libmudflapth.so.0 gcc-4.4.7,1.tbz:./lib/gcc44/libmudflap.so.0 ./lib/gcc44/libmudflapth.so.0 gcc-4.6.3.tbz: ./lib/gcc46/libmudflap.so.0 ./lib/gcc46/libmudflapth.so.0 gcc-4.6.4.20130215.tbz: ./lib/gcc46/libmudflap.so.0 ./lib/gcc46/libmudflapth.so.0 gcc-4.7.3.20130323.tbz: ./lib/gcc47/libmudflap.so.0 ./lib/gcc47/libmudflapth.so.0 gcc-4.8.1.20130328.tbz: ./lib/gcc48/libmudflap.so.0 ./lib/gcc48/libmudflapth.so.0 gcc-4.9.0.20130319.tbz: ./lib/gcc49/libmudflap.so.0 ./lib/gcc49/libmudflapth.so.0 google-perftools-1.8.3.tbz: ./lib/libtcmalloc.so.2 ./lib/libtcmalloc_and_profiler.so.2 ./lib/libtcmalloc_debug.so.2 ./lib/libtcmalloc_minimal.so.2 ./lib/libtcmalloc_minimal_debug.so.2 graphviz-2.30.1.tbz:./lib/graphviz/libgvpr.so.2 libhoard-3.8.tbz: ./lib/libhoard.so.1 lmdbg-1.1.0.tbz:./lib/liblmdbg.so.0.0 memcheck-0.2.4.tbz: ./lib/libmemcheck.so.2 mpatrol-1.4.8_3.tbz:./lib/libmpatrol.so.1 ./lib/libmpatrolmt.so.1 ptmalloc-3.0_1.tbz: ./lib/libptmalloc.so.3 ptmalloc2-20060605_1.tbz: ./lib/libptmalloc2.so.0 python27-2.7.3_6.tbz: ./lib/python2.7/lib-dynload/_ctypes.so python32-3.2.3_2.tbz: ./lib/python3.2/lib-dynload/_ctypes.so python33-3.3.0_2.tbz: ./lib/python3.3/lib-dynload/_ctypes.so spideroak-i386-4.8.3.10016.tbz: ./share/spideroak/_ctypes.so umem-1.0.1.tbz: ./lib/libumem_malloc.so.0 Most of those are intended to replace the standard memory allocator. The exception being: graphviz, python spideroak. We know python got broken and it's being fixed. This leaves 2 ports that we should definitely analyze. FYI, -- Marcel Moolenaar mar...@xcllnt.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: issue with libthr?
On Jun 2, 2013, at 8:08 AM, Waitman Gobble uzi...@da3m0n8t3r.com wrote:
On Sun, 2 Jun 2013 10:43:35 -0400, Mark Johnston ma...@freebsd.org wrote:
On Sat, Jun 01, 2013 at 12:54:14AM -0700, Waitman Gobble wrote:
Hi,
I'm getting a ton of core dumps from Python and any software that uses
Python,
ie has USE_PYTHON_BUILD=yes in Makefile.
hundreds of msgs in dmesg:
pid 36637 (seamonkey), uid 1001: exited on signal 11 (core dumped)
pid 36986 (seamonkey), uid 1001: exited on signal 11 (core dumped)
pid 37054 (seamonkey), uid 1001: exited on signal 11 (core dumped)
pid 51780 (seamonkey), uid 1001: exited on signal 11 (core dumped)
pid 83350 (python2.7), uid 0: exited on signal 6 (core dumped)
from gdb it seems to me to be libthr related? I've noticed a couple updates
in
May.. wonder if it's related? I've only noticed this issue in the past
week,
after a complete rebuild and updated.
I've been running into this issue too - python 2.7 would crash when
trying to rebuild databases/tdb and databases/py-sqlite3 with backtraces
similar to what you have below. The python port itself hasn't changed in
a while.
Reverting r250991 and rebuilding libc solves the issue for me:
http://svnweb.freebsd.org/base?view=revisionrevision=250991
Thanks for the info, I appreciate it. I had a heck of a time getting
database/py-sqlite3 to build as well.
My workaround to get it installed was to change the Makefile in WRKSRC
Can you apply the following patch to /usr/ports/lang/python27, rebuild
python, re-install and then try to build databases/py-sqlite3 again?
Index: files/patch-Modules-_ctypes-libffi-fficonfig.py.in
===
--- files/patch-Modules-_ctypes-libffi-fficonfig.py.in (revision 0)
+++ files/patch-Modules-_ctypes-libffi-fficonfig.py.in (working copy)
@@ -0,0 +1,10 @@
+--- Modules/_ctypes/libffi/fficonfig.py.in.orig2013-06-03
07:16:44.0 -0700
Modules/_ctypes/libffi/fficonfig.py.in 2013-06-03 07:17:03.0
-0700
+@@ -1,7 +1,6 @@
+ ffi_sources =
+ src/prep_cif.c
+ src/closures.c
+-src/dlmalloc.c
+ .split()
+
+ ffi_platforms = {
It seems the root cause is a broken python build that accidentally
defines malloc(), free(), at al in _ctypes.so. A longer explanation
was sent to svn-src-head@ and svn-src-all@
I expect that the patch also fixes the other problems mentioned in
this thread. It would be great if people can verify this.
FYI,
--
Marcel Moolenaar
mar...@xcllnt.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: [head tinderbox] failure on powerpc64/powerpc
On Feb 16, 2013, at 2:05 PM, Dag-Erling Smørgrav d...@des.no wrote: FreeBSD Tinderbox tinder...@freebsd.org writes: cc -O2 -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dnssec_verify.c -o dnssec_verify.o cc1: warnings being treated as errors /src/lib/libldns/../../contrib/ldns/dnssec_verify.c:638: warning: ldns_dnssec_trust_tree_print_sm' defined but not used *** [dnssec_verify.o] Error code 1 Stop in /src/lib/libldns. Why is this happening? The Makefile sets WARNS to 3, which adds -Wno-unused-function to CFLAGS, which should suppress this warning. I don't see -Wno-unused-function above. I only see -Wno-unused-parameter. I also don't see -Wno-parentheses-equality nor -Wno-conversion, so I guess that means that the set of flags applicable for WARNS=3 isn't being taken. It looks like WARNS is in fact 3: eris% make -V WARNS 3 Since bsd.sys.mk has grown unreadable, try unraveling the conditionals to see if WARNS for GCC does the equivalent for CLANG. Is the problem specific to architectures that don't use CLANG? -- Marcel Moolenaar mar...@xcllnt.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: ia64 r237134 netstat -r: netstat: kvm_read: Bad address
On Jul 16, 2012, at 12:30 AM, Anton Shterenlikht wrote: On ia64 netstat -r broke some time between 8.1-release, and r237134. Can you file a PR so that it's being tracked. Thanks, -- Marcel Moolenaar mar...@xcllnt.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: ia64 r235474 panic on dump 0aLuf - / | restore -rf - : exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe00000001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79
On Jul 2, 2012, at 5:43 AM, Anton Shterenlikht wrote: I think you're kernel is seriously screwed-up. Do you have any non-standard (for ia64) kernel configuration options? I didn't think so. The latest was this: *snip* Looks fine indeed. I have pretty much the same, except for the IPFILTER options. I'm not concerned about. -- Marcel Moolenaar mar...@xcllnt.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: init: fatal signal: Segmentation fault
On Jun 21, 2012, at 8:40 AM, Anton Shterenlikht wrote: *snip* Trying to mount root from ufs:/dev/da2p2 [rw]... WARNING: / was not properly dismounted Jun 21 17:35:34 init: fatal signal: Segmentation fault Setting hostuuid: 0aa09909-35f1-11df-b7f8-00110a31e60a. Setting hostid: 0xc70eae4e. Entropy harvesting: interrupts ethernet point_to_point kickstart. Fast boot: skipping disk checks. Why are you forcing a fast boot? Subsequent problems are the result of not making your file system clean. mount: /dev/da2p2: R/W mount of / denied. Filesystem is not clean - run fsck.: Operation not permitted Mounting root filesystem rw failed, startup aborted ERROR: ABORTING BOOT (sending SIGTERM to parent)! Jun 21 17:36:06 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Jun 21 17:36:06 init: fatal signal: Segmentation fault I don't know if there's a separate problem with init(8) dumping core or the immediate consequence of the above. How can I recover from this? boot -s and see what happens. If init(8) dies again, use a different init(8) by setting init_path at the loader prompt. SOmething like the following could do the trick: set init_path=/sbin/init.bak FYI, -- Marcel Moolenaar mar...@xcllnt.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: ia64 r235474 panic on dump 0aLuf - / | restore -rf - : exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe00000001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79
On Jun 29, 2012, at 3:40 AM, Anton Shterenlikht wrote: # newfs /dev/da2p2 /dev/da2p2: 16384.0MB (33554432 sectors) block size 32768, fragment size 4096 using 27 cylinder groups of 626.09MB, 20035 blks, 80256 inodes. super-block backups (for fsck -b #) at: 192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, 10258112, 11540352, 12822592, 14104832, 15387072, 16669312, 17951552, 19233792, 20516032, 21798272, 23080512, 24362752, 25644992, 26927232, 28209472, 29491712, 30773952, 32056192, 8432 # mount /dev/da2p2 /mnt # cd /mnt # dump 0aLuf - / | restore -rf - results in this panic: KDB: stack backtrace: getenv with the following non-sleepable locks held: exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe0001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 KDB: stack backtrace: getenv with the following non-sleepable locks held: exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe0001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 KDB: stack backtrace: getenv with the following non-sleepablefatal kernel trap (cpu 0): locks held: I think you're kernel is seriously screwed-up. Do you have any non-standard (for ia64) kernel configuration options? -- Marcel Moolenaar mar...@xcllnt.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: [CFC/CFT] large changes in the loader(8) code
On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote: All of the above is ugly, U'm afraid :( Indeed. The only sane way is to put the metadata in a partition of its own. Every compliant OS will respect that and consequently will not scribble over the data unintentionally. Any other scheme that puts valuable data in some undocumented or unregistered location is violating the GPT spec right away and is susceptible to being clobbered unintentionally. If the metadata is in its own partition, one can document the metadata layout and providing a reference implementation. That way one increases the chance that someone, somewhere may port support for it to some other OS. Lacking widespread support for the mirroring scheme, I think that the notion that one can safely and reliably mirror entire disks (read: mirror data not owned or controlled by FreeBSD) is a very questionable one -- all one has to do is boot some other OS and start modifying one of its partitions and you've failed to achieve the objective. My advise is to leave disk mirroring to H/W or firmware solutions and use FreeBSD mirroring for FreeBSD partitions only. If you want to mirror the whole disk, don't partition the disk with non-FreeBSD partitioning schemes and partition only with FreeBSD-specific schemes or put a FreeBSD file system on the whole disk. In other words: make the whole disk private to FreeBSD. Whether or not people agree with this is besides the point. All I'm saying is that unique disk identifiers such as the UniqueMBRSignature (a 4 byte ID written at offset 440 in the MBR) or the DiskGUID (an UUID written to offset 56 in the GPT header) cannot, in general, be mirrored across disks if OSes can see the mirrored disks as independent entities. One violates the spec on grounds of making the *unique* disk identifier non-unique by presenting OSes with multiple disks that have identical IDs. -- Marcel Moolenaar mar...@xcllnt.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: [CFC/CFT] large changes in the loader(8) code
On Jun 28, 2012, at 10:25 AM, Pawel Jakub Dawidek wrote: On Thu, Jun 28, 2012 at 08:33:17AM -0700, Marcel Moolenaar wrote: On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote: All of the above is ugly, U'm afraid :( Indeed. The only sane way is to put the metadata in a partition of its own. Every compliant OS will respect that and consequently will not scribble over the data unintentionally. Any other scheme that puts valuable data in some undocumented or unregistered location is violating the GPT spec right away and is susceptible to being clobbered unintentionally. If the user runs: # gpart create -s GPT /dev/mirror/foo for me it is obvious that he wants to partition the mirror device and not individual disks. It could definitely be interpreted as the user knowing what he/she wants and as such design an infrastructure around this assumption. If users were at least as knowledgable as developers, my concerns wouldn't be as big. But we all know how knoweldgable users can be and kike it or not, even developers aren't gurus in everything. We may think to know stuff, but in practice we're just as clueless in cases as users -- more clueless even sometimes. So you may think the intend is obvious, but you should know better. Let's modify gpart(8) to print a warning if GPT is configured on something else than raw disk. Let's the warning say that such configuration is non-standard and problems are expected if the disk is shared between other OSes. Yes. I think we finally reached the point we should have reached years ago. With the proper tooling, our flexible infrastructure can be used in a safe and complaint way while still giving the freedom to those who unwisely think they know better. Build it and I'll concur. -- Marcel Moolenaar mar...@xcllnt.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: [CFC/CFT] large changes in the loader(8) code
On Jun 28, 2012, at 12:49 PM, Alexander Leidinger wrote: On Thu, 28 Jun 2012 08:33:17 -0700 Marcel Moolenaar mar...@xcllnt.net wrote: My advise is to leave disk mirroring to H/W or firmware solutions and use FreeBSD mirroring for FreeBSD partitions only. If you want to mirror the whole disk, don't partition the disk with non-FreeBSD partitioning schemes and partition only with FreeBSD-specific schemes or put a FreeBSD file system on the whole disk. In other words: make the whole disk private to FreeBSD. If I gmirror the entire disk, I already expressed my interest to make the whole disk private to FreeBSD, haven't I? No. All you've done is type some commands. There's no inherent value in it that relays that you know what you're doing. I have no problem accepting that you do in fact know what you're doing, but that doesn't mean that anyone who types the same sequence of commands is as skilled as you are -- that would be a silly inference. What you need to do is not have it be about you, but about some random user. Or are you suggesting to convince all BIOS vendors to include the ability to boot from some kind of FreeBSD private partitioning scheme (not MBR as it is not suitable, not GPT as you are not OK to use it on a gmirror)? I would be having less problems if the mirroring didn't force the backup GPT header in anything but the last sector. If the metadata was somewhere else, then we wouldn't need to kluge various places to deal with the ambiguity and visible interoperability problems of the various tools and OSes. Thus, it's not that I object to the mirroring per se, just to the mirroring as it is currently implemented with gmirror. What about multipathing? In case the disk is attached via two paths but multipath is not enabled, the OS sees the same disk (and the same identical unique disk identifier) multiple times. Is this a violation of the spec too? It's the same disk, isn't it? The OS can actually use the property of the ID to infer that it has already seen this disk and not create multiple device nodes. -- Marcel Moolenaar mar...@xcllnt.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: [CFC/CFT] large changes in the loader(8) code
On Jun 28, 2012, at 4:07 PM, Pawel Jakub Dawidek wrote: I would be having less problems if the mirroring didn't force the backup GPT header in anything but the last sector. [...] GPT backup header is placed in the last sector of the mirror device, just like the user asked. Gmirror doesn't force anything. User decides to put GPT partitioning on the mirror device instead of raw disk. Gmirror doesn't even know and doesn't have to know how the user uses data area on the mirror device. This really is a cop-out paragraph. [...] If the metadata was somewhere else, then we wouldn't need to kluge various places to deal with the ambiguity and visible interoperability problems of the various tools and OSes. [...] Where is somewhere else, exactly? I already suggested a few things in this thread. Go read it. I'm bored now, so I'll just wait for UEFI booting to be forced upon those who mirror the whole disk with gmirror. I think that's when we will have a more substantial and meaningful continuation of this thread. -- Marcel Moolenaar mar...@xcllnt.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: [CFC/CFT] large changes in the loader(8) code
On Jun 26, 2012, at 10:37 AM, John Baldwin wrote: GPT really wants the backup header at the last LBA. I know you can set it, but I've interpreted that as a way to see if the primary header is correct or not. It seems to me that GPT tables created in this fashion (inside a GEOM provider) will not work properly with partition editors for other OS's. I'm hesitant to encourage the use of this as I do think putting GPT inside of a gmirror violates the GPT spec. Agreed. While it is a nice trick to use the last sector for meta data, it does create 2 problems. 1 is mentioned above. The second is that when there's different metadata in the first *and* the last sector, you can't decide which is to take precedence without also looking at the other and know how to interpret it. We have not solved this second problem at all. We do get reports about the problems though. At best we're handwaving or kluging. I think it's unwise to depend on FreeBSD-specific extensions or features in industry-standard partitioning schemes and as such make the use of foreign tools hard if not impossible. A much more flexible approach is to support out-of-band configuration data. This allows us to mirror GPT disks without having to become non- standard as it removes the need to use the last sector for meta-data. The ability to construct GEOM hierarchies unambiguously is very important and our current approach has proven to not deliver on that. This is actually impacting existing FreeBSD consumers already, like Juniper. So, se should not go deeper into this rabbit hole. We should finally solve this problem for real... -- Marcel Moolenaar mar...@xcllnt.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: [CFC/CFT] large changes in the loader(8) code
On Jun 26, 2012, at 2:43 PM, Pawel Jakub Dawidek wrote: As for sharing disk with other OS. If you share the disk with OS that doesn't support gmirror, you shouldn't use gmirror in the first place. You probably want to use only formats that are recognized by all your OSes. This statement is ridicuous by virtue of not being in touch with reality and by making gmirror useless for such wide range of cases that one can question why we have it at all. Put differently: a mirroring class is a fairly basic and useful thing to have. Limiting it's use is nothing but artificial and follows from having to use the underlying provider to store metadata. This then changes the view of the underlying providing to consumers above gmirror in a way that makes the presence or absence of gmirror visible. Solving the visibility problem makes gmirror useful all the time. I see that as a better way of looking at it than simply blurting out that you shouldn't use gmirror when certain awkward and artifical conditions apply. -- Marcel Moolenaar mar...@xcllnt.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: [CFC/CFT] large changes in the loader(8) code
On Jun 26, 2012, at 9:50 PM, Andrey V. Elsukov wrote: If the primary GPT is corrupt, software must check the last LBA of the device to see if it has a valid GPT Header and point to a valid GPT Partition Entry Array. For the FreeBSD an each GEOM provider can be treated as disk device. So, i don't see anything criminal if we will add some quirks in the our loader for the better supporting of our technologies. You can't just re-interpret standards to match a context you know very well isn't applicable and consequently redefine what the word device means. You're on a slippery slope and while you may not see it as a problem, you do make it a problem for FreeBSD users. It's our users we should be keeping in mind when we solve problems. If a user wants modify GPT in the disk editor from the another OS, he can do it, and it should work. The result depends only from the partition editor, it might overwrite the last sector and might don't. Right. Another happy user that sees his/her FreeBSD installation destroyed or degraded (no mirroring, warning messages about corrupted GPT, etc) for no apparent reason and without any kind of warning that what he/she is doing is potentially harmful... That's the spirit! -- Marcel Moolenaar mar...@xcllnt.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: [CFC/CFT] large changes in the loader(8) code
On Jun 27, 2012, at 11:34 AM, Pawel Jakub Dawidek wrote: I'm sorry, Marcel, but what you describe here has nothing to do with reality. To be able to implement realiable mirroring you have to use on-disk metadata. There is no way around that. You can implement non-redundant GEOM classes without using on-disk metadata, but out-of-band configuration in case of mirroring is simply naive. How do you detect that components are out of sync, for example? GEOM configuration and per-class runtime state are not to be treated the same. Out-of-band configuration is trivial. Per-class runtime state, like whether elements in a mirrored configuration are in sync or not is more difficult, but does not a priori require on-disk metadata as it's implemented now. You can have the configuration tell the GEOM where that state is being kept, so that you can put it in a partition on the disks involved, or even keep it independent from the disks, which then requires disks to be uniquely identifiable, for sure. But that's what GPT gives you anyway. But even without identification, you can invert the question from how do I detect that components are out of sync to how do I prove they are in fact in sync. That question has a very simple O(n) answer. So, if time isn't a concern or your storage is small, you can always scan all sectors as such prove that the disks are in sync. The point being: the current implementation isn't the only one. Granted, it can easily be the simplest one or even the best one in some cases, but that's besides the point you were making. -- Marcel Moolenaar mar...@xcllnt.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: [CFC/CFT] large changes in the loader(8) code
On Jun 27, 2012, at 11:20 AM, Pawel Jakub Dawidek wrote: On Wed, Jun 27, 2012 at 10:37:11AM -0700, Marcel Moolenaar wrote: On Jun 26, 2012, at 10:37 AM, John Baldwin wrote: GPT really wants the backup header at the last LBA. I know you can set it, but I've interpreted that as a way to see if the primary header is correct or not. It seems to me that GPT tables created in this fashion (inside a GEOM provider) will not work properly with partition editors for other OS's. I'm hesitant to encourage the use of this as I do think putting GPT inside of a gmirror violates the GPT spec. Agreed. Guys. This doesn't violate the GPT spec in any way. The spec is narrow-minded if it talks only about raw disks, but you should think about gmirror as pseudo-hardware RAID. I'm sorry, but this is a contradiction. If it doesn't violate the spec, then the spec is not narrow-minded on the grounds of what we're discussing. If the spec *is* narrow-minded then obviously it doesn't capture our scenario, which means that we're violating the spec. Clearly we're not discussing anything that falls well within the spec, or is undebatable. This makes the whole topic dangerous anyway. When you're in the grey area (this is only for argument's sake -- we're in violation for sure) you're opening yourself up to compatibility problems. Should we deliberately go there? -- Marcel Moolenaar mar...@xcllnt.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: [CFC/CFT] large changes in the loader(8) code
On Jun 27, 2012, at 12:08 PM, Christian Laursen wrote: On 06/27/12 16:28, John Baldwin wrote: On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote: When we are in the FreeBSD, our loader can detect that device size is lower than it see and it will work. When primary header is OK, then other OSes should work with this GPT. When it isn't OK, you just can't load other OS :) Ah, yes. The solution to violating standards is to make sure you never use standards-compliant software. That's a great argument. :) (Although not entirely uncommon. Standards aren't always perfect, but if we had a way to not gratuitously violate them it would be nice to avoid doing so.) To be standards compliant and allow whole-disk based mirroring to work at the same time wouldn't nested GPT work like this? GPTs don't nest. Nothing but FreeBSD would understand the freebsd-geom partition type, so the inner GPT device should be valid and standards compliant. If it were standards compliant, it would be discoverable by non-FreeBSD. That clearly isn't the case -- hence it's not standards compliant. What for example if someone wanted to share the swap partition between Linux and FreeBSD? -- Marcel Moolenaar mar...@xcllnt.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: [CFC/CFT] large changes in the loader(8) code
On Jun 27, 2012, at 12:27 PM, Andrey V. Elsukov wrote: On 27.06.2012 21:55, Marcel Moolenaar wrote: You can't just re-interpret standards to match a context you know very well isn't applicable and consequently redefine what the word device means. You're on a slippery slope and while you may not see it as a problem, you do make it a problem for FreeBSD users. It's our users we should be keeping in mind when we solve problems. If a user wants modify GPT in the disk editor from the another OS, he can do it, and it should work. The result depends only from the partition editor, it might overwrite the last sector and might don't. Right. Another happy user that sees his/her FreeBSD installation destroyed or degraded (no mirroring, warning messages about corrupted GPT, etc) for no apparent reason and without any kind of warning that what he/she is doing is potentially harmful... That's the spirit! Ok. Let's return back to my patches. They don't add any new methods to shoot in the foot. We are talking about the *FreeBSD loader*. This is the program that starts FreeBSD kernel. It doesn't start other OS. We already have many users who uses FreeBSD as a single system on the machine. Many of them use GPT inside of some GEOM provider. Your patches are a continuation on a path that we're discussing isn't necessarily the path we should be on. While you don't make things worse from a compliance perspective, you make it worse by adding the non-compliant behaviour to more components. As i understand there two parts where we haven't a consensus: 1. You are against from: Our loader detects that primary GPT header is damaged. It tries to read backup GPT header from the last LBA and it detects that there is GEOM:: signature. It tries to read one previous sector and there is *valid* GPT header. How do you know it's valid? It's in a location that is not valid to begin with. Validity is based on rules and you're violating the the rules without defining exactly what we call valid given the new rules. This may seem nitpicking, but having went through the hassle of dealing with the broken way we created the dangerously dedicated disk, I appreciate the importance of being anal when it comes to something that lives on non-volatile storage and gets to be exposed to a world much larger than FreeBSD. 2. You are against from having one fake PMBR entry by default in the /boot/pmbr image. I don't understand what you're saying or what I'm being accused to be against. -- Marcel Moolenaar mar...@xcllnt.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: [CFC/CFT] large changes in the loader(8) code
On Jun 27, 2012, at 1:48 PM, Andrey V. Elsukov wrote: On 28.06.2012 00:14, Marcel Moolenaar wrote: Our loader detects that primary GPT header is damaged. It tries to read backup GPT header from the last LBA and it detects that there is GEOM:: signature. It tries to read one previous sector and there is *valid* GPT header. How do you know it's valid? It's in a location that is not valid to begin with. Validity is based on rules and you're violating the the rules without defining exactly what we call valid given the new rules. This may seem nitpicking, but having went through the hassle of dealing with the broken way we created the dangerously dedicated disk, I appreciate the importance of being anal when it comes to something that lives on non-volatile storage and gets to be exposed to a world much larger than FreeBSD. So why do you not prevent to attach GEOM_PART_GPT to any providers that are not the disk drive? This will be the right solution to all our problems. Just don't create invalid GPT. It's not even the right solution, as it prevents legit nesting of gpart GEOMs *and* is fundamentally based on a flawed assumption that any non-disk GEOM underneath gpart yields an invalid GPT. Think gnop. -- Marcel Moolenaar mar...@xcllnt.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: r234118 uart kernel module failure: uart_cpu_eqres undefined
On Apr 17, 2012, at 8:09 AM, John Baldwin wrote:
On Friday, April 13, 2012 8:44:25 pm kwh...@site.uottawa.ca wrote:
The change from sys/dev/uart/uart_cpu_{i386,amd64}.c to uart_cpu_x86.c
probably also needs a corresponding change in the module Makefile.
# kldload uart
link_elf: symbol uart_cpu_eqres undefined
Here's one suggestion that works for me:
Index: /sys/modules/uart/Makefile
===
--- /sys/modules/uart/Makefile (revision 234249)
+++ /sys/modules/uart/Makefile (working copy)
@@ -16,6 +16,8 @@
uart_if.c uart_if.h uart_subr.c uart_tty.c
.if exists(${.CURDIR}/../../dev/uart/uart_cpu_${MACHINE}.c)
SRCS+= uart_cpu_${MACHINE}.c
+.elif ${MACHINE} == i386 || ${MACHINE} == amd64
+SRCS+= uart_cpu_x86.c
.endif
SRCS+= bus_if.h card_if.h device_if.h isa_if.h ${ofw_bus_if} pci_if.h \
power_if.h pccarddevs.h serdev_if.h
cc'ing Marcel (who made the uart(4) change). I think this is correct, yes.
Oh crap. Yes.
--
Marcel Moolenaar
mar...@xcllnt.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
[ptrace] please review follow fork/exec changes
All,
Please review the attached changes (done by Dmitry -- CC'd) to add support for
PT_FOLLOW_EXEC and cleanup PT_FOLLOW_FORK.
I'll commit this when there are no comments/objections.
Thanks,
--
Marcel Moolenaar
marc...@juniper.net
Index: sys/kern/kern_exit.c
===
--- sys/kern/kern_exit.c (revision 225189)
+++ sys/kern/kern_exit.c (working copy)
@@ -680,7 +680,7 @@ wait4(struct thread *td, struct wait_args *uap)
*/
void
proc_reap(struct thread *td, struct proc *p, int *status, int options,
-struct rusage *rusage)
+struct rusage *rusage, int child)
{
struct proc *q, *t;
@@ -720,7 +720,6 @@ proc_reap(struct thread *td, struct proc *p, int *
if (p-p_oppid (t = pfind(p-p_oppid)) != NULL) {
PROC_LOCK(p);
proc_reparent(p, t);
- p-p_pptr-p_dbg_child--;
p-p_oppid = 0;
PROC_UNLOCK(p);
pksignal(t, SIGCHLD, p-p_ksi);
@@ -738,7 +737,10 @@ proc_reap(struct thread *td, struct proc *p, int *
sx_xlock(allproc_lock);
LIST_REMOVE(p, p_list); /* off zombproc */
sx_xunlock(allproc_lock);
- LIST_REMOVE(p, p_sibling);
+ if (child)
+ LIST_REMOVE(p, p_sibling);
+ else
+ LIST_REMOVE(p, p_orphan);
leavepgrp(p);
#ifdef PROCDESC
if (p-p_procdesc != NULL)
@@ -859,7 +861,7 @@ loop:
nfound++;
PROC_SLOCK(p);
if (p-p_state == PRS_ZOMBIE) {
- proc_reap(td, p, status, options, rusage);
+ proc_reap(td, p, status, options, rusage, 1);
return (0);
}
if ((p-p_flag P_STOPPED_SIG)
@@ -893,16 +895,47 @@ loop:
if (status)
*status = SIGCONT;
+ }
+ PROC_UNLOCK(p);
+ }
+ LIST_FOREACH(p, q-p_orphans, p_orphan) {
+ PROC_LOCK(p);
+ if (pid != WAIT_ANY
+ p-p_pid != pid p-p_pgid != -pid) {
+ PROC_UNLOCK(p);
+ continue;
+ }
+ if (p_canwait(td, p)) {
+ PROC_UNLOCK(p);
+ continue;
+ }
+
+ /*
+ * This special case handles a kthread spawned by linux_clone
+ * (see linux_misc.c). The linux_wait4 and linux_waitpid
+ * functions need to be able to distinguish between waiting
+ * on a process and waiting on a thread. It is a thread if
+ * p_sigparent is not SIGCHLD, and the WLINUXCLONE option
+ * signifies we want to wait for threads and not processes.
+ */
+ if ((p-p_sigparent != SIGCHLD) ^
+ ((options WLINUXCLONE) != 0)) {
+ PROC_UNLOCK(p);
+ continue;
+ }
+
+ nfound++;
+ PROC_SLOCK(p);
+ if (p-p_state == PRS_ZOMBIE) {
+ proc_reap(td, p, status, options, rusage, 0);
return (0);
}
+ PROC_SUNLOCK(p);
PROC_UNLOCK(p);
}
if (nfound == 0) {
sx_xunlock(proctree_lock);
- if (td-td_proc-p_dbg_child)
- return (0);
- else
- return (ECHILD);
+ return (ECHILD);
}
if (options WNOHANG) {
sx_xunlock(proctree_lock);
@@ -932,6 +965,7 @@ proc_reparent(struct proc *child, struct proc *par
#ifdef RACCT
int locked;
#endif
+ struct proc *p;
sx_assert(proctree_lock, SX_XLOCKED);
PROC_LOCK_ASSERT(child, MA_OWNED);
@@ -952,5 +986,17 @@ proc_reparent(struct proc *child, struct proc *par
PROC_UNLOCK(child-p_pptr);
LIST_REMOVE(child, p_sibling);
LIST_INSERT_HEAD(parent-p_children, child, p_sibling);
+
+ LIST_FOREACH(p, parent-p_orphans, p_orphan) {
+ if (p == child) {
+ LIST_REMOVE(child, p_orphan);
+ break;
+ }
+ }
+ if (child-p_flag P_TRACED) {
+ LIST_INSERT_HEAD(child-p_pptr-p_orphans, child, p_orphan);
+ PROC_UNLOCK(child);
+ PROC_LOCK(child);
+ }
child-p_pptr = parent;
}
Index: sys/kern/kern_exec.c
===
--- sys/kern/kern_exec.c (revision 225189)
+++ sys/kern/kern_exec.c (working copy)
@@ -55,6 +55,7 @@ __FBSDID($FreeBSD$);
#include sys/priv.h
#include sys/proc.h
#include sys/pioctl.h
+#include sys/ptrace.h
#include sys/namei.h
#include sys/resourcevar.h
#include sys/sdt.h
@@ -895,16 +896,22 @@ exec_fail_dealloc:
free(imgp-freepath, M_TEMP);
if (error == 0) {
+ if ((p-p_flag (P_TRACED | P_FOLLOWEXEC)) ==
+ (P_TRACED | P_FOLLOWEXEC)) {
+ PROC_LOCK(p);
+ td-td_dbgflags |= TDB_EXEC;
+ PROC_UNLOCK(p);
+ }
+ /*
+ * Stop the process here if its stop event mask has
+ * the S_EXEC bit set.
+ */
+ STOPEVENT(p, S_EXEC, 0);
+ PTRACESTOP_SC(p, td, S_PT_EXEC);
PROC_LOCK(p);
- td-td_dbgflags |= TDB_EXEC;
+ td-td_dbgflags = ~TDB_EXEC;
PROC_UNLOCK(p);
-
- /*
- * Stop the process here if its stop event mask has
- * the S_EXEC bit set.
- */
- STOPEVENT(p, S_EXEC, 0);
- goto done2;
+ goto done2;
}
exec_fail:
Index: sys/kern/kern_fork.c
===
--- sys/kern/kern_fork.c (revision 225189)
+++ sys/kern/kern_fork.c (working copy)
@@ -59,6 +59,7 @@ __FBSDID($FreeBSD$);
#include sys/proc.h
#include sys/procdesc.h
#include sys/pioctl.h
+#include sys/ptrace.h
#include sys/racct.h
#include
Re: sysinstall as a post-install tool
On Jan 3, 2012, at 3:33 PM, Eitan Adler wrote: Hi, In the the recent sysinstall thread there seems to be general agreement that having a post-install configuration tool is a good thing. Until such a tool is written I think it would be a good idea to use sysinstall for this purpose. I am willing to do the work to restore sysinstall and maintain it as a post-install tool until a new one is written. I though sade was created for that purpose, because sysinstall was too much tied to the installation process. If sysinstall comes back, sade definitely has to go: r161060 | netchild | 2006-08-07 16:35:49 -0700 (Mon, 07 Aug 2006) | 9 lines Say welcome to 'sade', the SysAdmins Disk Editor. It's the fdisk and disklabel part of sysinstall. So sysinstall may retire now, we have the important non-install part of it covered. ATM it doesn't understand GEOM stuff (like mirror, stripe, raid, ...), but patches to change this and to clean it up internally are more than welcome. Submitted by: m...@nyitolap.hu In general I think it's a bad idea to revive sysinstall. It doesn't function appropriately on most architectures that FreeBSD supports and it's definitely the opposite of what we've been working towards for at least the last 5 years. FYI, -- Marcel Moolenaar mar...@xcllnt.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: possible mountroot regression
On Oct 18, 2011, at 9:04 AM, Andriy Gapon wrote:
on 14/10/2011 18:54 Arnaud Lacombe said the following:
Andry Gapon wrote:
Simple: revert to the previous behavior. If a user enters incorrect device
name
(i.e. root mounting fails), then return back to the prompt instead of
panicing.
That should do the job.
- Arnaud
---
sys/kern/vfs_mountroot.c | 45 +++--
1 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c
index ccbcb33..ae3ffa7 100644
--- a/sys/kern/vfs_mountroot.c
+++ b/sys/kern/vfs_mountroot.c
@@ -481,28 +481,29 @@ parse_dir_ask(char **conf)
printf(\n);
printf( ? List valid disk boot devices\n);
printf( . Yield 1 second (for background tasks)\n);
-printf( empty lineAbort manual input\n);
+printf( x Abort manual input)\n);
+
+do {
+error = EINVAL;
+printf(\nmountroot );
+gets(name, sizeof(name), GETS_ECHO);
+if (name[0] == '?') {
+printf(\nList of GEOM managed disk devices:\n );
+g_dev_print();
+continue;
+}
+if (name[0] == '.') {
+pause(rmask, hz);
+continue;
+}
+if (name[0] == 'x' name[1] == '\0')
+break;
+mnt = name;
+error = parse_mount(mnt);
+if (error 0)
+printf(Invalid specification.\n);
+} while (error != 0);
- again:
-printf(\nmountroot );
-gets(name, sizeof(name), GETS_ECHO);
-if (name[0] == '\0')
-return (0);
-if (name[0] == '?') {
-printf(\nList of GEOM managed disk devices:\n );
-g_dev_print();
-goto again;
-}
-if (name[0] == '.') {
-pause(rmask, hz);
-goto again;
-}
-mnt = name;
-error = parse_mount(mnt);
-if (error == -1) {
-printf(Invalid specification.\n);
-goto again;
-}
return (error);
}
Arnaud,
I like how your change fixes the regression and improves code style.
As you've said, the 'x' change is unrelated. I like it, but it needs to be
discussed and committed separately.
Marcel,
what do you think?
I like it.
Would you be able to commit a variant of this patch sans the 'x' part?
Yes, soonish. If people like the 'x' change I can do that in a followup
commit as well. I just need to know if people like it or not...
--
Marcel Moolenaar
mar...@xcllnt.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: [RFC] FDT fix for 64 bit platforms
On Oct 15, 2011, at 9:33 AM, Jayachandran C. wrote: On Sat, Oct 15, 2011 at 8:43 PM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 10/15/11 01:12, Jayachandran C. wrote: On Sat, Oct 15, 2011 at 2:01 AM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 10/14/11 14:10, Jayachandran C. wrote: I'm planning commit this -CURRENT if there an no objections. In the current implementation, phandle is used to store a pointer to the location inside the device tree. Since phandle_t is u32, this will not work on 64 bit platforms. With this fix, the phandle is the offset from the start of device tree pointer 'fdtp', which will be 32 bit. Review or testing from device tree users will be welcome. JC. Why not use offsets into the FDT rather than full pointers? I believe having phandles greater than 32 bits violates the FDT spec, and declaring that the FDT can't itself be larger than 4 GB seems reasonable. I am actually using the offset from the beginning of FDT (fdtp) as phandle. I cannot use the usual fdt offset (after off_dt_struct) as phandle, because in that case offset of 0 is valid, but phandle 0 should not be valid. Why shouldn't phandle 0 be valid? The invalid phandle is -1. This is one of the problems with our existing FDT code -- it makes all kinds of wrong assumptions like this about IEEE 1275. Well, the existing FDT code returns 0 as the invalid handle and I do not want to change that in this commit. If the return value is really wrong, we will need a bigger exercise to change the return value and fix any callers which are affected by that change. It should be fairly easy to change the base from fdtp to the usual fdt offset, so let me propose the following: 1. JC commits what he has and based on the current code. 2. We get all the facts on the table. I say this because I read different and contradictory things (0 being an invalid phandle in OF, negative phandles exist, etc). 3. We change the implementation, if such is warranted, in a separate effort. The point really is that 0 is an invalid phandle right now, right or wrong, and JCs changes are based on that. I see no problem proceeding on the path we're on, while we discuss what's the correct implementation and whether or not we should have a course change... Thoughts? -- Marcel Moolenaar mar...@xcllnt.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: possible mountroot regression
On Oct 14, 2011, at 12:51 AM, Andriy Gapon wrote: on 30/08/2011 13:01 Andriy Gapon said the following: So, just to re-iterate, I think that this is indeed a regression and the one that could be particularly unhelpful for a new release - the time when people are much more likely to end up at the mountroot prompt during an installation of a new system or an upgrade. Marcel, is there any chance that this regression can be fixed before the release? Probably, yes. How do you want to fix this? You haven't really expressed what you would like to see, other than mentioning that you think it's a regression from before. Arguably, the previous behaviour had a lot to be desired for so since you're worried about the user experience, thinking this through is important. If not, then maybe it would be proper to pull the change that introduced it out of the release branch (r214006) ? Don't be ridiculous. -- Marcel Moolenaar mar...@xcllnt.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: ia64 r221488: panic: blockable sleep lock (sleep mutex) process lock @ /usr/src/sys/ia64/ia64/trap.c:562
On Sep 16, 2011, at 11:15 AM, Anton Shterenlikht wrote: I know it's not exactly current anymore, but.. ia64 r221488 At this point in time, I don't have any clear indications that this is a code problem. I have found that different optimizations tend to affect the failure mode or rate. As such, I suspect GCC. It'll be difficult to find the bad code. -- Marcel Moolenaar mar...@xcllnt.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: possible mountroot regression
On Aug 29, 2011, at 1:21 AM, Andriy Gapon wrote: on 27/08/2011 18:16 Marcel Moolenaar said the following: On Aug 26, 2011, at 2:07 PM, Andriy Gapon wrote: It seems that after the introduction of the mountroot scripting language a user now has exactly one chance to try to specify a correct root device at the mountroot prompt. I am not sure that that is convenient/enough. This is no different from before. Are you sure? I remember trying multiple (incorrect) possibilities at the prompt and not getting the panic. But I know that sometimes I have cases of false memories, so _I_ am not sure. I'm sure now that we're both not sure :-) It's possible the failure mode varied by how the root mount failed... -- Marcel Moolenaar mar...@xcllnt.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: possible mountroot regression
On Aug 26, 2011, at 2:07 PM, Andriy Gapon wrote:
It seems that after the introduction of the mountroot scripting language a
user
now has exactly one chance to try to specify a correct root device at the
mountroot prompt. I am not sure that that is convenient/enough.
This is no different from before.
I suspect that the following code is the cause:
static void
vfs_mountroot_conf0(struct sbuf *sb)
{
char *s, *tok, *mnt, *opt;
int error;
sbuf_printf(sb, .onfail panic\n);
…
Yes.
It is certainly a behavior we can improve upon. It's
rather annoying to get a panic on a typo. However,
we must remain cognizant of the fact that an immediate
hard failure is what's needed at times.
Maybe a good approach is to change to .onfail retry
and extend the root mount prompt with a reboot command,
so that the user/operator is does not have to worry
about typos *and* don't have to trigger a panic just
so that he/she can initiate a reboot.
Thoughts?
--
Marcel Moolenaar
mar...@xcllnt.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: Well, there goes Windows!
On Aug 21, 2011, at 2:32 PM, Nathan Whitehorn wrote: gpart does not support (well, anyway) changing the underlying partition table format without committing changes. Replacing the partition scheme, which this does, is such an operation. Weird. I could always destroy tables, create new ones using a different scheme and populate it with partitions without there being a single write to disk. The commit/undo logic worked just as well for those operations as the simpler ones. Did that get broken or are you just mistaken? -- Marcel Moolenaar mar...@xcllnt.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: Well, there goes Windows!
On Aug 21, 2011, at 5:00 PM, Nathan Whitehorn wrote: No, it's stupider than that. When you destroy a gpart without committing, the GEOM itself lingers as a (none)-type partitioning. This of course makes sense, since that ghost geom is what is maintaining all the state, but sometimes causes problems. For instance, it breaks some of my lazy code that identifies non-partitioned disks by seeing if there is a GEOM there. But, while slightly more complicated to detect, this would not be too difficult to fix. What if gpart always creates the null scheme if no partitioning exists on the media? Then the difference between none but uncomitted and just plain none is gone and we can always make sure the distinction is represented in the XML. This would also improve the current behavior of gpart show in that you don't get to see any disks that don't have partitions right now. The larger problem is that this behavior means that destroying gparts sometimes doesn't work at all. For instance, if you have nested partitioning like MBR+BSD (or EBR) it is not possible to destroy the underlying MBR geom without committing the destruction of the BSD geom. This is because the MBR geom cannot be destroyed, even without committing, while it continues to have children, which it does due to the ghost geom for the BSD slice. Yup. It would be good if we can fix that… The regular partitioning editor only commits early in this particular case, and asks about each subpartition tree separately with a big scary dialog box. In the spirit of the autopartitioner, it makes one large scary dialog, and always runs in early commit mode instead of potentially showing many scary dialogs about partitions the user doesn't necessarily even know about. This behavior could be changed, but I think is the most friendly for the case in question: namely, I want to blow away everything and let the installer handle all partitioning details by itself. What about inserting a special class for doing commit/undo. The GEOM simply keeps all modifications in memory and 1) forgets everything on an undo operation or 2) writes all dirty sectors on a commit. This could be used even instead of the gpart-private support, which also removes the quirk for the null scheme. -- Marcel Moolenaar mar...@xcllnt.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: Well, there goes Windows!
On Aug 21, 2011, at 6:34 PM, Nathan Whitehorn wrote: The regular partitioning editor only commits early in this particular case, and asks about each subpartition tree separately with a big scary dialog box. In the spirit of the autopartitioner, it makes one large scary dialog, and always runs in early commit mode instead of potentially showing many scary dialogs about partitions the user doesn't necessarily even know about. This behavior could be changed, but I think is the most friendly for the case in question: namely, I want to blow away everything and let the installer handle all partitioning details by itself. What about inserting a special class for doing commit/undo. The GEOM simply keeps all modifications in memory and 1) forgets everything on an undo operation or 2) writes all dirty sectors on a commit. This could be used even instead of the gpart-private support, which also removes the quirk for the null scheme. Where would this class go? If it went below gpart (between gpart and userland), then it seems like we would lose the ability of gpart to validate its parameters. Who would be responsible for inserting this GEOM into the stack? Between the disk GEOM and the gpart GEOM. The gpart utility would still interact with the GEOM is before. -- Marcel Moolenaar mar...@xcllnt.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: make test under lang/perl5.14 causes panic: blockable sleep lock (sleep mutex) process lock @ /usr/src/sys/ia64/ia64/trap.c:562
On Aug 16, 2011, at 1:12 AM, Anton Shterenlikht wrote: On Mon, Aug 15, 2011 at 06:34:51PM +0100, Anton Shterenlikht wrote: On Fri, Aug 12, 2011 at 05:45:55PM -0700, Marcel Moolenaar wrote: On Aug 12, 2011, at 7:19 AM, Anton Shterenlikht wrote: On ia64 r221488 Please update to at least r223700, as that was a major stability fix. UZI uname -a FreeBSD mech-as221.men.bris.ac.uk 9.0-BETA1 FreeBSD 9.0-BETA1 #5 r224876: Mon Aug 15 12:06:05 BST 2011 r...@mech-as221.men.bris.ac.uk:/usr/obj/usr/src/sys/UZI ia64 UZI make test run with no panic once (though lots of errors, I should probably let the perl team know), and panicked on the second run: Anton, Do you have options PREEMPTON in your kernel configuration by any chance? The panics you report are the ones I typically get when I enable PREEMPTION. I haven't found the root cause for this yet. There's alsp a PR to track this particular issue. FYI, -- Marcel Moolenaar mar...@xcllnt.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: make test under lang/perl5.14 causes panic: blockable sleep lock (sleep mutex) process lock @ /usr/src/sys/ia64/ia64/trap.c:562
On Aug 12, 2011, at 7:19 AM, Anton Shterenlikht wrote: On ia64 r221488 Please update to at least r223700, as that was a major stability fix. Latest and greatest is preferred though. FYI, -- Marcel Moolenaar mar...@xcllnt.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: isp(4) timeout
On Jul 5, 2011, at 1:39 AM, Anton Shterenlikht wrote: On Thu, Jun 30, 2011 at 05:11:24AM -0700, Matthew Jacob wrote: On 6/30/2011 3:25 AM, Anton Shterenlikht wrote: I see in my logs: isp0: Polled Mailbox Command (0x54) Timeout (50us) (started @ isp_plogx:2122) isp0: Mailbox Command 'EXECUTE IOCB A64' failed (TIMEOUT) isp0: Chan 0 PLOGI 0x010500 failed isp0: Polled Mailbox Command (0x64) Timeout (25us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) More details please. These errors indicate failures to execute commands that try and figure out what's on a fabric and then log into devices on the fabric. Knowing what hardware you have (QLogic card version), what FreeBSD release you are running, would help. A verbose dmesg would be useful. I got it again. But this time the network seems fine. If you haven't updated to the latest sources, please do so. If you did already, please make sure you don't have PREEMPTION configured. FYI, -- Marcel Moolenaar mar...@xcllnt.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: isp(4) timeout
On Jun 30, 2011, at 3:25 AM, Anton Shterenlikht wrote: I see in my logs: isp0: Polled Mailbox Command (0x54) Timeout (50us) (started @ isp_plogx:2122) isp0: Mailbox Command 'EXECUTE IOCB A64' failed (TIMEOUT) This is most likely caused by a loss of interrupt handling. Be it masked interrupts or the inability to have the interrupt thread running. I have some important improvements in the pipeline that significantly improve stability. I'm doing a final test and then I'll commit. It may address the issue as a side-effect. FYI, -- Marcel Moolenaar mar...@xcllnt.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: [head tinderbox] failure on ia64/ia64
On Jun 22, 2011, at 4:03 PM, Jung-uk Kim wrote: MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror vers.c linking kernel acpi_cpu.o: In function `acpi_cpu_cx_list': acpi_cpu.c:(.text+0xab2): undefined reference to `cpu_can_deep_sleep' acpi_cpu.c:(.text+0xaf0): undefined reference to `cpu_can_deep_sleep' *** Error code 1 Sorry, it should be fixed by r223449. I have no idea why kern_clocksource.c was excluded for ia64, though. :-( Having a x86 focussed development community, probably... Thanks for fixing! -- Marcel Moolenaar mar...@xcllnt.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: [head tinderbox] failure on ia64/ia64
On Jun 20, 2011, at 11:40 AM, Garrett Cooper wrote: On Mon, Jun 20, 2011 at 11:37 AM, FreeBSD Tinderbox tinder...@freebsd.org wrote: TB --- 2011-06-20 17:09:28 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-20 17:09:28 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-06-20 17:09:28 - cleaning the object tree TB --- 2011-06-20 17:09:40 - cvsupping the source tree TB --- 2011-06-20 17:09:40 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-06-20 17:10:27 - building world TB --- 2011-06-20 17:10:27 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-20 17:10:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-20 17:10:27 - TARGET=ia64 TB --- 2011-06-20 17:10:27 - TARGET_ARCH=ia64 TB --- 2011-06-20 17:10:27 - TZ=UTC TB --- 2011-06-20 17:10:27 - __MAKE_CONF=/dev/null TB --- 2011-06-20 17:10:27 - cd /src TB --- 2011-06-20 17:10:27 - /usr/bin/make -B buildworld World build started on Mon Jun 20 17:10:28 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Mon Jun 20 18:35:55 UTC 2011 TB --- 2011-06-20 18:35:56 - generating LINT kernel config TB --- 2011-06-20 18:35:56 - cd /src/sys/ia64/conf TB --- 2011-06-20 18:35:56 - /usr/bin/make -B LINT TB --- 2011-06-20 18:35:56 - building LINT kernel TB --- 2011-06-20 18:35:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-20 18:35:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-20 18:35:56 - TARGET=ia64 TB --- 2011-06-20 18:35:56 - TARGET_ARCH=ia64 TB --- 2011-06-20 18:35:56 - TZ=UTC TB --- 2011-06-20 18:35:56 - __MAKE_CONF=/dev/null TB --- 2011-06-20 18:35:56 - cd /src TB --- 2011-06-20 18:35:56 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Jun 20 18:35:56 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/kgssapi/kgss_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=cc -E CC=cc xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding /src/sys/vm/vm_page.c:2356:2: error: #error PAGE_SIZE is not supported. mkdep: compile failed *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 r223307 broke tinderbox on ia64. What should the PAGE_SIZE be for that architecture? 16KB or 64KB. It's 8KB now, but that it shouldn't be. FYI, -- Marcel Moolenaar xcl...@mac.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: panic - Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe1fe38,gp ; ;
On Jun 13, 2011, at 9:14 AM, Anton Shterenlikht wrote: On ia64 r221488 KDB: enter: panic [ thread pid 1076 tid 100089 ] Stopped at kdb_enter+0x92: [I2]addl r14=0xffe1fe38,gp ;; db What's the panic? Can you (next time maybe) do: show msgbuf Thanks, -- Marcel Moolenaar mar...@xcllnt.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: Fdisk formatting of disk having bs=1K fails
On Apr 8, 2011, at 12:34 PM, Hans Petter Selasky wrote: Hi, It appears that src/sbin/fdisk.c can only read the MBR of disks having a blocksize different than 512 bytes. When writing a new MBR, the below check fails. Can someone having knowledge into fdisk, fix this issue and MFC to 8- stable? Also I'm curious about the #ifdef __ia64__ . You can eliminate the __ia64__ conditional if you want. From the commit log: r95860 | peter | 2002-05-01 06:48:29 + (Wed, 01 May 2002) | 4 lines Add a hack so that fdisk(8) can initialize an ia64 disk. There is no /boot/mbr to read the boot code from (ia64 does not *have* bootblocks!). fdisk depended on magic in the /boot/mbr file to initialize some fields. fdisk is not compiled for ia64 anymore since the introduction of gpart. The same holds for bsdlabel. So, that means that the hack is not needed anymore. FYI, -- Marcel Moolenaar xcl...@mac.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: [head tinderbox] failure on sparc64/sun4v
On Mar 23, 2011, at 1:25 AM, Jeff Roberson wrote: I did not notice this was still failing. I didn't realize this make universe would pull in my modules. I will fix this now. Thanks! powerpc and ia64 have been failing since the ofed commit as well. FYI, -- Marcel Moolenaar xcl...@mac.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: HEADS UP: sysinstall is no longer the default installer
On Mar 18, 2011, at 6:51 PM, Nathan Whitehorn wrote: On 03/15/11 12:20, Marcel Moolenaar wrote: On Mar 14, 2011, at 7:13 AM, Nathan Whitehorn wrote: I just committed (r219641) changes that make the release infrastructure (src/release/Makefile) use bsdinstall by default instead of sysinstall on install media. A big thank you is in order to everyone who provided advice, criticism, and testing for this project over the last few months! Thanks Nathan, I checked ia64 and it works well enough. I may come back with a tweak here and there after the dust settles, but so far it's more reliable (and a while lot simpler) than sysinstall is. Great work! Thanks! The installer doesn't yet know (and I don't know) how to set up the EFI system partition on IA64, so I'll need some input (or code) from you on that point to get things totally up and running. It's not that hard in general: create a partition that is 100MB in size, give it the right type (i.e. C12A7328-F81F-11d2-BA4B-00A0C93EC93B) and format with dosfs. This has to be the very first partition on a boot device. As part of the installation, we need to copy the EFI loader to a FreeBSD subdirectory. Adding an entry for FreeBSD to the boot menu is where it really gets interesting. The support for writing the EFI environment exists (see libefi), but construction an EFI device path from a device special file probably needs some more code. Getting that to work is interesting for installing on Intel based Apple hardware as well I would presume. Most systems have a system partition, so copying the loader to it is the most important aspect of getting a bootable installation. -- Marcel Moolenaar xcl...@mac.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: HEADS UP: sysinstall is no longer the default installer
On Mar 14, 2011, at 7:13 AM, Nathan Whitehorn wrote: I just committed (r219641) changes that make the release infrastructure (src/release/Makefile) use bsdinstall by default instead of sysinstall on install media. A big thank you is in order to everyone who provided advice, criticism, and testing for this project over the last few months! Thanks Nathan, I checked ia64 and it works well enough. I may come back with a tweak here and there after the dust settles, but so far it's more reliable (and a while lot simpler) than sysinstall is. Great work! -- Marcel Moolenaar xcl...@mac.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: [CFT][patch]cfi driver support for NOR flash arrays
On Mar 14, 2011, at 8:09 AM, Aleksandr Rybalko wrote: Hi, all. proposed patch add support of NOR flash arrays to cfi driver http://my.ddteam.net/files/2011-03-11_cfi_flash_array_support.patch Hi Aleksandr, The patch is interesting, but combines a whole bunch of different changes. Some of the changes are similar to the fixes we have at Juniper ourselves, so getting the driver sync'd up is a good idea. Not to mention that we have added support for the SPI interface. Just a quick question: is an array different from 2 independent CFI devices on the same bus? I mean: can we support an array by having 2 driver instances? Thanks, -- Marcel Moolenaar xcl...@mac.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: ieee denormal on ia64?
On Feb 25, 2011, at 1:33 AM, Anton Shterenlikht wrote: Can somebody please confirm that denormal are not available on ia64, see below. Itanium has denormals. However FP_X_DNML has not been defined, because it's non-standard: ns1% svn log -c121332 lib/libc/ia64/gen/fpsetmask.c r121332 | marcel | 2003-10-22 02:00:07 -0700 (Wed, 22 Oct 2003) | 11 lines The FP status register allows for 6 traps to be masked. One of them, the denormal/unnormal trap, is not a standard IEEE trap. We did not exclude it from being returned by fpgetmask(), nor did we make sure that fpsetmask() didn't clobber it. Since the non-IEEE trap is not part of fp_except_t, users of ifpgetmask()/fpsetmask() would be confronted with unexpected behaviour, one of which is a SIGFPE for denormal/unnormal FP results. This commit makes sure that we don't leak the denormal/unnormal mask bit in fp_except_t and also that we don't clobber it. -- Marcel Moolenaar xcl...@mac.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: Cosmetic path to bsdinstall
On Feb 24, 2011, at 7:00 AM, Nathan Whitehorn wrote: Thanks! I've received basically this patch from a couple people now. I'm going to investigate whether this is a more generic way to get this information (so the list doesn't grow infinitely long), and will commit this if I can't. Having CAM devices be part of newbus would simplify this a very great deal... See: http://people.freebsd.org/~marcel/gpt.diff It was my initial attempt of creating a generic (ncurses-based) partition editor that uses gpart. (the name of the patch relates to the perforce branch it was done on, not the partitioning scheme). In it you'll find a diff for sbin/pe/disk.c that contains logic for presenting a friendly disk name. Not complete, but maybe good for inspiration... FYI, -- Marcel Moolenaar xcl...@mac.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: [head tinderbox] failure on ia64/ia64
On Jan 31, 2011, at 3:51 PM, Pawel Jakub Dawidek wrote: On Mon, Jan 31, 2011 at 10:56:18PM +, FreeBSD Tinderbox wrote: [...] cc -O2 -pipe -I/src/sbin/hastctl/../hastd -DINET -DINET6 -DYY_NO_UNPUT -DYY_NO_INPUT -DHAVE_CRYPTO -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/sbin/hastctl/../hastd/proto_common.c cc1: warnings being treated as errors /src/sbin/hastctl/../hastd/proto_common.c: In function 'proto_common_descriptor_send': /src/sbin/hastctl/../hastd/proto_common.c:116: warning: cast increases required alignment of target type /src/sbin/hastctl/../hastd/proto_common.c: In function 'proto_common_descriptor_recv': /src/sbin/hastctl/../hastd/proto_common.c:146: warning: cast increases required alignment of target type /src/sbin/hastctl/../hastd/proto_common.c:149: warning: cast increases required alignment of target type *** Error code 1 Marcel, do you have an idea how one can use CMSG_NXTHDR() on ia64 with high WARNS? With WARNS=6 I get those errors and I've no idea how to fix it properly. If there is a fix, CMSG_NXTHDR() should probably be fixed, but maybe I'm wrong? this warning indicates that you're casting from a pointer to type P (P having alignment constraints Ap) to a pointer to type Q (Q having alignment constraints Aq), and Aq Ap. The compiler tells you that you may end up with misaligned accesses. If you know that the pointer satisfies Aq, you can cast through (void *) to silence the compiler. If you cannot guarantee that, you have a bigger problem. Solutions include packing type Q to reduce Aq or to copy the data to a local variable. Take the statement at line 116 for example: *((int *)CMSG_DATA(cmsg)) = fd; We're effectively casting from a (char *) to a (int *) and then doing a 32-bit access (write). The easy fix (casting through (void *) is not possible, because you cannot guarantee that the address is properly aligned. cmsg points to memory set aside by the following local variable: unsigned char ctrl[CMSG_SPACE(sizeof(fd))]; There's no guarantee that the compiler will align the character array at a 32-bit boundary (though in practice it seems to be). I have seen this kind of construct fail on ARM and PowerPC for example. In any case: The safest approach here is to use le32enc or be32enc rather than casting through (void *). Obviously these function encode using a fixed byte order when the original code is using the native byte order of the CPU. Having native encoding functions help. You could use bcopy as well, but the compiler is typically too smart for its own good and it will try to optimize the call away. This leaves you with the same misaligned access that you tried to avooid by using bcopy(). You need to trick the compiler so that it won't optimize the bcopy away, like: bcopy((void *)fd, CMSG_DATA(cmsg), sizeof(fd)); HTH, -- Marcel Moolenaar xcl...@mac.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: RFC vgrind in base (and buildworld)
On Jan 21, 2011, at 7:25 AM, Alexander Kabaev wrote: On Thu, 20 Jan 2011 17:11:13 -0800 Marcel Moolenaar xcl...@mac.com wrote: On Jan 20, 2011, at 12:31 PM, Alexander Kabaev wrote: On Thu, 20 Jan 2011 21:17:40 +0100 Ulrich Spörlein u...@freebsd.org wrote: Hello, Currently our buildworld relies on groff(1) and vgrind(1) being present in the host system. I have a patch ready that at least makes sure these are built during bootstrap-tools and completes the WITHOUT_GROFF flag. vgrind(1) is only used for two papers under share/doc and we could easily expand the results and commit them to svn directly, alleviating the need to run vgrind(1) during buildworld. OTOH, there are much more useful tools to vgrind(1) for source code formatting. So do we still have vgrind(1) users out there? Regards, Uli Why it needs to be in bootsrap tools at all? We have build tools for this exact purpose. Actually no. The buildtools target is there to allow building programs that are not installed, but are otehrwise needed to compile a program. These are typically little tools that create source files. The bootstrap target is the to deal with compatibility in case we can't use the version on the host or we don't want to depend on the version on the host. Then it is cross-tools, or whatever build stage that builds new gcc and other tools which run on host and are used to generate the final target binaries. Cross-tools is what you say. Anything that has target architecture neutral output should therefore not be build all the time as part of cross-tools. The point being that bootstrap-tools target is greatly abused in src, with recent addition of llvm libs making it almost pandemic. Yes, I can see bootstrap tools being abused. It started being abused the moment it came to live :-) But rather than abuse the other targets, I'm more inclined to review our build system and see if we need to start making big changes again. In particular: Juniper is ramping up on stock FreeBSD development and the first thing we ran into is that FreeBSD doesn't have a good cross-development and cross-build environment. We have hacks so that we don't have to say we don't have it at all, but one cannot possibly believe that what we have is good. So, let's get everything on the table and look for ways to improve things structurally rather than using ad-hoc or one- off tweaks. Is there value in having FreeBSD development ports that one can install on a machine and thereby making it suitable for FreeBSD (cross-) development? In other words: do people mind if there's a one-time setup (or upgrade) required before being able to build FreeBSD? What if this is done automatically as part of buildworld (i.e. installing or upgrading a port)? If not, then we can get rid of bootstrap-tools altogether. If the port also includes (cross-compilers) we can also rid ourselves of cross-tools and end up with a good cross-devel environment in the process. Thoughts? -- Marcel Moolenaar xcl...@mac.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: RFC vgrind in base (and buildworld)
On Jan 20, 2011, at 12:31 PM, Alexander Kabaev wrote: On Thu, 20 Jan 2011 21:17:40 +0100 Ulrich Spörlein u...@freebsd.org wrote: Hello, Currently our buildworld relies on groff(1) and vgrind(1) being present in the host system. I have a patch ready that at least makes sure these are built during bootstrap-tools and completes the WITHOUT_GROFF flag. vgrind(1) is only used for two papers under share/doc and we could easily expand the results and commit them to svn directly, alleviating the need to run vgrind(1) during buildworld. OTOH, there are much more useful tools to vgrind(1) for source code formatting. So do we still have vgrind(1) users out there? Regards, Uli Why it needs to be in bootsrap tools at all? We have build tools for this exact purpose. Actually no. The buildtools target is there to allow building programs that are not installed, but are otehrwise needed to compile a program. These are typically little tools that create source files. The bootstrap target is the to deal with compatibility in case we can't use the version on the host or we don't want to depend on the version on the host. -- Marcel Moolenaar xcl...@mac.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: BSDInstall: merging to HEAD
On Jan 14, 2011, at 10:26 AM, Nathan Whitehorn wrote: The final architecture on which we use sysinstall, ia64, is currently unsupported, because I don't know how to set up booting on those systems -- patches to solve this are very much welcome. Don't let this stop you. I'll work with you on this after the dust has settled. FYI, -- Marcel Moolenaar xcl...@mac.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: old references to vfs_mountroot_try()
On Nov 19, 2010, at 2:09 AM, Sergey Kandaurov wrote: On 19 November 2010 02:14, Alexander Best arun...@freebsd.org wrote: hi there, vfs_mountroot_try() seems to have been removed, yet the src still contains three references to it: vfs_mount.c:386 vfs_mount.c:723 freebsd32_misc.c:2368 So, what about just to rename those comments to reflect function name change? Index: sys/kern/vfs_mount.c === --- sys/kern/vfs_mount.c(revision 215516) +++ sys/kern/vfs_mount.c(working copy) @@ -383,7 +383,7 @@ * Filter out MNT_ROOTFS. We do not want clients of nmount() in * userspace to set this flag, but we must filter it out if we want * MNT_UPDATE on the root file system to work. -* MNT_ROOTFS should only be set in the kernel in vfs_mountroot_try(). +* MNT_ROOTFS should only be set in the kernel in parse_mount(). */ uap-flags = ~MNT_ROOTFS; Keep it vague. Just change the line to MNT_ROOTFS should only be set by the kernel when mounting its root file system. The parse_mount() function name has no meaning other than within sys/kern/vfs_mountroot.c, so referring to it isn't making things clear. FYI, -- Marcel Moolenaar xcl...@mac.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: Panic with vfs.root.mountfrom=nfs on CURRENT (was Re: [patch] functional prototype of root mount enhancement)
On Nov 17, 2010, at 4:10 PM, Garrett Cooper wrote: Hi Marcel, Do you have any examples that use nfs rootfs's out of the box that work with the new logic that don't involve creating an mfsroot? I keep on running into this error with vfs.root.mountfrom=nfs (previously on CURRENT it would just try to mount nfs via nfs_mount in the NFS client without any complaints): The syntax is $fs:$dev. For NFS $dev can be empty, leaving nfs:. The problem is with there not being a colon after nfs in your case. This could be a change in behaviour from before, which probably needs a fix. I'll look into it... I don't run into this error when I unset this variable sometimes (it boots up multiuser and all is happy, hunky dory when I manually query this variable from the pxeboot loader, but not when I don't... it's weird). It seems to ignore the directives in mount.conf: # cat mount.conf .onfail continue .ask The filename to use is /.mount.conf. Notice the period. -- Marcel Moolenaar xcl...@mac.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: libcompiler_rt now part of FreeBSD's base system
On Nov 11, 2010, at 7:52 AM, Ed Schouten wrote: Hello all, I just committed libcompiler_rt.a to HEAD. Even though I don't expect serious issues -- especially not on the tier 1 architectures -- be sure to contact me in case something goes wrong. I hooked it up to the build in a separate commit, so if your system starts to act weird, just revert r215127. I'm testing ia64, right now. I see the following: pluto2# chroot /tank/release/current /bin/tcsh # cd /lib # ls -al *gcc* *compiler* -r--r--r-- 1 0 0 104952 Nov 12 15:55 libgcc_s.so.1 # cd /usr/lib # ls -al *gcc* *compiler* -r--r--r-- 1 0 0 172434 Nov 12 15:53 libcompiler_rt.a -r--r--r-- 1 0 0 209196 Nov 12 15:53 libcompiler_rt_p.a lrwxr-xr-x 1 0 0 16 Nov 12 15:53 libgcc.a - libcompiler_rt.a -r--r--r-- 1 0 0 60754 Nov 12 15:55 libgcc_eh.a -r--r--r-- 1 0 0 65706 Nov 12 15:55 libgcc_eh_p.a lrwxr-xr-x 1 0 0 18 Nov 12 15:53 libgcc_p.a - libcompiler_rt_p.a lrwxr-xr-x 1 0 0 18 Nov 12 15:55 libgcc_s.so - /lib/libgcc_s.so.1 This looks like an inconsistency to me. Aren't we building a shared libcompiler_rt to replace the shared libgcc? Should I worry about the EH support? BTW: The chroot seems functional from the minimal testing I've done so far. We're not DOA! :-) -- Marcel Moolenaar xcl...@mac.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: multiple problems between r212316 and r212643 on ia64
On Oct 22, 2010, at 12:52 AM, Kostik Belousov wrote: Thank you for tracking it. I will wait for your merge of the revision to RELENG_8 before synchronizing rtld with HEAD. Ok. I'll try to MFC over the weekend. If you find yourself waiting for me too long (in case I didn't do it over the weekend), feel free to grab the revision and commit it to -stable. -- Marcel Moolenaar xcl...@mac.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: multiple problems between r212316 and r212643 on ia64
On Sep 16, 2010, at 3:57 AM, Anton Shterenlikht wrote: % man ls zcat: /usr/share/man/cat1/ls.1.gz already has .gz suffix -- unchanged % man man zcat: /usr/share/man/cat1/man.1.gz already has .gz suffix -- unchanged # cd /etc/mail # make start Starting: sendmail-submitmailwrapper: no mapping in /etc/mail/mailer.conf sendmail-clientmqueuemailwrapper: no mapping in /etc/mail/mailer.conf . # # cd /usr/src # svn up svn: Can't open file '/usr/local/etc/subversion/servers': Illegal byte sequence # This is now fixed (revision 214194). From the commit log: With r169630 I disabled symbol versioning because it broke rtld. With r211706 rtld got broken for ia64 powerpc64. It was fixed for powerpc64 with r212497. In between, r211749 removed the exports table because the version script handled the exports. But wait, symbol versioning was disabled on ia64. With exports controlled by the version script and symbol versioning disabled, all symbols are exported and too many symbols bind to the definition in rtld. Let's just say that waird things happen. So, enable symbol versioning on ia64 and apply a work-around for the SIGSEGV that triggered r169630 to begin with: when rtld relocates itself, it comes across r_debug_state and for some reason can't find the definition. This causes a failure, relocation aborts and null pointers galore. The work-around is to ignore the missing definition when rtld is relocating itself and keep going. Maybe with the next binutils this will all go away. Maybe not, in which case I still need to figure out why r_debug_state cannot be found. BTW: r_debug_state is in the symbol map -- I don't think any other rtld symbols that rtld references are in the symbol map... FYI, -- Marcel Moolenaar xcl...@mac.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: [zfs] Mounting from (...) failed with error 19
On Oct 19, 2010, at 9:38 PM, Andrey V. Elsukov wrote: On 20.10.2010 2:33, Marcel Moolenaar wrote: What about the attached patch? I'm going to give it a swirl soon. The difference is that it tests whether dev begins with /dev/. Interesting. I've been thinking about this too, but isn't exactly fool-proof. When devfs is the root file system, you can use ufs:da0s1a to refer to the device special file. It seems inconsistent to have ufs:da0s1 fail when ufs:/dev/da0s1 works (a real scenario with USB based mass storage devices -- root mount is unheld as soon as umass is created, but before daX exists for it). This patch at least covers the problem cases with a single strstr(), and we may get away with the inconsistency given above by documenting it properly. Andrey: any thoughts? Currently usage information in parse_dir_ask() says that device should be specified with /dev/. But conf0 does not use /dev/. Also, Marcel, do you have any plans write some documentation with examples about using of new features? Yes, this will be documented. -- Marcel Moolenaar xcl...@mac.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: [zfs] Mounting from (...) failed with error 19
On Oct 18, 2010, at 10:03 PM, Andrey V. Elsukov wrote: On 19.10.2010 3:50, Xin LI wrote: With latest kernel I got: Mounting from (...) failed with error 19 On boot. The system is using pure ZFS setup. It seems that 19 means ENODEV but according to the dmesg the device do exist. Yes, i have the same problem. Can you both boot verbose and send me the output. Also, please boot with -a and show me the console output, as well as the output of the '?' command. Thanks, -- Marcel Moolenaar xcl...@mac.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: [zfs] Mounting from (...) failed with error 19
On Oct 19, 2010, at 7:55 AM, Andrey V. Elsukov wrote: On 19.10.2010 09:03, Andrey V. Elsukov wrote: Mounting from (...) failed with error 19 On boot. The system is using pure ZFS setup. It seems that 19 means ENODEV but according to the dmesg the device do exist. Yes, i have the same problem. I fixed it with attached patch. Makes sense. tank (or its namesake) isn't a real device. Feel free to commit to unbreak things, but we may want to rethink this from a generality point of view. Listing exceptions doesn't scale and we now have 2 (the first was the empty device name as used by nfs, and now also zfs). Good catch, BTW. -- Marcel Moolenaar xcl...@mac.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: [zfs] Mounting from (...) failed with error 19
On Oct 19, 2010, at 2:21 PM, Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/19/10 08:49, Marcel Moolenaar wrote: On Oct 19, 2010, at 7:55 AM, Andrey V. Elsukov wrote: On 19.10.2010 09:03, Andrey V. Elsukov wrote: Mounting from (...) failed with error 19 On boot. The system is using pure ZFS setup. It seems that 19 means ENODEV but according to the dmesg the device do exist. Yes, i have the same problem. I fixed it with attached patch. Makes sense. tank (or its namesake) isn't a real device. Feel free to commit to unbreak things, but we may want to rethink this from a generality point of view. Listing exceptions doesn't scale and we now have 2 (the first was the empty device name as used by nfs, and now also zfs). Good catch, BTW. Yes good catch, it fixed the problem for me as well. What about the attached patch? I'm going to give it a swirl soon. The difference is that it tests whether dev begins with /dev/. Interesting. I've been thinking about this too, but isn't exactly fool-proof. When devfs is the root file system, you can use ufs:da0s1a to refer to the device special file. It seems inconsistent to have ufs:da0s1 fail when ufs:/dev/da0s1 works (a real scenario with USB based mass storage devices -- root mount is unheld as soon as umass is created, but before daX exists for it). This patch at least covers the problem cases with a single strstr(), and we may get away with the inconsistency given above by documenting it properly. Andrey: any thoughts? -- Marcel Moolenaar xcl...@mac.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: multiple problems between r212316 and r212643 on ia64
On Sep 16, 2010, at 3:57 AM, Anton Shterenlikht wrote: # cd /usr/src # svn up svn: Can't open file '/usr/local/etc/subversion/servers': Illegal byte sequence # I think your file system is borked. Nonetheless, let me upgrade myself and see if I run onto it too. I did fsck -f in single user mode - all seems fine: I see the svn problem too. I've tried to find suspicious commits, but only found commits to libthr that make me uncomfortable. svn is threaded, though... -- Marcel Moolenaar xcl...@mac.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: multiple problems between r212316 and r212643 on ia64
On Sep 15, 2010, at 8:23 AM, Anton Shterenlikht wrote: % man ls zcat: /usr/share/man/cat1/ls.1.gz already has .gz suffix -- unchanged % man man zcat: /usr/share/man/cat1/man.1.gz already has .gz suffix -- unchanged # cd /etc/mail # make start Starting: sendmail-submitmailwrapper: no mapping in /etc/mail/mailer.conf sendmail-clientmqueuemailwrapper: no mapping in /etc/mail/mailer.conf . # # cd /usr/src # svn up svn: Can't open file '/usr/local/etc/subversion/servers': Illegal byte sequence # I think your file system is borked. Nonetheless, let me upgrade myself and see if I run onto it too. -- Marcel Moolenaar xcl...@mac.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: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
Sorry for the top post: Anton, Can check if you have /usr/local/lib/liblzma on your other machines. I have this nagging feeling that you're picking up a library outside of your object tree. Also: can you send the contents of /etc/make.conf Thx -- Marcel (Mobile) On Jun 24, 2010, at 1:36 AM, Anton Shterenlikht me...@bristol.ac.uk wrote: On Wed, Jun 23, 2010 at 04:20:18PM +0200, Dag-Erling Smørgrav wrote: Anton Shterenlikht me...@bristol.ac.uk writes: I think it's possible that at some point, in anger, I did make installworld after a failed, or otherwise interrupted make buildworld. Perhaps I got an inconsistent set of binaries as a result... Would that explain an error like this? No, because at this point buildworld is using the toolchain and libraries that it built earlier. sorry for the delay On a clean copy of r209203 Can you do % find /usr/obj/usr/src -name liblzma.a There should be at least one in /usr/obj/usr/src/lib/liblzma and one in /usr/obj/usr/src/tmp/usr/lib, and they should be identical. seems so: # find /usr/obj/usr/src -name liblzma.a /usr/obj/usr/src/tmp/usr/lib/liblzma.a /usr/obj/usr/src/lib/liblzma/liblzma.a # diff /usr/obj/usr/src/tmp/usr/lib/liblzma.a /usr/obj/usr/src/lib/liblzma/liblzma.a # Next, do % nm /usr/obj/usr/src/lib/liblzma/liblzma.a | grep physmem and show us the result. # nm /usr/obj/usr/src/lib/liblzma/liblzma.a | grep physmem hardware_physmem.o: T lzma_physmem U lzma_tuklib_physmem tuklib_physmem.o: T lzma_tuklib_physmem # While you're at it, do this as well: % nm /usr/lib/liblzma.a | grep physmem # nm /usr/lib/liblzma.a | grep physmem nm: '/usr/lib/liblzma.a': No such file # Did you mean /usr/local/lib/liblzma.a ? # nm /usr/local/lib/liblzma.a|grep physmem # On my other 2 ia64 boxes, where I don't have this problem, the output of the last command is the same. many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
On Jun 24, 2010, at 8:53 AM, Dag-Erling Smørgrav d...@des.no wrote: Marcel Moolenaar xcl...@mac.com writes: Can check if you have /usr/local/lib/liblzma on your other machines. I have this nagging feeling that you're picking up a library outside of your object tree. That's what I'm working my way towards, Marcel. Can you wait until Anton has answered my questions. Will do. Thanks for looking into it. -- Marcel (mobile) ___ 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: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
On Jun 21, 2010, at 8:04 AM, Anton Shterenlikht wrote: On Mon, Jun 21, 2010 at 04:45:03PM +0200, Dag-Erling Smørgrav wrote: jhell jh...@dataix.net writes: Anton Shterenlikht me...@bristol.ac.uk writes: What do you mean by updating your headers? cd /usr/src/include make obj make depend make all make install wrong. % cd /usr/src % make obj % make cleandepend % make depend % make buildincludes % make installincludes DES -- Dag-Erling Smørgrav - d...@des.no Sorry, just to take one step back, why has this become necessary for this particular box? If /usr/obj is empty, and svn up, followed by svn diff, doesn't show any local changes, why can't I go straight to make buildworld? In other words, why do my headers need updating on this particular box, and not on other ia64 boxes? I must've screwed something up, haven't I? Anton, My suggestion would be to destroy the sandbox entirely and simply checkout a new one from scratch, provided you're not sharing sandboxes across NFS. I would also manually destroy your object tree under /usr/obj (or whereever you have it) before doing the buildworld. It's not impossible (double negative to emphasize that the possibility may not be big enough to worry about, but that I don't want to go there), that you have some corruption that is not exposed by svn diff, but that is causing the build-breakages. A clean slate helps... FYI, -- Marcel Moolenaar xcl...@mac.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: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL
On May 31, 2010, at 3:57 AM, Tai-hwa Liang wrote: http://en.wikipedia.org/wiki/Extended_boot_record says that there may be another boot loader inside 0x0 ~ 0x1bd. If that's the case, I'm wondering if there is any disadvantage to disable the checksumming against 0x60 ~ 0x1b5? The intend was to prevent false positives. I think it's probably best to remove the checksumming and deal with false positives differently: such as by making sure that the partition has the right type... -- Marcel Moolenaar xcl...@mac.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: Importing clang/LLVM into FreeBSD HEAD
On May 31, 2010, at 12:52 AM, Roman Divacky wrote: Hi, I would like to propose to integrate clang/LLVM into FreeBSD HEAD in the near future (days, not weeks). *nod of approval* -- Marcel Moolenaar xcl...@mac.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: a panic on uart_z8530_class?
On May 8, 2010, at 1:00 PM, Weongyo Jeong wrote: Hello, Anyone encountered this panic on recent CURRENT kernel? [r...@test ~]# uname -a FreeBSD test 9.0-CURRENT FreeBSD 9.0-CURRENT #16: Sun May 2 00:24:12 PDT 2010 r...@test:/usr/obj/usr/src/sys/GENERIC amd64 [r...@test /home/freebsd/sys/modules/bwn]# ifconfig wlan0 create wlandev bwn0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xff8073cdd810 frame pointer = 0x28:0xff8073cdd8e0 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 = 1795 (ifconfig) [ thread pid 1795 tid 100096 ] Stopped at 0: *** error reading from address 0 *** db bt Tracing pid 1795 tid 100096 td 0xff0003d8b390 uart_z8530_class() at 0 ifc_simple_create() at ifc_simple_create+0x89 if_clone_createif() at if_clone_createif+0x64 ifioctl() at ifioctl+0x685 kern_ioctl() at kern_ioctl+0xc5 ioctl() at ioctl+0xfd syscall() at syscall+0x102 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800b86d0c, rsp = 0x7fffe2e8, rbp = 0x7fffee36 --- I think what you have is a simple NULL function pointer dereference (i.e. calling a function pointer that's NULL). The uart_z8530_class shows first in the backtrace because that symbol has address 0 (it's weak and you typically don't have the Z8530 SCC driver on amd64), so it's being returned when DDB looks up symbols at address 0. This then implies that ifc_simple_create() called a NULL function pointer. FYI, -- Marcel Moolenaar xcl...@mac.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: gpart and sector size
On Apr 8, 2010, at 6:06 AM, Alexey Tarasov wrote: Hello. There is only one possibility to change sector size of physical disk (gnop -S 4096 ...). May be it is possible to add such possibility to gpart? e.g. gpart create -S 4096 -t gpt ad0? It will help all unlucky WD Advanced Format disks users. :-D A better approach is to have tunables for geom_disk to do this. This should absolutely not be part of a partitioning tool. It violates everything there is to violate AFAICT. FYI, -- Marcel Moolenaar xcl...@mac.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: ia64 - panic: deadlkres: possible deadlock detected for 0xe00000001187d880, blocked for 1801437 ticks
On Apr 2, 2010, at 3:55 PM, Anton Shterenlikht wrote: Hi Marcel I got this panic while trying to build some port on -current (csup'ed on 1-APR-2010) panic: deadlkres: possible deadlock detected for 0xe0001187d880, blocked for 1801437 ticks cpuid = 1 KDB: enter: panic [ thread pid 0 tid 100046 ] Stopped at kdb_enter+0x92: [I2]addl r14=0xffe1fbf0,gp ;; db db bt Tracing pid 0 tid 100046 td 0xe00010d4f500 kdb_enter(0xe4853640, 0xe4853640, 0xe439d170, 0x793) at kdb_enter+0x92 panic(0xe484b490, 0xe484b6d0, 0xe0001187d880, 0x1b7cdd) at panic+0x2f0 deadlkres(0xa0007ebca2d8, 0xe0001187d880, 0xe484b410, 0x1b7cdd) at deadlkres+0x470 fork_exit(0xe4893250, 0x0, 0xa000bd3db550) at fork_exit+0x110 enter_userland() at enter_userland db The panic followed a long freeze, of a sort that I've seen a lot on ia64 in the last couple of weeks. Do I get the panic (as opposed to a seemingly endless freeze) because of a recently added options DEADLKRES in my kernel config? Yes, exactly. At the db prompt, can you type: db show thread 0xe0001187d880 This should give you something like: Thread 11 at 0xe0001187d880: proc (pid 1): 0xe0301220c000 name: kernel stack: 0xa0021afd2000-0xa0021afd9fff flags: 0x10005 pflags: 0 state: RUNNING (CPU 0) priority: 52 container lock: sched lock 0 (0xe03400ad5080) With the thread ID, 11 in the example above, type: db thread 11 This should give you something like: [ thread pid 1 tid 11 ] kdb_enter+0x92: [I2] addl r14=0xffe279b8,gp ;; Then type the following for a backtrace: db bt FYI, -- Marcel Moolenaar xcl...@mac.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: gpart failing with no such geom after gpt corruption
On Apr 1, 2010, at 6:23 AM, Bartosz Stec wrote: Unfortunately it wasn't so easy. First of all system booted, and as I expected kernel message shows GPT error on ad1. Zpool was degraded but alive and kicking. However, when I tried to execute any gpart command on ad1, it return: ad1: no such geom If the GPT is rejected, no GEOM is created in the kernel. It's the GEOM that gpart(8) talks to, so the error indicates that the GPT is not accepted after you changed the disk size. For all practical purposes ad1 doesn't have a partitioning. The only gpart command you can use is: gpart create -s gpt ad1 This creates a new GPT on the disk, wiping out whatever was there... -- Marcel Moolenaar xcl...@mac.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: [PATCH] rename COMPAT_FREEBSD32
On Mar 23, 2010, at 7:05 AM, Nathan Whitehorn wrote: On Mar 22, 2010, at 10:52 AM, David O'Brien wrote: / On Mon, Mar 15, 2010 at 09:00:18AM -0700, Julian Elischer wrote: // I certainly agree.. can it be changed please? // // I've waited a while to see what other opinions would be expressed on this // topic. I believe there is sufficient support to rename COMPAT_FREEBSD32 // to something else based on responses in the mailing lists. // // I am sorry if some may wish to label this a bikeshead. But we seem to // have many folks disliking COMPAT_FREEBSD32. // // // Based on responses to the topic of COMPAT_FREEBSD32, the following // were the suggestions offered: //COMPAT_ARCH32, COMPAT_ARCH_32BIT, COMPAT_32BIT_ARCH, COMPAT_32BIT, //COMPAT_FREEBSD32BIT / There's probably a bigger problem than just how we name it. The option really encodes 2 independent aspects: 1. Support for a 32-bit ABI (i.e. ILP32) 2. Support for a particular OS in ILP32. Of course 2 implies 1. For example: COMPAT_IA32 in sys/ia64/ia64/machdep.c enabled code to save and restore IA32 registers as part of cpu_switch(). In this context COMPAT_IA32 was perfectly named. It's now called COMPAT_FREEBSD32, which doesn't make a lot of sense because what if I only want to support Linux/ia32 and not FreeBSD/ia32 (or vice-versa if you club them under a single COMPAT_*32)? The original version of my my patch had this split, with a COMPAT_FREEBSD32 and a COMPAT_[IA/PPC/MIPS]32. The problem is that the 32-bit FreeBSD compat is deeply intertwined with providing support for any 32-bit binaries at all (e.g., the 32-bit linuxolator depends on calling into it), so it isn't actually possible to support having COMPAT_LINUX32 without COMPAT_FREEBSD32 without a huge amount of work. So I scrapped that in favor of the unified name only, and we ended up with COMPAT_FREEBSD32. I understand. I just wonder if it was wise to expose this dependency across the whole source base with COMPAT_FREEBSD32 rather than keep it local to the linuxulator. What if we remove the dependency at some later point in time? Then what we have left is COMPAT_FREEBSD32 for no reason other than hysterical raisins. Anyway... Just want to point out that it's probably not a good idea to have a single option for multiple features, even if the code has them intertwined. Code changes easily, but options typically don't. out-on-a-limb Maybe we should improve our config to include dependencies, so that one only has to add options INVARIANTS and config knows to include options INVARIANT_SUPPORT. It's not uncommon for option/device X to need or depend on option/device Y... /out-on-a-limb -- Marcel Moolenaar xcl...@mac.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: csup/svn/ldd make host unresponsive [WAS: Re: ldd leaves the machine unresponsive]
On Mar 22, 2010, at 5:04 AM, jhell wrote: Not that this has anything to do with your problem but might turn into a problem if it is not your intent. But the above command will update your src to 9.0-CURRENT That is his intend. Anton: I fixed a bunch of things yesterday. You should be able to upgrade to HEAD. I have one more fix pending that's needed for preemption, but you should not hold off an upgrade for that... FYI, -- Marcel Moolenaar xcl...@mac.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: [PATCH] rename COMPAT_FREEBSD32
On Mar 22, 2010, at 10:52 AM, David O'Brien wrote: On Mon, Mar 15, 2010 at 09:00:18AM -0700, Julian Elischer wrote: I certainly agree.. can it be changed please? I've waited a while to see what other opinions would be expressed on this topic. I believe there is sufficient support to rename COMPAT_FREEBSD32 to something else based on responses in the mailing lists. I am sorry if some may wish to label this a bikeshead. But we seem to have many folks disliking COMPAT_FREEBSD32. Based on responses to the topic of COMPAT_FREEBSD32, the following were the suggestions offered: COMPAT_ARCH32, COMPAT_ARCH_32BIT, COMPAT_32BIT_ARCH, COMPAT_32BIT, COMPAT_FREEBSD32BIT There's probably a bigger problem than just how we name it. The option really encodes 2 independent aspects: 1. Support for a 32-bit ABI (i.e. ILP32) 2. Support for a particular OS in ILP32. Of course 2 implies 1. For example: COMPAT_IA32 in sys/ia64/ia64/machdep.c enabled code to save and restore IA32 registers as part of cpu_switch(). In this context COMPAT_IA32 was perfectly named. It's now called COMPAT_FREEBSD32, which doesn't make a lot of sense because what if I only want to support Linux/ia32 and not FreeBSD/ia32 (or vice-versa if you club them under a single COMPAT_*32)? -- Marcel Moolenaar xcl...@mac.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: rm/csup/svn/ldd make host unresponsive [WAS: Re: ldd leaves the machine unresponsive]
On Mar 21, 2010, at 1:27 PM, Anton Shterenlikht wrote: It seems the problems I've had in the last several days with ldd/csup/svn/rm have the same root cause. I'm aware of the issue. Give me a few days to fix it. I have a fix under test, but it exposes other problems... -- Marcel Moolenaar xcl...@mac.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
