Re: propose: all arch move into a separate dir
paradox writes: > so, I really do not understand why it is so difficult [...] Easy for you to say, since you're not the one who would have to do the work and spend the next two years cleaning up the resulting mess. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: propose: all arch move into a separate dir
"Poul-Henning Kamp" writes: > Really stupid question: Doesn't svn support symlinks ? It does, but the moment we move in that direction, someone will start complaining that they can't check out the source on Windows (which is the reason why we no longer have any files in the tree with colons in their name, or files with the same name but different case in the same directory) DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Pack of CAM improvements
Alexander Motin writes: > I've just added Power Up In Stand-by (PUIS) feature support into CAM > ATA in HEAD. It is one of the ways to implement staggered spin-up for > ATA devices. Now CAM will spin-up no more then 4 of such devices at a > time. Hmm, how does that work? Doesn't the BIOS spin the disks up long before the kernel even loads? Can you set a flag on the disk to tell it not to? This is a very real issue for me. I have a file server that can't cold boot because the disks take too long to spin up and / or the PSU can't deliver enough power to spin them all up at the same time. I would love to be able to delay spinning up each disk until it's actually needed (i.e. /etc/rc.d/zfs start). DES -- Dag-Erling Smørgrav - d...@des.no ___ 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 tool for remapping bad sectors in CURRENT?
Miroslav Lachman <000.f...@quip.cz> writes: > Yes, rewriting by dd or any other way works for reallocating or > clearing pending sectors counter, but in server environment In a server environment, you'd be a fool not to have some sort of redundancy set up. > I need to know the affected file, as it can be for example database > file and then it is a big problem! Rewriting the sector inside InnoDB > ib_data file can cause DB crash, data loss etc. How is that different from *not* rewriting the sector? If there's a bad sector somewhere in your data, your database is still going to crash. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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 tool for remapping bad sectors in CURRENT?
Miroslav Lachman <000.f...@quip.cz> writes: > So... can somebody with enough knowledge write some docs / script how > to find the affected file based on LBA read error from messages / > SMART log? ZFS will tell you straight away, but I guess if you used ZFS, you wouldn't be asking :) For FFS, you can unmount the file system (boot from a CD or memory stick or whatever if that file system is / or /usr), run fsdb on the failing disk, use findblk to look up the inode number for the file that contains the bad sector. Note that you have to convert the LBA to an offset relative to the start of the partition. Unfortunately, you can't easily go from inode to file name; you have to mount the file system and use something like find -inum. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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 tool for remapping bad sectors in CURRENT?
Miroslav Lachman <000.f...@quip.cz> writes: > As I write in my first post to this thread, I already tried fsdb + > findblk, but without success. Findblk did not returned any inode. > Maybe the meaning of block is of different size or something else I > can't understand. AFAICT, "block" is a disk block (i.e. 512-byte sector in most cases) relative to the start of the partition. > The LBA of bad sector is *79725167* [...] s1 starts 63 sectors from > the beginning of the drive and /var/db has offset 39845888. So am I > right that I need to find block number *39879105* by findblk command? Uh, 79725167 - 63 = 79725104 and 79725104 - 39845888 = 39879216. How did you arrive at 39879105? DES -- Dag-Erling Smørgrav - d...@des.no ___ 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 tool for remapping bad sectors in CURRENT?
Miroslav Lachman <000.f...@quip.cz> writes: > Dag-Erling Smørgrav writes: > > Uh, 79725167 - 63 = 79725104 and 79725104 - 39845888 = 39879216. How > > did you arrive at 39879105? > I am sorry, it was my confusion. > My calculation was for *LBA=79725056* reported in messages: > > ad4: FAILURE - READ_DMA status=51 error=40 > LBA=79725056 off-by-111... Are you sure 'smartctl -l error' reports only one error? DES -- Dag-Erling Smørgrav - d...@des.no ___ 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 tool for remapping bad sectors in CURRENT?
Miroslav Lachman <000.f...@quip.cz> writes: > As you can see, there are really two different numbers LBA=79725056 in > messages and LBA = 0x04c0826f = 79725167 in SMART log. I don't know how comfortable you are reading kernel code, but I would suggest looking through the atadisk driver to see why the numbers are different. And if you're comfortable *writing* kernel code, I would suggest implementing WORF in geom_mirror :) DES -- Dag-Erling Smørgrav - d...@des.no ___ 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 tool for remapping bad sectors in CURRENT?
Pieter de Goeje writes: > Dag-Erling Smørgrav writes: > > And if you're comfortable *writing* kernel code, I would suggest > > implementing WORF in geom_mirror :) > I am intrigued, what is this WORF you speak of? Write On Read Failure. It means that if you can't read a sector but you have (or can recreate) a copy of the data that's supposed to be on it, you rewrite that data to force the disk to reallocate the sector. I've done this manually several times (dd'ed a sector from the other disk in a mirror). I believe I even posted the procedure at some point; I'll check my archive. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys]
Michael Butler writes: > This breaks most (if not all) of the QT4-dependent ports for the lack of > a definition of "off64_t". They should not use off64_t. More importantly, they should not rely on zlib to provide it. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys]
Xin LI writes: > Tom Uffner writes: > > Michael Butler writes: > > > This breaks most (if not all) of the QT4-dependent ports for the > > > lack of a definition of "off64_t". > > it also breaks multimedia/mplayer, graphics/ImageMagick, and > > print/ghostscript8 & everything that depends on it. > Just because they used to compile DOES NOT mean they were right. It's > NOT right to define _LARGEFILE64_SOURCE on FreeBSD, see: > > http://www.delorie.com/gnu/docs/glibc/libc_13.html Nor is it correct on Linux. As the above link says, _LARGEFILE64_SOURCE is a hack that was introduced to ease the transition from 32-bit off_t to 64-bit off_t. The correct idiom is to define _FILE_OFFSET_BITS to 64 before including and . http://www.delorie.com/gnu/docs/glibc/libc_13.html That was *fourteen years ago*, almost to the day. There is *no* excuse for using this hack today. *Especially* in software that was written long after that document was published. *Especially* when all you need to do to get it right is add AC_SYS_LARGEFILE to configure.ac and use off_t, struct stat and stat() / lstat() (without the "64" suffix) as if none of this had ever happened. And yes, I *will* keep harping on this until people Get It. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys]
Mark Linimon writes: > Probably 75%+ of the application authors neither know nor care that > their code is being run on anything other than Linux. I think you missed the bit where what they're doing is wrong on Linux, too. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys]
Xin LI writes: > Applications aiming to be portable should not define _LARGEFILE64_SOURCE > at all, on any *BSD platforms. nor on Linux. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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] Rewriting sade(8)
Alexander Leidinger writes: > Please consider using SVN instead. A lot more users will be able to > check out from there. We don't grant non-committers access to the Subversion repo. > It looks like other people had a look at sysinstall, not at sade. As > sysinstall is supposed to be used at installation time, and the intent > for sade was to offer the functionality (or more) of the part of > sysinstall which is useful after installation (and to prevent admins > from using sysinstall after the installation to prevent some unwanted > foot-shooting), I do not think that we need to think about a strong > lock between sysinstall and sade. Yes we do. Otherwise we'll just end up back where we are today, where if you want anything more complicated than a single-disk install you have to drop into the fixit shell and do it manually before running the installation procedure. Anythig that sade can do, we want sysinstall to do as well, and we don't want to implement everything twice. My suggestion is to add a "sysinstall mode" to sade where it operates under certain (minor) constraints and reports what it did in a format that sysinstall can parse, so sysinstall can just fork-exec sade instead of duplicating the code. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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] Rewriting sade(8)
Rui Paulo writes: > Dag-Erling Smørgrav writes: > > Alexander Leidinger writes: > > > Please consider using SVN instead. A lot more users will be able > > > to check out from there. > > We don't grant non-committers access to the Subversion repo. > The SVN repo is available to the public via HTTP. AFAIK, the OP is not a committer, and hence does not have write access. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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] Rewriting sade(8)
Alexander Leidinger writes: > I think this is more complicated than to refactor the interesting part > into a backend with an API which both tools can use. This would also > allow someone to write a GUI program (e.g. for PC-BSD). There have been at least three or four attempts to do this in the past. One of them was even fully funded by the FreeBSD Foundation. They all failed. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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
Alexey Tarasov writes: > 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? I don't quite see how that would work - do you mean gpart should configure a gnop? AFAIK there is no "gnop label", so you can't set up a persistent gnop; you have to set it up manually at boot time every time, and there's a risk that the fs (or other layers higher up) will taste the underlying device instead of the gnop. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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
Alexey Tarasov writes: > I mean that gpart should act like gnop presenting another sector size > to user. I that possible at all? That depends on the underlying partition scheme. My guess is "no". (it all boils down to whether the desired logical sector size can somehow be recorded on-disk) DES -- Dag-Erling Smørgrav - d...@des.no ___ 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] Rewriting sade(8)
Alexander Leidinger writes: > Dag-Erling Smørgrav writes: > > There have been at least three or four attempts to do this in the > > past. One of them was even fully funded by the FreeBSD Foundation. > > They all failed. > I was told a lot of people tried to make the WITH_CTF part working > without the need to use -DWITH_CTF each time at the command line and > failed. Nevertless I did it. So telling something is not possible > because other people tried and failed is ridiculous. It's not ridiculous, it's experience. *Painful* experience over a period of nearly 15 years. > BTW: I do not think you talk about a partition editor, but about the > complete sysinstall. Yes and no. I'm talking about making the user interface pluggable, i.e. run the same program (whether sysinstall or sade) with, say, an ncurses interface on the console and a gtk interface in X. Debian's package system does this, to a certain extent, but only for very simple configuration questions - about the same level of functionality that you get with an HTML form. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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] Rewriting sade(8)
John Baldwin writes:
> Dag-Erling Smørgrav writes:
> > My suggestion is to add a "sysinstall mode" to sade where it
> > operates under certain (minor) constraints and reports what it did
> > in a format that sysinstall can parse, so sysinstall can just
> > fork-exec sade instead of duplicating the code.
> Actually, I would rather have sysinstall just invoke sade to do the
> disk related stuff.
...which is exactly what I said - but in the sysinstall case, you may
want to ask some additional questions ("are you sure you want to proceed
without a swap partition?") or place some additional constraints (such
as "don't allow the user to mount something on top of /mnt or /rescue"),
and sysinstall needs to know the outcome.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
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
Alexey Tarasov writes: > Ok, in case of GPT? :-) I doubt it, but I don't know for sure. > GPT implementation can be the simplest solution to this problem > compared to implementing additional ATA commands to determine if disk > is in Advanced Format. There are two issues: 1) There is already an ATA command to report both physical and logical sector sizes, but the disk lies - it always reports 512/512. 2) The disk may have already been formatted on a system that doesn't support 4k sectors, and may contain unaligned partitions and file systems, which won't be visible if we forcibly and unconditionally use 4k sectors. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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
Alexey Tarasov writes: > Advanced Format disks reports 512, but there is another command in ATA > standard which can tell us if it uses 4k sector. Send me one and I'll look into it :) DES -- Dag-Erling Smørgrav - d...@des.no ___ 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] Rewriting sade(8)
Alexander Leidinger writes: > I did not suggest to run the same program and get different > interfaces. My suggestion was to have a backend-lib and a frontend. > The backend containing the "business-logic", and the frontend being > the presentation layer. What you call the presentation layer is actually 80% of the work. What you call the business logic already exists (libgeom). DES -- Dag-Erling Smørgrav - d...@des.no ___ 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] Rewriting sade(8)
Garrett Cooper writes: > If the user shoots him or herself in the foot, that's their own > problem. That kind of attitude is why people choose Linux over FreeBSD... DES -- Dag-Erling Smørgrav - d...@des.no ___ 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] Rewriting sade(8)
Garrett Cooper writes:
> Dag-Erling Smørgrav writes:
> > Garrett Cooper writes:
> > > Dag-Erling Smørgrav writes:
> > > > [restored relevant context which was removed earlier in the thread]
> > > > ...which is exactly what I said - but in the sysinstall case, you may
> > > > want to ask some additional questions ("are you sure you want to proceed
> > > > without a swap partition?") or place some additional constraints (such
> > > > as "don't allow the user to mount something on top of /mnt or /rescue"),
> > > > and sysinstall needs to know the outcome.
> > > If the user shoots him or herself in the foot, that's their own
> > > problem.
> > That kind of attitude is why people choose Linux over FreeBSD...
> Where do you draw the line though? /media, /libexec, /proc, /sys, etc?
> I think it's better to educate users than build in more complexity to
> the install application.
I draw the line at mounting something - anything - on top of directories
that contain files that are critical to sysinstall's operation. IIRC,
/mnt is where the installation CD is mounted.
In sysinstall mode, sade's role is to 1) make sure that something
sensible is mounted in the location where sysinstall is going to install
the OS, 2) assist the user in making the correct disk, slice, partition
or what-have-you bootable, 3) within reasonable limits, prevent the user
from doing something that will break sysinstall, and 4) optionally allow
the user to prepare additional filesystems that sysinstall doesn't care
about (e.g. /usr/obj), as long as this does not conflict with 3).
I think the easiest way to achieve this is for sysinstall to provide an
empty directory (e.g. /inst) and have sade operate with that directory
as root, so what the user sees is how things will look when the system
reboots after installation; when the user asks sade to create /usr/obj,
sade actually creates /inst/usr/obj.
Last but not least, sade should report what it did to sysinstall -
perhaps in fstab format, since sysinstall needs to populate
(/inst)/etc/fstab anyway.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
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] Rewriting sade(8)
Paul Wootton writes: > But... If this is a fresh install, then you really have not lost > anything if you making a mistake. If sysinstall / sade is run from a > running system and a mistake is made then you could loose your data, > but as you will need to have su-ed up, how does this differ from > typing a wrong command in? Please, please, go have a cup of coffee, then come back and *read what I wrote* instead of just making stuff up. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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
Andriy Gapon writes: > P.S. DES's name looks strange in headers :-) Get a better MUA. MIME quoted-printable has been around for what, 15 years? DES -- Dag-Erling Smørgrav - d...@des.no ___ 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] Rewriting sade(8)
Garrett Cooper writes: > Now you're making a dangerous assumption that /inst isn't being used > by the end-user for any predefined purpose. No, I'm making the entirely reasonable assumption that *during the installation process* sysinstall can mount whatever the hell it wants wherever the hell it wants. Why is this so hard to understand? If the user wants to create an /inst filesystem *during installation* it will be mounted as /inst/inst. If the user runs sade *at a later time* and creates an /inst filesystem, it will be mounted as /inst. > Ok. Or maybe since `we're here' sade needs to be populating > $DESTDIR/etc/fstab, not sysinstall ? At that time (when sysinstall invokes sade) there is no $DESTDIR/etc - sysinstall hasn't yet started extracting the base distribution. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Switchover to CAM ATA?
Freddie Cash writes: > If a lowly user's vote counts for anything, I'd vote for the complete > removal of ataraid support. We have gstripe, gmirror, graid3, graid5, and > zfs (and gvinum for the masochistics). :) We don't need to support any of > the crappy pseudo-raid "hardware" out there. ataraid(4) has served it's > purpose, tiding us over until GEOM RAID facilities were in place. Now it's > time for it to be retired. gstripe can't create a bootable striped set; ataraid can. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Switchover to CAM ATA?
Maxim Sobolev writes: > Richard Tector writes: > > Could I also add that the removal of ataraid would affect those > > users who dual-boot with Windows and rely on the psuedo-raid > > provided by most Intel chipsets to be able to share the same pair of > > disks. > Well, this won't be a problem if we have GEOM classes that can > understand metadata created by the ATA RAID BIOS(es). Most pseudo-raid kit has nifty features like checksum offloading, composite writes etc. which can improve performance considerably. You can't access those from GEOM. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Switchover to CAM ATA?
Alexander Motin writes: > Dag-Erling Smørgrav writes: > > Most pseudo-raid kit has nifty features like checksum offloading, > > composite writes etc. which can improve performance considerably. You > > can't access those from GEOM. > Have you ever seen them documented? ISTR I got the info from sos@ at some point. I have several Promise cards lying around and was working onm RAID5 offloading, but I stopped when ZFS became usable. > Does the need to specifically handle dozens of incompatible > implementations with limited resources worth those (probably not > major) benefits? The details probably vary from controller to controller, but the capabilities are pretty much the same: perform the same write operation to several disks at once, split a write operation across several disks, compute and write parity. IIRC, composite writes are already supported but not used. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Switchover to CAM ATA?
Alexander Motin writes: > I haven't dug really deep into current ataraid(4), but AFAIK it is all > done in software. At least there is no any offloading support on the > controller drivers level. None of ata(4) drivers do anything except > executing one ATA command at a time. Correct. That doesn't mean they *shouldn't* use offloading. Like I said, I started working on checksum offloading for Promise SATA controllers, but ZFS came along and I replaced the controllers because of data corruption issues (which turned out to be either a driver bug or a PCI timing bug which sos@ worked around in the driver, I forget which) > Any URLs? Google "Promise FastTrak SATA RAID" I have two or three of those, including one with on-board SDRAM (but no battery backup) DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Switchover to CAM ATA?
Lev Serebryakov writes: > "Dag-Erling Smørgrav" writes: > > Most pseudo-raid kit has nifty features like checksum offloading, > > composite writes etc. > Why are they called ``PSEUDO-raids'' then? Several reasons - they don't present the array to the OS as a single device, they don't handle failover, etc. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Official request: Please make GNU grep the default
"Sean C. Farley" writes: > This should trim some time off BSD grep. Did you actually test your patch? It makes absolutely no measurable difference. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Official request: Please make GNU grep the default
Dimitry Andric writes: > - Uses plain file descriptors instead of struct FILE, since the > buffering is done manually anyway, and it makes it easier to support > gzip and bzip2. It might be worth a shot adding mmap(2) support as well, i.e. when processing an uncompressed regular file, try to mmap(2) it first, and if that fails, fall back to the plain buffered read(2) method. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Interpreted language(s) in the base
Doug Barton writes: > lua too "flavor of the day," not enough track record of stability, > not enough installed base/proven utility You're wrong. Lua has been around for ages and is especially widely used as a game scripting engine. It is not intended as a standalone language, but as an embeddable scripting engine. We could easily create our own scripting language based on lua with FreeBSD-specific functions, and there would be no fear of interfering with third-party software, because it wouldn't be called lua. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Official request: Please make GNU grep the default
"Sean C. Farley" writes: > Dag-Erling Smørgrav writes: > > Did you actually test your patch? It makes absolutely no measurable > > difference. > Yes, I saw a reduction, I didn't... DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Building world with clang
Dimitry Andric writes:
> Alexander Kabaev writes:
> > Does method 1) work fine with 'make buildenv'? I doubt that. I would
> > strongly suggest we should not lose this feature. I do not like the
> > idea of having to depend on -isystem in CFLAGS in such an environment.
> I have not tested make buildenv with this method, but since ${CC} is
> modified, not ${CFLAGS}, there is a reasonable chance that it might
> work. :)
I'm not a big fan of "reasonable chances" when it comes to the
toolchain.
> Note a similar method is already being using for the build32 stage on
> amd64, where ${CC} has a bunch of flags (including -isystem, -L and -B)
> appended.
No, what is used is a variant of method 1 *on top of* method 2 for a
very specific case. You need "a special version of clang" (method 2)
anyway to support cross-building.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
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: Building world with clang
Dimitry Andric writes: > Dag-Erling Smørgrav writes: > > No, what is used is a variant of method 1 *on top of* method 2 for a > > very specific case. You need "a special version of clang" (method 2) > > anyway to support cross-building. > Eventually, clang should support building objects for all targets from > one executable, but not in the short term, unfortunately... That doesn't matter. You still need two versions of the compiler. If you're cross-building sprac64 on an i386 machine, for instance, you need an i386 version of the compiler that produces sparc64 binaries *and* a sparc64 version that produces sparc64 binaries. The former is used only during the build, the latter is what will be installed on the target. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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
FreeBSD Tinderbox writes: >>>> Kernel build for LINT started on Thu Aug 19 02:51:08 UTC 2010 >>>> 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 >>>> stage 3.2: building everything > [...] > /src/sys/dev/ofw/ofw_standard.c:705: warning: cast to pointer from integer of > different size > /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_release': > /src/sys/dev/ofw/ofw_standard.c:719: warning: cast from pointer to integer of > different size > /src/sys/dev/ofw/ofw_standard.c:724: warning: cast from pointer to integer of > different size > /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_enter': > /src/sys/dev/ofw/ofw_standard.c:742: warning: cast from pointer to integer of > different size > /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_exit': > /src/sys/dev/ofw/ofw_standard.c:760: warning: cast from pointer to integer of > different size > *** Error code 1 > > Stop in /obj/powerpc.powerpc64/src/sys/LINT. Line 705 in ofw_standard.c is return ((void *)args.baseaddr); args.baseaddr is a cell_t, which is defined in : typedef uint32_tcell_t; which I assume is correct for powerpc (32-bits), but probably not for powerpc64. Note that it is defined as uint64_t on sparc64 and sun4v, and in sys/boot as unsigned long int, which is the correct size on both 32-bit and 64-bit machines (assuming I32LP64). DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Interpreted language(s) in the base
Luigi Rizzo writes: > Having sources in some fantastic new language 'fuffa' and no 'fuffa2c' > tool is almost as bad as having no source (in fact, it is like the > joke of supplying source for the GPL'd software in your brand new > LCD tv or appliance. I'd like to know who will ever be able to build > an updated image and upload it to the appliance) Actually, the GPL requires that you provide the source in a buildable condition (even if you only ship patches), and most mid-to-high-end AV equipment these days will load and run (or flash) software from a USB mass storage device or CD / DVD. That's certainly the case for my Sony Bravia TV (http://products.sel.sony.com/opensource/source_bivl.shtml) and my NAD Bluray player (not Linux, AFAIK). Furthermore, the GPLv3 forbids the use of GPLv3 software on devices that can't be flashed by the user (the "TiVo clause"), although the bits that are most commonly used in embedded devices (Linux itself and busybox) are still under GPLv2. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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 ICC (intel compiler) bits from mk
Alexander Leidinger writes: > If someone would get icc 11.x up and runnig as a port (similar to what > we have for outdated icc version in the ports collection), I would > have a look if my contact at Intel is still working there in a > position which allows him to get a commercial license for us. Does that really matter? We're not going to start building releases with icc, are we? DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Official request: Please make GNU grep the default
"M. Warner Losh" writes:
> So making it default turned out well in the end. Sure, there was pain
> involved (but this is current), but making it default exposed the pain
> that would otherwise have gone unnoticed. The big hue and cry, while
> excessive at times, did result in people actually running the
> profiling tools which pointed to the buffering as the number one thing
> to fix.
There is a lesson here: people who are unsatisfied with the performance
of ${TOOL} should profile it before they start a flamefest on -current.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
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: BSD grep performance
Doug Barton writes: > I'm not going to re-state my opinion here except to say it hasn't > changed. Even if the performance were not an issue I think the bugs > mentioned below combined with your 4-day absence should also have been > considerations. However, in regards to this particular case I think > it's pretty obvious that I'm either alone, or in a very non-vocal > group; so c'est la vie. "This is madness!" "Madness? This... is... CURRENT!" DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Official request: Please make GNU grep the default
"V. T. Mueller, Continum" writes: > If you're alluding to Dougs original email, I will strictly disagree. > He found a performance issue which noone had seen or brought up before > and gave feedback to Gabor in a constructive and distinctively polite > manner. It would have been far more "constructive and distinctively polite" to take ten minutes to build and run a profiling version of grep, and include the results in the OP. > I would also second, that changing back the default immediately then > would have been the better choice. No, it would only have ensured that nobody except Gabor used it. > In other words: as long as there are unresolved issues, the default > should be set to GNU grep. This doesn't stop anyone from improving the > BSD grep we're all waiting for. It only does good to those who rely on > using grep - expecting correctness and speed. Based on my 12 years of experience in this project, you are very, very wrong. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Official request: Please make GNU grep the default
"V. T. Mueller, Continum" writes: > Dag-Erling Smørgrav writes: > > Based on my 12 years of experience in this project, you are very, > > very wrong. > An 'argumentation' like the above is simply a killer phrase that ends > every discussion. An 'argumentation' like the above is simply a killer phrase that ends every discussion, especially when it's based on selective quoting. Here's what you left out: > I would also second, that changing back the default immediately then > would have been the better choice. No, it would only have ensured that nobody except Gabor used it. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Official request: Please make GNU grep the default
Gabor Kovesdan writes: > I've just committed a patch with the kind help of Dimitry Andric, > which gives BSD grep a huge performance boost. The performance is now > almost comparable to GNU grep. Not quite, as Doug pointed out. I don't know what benchmark you're using, but I'm using a greatly simplified variant of Doug's: % time sh -c 'for n in $(jot 1000) ; do /usr/obj/usr/src/usr.bin/grep/grep -q "^xfce4-wm" /usr/ports/INDEX-9 ; done' sh -c 13.57s user 7.06s system 99% cpu 20.783 total % time sh -c 'for n in $(jot 1000) ; do /usr/obj/usr/src/gnu/usr.bin/grep/grep -q "^xfce4-wm" /usr/ports/INDEX-9 ; done' sh -c 7.98s user 7.47s system 100% cpu 15.424 total The bottleneck is now in quite an unexpected location: % cumulative self self total time seconds secondscalls ms/call ms/call name 38.8 0.03 0.0312717 0.00 0.00 memchr [5] 35.6 0.07 0.03 395 0.08 0.08 _read [6] 16.4 0.08 0.010 100.00% _mcount [7] 1.7 0.08 0.0012362 0.00 0.00 memset [9] 1.5 0.08 0.000 100.00% .mcount (110) 1.5 0.08 0.000 43.41% re_search_internal [8] 0.8 0.08 0.00 820 0.00 0.00 memcpy [12] 0.6 0.09 0.0037045 0.00 0.00 free [13] 0.6 0.09 0.0012332 0.00 0.01 grep_fgetln [4] 0.6 0.09 0.001 0.4966.27 procfile [3] 0.4 0.09 0.000 100.00% re_string_construct_common [26] 0.3 0.09 0.001 0.25 0.34 _Read_RuneMagi [27] 0.1 0.09 0.00 261 0.00 0.00 arena_avail_comp [39] 0.1 0.09 0.00 155 0.00 0.00 arena_malloc [24] 0.1 0.09 0.00 153 0.00 0.00 arena_bin_malloc_easy [40] 0.1 0.09 0.00 54 0.00 0.00 arena_avail_tree_insert [35] 0.1 0.09 0.005 0.02 0.02 arena_purge [37] 0.1 0.09 0.003 0.04 0.44 setlocale [10] 0.1 0.09 0.001 0.12 0.46 __wrap_setrunelocale [21] 0.1 0.09 0.000 21.76% re_string_destruct [14] 0.1 0.09 0.000 100.00% regexec [38] The culprit seems to be the first memchr() in grep_fgetln(). For some reason, even with -O2, it is not inlined: % echo "disassemble grep_fgetln" | gdb -q -batch -x /dev/stdin /usr/obj/usr/src/usr.bin/grep/grep | grep memchr 0x000000000040291e : callq 0x40176c 0x004029fa : callq 0x40176c DES -- Dag-Erling Smørgrav - d...@des.no ___ 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 ICC (intel compiler) bits from mk
Anton Shterenlikht writes: >> It could matter for ports, I do not know if it matters for parts in >> src. The commercial license is also the only way that we could get icc >> installed on machines in the FreeBSD cluster [...] > If one begins to mention FreeBSD clusters, and moreover FreeBSD HPC, Not "FreeBSD clusters", but "*the* FreeBSD cluster", i.e. the .f.o machines hosted by Y!. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Official request: Please make GNU grep the default
Doug Barton writes: > There are 2 questions, did I do the right thing, and how should people > report problems in general. As for myself, while I have some facility > in C it's not my strong suit. Yes, I could have produced a profiling > version of grep, but it would have taken me a lot more than 10 minutes > because I don't even build the profiled libs on a regular basis. That's fair. I didn't use to do that because it increases build time considerably, but now I do. If you have profiling libraries installed, you can build a profiling version of grep (or any program) like so: % cd /usr/src/usr.bin/grep % make clean % make DEBUG_FLAGS="-pg -g" -DNO_SHARED Do *not" make install, because the result will be dog slow and you don't want to use it in production. Every time you run it, it will leave a file named grep.gmon in your current directory, so: % /usr/obj/usr/src/usr.bin/grep/grep -q "^xfce4-wm" /usr/ports/INDEX-9 % gprof /usr/obj/usr/src/usr.bin/grep/grep grep.gmon | less > More generally however I think that we need to be realistic with what > we expect people to do about reporting problems. This is not about "what we expect people to do" but about "what I expect *you*, an experienced FreeBSD committer, to do" :) DES -- Dag-Erling Smørgrav - d...@des.no ___ 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
Nathan Whitehorn writes: > The problem is that until yesterday, you could not build a powerpc64 > LINT, and so it was trying to build a PPC32 kernel with a 64-bit > toolchain. An actual powerpc64 kernel does not include > ofw_standard.c. This should be fixed now with r211483, so long as the > LINT config is made with TARGET_ARCH set (and is not reused for 32 and > 64-bit builds). There is a seat-belt mechanism I should add soon that > will complain earlier about architecture mismatches like this. Thanks > for your patience. >>> stage 3.2: building everything [...] /src/sys/powerpc/fpu/fpu_emu.c: In function 'fpu_execute': /src/sys/powerpc/fpu/fpu_emu.c:329: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:329: warning: format '%x' expects type 'unsigned int', but argument 5 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:359: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:359: warning: format '%x' expects type 'unsigned int', but argument 5 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:376: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:376: warning: format '%x' expects type 'unsigned int', but argument 4 has type 'vm_offset_t' /src/sys/powerpc/fpu/fpu_emu.c:778: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'register_t' *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. :) DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Official request: Please make GNU grep the default
Adrian Chadd writes: > I've just looked at grep_fgetln(). Surely memchr() isn't required there. Of course it is, how else are you going to locate the '\n'? OTOH, I'm not sure grep_fgetln() is needed at all. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Official request: Please make GNU grep the default
Adrian Chadd writes: > Have you tried this in pmc? No. I can't figure out how to use pmcstat, but I did find a bug in it: if you specify an output file with -o, but the command line is otherwise incomplete or incorrect, it will print usage information to the output file instead of stderr. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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
Nathan Whitehorn writes: > Next up: tinderbox needs to build GENERIC64, not GENERIC, on > powerpc64. make buildkernel is programmed to do the right thing is you > don't pass a KERNCONF, but tinderbox apparently passes GENERIC > explicitly. This one's in your court! There is no way to fix this with the current tinderbox code. MHO is that the entire powerpc64 thing is very poorly thought out. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Official request: Please make GNU grep the default
Alan Cox writes: > Here is what actually puzzles me about these results. With > traditional I/O, even after the optimizations to bsdgrep, the system > time for gnugrep is still less than half that of the optimized > bsdgrep. I haven't looked at the changes, but I would have thought > the system time for gnugrep and bsdgrep would be almost the same. Two reasons: 1) BSD grep does tons of unnecessary memory-to-memory copy operations in grep_fgetln(). 2) GNU grep has its own highly optimized regex code. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Interpreted language(s) in the base
"C. P. Ghost" writes: > After all LISP-like syntax is *still* more common and prevalent > than Lua, e.g. in Elisp, guile, esh, scsh and a lot of other apps > that use it as a small language. So we can expect more users > to be at least partially familiar with it. And there *are* lightweight > MIT- or BSD-licensed scheme interpreters out there too: Considering that the majority of people who might be interested in using this know *neither* Lisp *nor* Lua, my vote is for Lua, because people who are familiar with neither will be more open to learning Lua, which resembles other languages they already know, than Lisp, which doesn't. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Interpreted language(s) in the base
Gabor PALI writes: > Sorry for chiming in, just a quick idea. If you find the "get a > high-level language that compiled to C" idea good, I don't think it's a good idea, and I don't understand why this thread seems stuck in that rut. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Official request: Please make GNU grep the default
"b. f." writes: > At r211506, 'grep -wq' does not seem to work properly (in the very > least, it is not the same as with GNU grep), "Does not seem to work properly" is not a very useful statement. The least you could do is provide an example. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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
Nathan Whitehorn writes: > I'm the first to admit that many of the config tricks involved in this > port, and GENERIC64, are ugly hacks, largely because config(8) was not > designed with such things in mind. It's not just "config tricks and ugly hacks", it also violates the assumption that target names are unique. > To address the immediate problem, I think the best solution is to use > the -m option to config to reject kernel configs for different > architectures, I'm not sure I understand what you mean (or rather, how it would help the tinderbox). What *would* help would be an easy way to determine, *before* trying to build it, whether a specific kernel config is appropriate for a specific target. Can you think of an easier way to do this than to scan the config for the "machine" line? DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Interpreted language(s) in the base
Gabor PALI writes: > Dag-Erling Smørgrav writes: > > Gabor PALI writes: > > > Sorry for chiming in, just a quick idea. If you find the "get a > > > high-level language that compiled to C" idea good, > > I don't think it's a good idea > Could you be more specific on your concerns? I am just curious. If we want compiled code, we already have C and C++. What we need is an interpreted language with good libraries so people can write scripts and one-liners without having to jump through too many hoops and worry about quoting. The result may not be as fast as a compiled program, but it will be much faster than a shell script and take less time to write than either C or shell. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: CD/DVD ejecting after sysinstall
Randi Harper writes: > Rui Paulo writes: > > You are correct. We should not be ejecting the CD without a > > prompt. If the commit is reverted, it should be explicitly noted in > > the code so that we don't do this mistake again. > That's a judgement call, not an absolute. I think what we are doing > isn't a problem for 99.999% of use cases. On the rare occasions where I use sysinstall, I usually find that prompt annoying... but I almost broke a CD drive once by ejecting the tray with the enclosure's dust cover half closed. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: meory file system
gahn writes: > I am running 8.1. under /dev, I don't see /dev/md0, /dev/md0 won't show up until you actually run mdconfig. > so i am trying to add following lines in kernel file and got error > messages: > > options MFS #Memory Filesystem The correct line is "device md", but mdconfig(8) will automatically load the module, so you don't need it. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: why GNU grep is fast
Mike Haertel writes: > GNU grep uses the well-known Boyer-Moore algorithm, which looks > first for the final letter of the target string, and uses a lookup > table to tell it how far ahead it can skip in the input whenever > it finds a non-matching character. Boyer-Moore is for fixed search strings. I don't see how that optimization can work with a regexp search unless the regexp is so simple that you break it down into a small number of cases with known length and final character. > GNU grep uses raw Unix input system calls and avoids copying data > after reading it. Yes, that was the first thing we looked at (and fixed) in BSD grep. > Moreover, GNU grep AVOIDS BREAKING THE INPUT INTO LINES. Looking > for newlines would slow grep down by a factor of several times, > because to find the newlines it would have to look at every byte! Amen. The current bottleneck in BSD grep is the memchr() that looks for '\n' in the input buffer. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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
Nathan Whitehorn writes:
> Dag-Erling Smørgrav writes:
> > I'm not sure I understand what you mean (or rather, how it would
> > help the tinderbox). What *would* help would be an easy way to
> > determine, *before* trying to build it, whether a specific kernel
> > config is appropriate for a specific target. Can you think of an
> > easier way to do this than to scan the config for the "machine"
> > line?
> That's exactly what I proposed. You use config, before trying the
> build, to look up the machine specification for the config file. I
> sent you a 5 line patch to tinderbox.pl that does this by private
> email.
Here's a solution that works regadless of config(8) version, though I'm
not sure it qualifies as either easy or clean:
Index: tinderbox.pl
===
RCS file: /home/projcvs/projects/tinderbox/tinderbox.pl,v
retrieving revision 1.68
diff -u -r1.68 tinderbox.pl
--- tinderbox.pl25 Aug 2009 17:28:14 - 1.68
+++ tinderbox.pl22 Aug 2010 12:08:46 -
@@ -722,10 +722,29 @@
}
# Build additional kernels
+ kernel:
foreach my $kernel (sort(keys(%kernels))) {
if (! -f "$srcdir/sys/$machine/conf/$kernel") {
warning("no kernel config for $kernel");
- next;
+ next kernel;
+ }
+ # Hack: check that the config is appropriate for this target.
+ # If no "machine" declaration is present, assume that it is.
+ local *KERNCONF;
+ if (open(KERNCONF, "<", "$srcdir/sys/$machine/conf/$kernel")) {
+ while () {
+ next unless m/^machine\s+(\w+(?:\s+\w+)?)\s*(?:\#.*)?$/;
+ if ($1 !~ m/^\Q$machine\E(\s+\Q$arch\E)?$/) {
+ warning("skipping $kernel");
+ close(KERNCONF);
+ next kernel;
+ }
+ last;
+ }
+ close(KERNCONF);
+ } else {
+ warning("$kernel: $!");
+ next kernel;
}
logstage("building $kernel kernel");
logenv();
It will break if the "machine" declaration ever moves into an included
file, since it does not follow include statements, but it will do for
now.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
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: Interpreted language(s) in the base
Matthias Andree writes: > Looks a bit like a swing. First we remove Perl from the base system > (years ago) and move to sed/awk, now we discuss using a scripting > language in the base system... Read the discussion from the beginning. We are discussing introducing a domain-specific scripting language, not a general-purpose one. BTW, most of the Perl scripts we had were rewritten in C, not sed / awk. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: why GNU grep is fast
"Sean C. Farley" writes: > Some algorithms: > 1. http://en.wikipedia.org/wiki/Aho-Corasick_string_matching_algorithm Aho-Corasick is not really a search algorithm, but an algorithm for constructing a table-driven finite state machine that will match either of the search strings you fed it. I believe it is less efficient than Boyer-Moore for small numbers of search terms, since it scans the entire input. I don't see the point in using it in grep, because grep already has an algorithm for constructing finite state machines: regcomp(3). > 2. http://en.wikipedia.org/wiki/Rabin-Karp_string_search_algorithm It doesn't seem to compare favorably to the far older Aho-Corasick. It uses slightly less memory, but memory is usually not an issue with grep. > 4. GLIMPSE: http://webglimpse.net/pubs/TR94-17.pdf (Boyer-Moore > variant) Glimpse is a POS... and not really comparable, because grep is designed to search for a single search string in multiple texts, while glimpse is designed to search a large amount of text over and over with different search strings. I believe it uses suffix tables to construct its index, and Boyer-Moore only to locate specific matches, since the index lists only files, not exact positions. For anything other than fixed strings, it reverts to agrep, but I assume (I haven't looked at the code) that if the regexp has one or more fixed components, it uses those to narrow the search space before running agrep. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: why GNU grep is fast
Mike Haertel writes: > For example if your regex is /foo.*bar/, the initial Boyer-Moore search > is (probably) searching for foo. > > If the initial search succeeds, GNU grep isolates the containing line, > and then runs the full regex matcher on that line to make sure. You don't really need to "isolate the containing line" unless you have an actual match, do you? There are two cases: 1) The regexp does not use any character classes, including /./, so the FSA will stop if it hits EOL before it reaches an accepting state. 2) The regexp uses character classes, and you rewrite them to exclude \n: /[^bar]/ becomes /[^bar\n]/, /./ becomes /[^\n]/, etc., and the FSA will stop if it hits EOL before it reaches an accepting state. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: why GNU grep is fast
"Sean C. Farley" writes: > Dag-Erling Smørgrav writes: > > Aho-Corasick is not really a search algorithm, but an algorithm for > > constructing a table-driven finite state machine that will match > > either of the search strings you fed it. I believe it is less > > efficient than Boyer-Moore for small numbers of search terms, since > > it scans the entire input. I don't see the point in using it in > > grep, because grep already has an algorithm for constructing finite > > state machines: regcomp(3). > especially those that could be useful for fgrep functionality Not entirely sure what you mean by that, but in most cases, I think Boyer-Moore is a better fit for fgrep. For large numbers of search terms, I might use Aho-Corasick... if it weren't for the fact that, as mentioned, grep already has a regexp engine, which is a superset of Aho-Corasick. It might be a tad slower at building the FSA, because it's more general, and the FSA might occupy a tad more memory, but the complexity is *exactly* the same, and adding Aho-Corasick just for fgrep is, for lack of a better word, pedantry. For all you know, the increased code size could very well offset whatever performance advantage Aho-Corasick might offer. > Glimpse may be a POS; I have not used it personally. I only noted its > algorithm for possible use within fgrep. Apples and oranges. The problem glimpse tries to solve (fixed corpus, variable search terms) is precisely the opposite of the one fgrep tries to solve (fixed search terms, variable corpus). Glimpse does include grep-like functionality, but in the form of agrep, which is designed for approximate matching. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: why GNU grep is fast
Mike Haertel writes: > Dag-Erling Smørgrav writes: > > You don't really need to "isolate the containing line" unless you have > > an actual match, do you? > Theoretically no. However, suppose the pattern was /foo.*blah/. > The Boyer-Moore search will be for "blah", since that's the longest > fixed substring. But verifying a match for the full regexp either > requires a regexp matcher with the feature "start here, at THIS point > in the middle of the RE and THAT point in the middle of the buffer, > and match backwards and forwards", or else running a more standard > RE matcher starting from the beginning of the line. Stupidly enough, I only considered the case where the fixed search string is at the end of the regexp :) For the general case, you'd have to either build a second FSA that mirrors the first, or design your engine and data structures in such a way that the FSA can be traversed in either direction. Then you note which states correspond to the beginning and end of the fixed substring, and run the FSA forward from the end and backward from the beginning. That could prove advantageous when the input consists of very long lines and the frequency of partial matches is relatively high; large files with very long lines are very common in bioinformatics. > As you mentioned, you can avoid searching forwards for the next > newline if your RE matcher supports using newline as an exit marker. Umm, I don't understand why it needs to support using *anything* as an exit marker. The newline character will simply not match any of the transitions from whichever state the FSA is currently in, and neither will the null character. The only bit that needs to know about them is the bit that handles end-of-line and end-of-word anchors. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Official request: Please make GNU grep the default
"b. f." writes: > Dag-Erling Smørgrav writes: > > "Does not seem to work properly" is not a very useful statement. The > > least you could do is provide an example. > I did provide an example, later in the same sentence that you quoted. I forgot to answer this part. By example, I mean an actual grep command line and sample input that demonstrates the problem, the smaller the better: % echo elisp lisp | grep -w lisp && echo good || echo bad elisp lisp good % echo elisp lisp | grep -wq lisp && echo good || echo bad bad No idea what causes it, but a quick grep (hah!) for qflag turns up the following horror: /* Find out the correct return value according to the results and the command line option. */ exit(c ? (notfound ? (qflag ? 0 : 2) : 0) : (notfound ? 2 : 1)); which shows that -q *does* affect the exit code, but my brain refuses to try to understand that code. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Official request: Please make GNU grep the default
Dag-Erling Smørgrav writes: > No idea what causes it, but a quick grep (hah!) for qflag turns up the > following horror: > > /* Find out the correct return value according to the >results and the command line option. */ > exit(c ? (notfound ? (qflag ? 0 : 2) : 0) : (notfound ? 2 : 1)); > > which shows that -q *does* affect the exit code, but my brain refuses to > try to understand that code. My brain is in need of a break from $REALJOB. POSIX says EXIT STATUS The following exit values shall be returned: 0 One or more lines were selected. 1 No lines were selected. >1 An error occurred. CONSEQUENCES OF ERRORS If the -q option is specified, the exit status shall be zero if an input line is selected, even if an error was detected. Otherwise, default actions shall be performed. I suppose c is supposed to indicate, in some manner, whether an error occurred, but it's hard to tell; the code seems almost deliberately obfuscated. The name gives no clue whatsoever as to its meaning. It is incremented like a counter, but tested like a boolean. Its value is derived from the value returned by procfile(), but that value is also named "c", and is derived from values returned by other functions which I could not be bothered to track down. In any case - c notfoundqflag result truetruetrue0 truetruefalse 2 truefalse true0 truefalse false 0 false truetrue2 false truefalse 2 false false true1 false false false 1 By this point, my brain is tied into the shape of a pretzel, but it looks like c might actually be a count of matching lines and notfound might be an error flag. I give it -10 for calling the count "c" instead of "count" or "matches" (I'm being generous because "c" is the first letter of "count"), another -10 for testing it as a boolean instead of comparing it to 0, -1,000 for calling the error flag "notfound", and -1,000,000 for writing code so convoluted that, even with the source code in front of me, I had to reverse-engineer it to figure out what it does. I think that adds up to -1,001,020. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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 i386/pc98
Doug Barton writes:
> As far as I can tell the current state of the code builds just fine,
> so I'm wondering what the current problem with the tinderbox is.
No weasel words, please.
The tinderbox is complaining about these function definitions:
static void
pids_init()
{
/* ... */
}
static int
pids_empty()
{
/* ... */
}
static int
pids_full()
{
/* ... */
}
These are real errors which were introduced in r215615 and fixed in
r215642 with a highly misleading log message.
See for yourself:
d...@ds4 /usr/src/usr.bin/xargs% uname -a
FreeBSD ds4.des.no 9.0-CURRENT FreeBSD 9.0-CURRENT #63 r215049M: Wed Nov 10
11:44:38 CET 2010 d...@ds4.des.no:/usr/obj/usr/src/sys/ds4 amd64
d...@ds4 /usr/src/usr.bin/xargs% svn up -r215615
Uxargs.c
Updated to revision 215615.
d...@ds4 /usr/src/usr.bin/xargs% make
cc -O2 -pipe -march=native -g -std=gnu99 -fstack-protector -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
/usr/src/usr.bin/xargs/xargs.c
cc1: warnings being treated as errors
/usr/src/usr.bin/xargs/xargs.c: In function 'pids_init':
/usr/src/usr.bin/xargs/xargs.c:629: warning: old-style function definition
/usr/src/usr.bin/xargs/xargs.c: In function 'pids_empty':
/usr/src/usr.bin/xargs/xargs.c:641: warning: old-style function definition
/usr/src/usr.bin/xargs/xargs.c: In function 'pids_full':
/usr/src/usr.bin/xargs/xargs.c:647: warning: old-style function definition
/usr/src/usr.bin/xargs/xargs.c: In function 'findfreeslot':
/usr/src/usr.bin/xargs/xargs.c:676: warning: old-style function definition
*** Error code 1
Stop in /usr/src/usr.bin/xargs.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [-CURRENT tinderbox] failure on i386/i386
Peter Wemm <[EMAIL PROTECTED]> writes: > Tinderbox wrote: > > gzip -cn > > /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/nls/catgets.3 > > > catgets.3.gz > > Segmentation fault (core dumped) > > *** Error code 139 > These false alarms are wearing a bit thin. Is there a problem with the > tinderbox build machine perhaps? No, the failures are too systematic for that. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on i386/i386
Peter Wemm <[EMAIL PROTECTED]> writes: > Hmm. I thought it was gzip that was dying. Looks like its make instead, and > is rather consistent. "told you so" > So, who has been messing with make(1) lately? I believe that the problem is in the kernel, not in make(1); it just happens to be triggered by make(1) because it is a big (if not the biggest) vfork(2) consumer. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Does linux-sun-jdk_1.4.2 work?
Adam <[EMAIL PROTECTED]> writes: > Perhaps you should try working with Java 1.4.x on FreeBSD before you > assume something about me that's highly inaccurate. I think you'll find > very quickly that it doesn't work nicely unless the process is running > as root. I use it daily and have never had any trouble (except for the broken Xalan in 1.4.1). DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [current tinderbox] failure on sparc64/sparc64
Tinderbox <[EMAIL PROTECTED]> writes: > TB --- mkdir /home/des/tinderbox > TB --- mkdir /home/des/tinderbox/CURRENT > TB --- mkdir /home/des/tinderbox/CURRENT/sparc64 > TB --- mkdir /home/des/tinderbox/CURRENT/sparc64/sparc64 Sorry about that, I was a bit too hasty moving some directories around. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [current tinderbox] failure on i386/i386
Scott Long <[EMAIL PROTECTED]> writes: > Anyone know what is up with this? I'm not getting it on my LINT builds. revision 1.41 date: 2003/08/01 17:00:49; author: obrien; state: Exp; lines: +1 -1 Fix kernel build -- 'c' was the unused var, not 'lines'. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [current tinderbox] failure on amd64/amd64
Tinderbox <[EMAIL PROTECTED]> writes: > TB --- mkdir /home/des/tinderbox/CURRENT Disk failure on the tinderbox machine. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: buildworld broken after installworld
Ruslan Ermilov <[EMAIL PROTECTED]> writes: > > For example, this result is right and not the bug (but wrong tr usage): > > > > env LANG=de_DE.ISO8859-1 tr '[a-z]' '[A-Z]' > > vi_zero > > WI_]ERO > Clearly this is a useless construct then. The correct construct is tr '[:lower:]' '[:upper:]' DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: warnpassword and warnexpire in 5.1 login.conf
David Schultz <[EMAIL PROTECTED]> writes: > On Tue, Aug 05, 2003, Mats Larsson wrote: >> And the following varning when password is old: >> Aug 5 12:27:38 marvin sshd[55386]: error: PAM: OK >> Aug 5 12:27:40 marvin sshd[55390]: fatal: PAM: chauthtok not supprted with >> privsep >> >> Is there perhaps a better PAM way of doing this things now?? > > Hmm... Apparently you can't change an expired password with a > privilege-separated OpenSSH. I don't know whether that can be > fixed, but perhaps des@ has some insight. It can be done, but not without cheating. You have to have the PAM support code do chauthtok as part of the authentication sequence. I've been meaning to do it for a while but haven't gotten around to it yet. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [current tinderbox] failure on alpha/alpha
Andrew Gallatin <[EMAIL PROTECTED]> writes: > > cc1: error: invalid option `tune=ev5' > > cc1: error: invalid option `ieee' > > cc1: error: bad value (ev4) for -mcpu= switch > I assume that this is a crossbuild problem? No, the filesystem it was running on got yanked away in the middle of the run. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [current tinderbox] failure on i386/i386
Tinderbox <[EMAIL PROTECTED]> writes: > [nothing] The tinderbox is failing to start because it tries to acquire a lock file in the sandbox, which is currently on an NFS partition. I've therefore disabled it while John is working on getting more local disk space online for the tinderbox to use. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: config(8) KERNEL setting
John Birrell <[EMAIL PROTECTED]> writes:
> It would make more sense to me if kern.pre.mk contained this:
>
> KERNEL?= kernel
> KERNEL_KO?= ${KERNEL}
> KODIR?= /boot/${KERNEL}
>
> Comments?
I have
Index: kern.pre.mk
===
RCS file: /home/ncvs/src/sys/conf/kern.pre.mk,v
retrieving revision 1.34
diff -u -r1.34 kern.pre.mk
--- kern.pre.mk 22 Aug 2003 15:41:44 - 1.34
+++ kern.pre.mk 29 Aug 2003 21:06:02 -
@@ -9,7 +9,8 @@
# Can be overridden by makeoptions or /etc/make.conf
KERNEL_KO?=kernel
KERNEL?= kernel
-KODIR?=/boot/${KERNEL}
+KODIR?=/boot/${KERN_IDENT}
+BOOTKODIR?=/boot/${KERNEL}
M= ${MACHINE_ARCH}
and in /boot/loader.conf:
kernel="dwp_smp"
#kernel="dwp_up"
For old times' sake, I also have /boot/kernel as a symlink to
/boot/dwp_smp.
I used to have a more extensive patch which created that symlink at
kernel install time so you wouldn't need to modify loader.conf, and
the system would boot whichever kernel you installed last. I removed
that part because I couldn't be bothered to make it work correctly
with all combinations of make install / make reinstall and
pre-existing /boot/kernel directory or symlink.
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Entropy harvesting: interrupts ethernet point_to_point
"Putinas" <[EMAIL PROTECTED]> writes: > on the recent src with custom compiled kernel ( generic minus some stuff > what I don't need ) with firewall compiled in kernel , system infinitely > hangs on boot unless I press ctrl-c at this point: > Entropy harvesting: interrupts ethernet point_to_point > Same things happens on two different computers with nearly similar custom > kernel configuration > Could you tell me, what's causing the problem ? Try adding 'set -x' at the top of /etc/rc (not before the #!/bin/sh line, though), and you should see what command is executed before the script hangs. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
weird text size
[EMAIL PROTECTED] /home/des# ps -opid,vsize,tsiz,command -p$$ PID VSZ TSIZ COMMAND 4712 23804 zsh How can the text size for zsh be only 4 kB? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI problems on MSI K7D
Nate Lawson <[EMAIL PROTECTED]> writes:
> Please report the dmesg from boot -v as that should help figure out why
> pci_cfgregopen() fails.
Full log attached, both with and without ACPI.
> Also, I think the following should be "\_S3":
>Name (\SS3, Package (0x04)
That shouldn't have any impact on my problem though, should it?
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
Console: serial port
BIOS drive A: is disk0
BIOS drive C: is disk1
BIOS 640kB/523200kB available memory
FreeBSD/i386 bootstrap loader, Revision 1.1
([EMAIL PROTECTED], Mon Sep 1 18:48:59 CEST 2003)
Loading /boot/defaults/loader.conf
/boot/kernel/kernel text=0x1eaadc data=0x22608+0x44e34 syms=[0x4+0x2cfa0+0x4+0x372f6]
/boot/kernel/snd_ich.ko text=0x31e4 data=0x284 syms=[0x4+0x960+0x4+0x964]
loading required module 'snd_pcm'
/boot/kernel/snd_pcm.ko text=0x1412c data=0x24d8+0x1124 syms=[0x4+0x2a20+0x4+0x2e0d]
/boot/kernel/usb.ko text=0x1fad0 data=0xc4c+0x168 syms=[0x4+0x2c70+0x4+0x33ce]
/boot/kernel/ums.ko text=0x22e0 data=0x168+0x4 syms=[0x4+0x5f0+0x4+0x52f]
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel] in 3 seconds...
Type '?' for a list of commands, 'help' for more detailed help.
OK boot -v
/boot/kernel/acpi.ko text=0x3aa2c data=0x170c+0xec0 syms=[0x4+0x5bf0+0x4+0x7a42]
SMAP type=01 base= len=000a
SMAP type=02 base=000f len=0001
SMAP type=02 base=fec0 len=0140
SMAP type=01 base=0010 len=1fef
SMAP type=03 base=1fff3000 len=d000
SMAP type=04 base=1fff len=3000
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-CURRENT #9: Mon Sep 1 19:06:40 CEST 2003
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/meali
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0453000.
Preloaded elf module "/boot/kernel/snd_ich.ko" at 0xc04531d8.
Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc0453284.
Preloaded elf module "/boot/kernel/usb.ko" at 0xc0453330.
Preloaded elf module "/boot/kernel/ums.ko" at 0xc04533d8.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0453480.
Calibrating clock(s) ... i8254 clock: 1193232 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter "i8254" frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 1363433775 Hz
CPU: AMD Athlon(tm) MP 1500+ (1363.43-MHz 686-class CPU)
Origin = "AuthenticAMD" Id = 0x681 Stepping = 1
Features=0x383fbff
AMD Features=0xc048
Data TLB: 32 entries, fully associative
Instruction TLB: 16 entries, fully associative
L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative
L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative
L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative
real memory = 536805376 (511 MB)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x0047d000 - 0x1f6c9fff, 522506240 bytes (127565 pages)
avail memory = 516714496 (492 MB)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 -> irq 0
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): apic id: 0, version: 0x00040010, at 0xfee0
cpu1 (AP): apic id: 1, version: 0x00040010, at 0xfee0
io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0
bios32: Found BIOS32 Service Directory header at 0xc00fac90
bios32: Entry = 0xfb100 (c00fb100) Rev = 0 Len = 1
pcibios: PCI BIOS entry at 0xf+0xb130
pnpbios: Found PnP BIOS data at 0xc00fbb30
pnpbios: Entry = f:bb60 Rev = 1.0
Other BIOS signatures found:
null:
mem:
Pentium Pro MTRR support enabled
random:
SMP: CPU0 bsp_apic_configure():
lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff
npx0: on motherboard
npx0: INT 16 interface
acpi0: on motherboard
pci_open(1):mode 1 addr port (0x0cf8) is 0x80ff003c
pci_open(2):mode 2 enable port (0x0cf8) is 0xff
panic: AcpiOsDerivePciId unable to initialize pci bus
cpuid = 0; lapic.id =
Debugger("panic")
Stopped at Debugger+0x4e: xchgl %ebx,in_Debugger.0
db> where
Debugger(c02d384b,0,c0441336,c04757c4,100) at Debugger+0x4e
panic(c0441336,c042c47c,c400e940,c043db4a,1) at panic+0x151
AcpiOsDerivePciId(c3f60b40,c3f60940,c0475804,168,0) at AcpiOsDerivePciId+0x2d
AcpiEvPciConfigRegionSetup(c3fa6280,0,0,c047585c,c4004680) at
AcpiEvPciConfigRegionSetup+0x224
AcpiEvAddressSpaceDispatch(c3fa6280,0,56,0,8) at AcpiEvAddressSpaceDispatch+0x86
AcpiExAccessRegion(c400e780,0,c047590c,0,c401ae00) at AcpiExAccessRegion+0x70
AcpiExFieldDatumIo(c400e780,0,c047590c,0,14f) at AcpiE
Re: ufs related panic with latest current
Tomi Vainio - Sun Finland <[EMAIL PROTECTED]> writes: > First maxusers was 0 then when changed it to 8. That's a regression. Keep it at 0. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ufs related panic with latest current
Tomi Vainio - Sun Finland <[EMAIL PROTECTED]> writes: > Dag-Erling Smørgrav writes: > > Tomi Vainio - Sun Finland <[EMAIL PROTECTED]> writes: > > > First maxusers was 0 then when changed it to 8. > > That's a regression. Keep it at 0. > I understood that there is a bug on new kmem allocator and this was an > attempt to reduce kmem allocations but it didn't help. Do you know if > this is going to fixed somehow or should people just install more > memory to get system stay up? Well, reducing maxusers isn't going to help much as it only controls a small part of kernel memory, and setting it too low may render the system unusable. The backtrace you showed seems to indicate that the panic happened somewhere in the softupdates code, but IIRC that code has a fairly conservative built-in limit on memory consumption and degrades gracefully when it hits that limit. It's likely that something else gobbled up all available kernel memory, and the mallloc() call from softupdates was simply the straw that broke the camel's back. If you have a serial console hooked up, you could try running while :; do vmstat -m ; sleep 1 ; done on the serial console while doing whatever it is you do that causes the problem. This will tell you how much kernel memory was in use at the time of the panic and what it was used for. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ufs related panic with latest current
Tomi Vainio - Sun Finland <[EMAIL PROTECTED]> writes: > Second trace didn't have anything to do with fs only fork system calls > there so your expanation sounds reasonable. We probably don't see this > problem again because system now has enough memory (256M). It would be really useful to know where the fault lies. We might even (God forbid!) figure out a way to fix it. You can easily force the system to boot with less than the full amount of memory by setting hw.physmem to e.g. "64m" in /boot/loader.conf or at the loader prompt. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ufs related panic with latest current
Tomi Vainio - Sun Finland <[EMAIL PROTECTED]> writes: > If you could just give instructions what you wanna get when system > panics I might be able to persuade the other that we should crash our > system once more. I already have. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAng - delay probing for non-existent drive
Bryan Liesner <[EMAIL PROTECTED]> writes: > The last change to ata-lowlevel (rev 1.11) causes a 10-15 second delay > probing for a drive that's not there: [...] Same symptoms here... DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Release Engineering Status Report
David Rhodus <[EMAIL PROTECTED]> writes: > Right, say if still the OpenSSH did or still comes out to be > real. Ops, now thats right, we don't have 3.6.1 in STABLE, why ? It > was released on April 1, does that not give one enough time to merge > this in ? Is there a specific problem with OpenSSH 3.5 which requires an update to 3.6.1? Or do you just want me to update it to make the numbers look pretty on your screen? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Release Engineering Status Report
"Mike Jakubik" <[EMAIL PROTECTED]> writes: > > Is there a specific problem with OpenSSH 3.5 which requires an update > > to 3.6.1? Or do you just want me to update it to make the numbers > > look pretty on your screen? > Apparently, yes. No. 3.6.1 has the same bug, and 3.7 isn't out yet. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Release Engineering Status Report
David Rhodus <[EMAIL PROTECTED]> writes: > On Tuesday, September 16, 2003, at 11:54 AM, Dag-Erling Smørgrav wrote: > > Is there a specific problem with OpenSSH 3.5 which requires an update > > to 3.6.1? Or do you just want me to update it to make the numbers > > look pretty on your screen? > Umm, yeah, so after today are we going to get a new import into RELENG_4 > before 4.9 is pushed out the door ? No, OpenSSH 3.7 will not be ready in time for 4.9. Both -CURRENT and -STABLE have already been patched, BTW, so you needn't worry. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAng hangs with kernel from september 15
Soren Schmidt <[EMAIL PROTECTED]> writes: > Well, the ATA driver has just grown more standard compliant :) > You *must* hang around for 31secs to wait for slow devices to come ready, > according to the ATA specs. Now I've gone to great length before to > get around this by using clever heuristics, and I'm getting there again, > but there are *so* many crappy devices out there that it takes time > to accomodate them all. Is there any way you can postpone the device initialization so you can do them in paralell? Or make the length of the wait configurable, like SCSI_DELAY? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Release Engineering Status Report
Jeremy Messenger <[EMAIL PROTECTED]> writes: > On Wed, 17 Sep 2003 10:57:58 +0200, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: > > No. 3.6.1 has the same bug, and 3.7 isn't out yet. > http://www.mindrot.org/pipermail/openssh-unix-announce/2003-September/64.html We use OpenSSH-portable, which lags a little behind. 3.7.1p1 seems to have been released late last evening, but it hasn't hit the mirrors yet. In any case, 3.7.1p1 will not hit -STABLE until it has spent at least a month in -CURRENT. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [current tinderbox] failure on alpha/alpha
Scott Long <[EMAIL PROTECTED]> writes: > Sam is pretty sure that he already fixed this. Is it possible that the > tinderbox machine is no longer getting cvs updates? It would seem so. Revision 1.69 of src/sys/net/bridge.c (which fixes this particular problem) is not in the repo on the RTP cluster. John, is something wrong with cvsup on the RTP cluster? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [current tinderbox] failure on ia64/ia64
Tinderbox <[EMAIL PROTECTED]> writes: > /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/net/bridge.c: In function > `bridge_in': > /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/net/bridge.c:857: warning: > cast from pointer to integer of different size > *** Error code 1 Please ignore. It seems the RTP cluster's CVS repo is no longer being updated; I've disabled the tinderbox until this is resolved. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: more panics from current (partII)
Tomi Vainio - Sun Finland <[EMAIL PROTECTED]> writes: > After adding more disks to this system it dies continously. Last two > traces look quite the same. > > Tomppa > > ---clipclip--- > login: kernel trap 19 with interrupts disabled > NMI ... going to debugger An NMI almost certainly indicates a hardware failure. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /bin/sh terminated abnormally
Kris Kennaway <[EMAIL PROTECTED]> writes: > Yes, since you have run installworld you have now installed a 5.x > /bin/sh binary, which cannot run on the 4.x kernel you are running. He *hasn't* run installworld; installworld would have installed the new loader. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [releng_5_1 tinderbox] failure on sparc64/sparc64
Tinderbox <[EMAIL PROTECTED]> writes: > [nothing] argh! /me fix DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
