Re: autofs -hosts maps
On 11/18/23 07:13, Daniel Braniss wrote: On 18 Nov 2023, at 5:47, Cy Schubert wrote: Hi, The discussion about NFS exports of ZFS snapshots prompted me to play around with -hosts maps on my network. -hosts maps are mounted on /net. I've discovered that -hosts maps don't work with most shares but do with others. I've only played with this for a few minutes so I don't fully understand why some maps work and others not. Some of underlying directories that don't work are ZFS while others are UFS. Yet, auto_home maps mounting the same directories does work. And mounting the shares by hand (using mount_nfs) also works. Just putting this out there should someone else have noticed this. I'll play around with this a little over the weekend. it’s subdirectories that don’t work? if so it’s a bug/feature of -hosts. danny -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 Daniel Braniss da...@cs.huji.ac.il Hi, Could it be related to the issue in the (old) discussion starting with this message: https://lists.freebsd.org/pipermail/freebsd-current/2014-September/051969.html -- Kind regards, Hans Ottevanger Eindhoven, Netherlands h...@beastielabs.net www.beastielabs.net
Re: [HEADSUP] making /bin/sh the default shell for root
On 9/22/21 10:36 AM, Baptiste Daroussin wrote: Hello, TL;DR: this is not a proposal to deorbit csh from base!!! For years now, csh is the default root shell for FreeBSD, csh can be confusing as a default shell for many as all other unix like settled on a bourne shell compatible interactive shell: zsh, bash, or variant of ksh. Recently our sh(1) has receive update to make it more user friendly in interactive mode: * command completion (thanks pstef@) * improvement in the emacs mode, to make it behave by default like other shells * improvement in the vi mode (in particular the vi edit to respect $EDITOR) * support for history as described by POSIX. This makes it a usable shell by default, which is why I would like to propose to make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed) If no strong arguments has been raised until October 15th, I will make this proposal happen. Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! Best regards, Baptiste Hello, I applaud the proposal to change the default login shell of root to /bin/sh. As you mention the rest of the Unix(-like) world has used a Bourne-like root login shell forever. It is one of the first things I change on a new FreeBSD install anyway. While there, you could change "Charlie &" in the gecos field to something more sensible, e.g. just "Superuser". I know Charlie is there since 4.2BSD, but the reference to a long forgotten baseball player is probably lost by now. Also, a lot of explanation is often needed when users receive (automated) emails from Charlie Root. Once the login shell of root has changed to /bin/sh, I do not see any reason to keep toor around. It is there since 4.3BSD, but I don't know anybody who uses it in the long term. Many will just change the login shell of root to a Bourne-like shell right away. I have experimented a bit with the new usability features of sh in 14.0 and I must say that it was quite a positive experience. I could easily suppress the urge to install and use bash instead of sh. I wonder if the changes (but not the ones to /etc/passwd) could be MFC'd in a few months, once they have matured a bit, so they would land in 13.1. As you mention elsewhere in this thread, usage in scripts is not affected by these changes. And for interactive use it could be a POLA violation, but the astonishment would be a positive one. -- Kind regards, Hans Ottevanger Eindhoven, Netherlands. h...@beastielabs.net www.beastielabs.net
Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted
On 05/30/18 17:50, Glen Barber wrote: Hi, Could folks please help boot-test the most recent 12.0-CURRENT amd64 memstick images on various hardware? Note, this is not a request to install 12.0-CURRENT, only a boot-test with various system knobs tweaked. The most recent images are available at: https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we would like to get this included in the upcoming 11.2-RELEASE if the change that had been committed addresses several boot issues reported recently. Please help test, and report back (both successes and failures). Hi, I tried to boot the memstick.img on the following two systems (both fairly ancient and just having a BIOS): ASUS N4L-VM DH, CPU T7400 @2.16GHz Intel DP965LT, CPU Q6600 @2.40GHz Both booted perfectly. With FreeBSD 11.1 the latter system needed a freshly written USB stick to be treated with "gpart recover da0 && gpart set -a active da0" before it would boot, so this is certainly an improvement. Kind regards, Hans Ottevanger www.beastielabs.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: Lenovo BIOS boot fix
On 07/12/15 20:07, Allan Jude wrote:
On 2015-07-12 11:10, Andrey V. Elsukov wrote:
On 12.07.2015 09:02, Allan Jude wrote:
I forgot to include the link to the patch as well:
http://www.allanjude.com/bsd/lenovofix_gpart.patch
I will most likely make this patch optional, behind a flag to the 'gpart
create -s gpt' command, to avoid potentially breaking existing working
systems, but if using offset 1 works on all other hardware, having it as
the default would be nice.
Another option would be to make a separate standalone program to modify
the pMBR for Lenovo machines, rather than modifying gpart.
Hi,
I think Lenovo's BIOS just think that your partition layout is MBR and
uses legacy boot.
if (MBR_partition[0].type == 0xee gpt_is_ok()) {
UEFI_boot();
} else {
MBR_boot();
}
I am not sure what they actually do, but, by making it the
MBR_partition[1].type that is 0xee, FreeBSD is still perfectly happy,
and the Lenovo boots.
Other non-lenovo machines I tested on also worked.
Tested Platforms (in BIOS/non-UEFI mode):
Lenovo X220
Lenovo X230 (doesn't have the bug, boots fine with MBR[0].type = 0xee)
Lenovo T530 (also doesn't have the bug)
Asus Core2Duo
Asus i7 Nehalem desktop
Asus i5 Sandy bridge desktop
Gigabyte i5 Ivy bridge desktop
Intel Ivy bridge NUC
Intel Haswell NUC
Supermicro i7 Haswell workstation
Hi Allan,
I did some experiments with the newest memstick image you provided
(lenovofix_20150712-r285132.img).
On an oldish Q6600 based system using an INTEL DP965LT main-board (it
only has BIOS mode) I first pulled the SATA connectors before trying to
boot from the USB stick. It shows the same problem as always with a
fresh install of FreeBSD 10.x:
No bootable device -- insert boot disk and press any key
This can be fixed by first modifying the image on the USB stick using
gpart recover da0
(the stick is 8Gbyte and the image as copied on it is 1Gbyte, so the GPT
seems corrupt), followed by the usual
gpart set -a active da0
I think this issue manifests itself on a generation of older Intel and
Foxconn main-boards and possibly differs from the problem that you try
to solve with Lenovo hardware.
I also tried the unmodified image on an even older T7200 based system
having an Asus NL4VM-DH main-board and there it just dumps the registers
(followed by BTX Halted) very early in the boot process. This has
happened before on several occasions with FreeBSD 10.x. The board is
probably too rare to worry about too much, though it still runs OpenBSD
5.7 perfectly.
Kind regards,
Hans Ottevanger
Eindhoven, Netherlands
www.beastielabs.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: [CFT] Autofs.
On 08/17/14 16:50, Edward Tomasz Napierała wrote: On 0817T1244, Hans Ottevanger wrote: [...] Hi! Great to see a real autofs finally coming to FreeBSD. I already did some very cursory testing on a recent 11-CURRENT system that I still happened to have and things with at least the /net map look quite OK. I could do some more extensive testing if I could use some of my 10-STABLE systems. I already checked that the patch applies cleanly to a recent 10-STABLE (modulo a few offsets) and that both buildworld and buildkernel succeed. Should I expect difficulties actually running your autofs on 10-STABLE? No, it should be fine. Plan is to MFC this to 10 soon, btw. Good to see that autofa has been MFC'd during my vacation 8-) But I found a little problem... When I try to access the NFS exported file-systems on an older test machine (running 7.x, but that is not so relevant, it also happens with other servers), with the following exports: $ showmount -e soekris Exports list on soekris: /var 192.168.0.0 /usr 192.168.0.0 /home 192.168.0.0 / 192.168.0.0 I get: $ ls /net/soekris COPYRIGHT distlibexec proctmp bin entropy lost+found rescue usr bootetc media rootvar compat homemnt sbin dev lib which is correct, but the next level fails: $ ls -l /net/soekris/usr total 0 since /usr on soekris is definitely not empty. Relevant output of mount : ... map -hosts on /net (autofs) soekris:/ on /net/soekris (nfs, nosuid, automounted) This is on 10.1-PRERELEASE r270922. The kernel config is GENERIC minus devices I do not have and AUTOFS added. Config files (/etc/auto_master, et al) are default. Mounting manually does succeed (in two steps, of course). When trying this from Mac OS X (I am still on Snow Leopard) automounting works as expected. I did not have the opportunity yet to try a Linux box (also do not know whether autofs there has been eaten by systemd already 8-)). Do I miss something, or is this a bug? Kind regards, Hans ___ 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] Autofs.
On 09/04/14 09:15, Garrett Cooper wrote: Hi Hans! On Wed, Sep 3, 2014 at 10:59 PM, Hans Ottevanger h...@beastielabs.net wrote: Good to see that autofa has been MFC'd during my vacation 8-) But I found a little problem... ... Do I miss something, or is this a bug? Can you please provide the output of `mount -p' from your server? Sure, looks like this: [root@soekris ~]# mount -p /dev/ad0s1a / ufs rw 1 1 devfs /devdevfs rw 0 0 /dev/ad0s1f /home ufs rw 2 2 /dev/ad0s1e /usrufs rw 2 2 /dev/ad0s1d /varufs rw 2 2 And as I mentioned, mounting manually succeeds. Kind regards, Hans ___ 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] Autofs.
On 09/04/14 14:43, Edward Tomasz Napierała wrote: On 0904T0759, Hans Ottevanger wrote: On 08/17/14 16:50, Edward Tomasz Napierała wrote: On 0817T1244, Hans Ottevanger wrote: [...] Hi! Great to see a real autofs finally coming to FreeBSD. I already did some very cursory testing on a recent 11-CURRENT system that I still happened to have and things with at least the /net map look quite OK. I could do some more extensive testing if I could use some of my 10-STABLE systems. I already checked that the patch applies cleanly to a recent 10-STABLE (modulo a few offsets) and that both buildworld and buildkernel succeed. Should I expect difficulties actually running your autofs on 10-STABLE? No, it should be fine. Plan is to MFC this to 10 soon, btw. Good to see that autofa has been MFC'd during my vacation 8-) But I found a little problem... When I try to access the NFS exported file-systems on an older test machine (running 7.x, but that is not so relevant, it also happens with other servers), with the following exports: $ showmount -e soekris Exports list on soekris: /var 192.168.0.0 /usr 192.168.0.0 /home 192.168.0.0 / 192.168.0.0 I get: $ ls /net/soekris COPYRIGHT distlibexec proctmp bin entropy lost+found rescue usr bootetc media rootvar compat homemnt sbin dev lib which is correct, but the next level fails: $ ls -l /net/soekris/usr total 0 since /usr on soekris is definitely not empty. Relevant output of mount : ... map -hosts on /net (autofs) soekris:/ on /net/soekris (nfs, nosuid, automounted) This is on 10.1-PRERELEASE r270922. The kernel config is GENERIC minus devices I do not have and AUTOFS added. Config files (/etc/auto_master, et al) are default. Mounting manually does succeed (in two steps, of course). When trying this from Mac OS X (I am still on Snow Leopard) automounting works as expected. I did not have the opportunity yet to try a Linux box (also do not know whether autofs there has been eaten by systemd already 8-)). Do I miss something, or is this a bug? It's a bug. Or rather, a missing feature. The problem here is that the / export shadows the rest. To handle this correctly, automountd(8) would need to mount the / share, then mount autofs on /usr etc, and then call it done. This part is easy. The problem is: how to expire (automatically unmount) it? Because of autofs mounts, the / share will always be busy, and thus won't ever get automatically unmounted. So, for now, we don't even try to handle this situation. I'm not sure what would the best way to solve it. Maybe the same way as Mac OS X does. On my old MacMini (Snow Leopard) I get in a quiescent state, before automounting anything: /dev/disk0s2 on / (hfs, local, journaled) devfs on /dev (devfs, local, nobrowse) map -hosts on /net (autofs, nosuid, automounted, nobrowse) map auto_home on /home (autofs, automounted, nobrowse) Immediately after ls -l /net/soekris/usr: /dev/disk0s2 on / (hfs, local, journaled) devfs on /dev (devfs, local, nobrowse) map -hosts on /net (autofs, nosuid, automounted, nobrowse) map auto_home on /home (autofs, automounted, nobrowse) soekris:/ on /net/soekris (nfs, nodev, nosuid, automounted, nobrowse) trigger on /net/soekris/usr (autofs, automounted, nobrowse) trigger on /net/soekris/var (autofs, automounted, nobrowse) trigger on /net/soekris/home (autofs, automounted, nobrowse) soekris:/usr on /net/soekris/usr (nfs, nodev, nosuid, automounted, nobrowse) Then, after more than 400 seconds: /dev/disk0s2 on / (hfs, local, journaled) devfs on /dev (devfs, local, nobrowse) map -hosts on /net (autofs, nosuid, automounted, nobrowse) map auto_home on /home (autofs, automounted, nobrowse) soekris:/ on /net/soekris (nfs, nodev, nosuid, automounted, nobrowse) trigger on /net/soekris/usr (autofs, automounted, nobrowse) trigger on /net/soekris/var (autofs, automounted, nobrowse) trigger on /net/soekris/home (autofs, automounted, nobrowse) and finally after 600 seconds we are back to: /dev/disk0s2 on / (hfs, local, journaled) devfs on /dev (devfs, local, nobrowse) map -hosts on /net (autofs, nosuid, automounted, nobrowse) map auto_home on /home (autofs, automounted, nobrowse) So triggers for the subdirectories are automounted on their automounted parent directory and expiration occurs in steps. BTW, I reconfigured the automount timeout as 300s (was 3600s) so I do not fully understand why the first time takes at least 400s. If you think it is useful I can grab an older Linux box from my basement and try to get autofs running on it, to do the same experiment. I currently do not have a Solaris installation. Kind regards, Hans ___ freebsd-current
Re: [CFT] Autofs.
On 07/30/14 09:19, Edward Tomasz Napierała wrote: At the link below you will find a patch that adds the new automounter. The patch is against yesterdays 11.0-CURRENT. http://people.freebsd.org/~trasz/autofs-head-20140729.diff Slides that explain the project scope and deliverables are here: http://people.freebsd.org/~trasz/autofs.pdf Testing is welcome. Please start with manual pages, eg. automount(8). Note that you need not only to rebuild both kernel and world, but also to run mergemaster, to install required /etc files. To run at startup, add 'autofs_enable=YES' to /etc/rc.conf. This project is being sponsored by FreeBSD Foundation. Hi! Great to see a real autofs finally coming to FreeBSD. I already did some very cursory testing on a recent 11-CURRENT system that I still happened to have and things with at least the /net map look quite OK. I could do some more extensive testing if I could use some of my 10-STABLE systems. I already checked that the patch applies cleanly to a recent 10-STABLE (modulo a few offsets) and that both buildworld and buildkernel succeed. Should I expect difficulties actually running your autofs on 10-STABLE? And do you plan support for NIS? I know NIS is quite dead and has been so for at least 20 years, but I still see it being used occasionally (probably most out of habit) and it is (still ?) available in the base-system. Kind regards, Hans ___ 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: Import of DragonFly Mail Agent
On 02/24/14 17:16, Lucius Rizzo wrote: * Bryan Drewery bdrew...@freebsd.org [2014-02-24 09:40]: Remembering the time I spent trying to configure sendmail to not accept inbound mail, and trying to get it to behave how I want, I fully support this. Of all the years I've messed with sendmail, I still have little understanding of how to configure it or if I've done it right. Hush! No sendmail hating :P. I remember it being a right of passage to graduate to a ^real^ UNIX admin when you had lost half of your hair while working on sendmail.cf. In a era now long gone, I remember carrying the sendmail bible (thick with detailed instructions on cf vars) as protection vs. say a baseball bat. The Sendmail manual was thick, heavy and while I never did use it as a weapon; I had imagined many times throwing it at a server and see if that maybe fixed the problem with sendmail.cf. I've worked with MTA's a lot. I have hated and loved Sendmail. ATM, I am back in my I 3 Sendmail mode and have it running quite well -- with a lot of cool milters on some of my servers. But sendmail is not for the faint of heart, or ones who are at risk of hair loss. In fact, I would highly discourage sendmail use in the latter case. My exaggerated view of sendmail as a user: [...] Poof..that's easy :P # Uncomment if you want STARTTLS support (only used in combination with # SECURETRANSFER) #STARTTLS Yes please. Simple. I'm not sure where to even start with sendmail to enable those options. See! That wasn't hard at all!! I don't get why people get so worried. What you posted was mostly mc stuff anyways. I would be far more impressed if you would have debugged that in the cf or via sendmail flags. :))) I often use ssmtp on servers that run Wordpress etc and collect most mail to a mailhub which routes it internally and externally. I 3 Sendmail. I have been using Sendmail for about 25 years now and I must say that I still find it quite satisfactory, though a bit overkill for the current needs of me and my customers. And I certainly lost a lot of hair, but not just due to using Sendmail 8-). So you understand that I grew quite attached to Sendmail. Nevertheless, I would like see Sendmail moved to ports and replaced by DMA in base, as proposed by Baptiste. Sendmail can receive much better care as a port and it also should become much easier to configure it for special needs (authentication, etc). This would also open possibilities to experiment more with newer and lighter MTA's like Postfix and OpenSMTPD without having parts of sendmail still lying around and sendmail being rebuilt on every buildworld. Go for it, and don't wait too long! Kind regards, Hans ___ 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: rcs
On 10/08/13 04:31, Lyndon Nerenberg wrote: Okay folks, can we make a call about keeping the RCS tools in the base? The proponents wanting to remove RCS need to speak up and make their technical case. Technically it is quite simple: I need RCS to start versioning config files, even before starting any customization. I know about several others who do the same (and have not yet defected to Linux). I would like to see RCS to be put back into the tree for 10.0. If it really -has- to be victimized by the current anti-GPL crusade, it could be replaced by OpenRCS in 11. And as a long time hard-core user I would appreciate if this kind of changes were performed only after at least -some- public discussion. The way this change was sneaked in (though apparently with approval of core@), reminds me more of a Secret Society than of an Open Source project. Regards, Hans ___ 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: rcs
On 10/09/13 15:47, Julian Elischer wrote: On 10/9/13 3:20 PM, Hans Ottevanger wrote: On 10/08/13 04:31, Lyndon Nerenberg wrote: Okay folks, can we make a call about keeping the RCS tools in the base? The proponents wanting to remove RCS need to speak up and make their technical case. Technically it is quite simple: I need RCS to start versioning config files, even before starting any customization. I know about several others who do the same (and have not yet defected to Linux). I would like to see RCS to be put back into the tree for 10.0. If it really -has- to be victimized by the current anti-GPL crusade, it could be replaced by OpenRCS in 11. And as a long time hard-core user I would appreciate if this kind of changes were performed only after at least -some- public discussion. The way this change was sneaked in (though apparently with approval of core@), reminds me more of a Secret Society than of an Open Source project. no, with private approval of a CORE MEMBER.. that is quite a different thing.. Core, AFAIK has not ruled on this sort of topic.. (and actually it's not really it's job to do so unless it's resolving a dispute.) You are probably right, but as a relative outsider I only saw this in the commit message: Log: Good bye RCS. You will be missed. (devel/rcs and devel/rcs57 are available as alternatives) Approved by: core Approved by: re (hrs) which led me to my possibly wrong conclusion about the approval of core@. Kind regards, Hans ___ 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: Time to kill fdc ?
On 02/10/13 12:46, Daniel O'Connor wrote: On 10/02/2013, at 22:14, Poul-Henning Kamp p...@phk.freebsd.dk wrote: I've used it in 7.x to read install.cfg for a semi automated install process. I didn't see any panics, but then again install.cfg is a pretty small file. On 7.x I got consistent panics about bounce-buffers. Hmm strange, I am not sure I have requisite hardware at work any more, all of the suitable machines were shipped. In any case I am in no position to maintain FDC as I no longer user it as part of my install process. -- I still use those old 1.4 Mbyte diskettes quite often (ancient archives of experimental data, exchanging data with retro-computers, etc.), but these days I mostly (but not always) use a USB diskette drive. But I just did an experiment on an old Pentium 4 system here, using the fdc driver and 8.3-STABLE as of early December (r243900). I read several diskettes using dd /dev/fd0 /dev/null and everything went flawlessly. The only issue I have seen with fdc over the years/releases is that around 7.x old DD diskettes (maximum of 720 kbyte) stopped working. Attempting to write them failed with a lot of retries, but never resulted in a panic. Strange enough they do work with my USB drive ... Could it be that the drive that Poul-Henning is using is worn out a bit? Not that the system should be panicking in that case, but it could at least explain why we see different thing happening. Kind regards, Hans ___ 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: Time to kill fdc ?
On 02/10/13 15:55, Poul-Henning Kamp wrote: Content-Type: text/plain; charset=ISO-8859-1 In message 5117a0cd.6060...@beastielabs.net, Hans Ottevanger writes: On 02/10/13 12:46, Daniel O'Connor wrote: But I just did an experiment on an old Pentium 4 system here, using the fdc driver and 8.3-STABLE as of early December (r243900). I read several diskettes using dd /dev/fd0 /dev/null and everything went flawlessly. Could you try: dd if=/dev/fd0 of=/dev/null bs=1048576 Tried this, 20 times in a row, without any failures. Did the same for dd if=/dev/fd0 of=/tmp/junk bs=1048576 again without failures. As stated before, this is on an old Pentium 4, now updated to 8.3-STABLE r246624. What hardware are you using? Maybe I can reproduce that panic if I can find similar hardware in my collection. That consistently exploded 7.x and 8.x here yesterday... (I used recoverdisk, but that's not material) Could it be that the drive that Poul-Henning is using is worn out a bit? No, that's not it. It's (amongst other things) ISA-DMA being børken (try something different that /dev null btw :-) and bounce buffers for same panicking the system. Kind regards, Hans ___ 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: removal of share/doc/{papers,psd,smm,usd} in 2 months
On 10/19/12 16:36, Ulrich Spörlein wrote: Hi all, those roff sources have been very naughty and will be removed from the tree by the end of the year. Most of those papers are severely out of date and provide no more use to the system. They can probably also be found online using a search engine of your choice. Could you be more specific as to why these sources have been very naughty? Should people feel strongly about them, we might be able to move them over to the doc repository. I strongly object this removal. As already pointed out by others, there are papers documenting vi/ex and RPC/XDR. These papers are practically the only docs available on these subjects, apart from the very terse man pages. There are also tutorials on e.g. Yacc and Lex, that probably are not that up-to-date but quite short and (at least for now) readily available. And there is also the IPC Tutorial. This may not all be documents that are immediately needed for operational purposes, but they do offer much needed background information, also of historical character, i.e. how and why things became as they are today. Regards, Hans Ottevanger ___ 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: Use of C99 extra long double math functions after r236148
On 05/29/12 19:54, Stephen Montgomery-Smith wrote: [...] Anyway, given that floating point is a big issue, and we are about a decade behind schedule, really suggests that a floating-po...@freebsd.org mailing list is needed. Or maybe there is an existing freebsd mailing list you guys already occupy. I would certainly take part in discussions on such a list. And since I have developed similar software in the past, I could even contribute a bit more, if desired. I have quite a tight schedule, but this type of development does not require an extensive infrastructure and can be done in lost hours on the road. Kind regards, Hans Ottevanger ___ 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: amd: is there an alternative with NFSv4 capabilities?
On 01/21/12 03:35, Rick Macklem wrote: O. Hartmann wrote: Hello. I still use the amd automounter, but I miss NFSv4 capabilities. Since Linux seems to use a more deep in the kernel located facility, I'd like to ask whether FreeBSd has an alternative to the amd automounter with NFSv4 capabilities. Sorry if I bother someone, I'm not aware of an alternative and it maybe the case that I'm stuck with the amd ... Cheers, Oliver I'm not aware of anything, but maybe someone else knows of an alternative? On my maybe it would be nice list (not my to do list, because I'll never get around to it) was to look at the Solaris' AutoFS. I believe Apple switched to it and has found it worked well in Mac OSX. I suspect that there are OpenSolaris sources for it out there under the CDDL, but I haven't even checked that. So, if anyone is looking for an interesting project, this might be a nice one. (I could probably provide some help with it, if someone took it on.) AutoFS for FreeBSD was the topic of a GSoC 2006 project and results seem to be presented at BSDCan 2007, see: http://www.bsdcan.org/2007/schedule/events/32.en.html (The presentation has a .ppt extension, but is actually a pdf). Despite plans, to my knowledge nothing ever happened with the results. As far as I remember, the code is viewable in Perforce, but not (easily) down loadable by mere mortals, and probably quite stale by now. I concur that having a real AutoFS, integrated with NFSv4 and fully inter operable with Linux and Solaris (and Mac OS-X ?) would be really nice to have, especially for scientific and engineering environments. Kind regards, Hans Ottevanger ___ 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: WITHOUT_PROFILE=yes by default
On 12/02/11 19:39, Lyndon Nerenberg wrote: Isn't this about user choice, and making sensible defaults? There are two or three users out of thousands complaining about the default. If the extra build time bugs you that much, I'll contribute towards buying you better build hardware, too. Well, I am not a FreeBSD developer (though I do hunt down a bug occasionally), but for many, many years I do develop software using FreeBSD as a development platform. And for solving performance issues, mainly in long running, CPU intensive (numerical) applications gprof and all too often the profiled libraries appeared to be indispensable. I am mostly using STABLE, but occasionally switch to CURRENT to get a feeling for the newest developments (e.g. LLVM). One of the reasons I am still using FreeBSD is the out-of-the-box availability of tools like the profiler and profiled libraries. Maybe I could live with a switch in /etc/src.conf, if it were properly documented, but that would imply that the profiled libraries are not built anymore with any regularity. And of course we all know where that could lead to in the future ... I would certainly keep the profiled libraries by default in the build for CURRENT and maybe even in STABLE. With binary installations of RELEASE it could be an option, as it always was. Regards, Hans ___ 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
Snapshots fail with UFS+J (was: Re: Fwd: Re: Can *you* UFS snapshot a filesystem with 9.0-BETA1?)
On Sun, Aug 21, 2011 at 12:04:26PM +0200, Hans Ottevanger wrote: On Sat, Aug 20, 2011 at 09:35:01AM +0100, Hugo Silva wrote: Le Thu, 18 Aug 2011 10:22:31 +0100, Hugo Silva h...@barafranca.com a ?crit : Hello, I'm wondering. On a virtual machine (amd64 HVM+PV), it's crashing every time. Not sure if this is SNAFU, as I had never used ufs snapshots on freebsd before. After running mksnap_ffs, ssh stops working (a telnet session doesn't show the sshd banner). The ssh session where the command was run from stops responding, the webserver dies and xm console'ing from the dom0 works, but the VM is unresponsive (ie no login prompt on ENTER). Anyone else seeing the same? I've tried in a FreeBSD guest (9.0-beta1/i386) into VirtualBox and I see a LOR (or looks like a LOR), then the system is freezed. This is 100% reproductible. Unfortunatly, I'm not able to dump a panic or to break into the debugger, so a screenshot : http://user.lamaiziere.net/patrick/public/lormksnap.png You should ask on freebsd-current@ Hi, I can confirm that this happens on real iron too. I use an i386 test installation (P4 2.4 GHz, 2GB RAM, 500GB PATA disk), running 9.0-BETA1 as distributed (with a kernel effectively being GENERIC with devices removed that I don't have). When I try to make a snapshot using cd /usr; mksnap_ffs /usr/.snap/testsnap the system is still responsive for a few seconds, with lots of disk activity, but then it prints the following output on the console (using firewire and dcons to ease capturing): lock order reversal: 1st 0xc5a289e8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:425 2nd 0xdeb3c078 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 3rd 0xc5663af8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:546 KDB: stack backtrace: db_trace_self_wrapper(c09ec6ba,616e735f,6f687370,3a632e74,a363435,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07099eb,c09efe14,c5035308,c5039408,c4fda440,...) at kdb_backtrace+0x2a _witness_debugger(c09efe14,c5663af8,c09df984,c5039408,c0a10ba2,...) at _witness_debugger+0x25 witness_checkorder(c5663af8,9,c0a10ba2,222,0,...) at witness_checkorder+0x839 __lockmgr_args(c5663af8,80100,c5663b18,0,0,...) at __lockmgr_args+0x804 ffs_lock(c4fda568,c0bf1250,c59b9c30,80100,c5663aa0,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0a7fb80,c4fda568,c4fda588,c0a8df20,c5663aa0,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c5663aa0,80100,c0a10ba2,222,c5011e80,...) at _vn_lock+0x5e ffs_snapshot(c54f9798,c52dda60,c0a13fb0,1a2,0,...) at ffs_snapshot+0x14cb ffs_mount(c54f9798,c59b0300,ff,394,3,...) at ffs_mount+0x1c13 vfs_donmount(c59b9b80,11100,c50c7c80,c50c7c80,c59ae580,...) at vfs_donmount+0x11e7 nmount(c59b9b80,c4fdacec,c4fdad28,c09ee6dd,0,...) at nmount+0x84 syscallenter(c59b9b80,c4fdace4,c4fdace4,0,c0ab5690,...) at syscallenter+0x263 syscall(c4fdad28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280db52b, esp = 0xbfbfe59c, ebp = 0xbfbfed18 --- lock order reversal: 1st 0xdeb3c078 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 2nd 0xc51a72dc snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:818 KDB: stack backtrace: db_trace_self_wrapper(c09ec6ba,662f7366,735f7366,7370616e,2e746f68,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07099eb,c09efdfb,c5035308,c5039b58,c4fda440,...) at kdb_backtrace+0x2a _witness_debugger(c09efdfb,c51a72dc,c0a10c04,c5039b58,c0a10ba2,...) at _witness_debugger+0x25 witness_checkorder(c51a72dc,9,c0a10ba2,332,c5a28a08,...) at witness_checkorder+0x839 __lockmgr_args(c51a72dc,80400,c5a28a08,0,0,...) at __lockmgr_args+0x804 ffs_lock(c4fda568,deb2434c,10,80400,c5a28990,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0a7fb80,c4fda568,deb243a8,c0a8df20,c5a28990,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c5a28990,80400,c0a10ba2,332,0,...) at _vn_lock+0x5e ffs_snapshot(c54f9798,c52dda60,c0a13fb0,1a2,0,...) at ffs_snapshot+0x295e ffs_mount(c54f9798,c59b0300,ff,394,3,...) at ffs_mount+0x1c13 vfs_donmount(c59b9b80,11100,c50c7c80,c50c7c80,c59ae580,...) at vfs_donmount+0x11e7 nmount(c59b9b80,c4fdacec,c4fdad28,c09ee6dd,0,...) at nmount+0x84 syscallenter(c59b9b80,c4fdace4,c4fdace4,0,c0ab5690,...) at syscallenter+0x263 syscall(c4fdad28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280db52b, esp = 0xbfbfe59c, ebp = 0xbfbfed18 --- After this the system is fully unresponsive and requires a hard reset. Once rebooted, the snapshot file appears to exist, but is unusable. When reverting to just softupdates, i.e. disabling journaling on /usr, everything goes well, except that the same LOR's still do occur, though the addresses differ. My amd64 9.0-CURRENT system, just updated to r225055, has the same issue, but since I do not have WITNESS in the kernel config there, the console output is missing. BTW
Re: Fwd: Re: Can *you* UFS snapshot a filesystem with 9.0-BETA1?
On Sat, Aug 20, 2011 at 09:35:01AM +0100, Hugo Silva wrote: Le Thu, 18 Aug 2011 10:22:31 +0100, Hugo Silva h...@barafranca.com a ?crit : Hello, I'm wondering. On a virtual machine (amd64 HVM+PV), it's crashing every time. Not sure if this is SNAFU, as I had never used ufs snapshots on freebsd before. After running mksnap_ffs, ssh stops working (a telnet session doesn't show the sshd banner). The ssh session where the command was run from stops responding, the webserver dies and xm console'ing from the dom0 works, but the VM is unresponsive (ie no login prompt on ENTER). Anyone else seeing the same? I've tried in a FreeBSD guest (9.0-beta1/i386) into VirtualBox and I see a LOR (or looks like a LOR), then the system is freezed. This is 100% reproductible. Unfortunatly, I'm not able to dump a panic or to break into the debugger, so a screenshot : http://user.lamaiziere.net/patrick/public/lormksnap.png You should ask on freebsd-current@ Hi, I can confirm that this happens on real iron too. I use an i386 test installation (P4 2.4 GHz, 2GB RAM, 500GB PATA disk), running 9.0-BETA1 as distributed (with a kernel effectively being GENERIC with devices removed that I don't have). When I try to make a snapshot using cd /usr; mksnap_ffs /usr/.snap/testsnap the system is still responsive for a few seconds, with lots of disk activity, but then it prints the following output on the console (using firewire and dcons to ease capturing): lock order reversal: 1st 0xc5a289e8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:425 2nd 0xdeb3c078 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 3rd 0xc5663af8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:546 KDB: stack backtrace: db_trace_self_wrapper(c09ec6ba,616e735f,6f687370,3a632e74,a363435,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07099eb,c09efe14,c5035308,c5039408,c4fda440,...) at kdb_backtrace+0x2a _witness_debugger(c09efe14,c5663af8,c09df984,c5039408,c0a10ba2,...) at _witness_debugger+0x25 witness_checkorder(c5663af8,9,c0a10ba2,222,0,...) at witness_checkorder+0x839 __lockmgr_args(c5663af8,80100,c5663b18,0,0,...) at __lockmgr_args+0x804 ffs_lock(c4fda568,c0bf1250,c59b9c30,80100,c5663aa0,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0a7fb80,c4fda568,c4fda588,c0a8df20,c5663aa0,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c5663aa0,80100,c0a10ba2,222,c5011e80,...) at _vn_lock+0x5e ffs_snapshot(c54f9798,c52dda60,c0a13fb0,1a2,0,...) at ffs_snapshot+0x14cb ffs_mount(c54f9798,c59b0300,ff,394,3,...) at ffs_mount+0x1c13 vfs_donmount(c59b9b80,11100,c50c7c80,c50c7c80,c59ae580,...) at vfs_donmount+0x11e7 nmount(c59b9b80,c4fdacec,c4fdad28,c09ee6dd,0,...) at nmount+0x84 syscallenter(c59b9b80,c4fdace4,c4fdace4,0,c0ab5690,...) at syscallenter+0x263 syscall(c4fdad28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280db52b, esp = 0xbfbfe59c, ebp = 0xbfbfed18 --- lock order reversal: 1st 0xdeb3c078 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 2nd 0xc51a72dc snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:818 KDB: stack backtrace: db_trace_self_wrapper(c09ec6ba,662f7366,735f7366,7370616e,2e746f68,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07099eb,c09efdfb,c5035308,c5039b58,c4fda440,...) at kdb_backtrace+0x2a _witness_debugger(c09efdfb,c51a72dc,c0a10c04,c5039b58,c0a10ba2,...) at _witness_debugger+0x25 witness_checkorder(c51a72dc,9,c0a10ba2,332,c5a28a08,...) at witness_checkorder+0x839 __lockmgr_args(c51a72dc,80400,c5a28a08,0,0,...) at __lockmgr_args+0x804 ffs_lock(c4fda568,deb2434c,10,80400,c5a28990,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0a7fb80,c4fda568,deb243a8,c0a8df20,c5a28990,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c5a28990,80400,c0a10ba2,332,0,...) at _vn_lock+0x5e ffs_snapshot(c54f9798,c52dda60,c0a13fb0,1a2,0,...) at ffs_snapshot+0x295e ffs_mount(c54f9798,c59b0300,ff,394,3,...) at ffs_mount+0x1c13 vfs_donmount(c59b9b80,11100,c50c7c80,c50c7c80,c59ae580,...) at vfs_donmount+0x11e7 nmount(c59b9b80,c4fdacec,c4fdad28,c09ee6dd,0,...) at nmount+0x84 syscallenter(c59b9b80,c4fdace4,c4fdace4,0,c0ab5690,...) at syscallenter+0x263 syscall(c4fdad28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280db52b, esp = 0xbfbfe59c, ebp = 0xbfbfed18 --- After this the system is fully unresponsive and requires a hard reset. Once rebooted, the snapshot file appears to exist, but is unusable. When reverting to just softupdates, i.e. disabling journaling on /usr, everything goes well, except that the same LOR's still do occur, though the addresses differ. My amd64 9.0-CURRENT system, just updated to r225055, has the same issue, but since I do not have WITNESS in the kernel config there, the console output is missing. BTW, this issue also makes dump(9) hang the system when the -L option is used. Kind regards, Hans Ottevanger ___ freebsd-current@freebsd.org
SU+J: negative used diskspace (for a while)
Hi, I found a possible issue with SU+J on recent versions of -CURRENT. After deleting a large file hierarchy (copy of /usr/src, ~1.5 Gbyte), df reports a negative number of blocks Used for a while. I am using a GENERIC kernel (r223184) on an amd64 platform. The hardware is relatively simple: Intel DP965LT mainboard with a Q6600 CPU, 8 Gbyte RAM and two Samsung 501LJ 500 Gbyte SATA disks. The issue can be demonstrated by copying /usr/src to the current directory (cp -R /usr/src .) and running the following script to delete the copy and print the free space at 10 second intervals: #!/bin/sh df . time rm -rf src echo 'src is gone ...' while true do df . | tail -1 sleep 10 done This yields the following output: Filesystem 1K-blocksUsed Avail Capacity Mounted on /dev/ada0s1g 416144900 1612066 381241242 0%/home 51.21 real 1.00 user17.38 sys src is gone ... /dev/ada0s1g 416144900 -164692 383018000-0%/home /dev/ada0s1g 416144900 -165082 383018390-0%/home /dev/ada0s1g 416144900 -246852 383100160-0%/home /dev/ada0s1g 416144900 -246852 383100160-0%/home /dev/ada0s1g 416144900 -246852 383100160-0%/home /dev/ada0s1g 416144900 -64146 382917454-0%/home /dev/ada0s1g 416144900 -64146 382917454-0%/home /dev/ada0s1g 416144900 -64146 382917454-0%/home /dev/ada0s1g 416144900 32910 382820398 0%/home /dev/ada0s1g 416144900 32910 382820398 0%/home So it takes more than a minute before the disk space is back to normal values. After disabling journaling (tunefs -j disable) I get the following output: Filesystem 1K-blocksUsed Avail Capacity Mounted on /dev/ada0s1g 416144900 1579284 381274024 0%/home 35.40 real 0.96 user13.32 sys src is gone ... /dev/ada0s1g 416144900 128 382853180 0%/home /dev/ada0s1g 416144900 128 382853180 0%/home /dev/ada0s1g 416144900 128 382853180 0%/home /dev/ada0s1g 416144900 128 382853180 0%/home which is as it should be. The problem also does not occur with journaling enabled when I revert to r222723. Is anybody else seeing these weird phenomena? Could this be related to the recent changes to UFS? Kind regards, Hans Ottevanger ___ 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: Profiling code execution on amd64?
On 01/15/11 07:15, Garrett Cooper wrote: On Fri, Jan 14, 2011 at 10:10 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Fri, Jan 14, 2011 at 03:40:46PM -0500, George Neville-Neil wrote: On Jan 13, 2011, at 23:05 , Steve Kargl wrote: On Thu, Jan 13, 2011 at 10:08:30PM -0500, Ryan Stone wrote: I would suggest using hwpmc for profiling: # kldload hwpmc # pmcstat -S unhalted-cycles -O /tmp/samples.out ../penetration # pmcstat -R /tmp/samples.out -G /tmp/penetration.txt You can also get pmcstat to generate gprof-compatible output with -g, but I never use the mode so I'm really not sure what it gives you. I think that you have to run gprof on the output or something, but don't hold me to that. Thanks. I'll give it a try, but my initial attempt seems to indicate that one needs to be root to use hwpmc. laptop:kargl[210] pmcstat -S unhalted-cycles -O /tmp/samples.out ../penetration pmcstat: ERROR: Cannot allocate system-mode pmc with specification unhalted-cycles: Operation not permitted You only need to be root to profile the kernel or someone else's process. This tutorial might help: www.dcbsdcon.org/speakers/slides/neville-neil_dcbsdcon2009.pdf Thanks. I'll look at the tutorial. Meanwhile, should gprof be removed from the base system because it appears broken? Instead of just removing things, why not determine why things are broken and try to fix them? -Garrett gprof is not as badly broken as it seems 8-) I have encountered the issue described by the original poster regularly over the last few years, using different versions of FreeBSD. The total time reported by gprof is often way shorter than the time reported by time. I have checked that the problem goes back to at least 7.3-RELEASE, and it occurs on both amd64 and i386. I found that this problem is caused by neither the profile start-up code nor gprof knowing about dynamic linking. The start-up code calls profil() with etext as the upper limit of the address range to be profiled. This implies that all dynamically linked code will not be profiled, which explains the lost ticks in gprof. A solution might be to teach both the profiling start-up code and gprof about dynamic linking, but I guess that is not that trivial ... A good work-around is linking statically (-static). Also be aware that with dynamic linking and specifying -pg, a profiled (and static!) version is used only for the C library. So if e.g. the math library is needed -lm_p has to be specified explicitly instead of just -lm, or ticks will be lost. So specifying standard libraries with _p appended might already solve most of the problems. I also remember (and just verified) that in the good old days (FreeBSD 2.2.8) static linking took place automatically when profiling was requested, so the issues at hand might not even be new 8-) Kind regards, Hans Ottevanger PS. Thanks for the link to your tutorial, George. I am very interested in hwpmc, and since documentation seems to be somewhat sparse, this really helps. ___ 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: RC3 install floppies: panic: resource_list_alloc: resource entry is busy
Soren Schmidt wrote: [...] Hmm, seems to be a resource conflict problem, question is what is causing this. Could you do a verbose boot both with the old working kernel, and the new failing one ? Attached are two files. Both kernels used are built from the same config file, which is mostly GENERIC with devices removed that I do not have. The file "new" results from booting a kernel built completely from sources cvsupped yesterday. For "old" I replaced the contents of /sys/dev/ata by the files of February 17, i.e. before the major changes. I must remark that this is one of the machines that reports its IDE IRQ as 0 when asked for it. About two months ago there were problems when the ata driver took the timer interrupt. This was fixed by a special clause in ata-all.c, at least up to February 17. Maybe the current problem is related. This machine has an Intel motherboard with a Mercury chipset, 64 Mbyte RAM, Matrox Millenium II, two Western Digital disks, and it ran all previous FreeBSD releases perfectly for almost five years. Yeah I notice the RZ 1000 chips in there, BE CAREFULL, I wouldn't use this for anything I cared about... For serious work I now have two BP6 based machines, this became just a testmachine. I know about the possible data corruption problems with RZ1000 chips, but I have never seen them with FreeBSD, despite the fact that I did a "make world" every other week for more than two years. However, if you run Linux or Solaris on this machine, and forget to switch off the EIDE prefetch buffers, the results can be quite dramatic... Kind regards, Hans SMAP type=01 base= len= 0009fc00 SMAP type=01 base= 0010 len= 03f0 SMAP type=02 base= fffc len= 0004 Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Fri Mar 10 21:43:07 CET 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/CUSTOM Calibrating clock(s) ... TSC clock: 66643091 Hz, i8254 clock: 1300543 Hz 1300543 Hz differs from default of 1193182 Hz by more than 1% Timecounter "i8254" frequency 1193182 Hz TSC clock: 48650664 Hz (Method B) Timecounter "TSC" frequency 48650664 Hz CPU: Pentium/P5 (48.65-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x517 Stepping = 7 Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 real memory = 67108864 (65536K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x002d1000 - 0x03ff7fff, 64122880 bytes (15655 pages) avail memory = 62267392 (60808K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f0120 bios32: Entry = 0xf145c (c00f145c) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0x1440 pnpbios: Found PnP BIOS data at 0xc00f0130 pnpbios: Entry = f:1245 Rev = 1.0 Other BIOS signatures found: ACPI: Preloaded elf kernel "kernel" at 0xc02b8000. Intel Pentium detected, installing workaround for F00F bug pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x (0x8000) pci_open(1b): mode1res=0x (0xff01) pci_open(2):mode 2 enable port (0x0cf8) is 0x00 pci_open(2a): mode2res=0x0e (0x0e) pci_open(2a): now trying mechanism 2 pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=04a38086) npx0: math processor on motherboard npx0: INT 16 interface i586_bzero() bandwidth = 54761513 bytes/sec bzero() bandwidth = 27416038 bytes/sec pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x (0x8000) pci_open(1b): mode1res=0x (0xff01) pci_open(2):mode 2 enable port (0x0cf8) is 0x00 pci_open(2a): mode2res=0x0e (0x0e) pci_open(2a): now trying mechanism 2 pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=04a38086) pcib0: Host to PCI bridge on motherboard found- vendor=0x8086, dev=0x04a3, revid=0x03 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 found- vendor=0x1042, dev=0x1000, revid=0x01 class=01-01-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[10]: type 1, range 32, base 01f0, size 3 map[14]: type 1, range 32, base 03f4, size 2 found- vendor=0x8086, dev=0x0484, revid=0x03 class=00-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 found- vendor=0x102b, dev=0x051b, revid=0x00 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=11 map[10]: type 1, range 32, base a000, size 24 map[14]: type 1, range 32, base a100, size 14 map[18]: type 1, range 32, base a180, size 23 found- vendor=0x10b7, dev=0x9200, revid=0x74 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=10 map[10]: type 1, range 32, base
RC3 install floppies: panic: resource_list_alloc: resource entry is busy
Hi folks, I just tried to boot the RC3 install floppies on my Pentium 66 testbox. It gets through the config stage without trouble, but then panics immediately with: ... pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 atapci0: RZ 100? ATA controller !WARNING! buggy chip data loss possible port 0 x3f4-0x3f7,0x1f0-0x1f7 at device 1.0 on pci0 atapci0: Busmastering DMA not supported panic: resource_list_alloc: resource entry is busy I am also having this problem with 4.0-CURRENT kernels since February 18, both with my own custom kernel config and GENERIC. I have to revert to the ata driver of February 17 or earlier to get the system booting again, and then it runs perfectly. This machine has an Intel motherboard with a Mercury chipset, 64 Mbyte RAM, Matrox Millenium II, two Western Digital disks, and it ran all previous FreeBSD releases perfectly for almost five years. Anybody else having this problem ? And before I start digging, any idea where to look for a solution, if it makes sense at all ? Kind regards, Hans To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Panic booting P66 with new ata drivers
Hi folks, I am having problems again with the ata drivers on my old Pentium 66 system. With a kernel built from sources cvsupped today, I get he following messages when booting: ... pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 atapci0: RZ 100? ATA controller !WARNING! buggy chip data loss possible port 0 x3f4-0x3f7,0x1f0-0x1f7 at device 1.0 on pci0 atapci0: Busmastering DMA not supported panic: resource_list_alloc: resource entry is busy I had problems with this old system and the ata drivers before. The EIDE hardware apparently reported its IRQ as 0, which normally is reserved for the timer interrupt. Until recently, the ata driver contained code to force the IRQ back to 14 or 15 when it encountered such hardware. I do not see that code in the newest driver. Indeed, when I revert to the ata driver of last Sunday, the system boots and runs perfectly again. Is anybody having the same problem ? Any idea for a solution ? Kind regards, Hans To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ABIT BP6 + UDMA66: ad_timeout: lost disk contact
Hi folks, I am currently having problems with my new Dual Celeron testsystem, when trying to use UDMA66. Hardware: ABIT BP6 2x Celeron 466 (NOT overclocked) 128 Mbyte RAM Matrox G400 16 MByte 3Com 905B 2x Maxtor 92041U4 20 GByte Aopen CDROM 48x One of the disks is master on the first "standard" disk channel, and uses UDMA33, the other is master on the first "fast" channel controlled by the on-board HPT-366, and is probed as UDMA66. When I use the UDMA33 disk, no problem occurs at all, I can even run "make buildworld" without any problems. When accessing the disk on the UDMA66 channel however, the system regularly hangs, followed by a message like: Feb 12 12:39:54 myhost /kernel: ad4: ad_timeout: lost disk contact - resetting Feb 12 12:39:54 myhost /kernel: ata2: resetting devices .. done After a few of these messages the system hangs completely, and needs to be rebooted. The problem already occurred during my first attempts to use UDMA66 last week, but now persists using today's 4.0-CURRENT. My kernel is derived from GENERIC, with SMP added, and devices removed that are not present. I do not yet use softupdates. The problem can easily be reproduced by creating a large file as follows: dd if=/dev/zero of=junk bs=1024k count=512 This command runs without any problem. Reading this file with: dd if=junk of=/dev/null bs=1024k causes the problem to occur within a few seconds. Decreasing the blocksize makes the system survive somewhat longer, but the problem still occurs. Only with a blocksize lower than 4k the system does not hang. Very strange is the fact that reading the raw device file with: dd if=/dev/ad4s1c of=/dev/null bs=1024k completes without problems, even with two commands running concurrently. I already tried to swap the disks, but the problem still occurs on the one that is using UDMA66. Even when switching to PIO using 'sysctl', the system still hangs, it just takes somewhat longer before it happens. Does anybody have an idea what happens ? Kind regards, Hans To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ABIT BP6 + UDMA66: ad_timeout: lost disk contact
Marius Strom wrote: Hans and others, I have the same situation - happy to get a new motherboard and processor, unhappy to hang FreeBSD. My situation is different, however - I'm running single processor currently and it still hangs. I've also experienced this issue with and without softupdates. I also tried using the GENERIC kernel, i.e. running only a single CPU, and still the same situation ... Well, things like this may happen when using FreeBSD-CURRENT. Cheers, Hans To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ABIT BP6 + UDMA66: ad_timeout: lost disk contact
Soren Schmidt wrote: [...] If you are using the newest code, then the problem might be that your disks doesn't work proberly with UDMA66. I've seen several newer disks that has problems here, and frankly Maxtor is not known for their quality in this respect. I cvsupped this morning. AFAIK I have the newest code. You could try to disable the UDMA66 code on the HPT chips by ifdef'ing out the code that deals with it like below, if this helps you are most like dealing with disks that has problems with UDMA66. Dont be alarmed though, there is next to no performance difference for you... Tried this patch, and the system does not hang any more. Even better, I/O to this disk is still quite fast, at least way faster than using the "standard" interface on this board (and even that is not really slow). I'll run a "buildworld" as torture test this evening. Trying another disk is also an option, I know that the IBM's work just fine, and that some of the Quantums and WDC's are broken. I'll try a WD from my other BP6 one off these days. Maybe I had better buy IBM in the future. BTW, would it be possible to modify sysctl() to switch between UDMA66 and UDMA33, or maybe use "flags" like the old wd driver had. I fear that a lot of "broken" hardware is around, and once FreeBSD 4.0 hits the streets, you may expect a lot of problem reports. -Søren Kind regards, Hans To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New kernel no longer boots on one of my machines... ata, other problems
Matthew Dillon wrote: Well guys, I tried upgrading one of my older machines today to the latest 4.0. It was running an older 4.0 kernel (Nov 29 1999). .. HELP! Whats happening!!! :-( :-( :-( At the moment I am stymied. I switched to a GENERIC kernel and got the same results, so it isn't anything weird that I have done in my own kernel config. I was hoping that someone would have an idea. -Matt I also have one of those old Pentiums, with an Intel motherboard and a Mercury chipset. And I have similar problems with CURRENT of a few days ago. When I configure my kernel to use the new ata driver, it hangs when booting. I plan to reproduce this problem this weekend, with a more recent CURRENT. I think the problem is caused by the RZ1000 EIDE controller on this type of motherboard. I suspect that the new ata driver deals with interrupts in ways somewhat different from the old wd driver. According to the Intel documentation, interrupts during data transfers may cause data corruption. This RZ1000 issue has been discussed on this list a few weeks ago, without a real solution. Kind regards, Hans To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
