Re: Formatting a 4k disk on FreeBSD with ext2
Am 08.05.2017 um 17:42 schrieb HSR Hackspace: > Hi folks; > > I'm trying to format a 300 GB partition on x86_64 box running running > BSD 10.1 with HW RAID configuration. All my attempt so far have > failed. Below are the logs for same. > > Logs: > > 1. pod1208-wsa07:rtestuser 106] ./mkfs.ext3 /dev/da0p7 > mke2fs 1.43.4 (31-Jan-2017) > Warning: could not erase sector 2: Invalid argument-> Please show the output of $ env LANG= LANGUAGE= LC_ALL=C mkfs.ext3 -V It should print 1.43.4 for the program _and the library_ (the latter isn't shown above). Then, please run mkfs.ext3 under truss, or under ktrace, and upload the truss or kdump log somewhere and post the URL. Do not mail the log, it's gonna be too big. "Invalid argument" aka EINVAL looks like misaligned access. Now, diskinfo provided the right sectorsize (4096), which it - as of FreeBSD 10.3 - obtains with ioctl(fd, DIOCGSECTORSIZE, ), where sectorsize is a u_int, and unsigned int. Which RAID device is it, what's its structure? ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: portupgrade(1) | portmaster(8) -- which is more effective for large upgrade?
Am 26.06.2013 18:42, schrieb Chris H: Greetings, I haven't upgraded my tree(s) for awhile. My last attempt to rebuild after an updating src ports, resulted in nearly installing the entire ports tree, which is why I've waited so long. Try as I might, I've had great difficulty finding something that will _only_ upgrade what I already have installed, _and_ respect the options used during the original make make install, or those options expressed in make.conf. As portupgrade(1) portmaster(8) appear to be the most used in this scenario, I'm soliciting opinions on which of these works best, or if there is something else to better manage this situation. Is there such a thing as a FreeBSD upgrade easy button? Thank you for all your consideration. Chris, this time around, you will again rebuild almost your entire ports tree because some basic ports, such as Perl. Also, you will rarely be able to only upgrade what you already have installed because sometimes ports grow new requisite other ports you do not already have. I haven't used portupgrade in a long time because there was a period where it had fallen to bit-rot, but both tools are being maintained now. portupgrade has the decided advantage of being able to continue building some ports if another port failed as long as the failed port is not itself a requisite port for one that is yet to be built; portmaster bails out at the first error. portmaster, on the other hand, has a rebuild everything approach in the manual page, and can be used to list only leaf ports -- but that approach will require you to deinstall all ports so that the machine becomes unusable while it builds. There are other approaches, like using portmaster just to list this ports tree, and then use Tinderbox or poudriere to build packages in a chroot, and then only deinstall and install if you have all packages built successfully - but I am not familiar with automating this, not familiar with poudriere, and it requires a bit of work to get your options transferred to these build systems. Such a build all packages first before you start deinstalling would reduce the downtime, though. Hope that helps a little. Best regards Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ada(4) and ahci(4) quirk printing
Am 23.04.2013 09:44, schrieb Alexander Motin: Let me disagree. bootverbose keeps dmesg readable for average user, while quirks are specific driver workarounds and their names may confuse more then really help. If every driver print its quirks, dmesg would be two times bigger. There is bootverbose for it. quirks print hardware shortcomings that FreeBSD is working around, it is useful both to reassure users that FreeBSD is aware of the issues as well as give them a hint not to buy the same hardware if the quirks have too severe an impact (like NCQ unusable). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Any objections/comments on axing out old ATA stack?
Am 20.04.2013 23:29, schrieb Jeremy Chadwick: My feeling is that the stalls are mostly from the error handler and the overall time the drive is frozen gets shorter. If it had not _felt_ faster, I'd not have left that in sysctl.conf in the first place. Your understanding of what that sysctl does is wrong, or I'm misunderstanding what you're saying (very possible!). What I am saying is a high-level view on the situation. If I leave the default slot timeout set, whenever the computer gets into an episode of stalls, it becomes unusable (all I/O stalled so anything that needs disk I/O will hang) for so long that it is much faster to depress the reset button, reboot, force fsck, and retry. This usually entails hand-holding and manually cleaning up debris, such as b0rked .o files from a buildworld, or similar. These stalls happens out of the middle of the buildworld, under heavy I/O, so I'd dispute excessive head unloading and drive spindown is the issue -- the computer (and fans in particular) is generally very quiet, no VGA board (just fanless onboard Radeon HD 3300), I could hear re-spinups or parking heads. I don't hear anything like it. I don't know how rescheduling commands that timed out and get rescheduled happens overall. How I interpret what you're saying: that the sysctl somehow decreases stall times during I/O operations that fail. This is incorrect. That may not be the intention of the sysctl, but it is the high-level outcome. What that sysctl does is define the number of seconds that transpire ***before*** the CAM layer says Okay, I didn't get a response to the ATA CDB I sent the disk, and then re-submits the same CDB to the disk. The other question (to Alexander Motin) then is why do I see the timeouts for the related slots rougly $timeout seconds apart. Alexander, is there any way we can make the kernel dump the entire set of pending NCQ queue entries including submitted timestamp, or timeout values, so that we can see how much workload is queued? Note also that the CRC count has not increased since I've put the smartctl output online, it's still at 14 -- I would have to see CRC errors and their consequences in Linux or Windows, too. Linux's smartd 5.41 never mailed about an increase of the CRC value, and I told it not to mail temperature changes. Rephrased: in the case of a disk stalling on an I/O request, you will experience the effects of that stall no matter what that sysctl is set to. A lower value in that sysctl will result in CAM spitting out nasties on the console + hitting the CDB retry submission scenario sooner, which if the drive is awake/responsive by that time will go smoothly. That's all it does. That's how you have explained and I have understood it on the queue-slot level (microscopic), but at a larger scale, I do not observe that the shorter timeout sysctl value led to these stall episodes happen more often (as should be the consequence if spindown were the cause of the stalls), only recovery is faster. Thus a value of 5 indicates a device/drive did not respond to a CDB within 5 seconds, and a value of 30 indicates a device/drive did not respond to a CDB within 30 seconds. Regardless, those lengths of time are VERY long for an I/O operation on a mechanical HDD. Indeed they are, and because /usr is on the offending drive, I lowered the value to 5 s, which I still deem conservative. I know that an older ATA standard edition permitted longer completion times for flushing HDD internal write caches to platters (15 s IIRC). Oh look, it's the Samsung SpinPoint series, especially the EcoGreen (EG) series. No joke: ~60% of the problem reports I deal with when it comes to weird wonky problems stem from this drive series. I have no idea why, but they're a common pain point for me. I know they are, especially the larger siblings 1.5 G up. Politely, your analysis of the drive (looks sane to me) is an indicator of why SMART output needs to be interpreted by a person who is familiar with the information. That drive *does not* look sane to me. :-) 14 CRC errors with a drive that moved through computers that got modified over time, that does not run the whole day, and that was first attached to a computer whose controller (VIA garbage) could only talk to 1.5 Gb/s ATA drives but not 3 Gb/s is not something I care about. Key points about these errors: [...] - These are conditions that short, long, select (LBA range scan), and conveyance SMART tests would probably not detect. Like I said: it seems to be all over the board. I agree that it is more likely to be a communications issue between FreeBSD and the drive's logic, with all components, hard- and software involved. Bernd Walter responded indicating that his experience indicated that the issue related to NCQ compatibility. This would not surprise me. Neither would it surprise me, but Linux should suffer, too, then. It does use NCQ, too. FreeBSD can be booted
Re: Any objections/comments on axing out old ATA stack?
Am 04.04.2013 03:05, schrieb Jeremy Chadwick: Please provide gpart show -p ada1 output, both here and in the PR, if you could. =63 1953525105ada1 MBR (931G) 63 209714337 ada1s1 freebsd [active] (100G) 209714400 800 - free - (400k) 2097152007168 ada1s2 ntfs (34G) 281395200 15405 - free - (7.5M) 281410605 488263545 ada1s3 linux-data (232G) 769674150 1183851018 - free - (564G) Thanks for all the useful information provided so far (including further down). I know some of that already, but am not going to complain because it is very useful in the logs. The problem here is that I cannot guarantee you that alignment is the problem. The performance impact of writes to partitions which are non-aligned is quite high, and NCQ just exacerbates this problem. I would love to tell you switch to GPT and follow Warren Block's document*** but if your NTFS partition is Windows and is a Windows version older than Windows 7 GPT is not supported. I am happy to make that realign-and-use-GPT experiment. My Windows is 7 Professional 64-bit. It will take me a few days because this is spare-time stuff. One piece of evidence that refutes my theory is that if Windows and/or Linux partition are something you boot into and use often, I would imagine NCQ would be used in both of those environments and would suffer from the same issue. Although Windows tends to hide all sorts of transient errors from the user (sigh), Linux tends to be like FreeBSD with regards to such issues (on the console anyway; you wouldn't see such messages normally inside of X). Now, the FreeBSD slice is the only partition on that disk that would likely see concurrent write accesses (think make -j8 on a quadcore computer) which is more prone to ferret out such alignment contention. The NTFS partition is aligned on a multi-MB boundary, so wouldn't hit the problem anyways. The Linux partition is in ext4 format for mostly sequential access to files usually in excess of 10 MB each. Linux's ext4 jumps through several hoops to end up with bulk writes, like extents, delayed allocations (to avoid fragmentation), reordering of data and metadata writes, serialized log writes and all that stuff, and it would appear I am permitting it to cache writes -- Linux uses write barriers to enforce proper ordering of journal/meta-data writes. It would be rather hard to hit ATA taskfile timeouts, the expected rate with which the drive needs to do a partial write is orders of magnitude lower. Any good concurrent write exercise tools for Unix that I could run on the Linux ext4 partition that you would propose? If you have the time and want to put forth the effort, I would recommend backing up all your data on ada1, zero the first and last 1MByte of the drive, and then try following Warren Block's guide. I'd just recommend doing this: gpart create -s gpt ada1 gpart add -t freebsd-ufs -b 2m ada1 newfs -U -j /dev/ada1p1 (or remove -j if you don't want to use SUJ) Will do. - I am running with kern.cam.ada.default_timeout=5 which makes the computer recover faster I can definitely imagine cases where a drive using NCQ but doing writes to a non-aligned partition could take longer than 5 seconds to respond to an ATA CDB (this is different than a SATA or AHCI layer timeout). I am not telling you change this back to 30, but it might not be helping your situation at all given my above theory. My feeling is that the stalls are mostly from the error handler and the overall time the drive is frozen gets shorter. If it had not _felt_ faster, I'd not have left that in sysctl.conf in the first place. Finally: could you please provide output from smartctl -x /dev/ada1? I would like to rule out any possibility of your drive having some other kind of issue that might cause it to go catatonic. Thanks. I have fetched the data with Linux this time (should not make a difference as it's all drive internal data, not host OS stuff). Looks sane to me, http://people.freebsd.org/~mandree/smartctl.log. I'll be happy to refetch this data with a more current smartctl version under FreeBSD if required. ** -- http://www.seagate.com/files/www-content/support-content/documentation/samsung/tech-specs/eco_greenf2.pdf *** -- http://www.wonkity.com/~wblock/docs/html/ssd.html signature.asc Description: OpenPGP digital signature
Re: Any objections/comments on axing out old ATA stack?
I have just sent more information to the PR at http://www.freebsd.org/cgi/query-pr.cgi?pr=157397 The short summary (more info in the PR) is: - limiting tags to 31 does not help - disabling NCQ appears to help in initial testing, but warrants more testing - error happens during WRITE_FPDMA_QUEUED, - File system in question is SU+J UFS2 mounted on /usr, and I can for instance rm -rf /usr/obj or just log into GNOME and try to open a gnome-terminal to trigger stalls; - Linux uses 31 tags (for different reason) and has no drive quirks, but a controller quirk; for Jeremy's topic #6, regarding the ATI/AMD SB7x0 that I am using, it might be worthwhile investigating the AHCI_HFLAG_IGN_SERR_INTERNAL flag - it gets set by Linux on the SB700 that my computer is using, see ahci_error_intr() in libahci.h - I am not going to interpret that for lack of expertise, but it does affect error handling and appears to ignore a certain condition. Why only my Samsung HDD drive triggers this but not the WD drive, I do not know yet. Hope that helps a bit. signature.asc Description: OpenPGP digital signature
Re: Any objections/comments on axing out old ATA stack?
Am 04.04.2013 01:38, schrieb Jeremy Chadwick: ... While skimming Linux libata code and commits in the past, the only glaringly obvious bug/issue I see is with SB600/SB700 chipsets (the hardware revision apparently matters) and port multiplier (PMP) support and soft resets. Are you using a port multiplier? I doubt it, but I have to ask. I am not using a PMP as far as I know (unless one is buried on my Asus M4A78T-E main board). It would seem the drives are directly attached to the south bridge's SATA ports. Why only my Samsung HDD drive triggers this but not the WD drive, I do not know yet. Please provide gpart show -p ada1 output, both here and in the PR, if you could. =63 1953525105ada1 MBR (931G) 63 209714337 ada1s1 freebsd [active] (100G) 209714400 800 - free - (400k) 2097152007168 ada1s2 ntfs (34G) 281395200 15405 - free - (7.5M) 281410605 488263545 ada1s3 linux-data (232G) 769674150 1183851018 - free - (564G) HTH Best regards Matthias signature.asc Description: OpenPGP digital signature
Re: Any objections/comments on axing out old ATA stack?
Am 31.03.2013 23:02, schrieb Scott Long: So what I hear you and Matthias saying, I believe, is that it should be easier to force disks to fall back to non-NCQ mode, and/or have a more responsive black-list for problematic controllers. Would this help the situation? It's hard to justify holding back overall forward progress because of some bad controllers; we do several Tbps off of AHCI controllers with NCQ enabled on FreeBSD 9.x, enough to make up a sizable percentage of the internet's traffic, and we see no problems. How can we move forward but also take care of you guys with problematic hardware? Well, I am running the driver fine off of my WD Caviar RE3 disk, and the problematic drive also works just fine with Windows and Linux, so it must be something between the problematic drive and the FreeBSD driver. I would like to see any of this, in decreasing order of precedence: - debugged driver - assistance/instructions on helping how to debug the driver/trace NCQ stuff/... (as in Jeremy Chadwick's followup in this same thread - this helps, I will attempt to procure the required information; back then, reducing the number of tags to 31 was ineffective, including an error message and getting a value of 32 when reading the setting back) - user-space contingency features, such as letting camcontrol limit the number of open NCQ tags, or disable NCQ, either on a per-drive basis I am capable of debugging C - mostly with gdb command-line, and graphical Windows IDEs - but am unfamiliar with FreeBSD kernel debugging. If necessary, I can pull up a second console, but the PC that is affected is legacy-free, so serial port only works through a serial/USB converter. signature.asc Description: OpenPGP digital signature
Re: Any objections/comments on axing out old ATA stack?
Am 01.04.2013 17:07, schrieb Stefan Esser: Am 01.04.2013 15:14, schrieb Victor Balada Diaz: Being able to configure quirks from loader.conf for disks AND controllers would be great and is not hard to do. If you want i can do a patch in two weeks and send it to you. That way it's easy to test disabling NCQ and/or other things in case of hitting a bug. Also being able to modify the configuration without a kernel recompile would be a big improvement because we could still use freebsd-update to keep systems updated. Something like: kern.cam.ada.0.quirks=1 to force 4KB sectors? No need to implement that, it is in -CURRENT (did not check -STABLE). But there is no quirk, that disables NCQ, currently, although it is easy to implement. See the places where ADA_FLAG_CAN_NCQ is set and make that value depend on a new quirk flag being unset ... But instead of setting that flag in the loader, it would be good to collect drive signatures that need it and to add quirk entries for them in ata_da.c ... Before we can do that, we need to know if it's really the drive's fault or if the driver is wrong. We need to debug that. If we have relevant parameters exposed through the CAM interface (rather than loader variables), that would also help expedite the debugging. signature.asc Description: OpenPGP digital signature
Re: Any objections/comments on axing out old ATA stack?
Am 31.03.2013 06:00, schrieb Peter Wemm: We're talking about 10.x, so if you want it fixed, you need update with 10.x information. Please put 10.x diagnostics in the PR. I will not. The PR was filed four months before 10-CURRENT branched; I have no reason to assume it were to be no longer pertinent -- no MFCs, no PR followups). (according to http://www.freebsd.org/doc/en/books/porters-handbook/freebsd-versions.html, 10-CURRENT appeared on 2011-09-26) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Any objections/comments on axing out old ATA stack?
Am 27.03.2013 22:22, schrieb Alexander Motin: Hi. Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA stack, using only some controller drivers of old ata(4) by having `options ATA_CAM` enabled in all kernels by default. I have a wish to drop non-ATA_CAM ata(4) code, unused since that time from the head branch to allow further ATA code cleanup. Does any one here still uses legacy ATA stack (kernel explicitly built without `options ATA_CAM`) for some reason, for example as workaround for some regression? Does anybody have good ideas why we should not drop it now? Alexander, The regression in http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/157397 where the SATA NCQ slots stall for some Samsung drives in the new stack, and consequently hang the computer for prolonged episodes where it is in the NCQ error handling, disallows removal of the old driver. (Last checked with 9.1-RELEASE at current patchlevel.) Chances are that limiting the open queue slots to 31 might help, but that is hearsay from what Linux would be doing. Unless we get a fix, if you want to drop the old driver, you'll need to add features so that 1. the new driver to lets users (down-)configure the max. number of tagged openings 2. the new driver allows disabling NCQ altogether for individual drives 3. list the relevant Samsung drives in some quirks data base so that we avoid the stalls while permitting users to open it up to 32 NCQ slots. So unless these are all addressed, I'd veto removal of the old ATA driver - sorry! Best regards Matthias signature.asc Description: OpenPGP digital signature
Re: Any objections/comments on axing out old ATA stack?
Am 28.03.2013 16:31, schrieb Scott Long: On Mar 28, 2013, at 8:00 AM, Ian Lepore i...@freebsd.org wrote: On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote: On 28.03.2013 02:43, Adrian Chadd wrote: My main concern with the new stuff is that it requires CAM and that's reasonably big compared to the standalone ATA code. It'd be nice if we could slim down the CAM stack a bit first; it makes embedding it on the smaller devices really freaking painful. Are there many boards now with ATA, but without USB? But I agree, it should be checked. It's not necessarily what the boards have but how they're used. We use industrial SBCs at work that have ata compact flash sockets on the board which we do use, and usb interfaces which we don't use. I've never tested the new ata+cam stuff on some of these boards, most based on Cyrix, Via, Geode, and VortexD86 chipsets. The older ata code works, but not always very well -- for example, we usually have to set hw.ata.ata_dma=0 for absolutely no reason we've ever been able to figure out except that if we leave it enabled we get DMA errors and panics on some CF cards and not on others. I have no idea whether to expect such things to be better, worse, or no different by changing to the ata+cam way of doing things (but I don't really have time to do extensive testing right now either). The legacy ATA code was hard to maintain, very buggy (as you point out), and is essentially unmaintained. Also, IIRC, the legacy stack simply cannot support NCQ tagged queueing. ...which is exactly why it currently is the only way to get certain Samsung drives to cooperate reliably, without stalling the kernel for prolonged times (minutes) making the computer essentially unusable once it gets under I/O load (such as make -C /usr/src -j4 buildworld) - as the new ahci+ata+cam+... would. Details including PR reference in my other message in this thread. signature.asc Description: OpenPGP digital signature
Re: Why can't gcc-4.2.1 build usable libreoffice?
Am 19.02.2013 19:54, schrieb Mikhail T.: These were, indeed, complaints, but not about the port not working after I broke it. My complaint is that, though the port works out of the box, the office@ maintainers have given up on the base compiler too easily -- comments in the makefile make no mention of any bug-reports filed with anyone, for example. It sure seems, no attempts were made to analyze the failures... I don't think, such going with the flow is responsible and am afraid, the inglorious days of building a special compiler just for the office will return... Feel free to debug MyFavouriteOffice to the point where it will build with base GCC, but don't complain if the *office teams don't look at your patches. If there are compiler bugs in gcc 4.2, there is no place where anyone will care for anyone else to file them, not upstream (abandoned 4.2.X years ago), not FreeBSD (decided to switch to clang instead). What is your point, besides getting software from the museum to build stuff from the relative future? LibreOffice's own Native_Build page https://wiki.documentfoundation.org/Development/Native_Build makes no mention of a required compiler version. Unless a compiler is documented to not support a required feature, it is supposed to work. Thus, filing a bug-report with LibreOffice could've been fruitful -- if it is the code, rather than the toolchain, that are at fault... That will likely only buy you the compiler requirement you are currently missing, and it is likely to be the exact version that they used to build their official binaries, with a newer versions may work, but no promises attached. Feel free to query the LibreOffice developers if, and according to which conditions, they'd take your patches to make LO build with our decrepit gcc 4.2.1. Am I really the only one here disturbed by the fact, that the compilers shipped as cc(1) and/or c++(1) in our favorite operating system's most recent stable versions (9.1 and 8.3) are considered buggy? Not just old -- and thus unable to process more modern language-standards/features, but buggy -- processing those features incorrectly? There is certainly nothing in our errata http://www.freebsd.org/releases/9.1R/errata.html about it... You have not yet proven that either the base compilers or LibreOffice are at fault. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Does / Is anyone maintaining CVS for FreeBSD?
Am 03.01.2013 16:36, schrieb Eitan Adler: On 3 January 2013 02:32, Matthias Andree mand...@freebsd.org wrote: Please do not quote addresses. Not all web archives and copies hide them properly. Hiding email addresses is useless for spam control. Obfuscating them makes it harder to follow a conversation. Anyways it's useless baggage in the presence of real names. Threading is to happen along In-Reply-To: and References: headers - they were made exactly for that - and not after body content. I take care to reply to the message I am referring to so that those headers are intact. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Does / Is anyone maintaining CVS for FreeBSD?
Am 03.01.2013 23:15, schrieb Mark Andrews: In message 50e5a7d1.4080...@freebsd.org, Matthias Andree writes: Am 03.01.2013 16:36, schrieb Eitan Adler: On 3 January 2013 02:32, Matthias Andree mand...@freebsd.org wrote: Please do not quote addresses. Not all web archives and copies hide them properly. Hiding email addresses is useless for spam control. Obfuscating them makes it harder to follow a conversation. Anyways it's useless baggage in the presence of real names. Garbage. Real names are *not* unique. Email address are disambiguators. No need to disambiguate text if the headers convey all necessary information. Let's take this part off-list now, reply-to: is set. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Does / Is anyone maintaining CVS for FreeBSD?
Am 02.01.2013 06:31, schrieb Erich Dollansky: Hi, Thank God! I'd hate to think that after unwinding years accumulated CVS process, to rewind it for SVN, only to have to do it again for GIT, just seems a bit masochistic. do not worry. It will come. Seriously, I do not understand many changes especially when there is a system in place which does not affect a running system at all but things inside the OS still could be improved. The migration was made in order to get things inside the OS ... improved at all. Developers were fed up wasting too much time struggling with CVS itself rather than working on the things inside the OS. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Does / Is anyone maintaining CVS for FreeBSD?
Am 03.01.2013 01:50, schrieb Erich Dollansky: Hi, On Wed, 02 Jan 2013 17:02:11 +0100 Matthias Andree ...@FreeBSD.org wrote: Please do not quote addresses. Not all web archives and copies hide them properly. The migration was made in order to get things inside the OS ... improved at all. Developers were fed up wasting too much time struggling with CVS itself rather than working on the things inside the OS. I hightly doubt that the efforts spent now are worth this. It would have been so much easier and smoother to make the change with 10.0. Regarding versions, please read the relevant information: the relevant decision was made years ago, and the version number you slap at the switch is a moot point. A security incident pushed things forward in an unscheduled way, and prompted the project to expedite some infrastructure works that had been pending, because work was required to rebuild major parts of it anyways. A normal user does not expect any changes of this kind in a x.1 release. A normal user does not care about what happens in between releases beyond security updates and other errata corrections, but uses freebsd-update to upgrade from one pre-compiled release to a newer, and I have also observed that people need to recompile custom kernels less often than with older FreeBSD releases. Anything else is talking about doing FreeBSD development. But it also makes one other problem obvious. The ports tree has no version numbers. So, even if the switch would have been made with the 10.0 release, it would have been the same problem for the ports tree. That, too, was discussed, and dismissed due to lack of manpower to look after a versioned tree, on the relevant -ports list. This item crops up every so often, but stable@ is not the right list to discuss this on. For users, again, portsnap is the tool to use. Anything else is talking about doing FreeBSD development. Even today, the handbook states only two sites for SVN and a long list for CVS. Wouldn't it have been a bit more practical to build the infrastructure first and then pull the plug? What will happen to the two SVN servers when no others come up soon? A long list [of sites] for CVS is required to overcome load problems. I have not yet found SVN servers lacking in performance, whether I was checking out FreeBSD 9 sources, or the ports tree. Updates are much quicker IMO than they ever were with CVS, even with a local c[v]sup copy of the CVS sources on the same computer. You would not provision more servers unless there is a need to. I suppose more would be added should the need arise. And it is really recommended that users read the existing material on the list archives before re-iterating. (We should possibly just respond with a list of URLs :)) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Does / Is anyone maintaining CVS for FreeBSD?
Am 31.12.2012 21:40, schrieb Chris H: IM(NS)HO; SVN is an inferior RCS created so Windows users wouldn't feel left out. No, and it has nothing to do with Windows. CVS does work on Windows. SVN 1.5 or newer is CVS done right, if you want the server-client split model, and can waive the distributed nature of Mercurial, Git, or Bazaar-NG. For those who abuse CVS as content distribution and management system to just peek at individual files, it may not matter, and the pain of migrating to SVN may dominate, but if you have ever manually assembled a list of versions for how to merge because someone else branched in CVS without laying proper tags, you know why CVS must be replaced. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: bad sector in gmirror HDD
Am 20.08.2011 19:34, schrieb Dan Langille: This is an older system. I suspect insufficient ventilation. I'll look at getting a new case fan, if not some HDD fans. The answer is quite simple, get new drives. They have gone for some 24000 hours, IOW, at least 3 years (assuming 24x7), and at around 50 °C, they're worn. After three years, at the slightest hitch, replace drives, before Something Bad[tm] happens. You'll get faster replacements anyhow :) On a related note, since this is about gmirror: Linux has a similar subsystem in place called the drive mapper (dm), with user-space tools mdadm. The whole rig (kernel + user space) supports various RAID levels through modules, the gmirror equivalent being raid1 -- and that module somewhat recently acquired an interesting *feature:* it can automatically rewrite broken sectors. Meaning that when it sees a read error on one drive, it will read the block from the intact other drive and re-write it on the faulty drive so that it gets reallocated (assuming nobody turned the drive's ARWE feature off). Perhaps that's a useful feature for gmirror, too. 2848980992 bytes transferred in 127.128503 secs (22410246 bytes/sec) Eek, someone should fix dd to use proper units and not confuse seconds (s) with the secans function (sec). Anyways, that's pretty low by today's standards. My I/O speeds even on lowly Samsung 5400/min drives are in excess of 100 MBytes/s, and that's talking about drives made in 2009. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [SOLVED] Re: labelling root file system (RELENG_8)
Am 08.06.2011 19:59, schrieb Rob Farmer: Also, I've seen the sysctl kern.geom.debugflags=16 thing in zfs tutorials and such, but haven't seen where it's actually necessary. I think this is outdated and changed circa 8.0. Possibly - it's still a de-facto standard reflex action whenever a newer FreeBSD kernel refuses to write a superblock or MBR or partition stuff. 8-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
labelling root file system (RELENG_8)
Greetings, I've tried to re-label an existing (and up to date) 8-STABLE installation's root partition. This failed, tunefs reports it cannot write the super block. I have attempted this sequence: 1. reboot (through BIOS and loader) directly into single-user mode (boot -s) 2. sysctl kern.geom.debugflags=16 3. tunefs -L root /dev/ada0s4a# that's the dev I mount the root # partition from Still no joy = tunefs cannot update the super block. Remounting / as rw doesn't help, as expected. The root fs uses softupdates but no journalling -- what other hoops do I need to jump through to create labels for my root ufs file system? Thanks. Best regards, Matthias ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[SOLVED] Re: labelling root file system (RELENG_8)
Am 08.06.2011 15:11, schrieb nickolas...@gmail.com: 1. Change your root fstab record to /dev/ada0s4a (not label!), reboot to single mode and try to re-label partition. Indeed not mounting from the label was (apparently) the key to solve this. Thank you. In fact the successful procedure was: - from boot menu, escape to loader prompt - set vfs.root.mountfrom=ufs:/dev/ada0s4a - boot -s - tunefs -L mylabel /dev/ada0s4a - mount -a - edit /etc/fstab to use /dev/ufs/mylabel as device for / - shutdown -r now Best regards, Matthias ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_8: panic: wrong offset 4096 for sectorsize 2352
Am 24.05.2011 10:53, schrieb Jeremy Chadwick:
On Tue, May 24, 2011 at 09:26:18AM +0200, Joerg Wunsch wrote:
As Andriy Gapon wrote:
panic: wrong offset 4096 for sectorsize 2352
Any ideas why this happens, and how to avoid it?
Backtrace would be a first thing.
OK, here we go (the core has been dumped from within a serial console
BREAK DDB entry, I'm omitting the frames related to that):
#16 0xc0537352 in _cv_wait (cvp=0xc6e6bcd4, lock=0xc6e6bdd4) at
/usr/src/sys/kern/kern_condvar.c:96
#17 0xc0aa8a13 in usb_process (arg=0xc6e6bccc)
at /usr/src/sys/modules/usb/usb/../../../dev/usb/usb_process.c:183
#18 0xc054f948 in fork_exit (callout=0xc0aa88e0 usb_process,
arg=0xc6e6bccc, frame=0xc6a1ad28)
at /usr/src/sys/kern/kern_fork.c:865
#19 0xc077fd34 in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:275
After the initial panic, I typed c in DDB, in the assumption
it would proceed with a coredump, but it didn't. That's why I
hit BREAK again, and forced a dump through the panic DDB
command. Now, I'm no longer sure whether the frames above do
really relate to the mentioned panic string.
Just an informational note about inducing a panic: I tend to, once at
the db prompt, do bt then immediately call doadump. That induces
memory being written to swap, then do reboot. I assume (since you
have a crash at all) that you have dumpdev defined in /etc/rc.conf.
savecore(8) will then pick up the panic, etc... you get the idea.
The panic in question is intentional from what I can tell in the code.
I'm not sure how much a kernel crash/dump is going to help with this,
given the following code in src/sys/geom/geom_io.c:
391 void
392 g_io_request(struct bio *bp, struct g_consumer *cp)
393 {
...
426 if (bp-bio_cmd (BIO_READ|BIO_WRITE|BIO_DELETE)) {
427 KASSERT(bp-bio_offset % cp-provider-sectorsize == 0,
428 (wrong offset %jd for sectorsize %u,
429 bp-bio_offset, cp-provider-sectorsize));
phk@ added this code 6 years ago to HEAD (at the time); see the
annotation around line 426:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/geom_io.c#rev1.59
The assertion failed because sectorsize was not a multiple of
bio_offset. Specifically: 4096 / 2352 = 1.741, which isn't zero,
therefore the panic occurs. (It's important to read assertions
backwards; that is, the assertion/panic happens when the conditional
proves false).
I know little to nothing about CD ripping so I can't tell you why abcde
was able to somehow trigger this. Possibly some device read routines
that abcde uses get translated directly into GEOM requests and therefore
indirectly trigger the assertion?
CDDA blocks have 588 samples * 2 channels * 16 bit, 1/75th of a second
sampled at 44100 Hz, so that's the high-level view where the block size
of 2352 comes from. IMNSHO the kernel should return EINVAL or EIO or
similar, not panic.
Where the 4096 offset comes from on a 2352 block size is the other
question. If something's trying block 3, it should seek to 4704; OTOH if
anywhere block sizes get out of synch, that might explain it. Perhaps
truss can help if its output doesn't get scratched in the panic.
The interesting question is, which devices are affected, does this
happen with acd (ATAPI) or with cd (SCSI/CAM)?
Not that I could help with that though, just a hint to Jörg for
sidestepping the problem: if it was ATAPI, try loading atapicam via
/etc/loader.conf and retry abcde on cd. ISTR that it worked for me on an
internal SATA or PATA CD-ROM. Feel free to ping me off-list if you want
me to try if narrowing down 8-STABLE drivers is any help for the kernel
hackers.
--
Matthias Andree
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Double installation of liblzma.so.5 breaks libarchive.so.5
Am 06.05.2011 20:37, schrieb Michael Hoffmann: I cannot reconstruct why 'pkgdb -Fu' did not tried to prevent me from using 'archivers/xz' furthermore, allthough it now seems to be marked as IGNORE. I also don't know how this LD_LIBRARY thing ever popped up in csh.cshrc, but it seems to persist there from at least 7.2. Newer systems don't seem to have such an entry. Michael, It's apparently not designed to do that. Does portmaster --check-depends complain? It's a shell script from ports-mgmt/portmaster, just install and run it, it's lightweight (as opposed to portupgrade). Was your library path in csh created or suggested by pth-related ports? (Perhaps there could be something in the ports framework that warns if port duplicates base system functionality and suggests to deinstall a port that is no longer needed -- however, that would have to work also in cases where a newer ports is supposed to complement base system services. There were such situations for ssh, for instance.) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Kernel memory leak in 8.2-PRERELEASE?
Am 05.04.2011 15:51, schrieb Andriy Gapon: Boris, ARC is an adaptive cache (as its name says), but the adaption doesn't happen instantly. So, when your applications do not use a lot of memory, but there is steady filesystem usage, then ZFS ARC is going to gradually grow to consume an optimum amount of RAM. Then, your applications suddenly need a lot more memory, they put pressure on VM system, ARC starts to shrink. But if memory demand grows faster than ARC shrinks, you are going to get a memory shortage. And since you don't have any swap to act as a safety net, you are getting out-of-memory situation. So no surprises here, no system problems, just a normal foot-shooting :) Clamping maximum ARC size, as Jeremy has suggested, should help some. Adding some swap would help a lot more. The problem to me seems that ARC, the way you describe it, isn't really integrated with the system. It's not buffer or cache memory, but some separate application memory that can't adapt as quickly to system memory demands as all other kernel-managed caches and buffers can. FWIW, I've been using it on a 4 GB amd64 computer. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS performance as the FS fills up?
Am 08.03.2011 12:48, schrieb Jeremy Chadwick: On Tue, Mar 08, 2011 at 12:26:49PM +0100, Patrick M. Hausen wrote: we use a big JBOD and ZFS with raidz2 as the target for our nightly Amanda backups. I already suspected that the fact that the FS was 90% full might be the cause of our backup performance continously decreasing. I just added another vdev - 6 disks of 750 GB each, raidz2 and the FS usage is back to 71% currently. This was while backups were running and write performance instantly skyrocketed compared to the values before. So, is it possible to name a reasonable amount of free space to keep on a raidz2 volume? On last year's EuroBSDCon I got the impression that with recent (RELENG_8) ZFS merges I could get away with using around 90%. I'm in no way attempting to dissuade you from your efforts to figure out a good number for utilisation, but when I hear of disks -- no matter how many -- being 90% full, I immediately conclude performance is going to suck simply because the outer tracks on a disk contains more sectors than the inner tracks. This is the reason for performance degradation as the seek offset increases, resulting in graphs like this: Whatever. I've experienced similar massive performance decrease even on a non-redundant single-disk ZFS setup after the ZFS (8-STABLE between 8.0 and before 8.2) had filled up once. Even clearing the disk down to 70% didn't get my /usr (which was a ZFS mount) snappy again. The speed decrease was one to two orders of magnitude in excess of what you'd attribute to the CLV or sectors-per-track change across the disk. What I heard from my 7200/min WD RE3 drive (which seeks rather fast for a 7200/min drive - I think it was the fastest seeking 7200/min drive when I bought it) it was seeking and thrashing heads like hell even on single-threaded bulk reads of large files, and I suppose there was fragmentation and/or non-caching of metadata afoot, and it was far worse than any decrease in constant linear velocity or sectors-per-track of the disk tracks could explain, and the relevant ZFS ARC related options didn't rectify that either, so I reverted to GJOURNAL-enabled UFS which gave me a much better performance on a 5400/min disk than I've ever had with a halfway filled ZFS on the 7200/min RAID-class disk. And bulk transfer rates of both drives are beyond any doubt. In other words, the file system didn't recover speed (I'm not sure if that's a zfs or zpool feature), and I attribute that (and the failure to rm files from a 100% full file system) to the write-ahead-logging behaviour of ZFS. Any comments? -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS performance as the FS fills up?
Am 09.03.2011 14:28, schrieb Tom Evans: On Wed, Mar 9, 2011 at 12:51 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: Otherwise, I can imagine that prefetching could cause what you describe, which is enabled by default in 8.0 and 8.1 and auto-disables in 8.2 if the amount of available memory is less than 4GB. I don't think this is accurate. Prefetch was certainly disabled by default on 8.0 if you had 4GB of RAM or less, requiring the sysctl vfs.zfs.prefetch_disable=0 to be set if you wanted prefetch and had 4GB of RAM or less. Personally I've got a 4 GB amd64 setup, had been on RELENG_8 aka 8-STABLE before 8.2-RELEASE (and use RELENG_8_2 aka 8.2-RELEASE now), and I had tried vfs.zfs.prefetch_disable either way without seeing a big difference in sluggish performance (and actually even moved out /usr/home to a UFS file system to get somewhat back up to speed). I suppose that fragmentation was a big issue but cannot confirm that now. However, I cannot produce the data Jeremy has asked for any more, as the incriminated file system no longer exists. I recall ZFS (even the earlier versions before the bigger version leap) was very responsive when it was less than 50% full. I have, however, collected and reformatted (for Wiki) Jeremy's list at http://wiki.freebsd.org/ZFS/ProblemReporting - we'd need to review this and once deemed suitable, link it from the ZFS and possibly ZFSTuningGuide pages, and possibly also from the FreeBSD ZFS manual pages. HTH Matthias -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: bin/139146 still not right in FreeBSD 8.2 (-m32 on amd64)?
Am 09.03.2011 21:52, schrieb Josh Carroll:
On Wed, Mar 9, 2011 at 12:15 PM, Thomas David Rivers riv...@dignus.com
wrote:
Just installed a fresh 8.2-stable on a brand-spanking-new 64-bit
machine...
But, when I try to build 32-bit programs I get problems linking,
and I stumbled onto PR bin/139146.
The PR mentions this quick test:
uname -sr echo int main () { } t.c gcc -v --help 21 | grep m32
gcc -m32 t.c
Add -B/usr/lib32 to the gcc command line, e.g.:
echo int main () { } t.c gcc -v --help 21 | grep m32 gcc
-m32 -B/usr/lib32 t.c
Then it should work.
I experienced the same some time ago - but:
Shouldn't this (-B/usr/lib32) be subsumed under the -m32 switch in the
future?
Best regards
--
Matthias Andree
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: PR - submitting a patch
Am 24.02.2011 12:44, schrieb Damien Fleuriot: Cheers, I've done just that :) Merci. I've just forwarded the PR to the maintainer for dis- or approval. -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
recent 8.2-STABLE commits break nullfs for tinderbox?
Greetings, I'm tracking 8.2-PRERELEASE, and it appears that recent commits to nullfs, zfs, vfs, or thereabouts have broken Tinderbox for me. I'm mounting my ports tree via nullfs, which has been working fine for a year. Any ideas, or further info needed? Best regards Matthias ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: recent 8.2-STABLE commits break nullfs for tinderbox?
Am 22.12.2010 13:44, schrieb Mike Tancsa: On 12/22/2010 7:03 AM, Matthias Andree wrote: Greetings, I'm tracking 8.2-PRERELEASE, and it appears that recent commits to nullfs, zfs, vfs, or thereabouts have broken Tinderbox for me. I'm mounting my ports tree via nullfs, which has been working fine for a year. Any ideas, or further info needed? Hi, Whats specifically broken ? Two of the freebsd tinderbox machines are RELENG_8 from Dec 3 and they are fine. However, they dont use nullfs, just zfs and ufs. Is it just nullfs thats broken ? What are the errors you are getting ? I updated after that. mount_nullfs /usr/ports.cvs /usr/local/tinderbox/portstrees/FreeBSD/ports fails with resource conflict avoided. I'll now rebuild GENERIC from scratch (including make clean) to see if that helps. Tried switching to NFS, this appears to work now. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: recent 8.2-STABLE commits break nullfs for tinderbox?
Am 22.12.2010 14:29, schrieb Jeremy Chadwick: On Wed, Dec 22, 2010 at 02:21:20PM +0100, Matthias Andree wrote: Am 22.12.2010 13:44, schrieb Mike Tancsa: On 12/22/2010 7:03 AM, Matthias Andree wrote: Greetings, I'm tracking 8.2-PRERELEASE, and it appears that recent commits to nullfs, zfs, vfs, or thereabouts have broken Tinderbox for me. I'm mounting my ports tree via nullfs, which has been working fine for a year. Any ideas, or further info needed? Hi, Whats specifically broken ? Two of the freebsd tinderbox machines are RELENG_8 from Dec 3 and they are fine. However, they dont use nullfs, just zfs and ufs. Is it just nullfs thats broken ? What are the errors you are getting ? I updated after that. mount_nullfs /usr/ports.cvs /usr/local/tinderbox/portstrees/FreeBSD/ports fails with resource conflict avoided. I'll now rebuild GENERIC from scratch (including make clean) to see if that helps. Tried switching to NFS, this appears to work now. FWIW, i can't find this error message (resource conflict avoided) anywhere in /usr/src, /usr/include, nor /usr/ports on RELENG_8 source dated from 2 hours ago. grep -ri resource conflict /usr/src does return some results, but nothing that looks identical to the string you posted. Sorry, my fault, was quoting from memory. This is now pasted: mount_nullfs: Resource deadlock avoided Only reason I'm pointing this out: it would be good to find the commit that breaks things for you, if there is such a commit, but we need something to key off of. Provided above. Tests of kernel rebuilt from scratch are pending (requires reboot and reconfiguration for nullfs). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: recent 8.2-STABLE commits break nullfs for tinderbox?
Am 22.12.2010 14:53, schrieb Paul B Mahol: On 12/22/10, Jeremy Chadwick free...@jdc.parodius.com wrote: On Wed, Dec 22, 2010 at 02:21:20PM +0100, Matthias Andree wrote: Am 22.12.2010 13:44, schrieb Mike Tancsa: On 12/22/2010 7:03 AM, Matthias Andree wrote: Greetings, I'm tracking 8.2-PRERELEASE, and it appears that recent commits to nullfs, zfs, vfs, or thereabouts have broken Tinderbox for me. I'm mounting my ports tree via nullfs, which has been working fine for a year. Any ideas, or further info needed? Hi, Whats specifically broken ? Two of the freebsd tinderbox machines are RELENG_8 from Dec 3 and they are fine. However, they dont use nullfs, just zfs and ufs. Is it just nullfs thats broken ? What are the errors you are getting ? I updated after that. mount_nullfs /usr/ports.cvs /usr/local/tinderbox/portstrees/FreeBSD/ports fails with resource conflict avoided. I'll now rebuild GENERIC from scratch (including make clean) to see if that helps. Tried switching to NFS, this appears to work now. FWIW, i can't find this error message (resource conflict avoided) anywhere in /usr/src, /usr/include, nor /usr/ports on RELENG_8 source dated from 2 hours ago. grep -ri resource conflict /usr/src does return some results, but nothing that looks identical to the string you posted. Only reason I'm pointing this out: it would be good to find the commit that breaks things for you, if there is such a commit, but we need something to key off of. Perhaps OP means resource deadlock avoided? Such message appears if you try to mount same mount point with nullfs twice - which doesnt have sense. Then either tinderbox's check if the directory exists is broken, else it wouldn't retry mounting it, or something else is broken. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-stable kernel compile error
Am 04.12.2010 15:24, schrieb Irakli: mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/src/sys/i386/compile/NS /usr/src/sys/modules/ae/../../dev/ae/if_ae.c === aesni (depend) @ - /usr/src/sys machine - /usr/src/sys/i386/include make: don't know how to make aesni.c. Stop *** Error code 2 Stop in /usr/src/sys/modules. *** Error code 1 If you've built with -DNOCLEAN, try without that option, or running make clean HTH Matthias ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: GSSAPI (for OpenLDAP) on FreeBSD 8?
Am 01.09.2010 18:33, schrieb Jan Henrik Sylvester: I have got problems with GSSAPI authentication to OpenLDAP: ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown) Did you run kinit to obtain tickets? You didn't mention that. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: cname replace in mail address? [off-topic] (Re: Attn Ronald Klop)
Am 27.08.2010 11:22, schrieb Ronald Klop: Mandatory? I'm googling, but can't find a document that declares it mandatory and only sendmail seems to do it. I think it is lame to use DNS info to rewrite e-mail addresses, but the person who made it 'mandatory' will have good reasons for it. May have been RFC0974, perhaps in connection with others - January 1986... -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd-update 7.2-7.3 manul merging of all files
Am 27.03.2010, 16:45 Uhr, schrieb Thomas Krause: Hi, I want to upgrade a 7.2-RELEASE-p4 to 7.3-RELEASE with the command # freebsd-update upgrade -r 7.3-RELEASE After fetching and patching I get Attempting to automatically merge changes in files... done. The following file could not be merged automatically: /boot/device.hints Press Enter to edit this file in vi and resolve the conflicts manually... this goes on with *every* file in the /etc directory. What's wrong here? I got this once when updating from a self-built foo-STABLE to a -RELEASE later, because the $FreeBSD: ... tags were all wrong (and it was a nightmare that affected some 200 files). Did you installed your prior 7.2 system from a RELENG_7_2 cvsup/csup checkout, or was it a binary install? What triggers the conflicts for you - are there files where you only need to change the $FreeBSD: ... line but no others? I'm wondering if the etcmerge stuff should just ignore conflicts on the $FreeBSD$ line. -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_7: gdm after portupgrade does not allow logins
Am 17.12.2009, 02:09 Uhr, schrieb Dmitry Morozovsky ma...@rinet.ru:
Dear colleagues,
after portupgrade'ing on last gnome update I have very strange situation:
gdm does not show neither login list not username text field; after
pressing
space, some unlabelled text field opens (symbols are echoed, so I
suppose it's
like login name field); however, entering anything there does not lead
anywhere.
portupgrade -f gdm does not help; portupgrade -f ${direct gdm
dependencies}
does not help, either.
And, of course, I even rebooted the machine without a bit of success.
Any hints? Thanks in advance!
Make sure that /proc is mounted, see the GNOME FAQ for details on how to
set /etc/fstab to make that happen automatically on boot.
--
Matthias Andree
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Turn off rebooting in single-user mode after fail.
Am 27.07.2009, 12:55 Uhr, schrieb Cristiano Deana cristiano.de...@gmail.com: On Mon, Jul 27, 2009 at 11:59 AM, Paul P.kame...@gmail.com wrote: Hello. How to turn off automatic reboot in single user mode after power fails or sudden reset? Do i need to make passin value in fstab equal to zero just to turn off automatic FSCK fs check? if i understood correctly: rc.conf: fsck_y_enable=YES # Set to YES to do fsck -y if the initial preen fails. This sort of disposed of 8 out of 13 GB on one of my systems after a growfs failure, and after a 24 hrs fsck run... I guess that rsync before fsck could have recovered quite a lot of such data (I can't tell, as I didn't have full image backups). Probably not fsck's fault, but if there is a major file system corruption, it can wreak havoc. -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Fix bin/102299 (has patch in PR)?
Greetings, could anybody have a look at bin/102299 please? The PR contains a patch to fix malloc() differences between GNU libc and FreeBSD's libc, so this should be little effort. Thank you. Best regards -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
Am 05.05.2009, 09:46 Uhr, schrieb Daniel Gerzo dan...@freebsd.org: Manolis Kiagias wrote: I always use -iU too. I've lost motd, passwd, group and master.passwd During mergemaster -p I was asked to merge changes to some of these, and still they were replaced with the newer versions. I don't know what went wrong but have restored them from backup. (I always tar /etc before a source upgrade). Upgrading another system using freebsd-update did not cause any problem. I have the same experience while I was upgrading a few machines upgrading from RELENG_7 to RELENG_7_2. I haven't experienced when upgrading from 7.1-R to 7.2-R. Careful there - RELENG_7 is _newer_ than RELENG_7_2. The latter is branched off RELENG_7 at some point and progresses much slower (as in: errata and security, but no development), so that's no update, but often the reverse. -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7.2-RC2 Available
Am 25.04.2009, 01:23 Uhr, schrieb Ken Smith kensm...@cse.buffalo.edu: The second of the two planed Release Candidates for the 7.2-RELEASE cycle is now available. We believe with the exception of the new bce(4) driver not working with lagg(4) all the major issues that have come up from the testing have been addressed. We will work with the vendor to get that issue addressed post-release. At this point we know of no problems big enough to impact the dates for the rest of the release cycle which is here: http://www.freebsd.org/releases/7.2R/schedule.html Is there any schedule WRT the Release Notes? They[1] were still empty when I checked yesterday, and I find that makes it more difficult than necessary to actually test the RC. Nevermind the schedule, and release when it's done. [1] http://www.freebsd.org/relnotes/7-STABLE/relnotes/new.html -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7.2-RC1 Available
Am 17.04.2009, 19:15 Uhr, schrieb Ken Smith kensm...@cse.buffalo.edu: The first of two planned Release Candidates for the FreeBSD 7.2-RELEASE cycle is now available. Testing of some of the recent work would be particularly appreciated. This includes: Can one peek at the release notes already? The /relnotes.html main links point to empty documents, the snapshots point to 7.0 release notes. Particularly, can FreeBSD 7.2 support 256-byte inodes in ext2fs? -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: problem with cold hardware? [Was: panic in callout_reset: bad link in callwheel]
Andriy Gapon schrieb: on 28/01/2009 21:22 Andrew Snow said the following: Andriy Gapon wrote: Previously I heard about problems with hardware running hot, but not with it being cold. I put the word in quotes, because the system is in a room with normal room temperature. Any guesses what hardware part might be acting up like this? Power supply. Give all the capacitors a visual check. Or you may be drawing too much power from your rated supply. Right on the target. I opened the PSU after replacing it, visually it looks OK (too me), nevertheless I have verified that the fault was in it. Thank you and everybody who helped! Electronic devices, including computers, that become unable to /cold/ boot (and need a reset some seconds or minutes after power-up) usually suffer from dry or leaked capacitors, either in the PSU or - I've seen that more often - the voltage regulator on the main board. Dry capacitors often look innocuous, unlike leaked ones that show brownish stains (electrolytes) on the cap or underneath. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
7.1-RELEASE growfs/fsck_ffs woes
Greetings, I have a hard time with file system access. Here's the story: I'd been unhappy about GEOM_JOURNAL within the same provider as my /usr and /var partitions (used JOURNAL on a fresh install), it would occasionally give up on fsync() for lock messups (FreeBSD 7.1-RELEASE-p2). Several weeks ago, I reverted my -o async journalled /var to softupdates without journal, with no ill effects. AFAIR, I installed with gjournal label with just one provider, and then newfs UFS2 with journal. Earlier today, I disabled the journal on /usr (shutdown to single user mode, dismount, gjournal sync, gjournal stop, gjournal clear, tunefs -J disable, kldunload geom_journal, fsck) - that worked, and fsck preen considered the FS clean. I tried to resize the partition to its full size with growfs; and it warned about being unable to allocate some 58,000 blocks, but performed the operation (i. e. I got a list of superblocks) - apparently it completed. A subsequent fsck -f however turned up with a gazillion of DUP blocks, in random places. I have no explanation for that; am currently running fsck -y. Accidentally, I ran growfs twice, but the second run didn't seem to do a lot - it just warned it couldn't allocate 58,600+ sectors and quit. I've also found that fsck_ffs's pass 1b is EXTREMELY slow, and from a cursory glance at pass1b.c, some none-scalable (as in O(n^2) or worse) effects seem to be at play. I'm currently away from the machine, but any insights on the growfs corruption and/or pass1b.c accelerators are welcome - ext2fsck is a lot faster when doing deep searches for duplicate blocks (pass 1b and pass 1c), but I haven't checked the code. The partition slice is several GB in size with default newfs settings, but not overly huge ( 100 GB), and last time I checked, it had taken around 30 min for scanning 7 out of 78 (IIRC) cylinder groups. I hope fsck doesn't do more damage... ;-) This is an Athlon XP 2500+ (later Barton version with 512 kB L2 cache) with 1 GB of RAM and a reasonably fast Maxtor 250 GB SATA drive, with a reasonably fast fsck if pass1b isn't needed (perhaps two or three minutes). I've recompiled fsck_ffs with -O3 -march=athlon-xp to peep cycles, but compiler optimization cannot fix slow algorithms. Thanks in advance, Matthias ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
make delete-old misses files, breaking KRB5-related builds
Greetings, I am a long-time user of FreeBSD (I think my oldest installations used to be 4.0 and have been upgraded ever since). Not quite recently, the build targets for make delete-old and make delete-old-libs were added, and I thought there were sort of useful to get rid of crap after updates. However, something somehow somewhen dropped old gssapi_generic.h and related files into /usr/include/gssapi which sat there waiting to wreak havoc on port builds on later 6.X or 7.0 releases. Either some port installed outside $PREFIX, or these used to be part of the system and got removed before the make delete-old framework was put into place. Wreak havoc means mislead configure scripts of several packages (GNOME-related in my case) to believe some other installation was there, but it wouldn't work because some parts of the system were missing/changed... I ended up manually figuring out what got installed and kill everything that had no source... an enormous effort. What I would like to have is a means of compare what gets installed into /bin /sbin /libexec /lib /usr/bin /usr/sbin /usr/include /usr/lib /usr/libexec and other standard system directories to what's actually in those directories - such a comparison would have easily allowed me to spot the problem areas. Comparing file dates doesn't work properly, else a find /usr /lib* /*bin -name local -prune -or \( -mtime 30 -print \) after a make installworld would be the easiest thing to do... but some parts of the system use install -C (probably to avoid excessive recompiling or relinking). So what's the canonical way to installworld into a staging area so I can just compare or rsync --del system directories? -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recommendations for a serial port card you can actually BUY?
Karl Denninger [EMAIL PROTECTED] writes: Uh, if you unplug a working serial device's USB cable, you've got bigger problems :) So you think? USB is hotplug, and it doesn't have to be a port in use that you're unplugging. If you plug and unplug ONLY ONE, it should ID in the same place, since there's a hole. If you plug / unplug more than one, I can live with the penalty being a required reboot. After all, these are NOT supposed to be tampered with while the machine is running! OK, that makes things easier. Perhaps un-/reloading the kernel driver modules (if compiled as module) is sufficient anyways -- the module will probably reprobe everything upon reload; OTOH you can check usbd and devd and things if you can pin devices to certain ordering. -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recommendations for a serial port card you can actually BUY?
Karl Denninger [EMAIL PROTECTED] writes: Much of the latter hardware is still only available in a serial interface, no matter the cost. It is not high-data-rate by any means (typically 4800 or 9600 bps) but it is what it is. Personally, I've seen lots of 14k4 fax stuff deployed, but then again, doesn't matter much. Anyways, in that previous life when I bought my hardware (for FreeBSD 4.X that was), there have been FourPort-compatible cards (not original AST, but third-party with the same register layout and functionality, including interrupt vector registers that FreeBSD 4.x couldn't use, but Linux) -- I got the ISA variant, there have also been PCI specimen but haven't tried them. I'm not sure how I would configure the PCI stuff for FreeBSD though, I've only ever used ISA and the instructions the vendor (VSCom) shipped were for Linux's setserial(8)... Serial over IP will not work for either. Serial-via-USB might, and I will look into that, but I suspect I'm going to get in trouble with that one, especially if I have to toggle control signals (e.g. DTR, etc) or support hardware flow control (and for the fax servers, you DO need it if you expect things to work correctly.) I'd be less concerned about those than about issues with getting things to work in real-time, or perhaps USB hub quality... USB isn't meant for that type of real-time thing, but for commodity. It doesn't matter if your keypress arrives a ms sooner or later, but it does matter for your serial bytes. Buying several different USB-to-RS232-converters isn't an issue financially anyways if you're ready to spend 500 dollars - these cost perhaps 10 a piece. Only you're often not sure you're getting the same hardware next time you order the same article number, because this stuff is often made in Indonesia or China or some place like that and brands seem to do some kind of manufacturer hopping there, and it's not sure that the manuf' sticks to the specs... ask Techsolo about USB 2.0 hubs. its hands when you plug it in. I wasn't aware that the USB to Serial converters would work - I can try them, but there are a lot of those out there that don't work right even under Windows - expecting them to under FreeBSD might be asking too much. It's a matter of trying them -- there are examples of cheapo hardware where FreeBSD seems to work better. Not that it helps your issue, but the Windows 2000 drivers (all versions I could find, RATech and Edimax) for RATech 2500 WLAN chips for instance is plain growse and next to unusable; the Linux driver is flakey, the FreeBSD 6.1 driver however is rock solid (but unusable, among other IEEE 802.11 stuff, under 6.0...) -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recommendations for a serial port card you can actually BUY?
Karl Denninger [EMAIL PROTECTED] writes: I think there may be another option. Here's the boot message, with just USB related things: usb0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 usb0: USB revision 1.0 usb1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 usb1: USB revision 1.0 usb2: Intel 82801EB (ICH5) USB controller USB-C on uhci2 usb2: USB revision 1.0 usb3: Intel 82801EB (ICH5) USB controller USB-D on uhci3 usb3: USB revision 1.0 usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0 usb4: USB revision 2.0 Now, isn't this in fact invarient? That is, isn't the probe on the bus going to be the same across boots? This is effectively inheriting PCI order, so unless you're changing PCI configuration, these are in fact stable. We can then get which device is on which port with Fs:/disk/karl usbdevs -v ...until the moment one is un- and re-plugged, right? At least my two USB printers (easily told apart from the vendor ID) like to rearrange their ordering frequently on Linux... -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gzip is faster with -O3
Nikolas Britton [EMAIL PROTECTED] writes: dd if=/dev/random of=testfile bs=1m count=5000 1. gzip isn't usually used to compress incompressible data. 2. use time to figure out how much CPU time it actually burns. 5 GB are somewhat I/O bound, but gcc options don't help with that, so CPU time is better than wallclock time. gzip compiled with -O3: # date ; nice -10 ./gzip -c9 testfile testfile.gz ; date Wed Aug 9 08:01:21 CDT 2006 -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade bug: -M no longer works after v2.1.0
Atanas [EMAIL PROTECTED] writes: Recent portupgrade versions no longer obey the -M command line switch, i.e. any optional arguments to be prepended to each make command. How to reproduce: # portinstall -M APACHE_HARD_SERVER_LIMIT=1024 www/apache13 ... === src/ap cc -c -I../os/unix -I../include -I/usr/local/include -funsigned-char -O2 -fno-strict-aliasing -pipe -DDOCUMENT_LOCATION=\/usr/local/www/data\ -DDEFAULT_PATH=\/bin:/usr/bin:/usr/local/bin\ -DHARD_SERVER_LIMIT=512 `../apaci` ap_cpystrn.c ... Note the -DHARD_SERVER_LIMIT=512 above. Does it work if you type (you can omit the env in /bin/sh, bash, (pd)ksh and other Bourne-like shells): env APACHE_HARD_SERVER_LIMIT=1024 portinstall www/apache13 (Isn't it time to migrate to a newer Apache version anyways? 8-) ) -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Installation on Linux LVM Logical Volumes (LV)?
Alexander Skwar [EMAIL PROTECTED] writes: Good morning! Ever thought that there might be more than Europe and Africa on the lists? [...] Does FreeBSD support Linux LVM2? No. You need a primary partition. -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How can I know which files a proccess is accessing?
Eduardo Meyer [EMAIL PROTECTED] writes: On 6/6/06, David Wolfskill [EMAIL PROTECTED] wrote: You may find the lsof port useful for answering such questions. I tried it, but it seems that I found some limitations: lsof: no local file space at PID 16543 # ps 16543 PID TT STAT TIME COMMAND 16543 ?? S 0:02.43 /usr/local/sbin/httpd -k start -DSSL Any tuning would do the job? Are you running with tightened up security that might prevent fstat from accessing /dev/kmem? I don't know fstat failures from experience or what causes it to just show inode numbers - perhaps delete files that are still open. I'm unsure about the reason for lsof's complaint; if you installed a package, try rebuilding the port. Something different, if fstat and lsof continue to fail: you may try attaching a syscall tracer such as truss, ktrace or strace (the latter from ports) to the process and see if it leaks file descriptors. This may fail due to permissions however. -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fwd: Problem with modern Postfix on 4.7
Scott Harrison [EMAIL PROTECTED] writes: There was a suggestion on the web indicating that binutils is the problem and that that should be updated. However, I do not know the proper way to go about updating binutils. Can someone please tell me how to do it or point me to a resource that does? NOTE I haven't tried to understand all of your two posts. The easiest solution is probably to update FreeBSD 4.X using the official ways described in the handbook, I'd suggest using 4.11, as 4.10 is about to be discontinued, and kernel and base system security fixes are only provided for 4.10 and 4.11 at this time. The ports tree has been requiring FreeBSD 4.8 at a minimum for a very long time now, and I'd expect that even that it requires 4.11 soon enough. -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Security Survey
Scott Long [EMAIL PROTECTED] writes: I share this frustration with you. I was once told that the pain in upgrading is due largely to a somewhat invisible difference between installing a pre-compiled package, and building+installing a port. In theory, if you stick to one method or the other, things will stay mostly consistent. But if you mix them, and particularly if you update the ports tree in the process, the end result is a bit more undefined. One thing that I wish for is that the ports tree would branch for releases, and that those branches would get security updates. I know that this would involve an exponentially larger amount of effort from the ports team, and I don't fault them for not doing it. Still, it would be nice to have. Speaking as a port maintainer, if these branches would allow to just MFC updates from HEAD that are proven and meet dependency requirements for the new version, I think I'd be able to handle this. The major ports for concern I maintain (db3* db4*) have forked minor versions for compatibility anyways. If it's a bugfix only policy that may involve ripping out the minimum fix out of a larger patch set, it'll pretty much be a non-starter for me unless someone funds that work. -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
port vs. packages vs. FreeBSD updating (was: FreeBSD Security Survey)
Scott Long [EMAIL PROTECTED] writes: I share this frustration with you. I was once told that the pain in upgrading is due largely to a somewhat invisible difference between installing a pre-compiled package, and building+installing a port. Well, the last time I saw this as a major issue was when people were innocently attempting to install packages fetched from packages-6-stable .tbz with rcNG scripts, that already expected a 6.1 base system (rcorder(8) migration) on 6\.0-RELEASE(-p.*)? - this failed horribly for some users with services not being started since the new rcNG script naming wasn't at the time supported by the base system. These issues did not ever affect, AFAICS, building ports from source -- however, doing this requires a lot of machine horsepower. Regardless of the creation of a stable ports branch, I'd URGE to add minimum and maximum OSVERSION required tags to packages to prevent their being installed on incompatible systems. -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.1 Released
Mike Jakubik [EMAIL PROTECTED] writes: Jonathan Noack wrote: The *entire* errata page was from 6.0; it was a mistake. This wasn't some put on the rose-colored classes and gloss over major issues thing. It was a long release cycle and something was forgotten. C'est la vie. It's always a good idea to check the most up-to-date version of the errata page on the web anyway, so it's *not* too late to update it. How convenient. These problems needed to be addressed in the release notes, not some on line version. You lost connection to the ground, Mike. Come back please :-) People make mistakes, and that applies to both the code as to the documentation, and users will know that sometimes problems will be found only after the release so they'll check online later when running into a problem. The 6.1 release announcement already mentioned the errata lapsus BTW and asked people to check on-line, so it appears someone's asking for perfection -- but it was decided months ago to stick to a schedule rather than making perfect releases. Having said that, 6.1 is a real and visible improvement over 6.0 for me. 6.1 is usable, where 6.0 toppled over every few minutes (I'm talking about ral(4) and other nasty stuff such as tmpfs/mdmfs panics in 6.0 - ral(4) is what prompted me to do the 5.4-6.0 upgrade). -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 RELEASE and Volume Managers
Yousef Raffah [EMAIL PROTECTED] writes: I'm trying to install a new server which has a hardware RAID controller. Hardware RAID controllers such as amr(4) or twe(4) (I've seen LSI MegaRAID SCSI 320-1 and 3Ware Escalade 8006-2 LP, the latter is a 2-port SATA controller and can't do RAID5 for lack of ports) stuff usually presents a whole logical unit as a single SCSI drive (/dev/da0 for the first disk array, /dev/da1 for the second and so on), so you shouldn't need vinum, geom or anything like that - just the driver would suffice. If you need vinum or geom to implement a RAID then chances are your so-called hardware RAID is actually fake (fakeraid) and really software RAID. Adaptec HostRAID and the RAID in intel's ICH x-R chipsets falls into this fakeraid category. The vendors don't like to present it as software RAID, so that particular bit is extremely hard to find :-( What is the brand and model of your so-called hardware RAID? -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA RAID: Adaptec 1420SA, Promise TX4300?
Daniel O'Connor [EMAIL PROTECTED] writes: On Sunday 02 April 2006 05:20, Lars Cleary wrote: Why don't you just use gmirror(8) and do software RAID 1? IMHO a controller just for RAID 1 is unnecessary, as the OS together with a reasonable motherboards disk controller is just as fast as any RAID controller. You can't boot off a system with a dead primary disk with software RAID1. (well you MIGHT but.. in any case RAID1 cards are quite cheap) It's a matter of the BIOS: will it complain, or will it proceed to the next SATA disk? -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA RAID: Adaptec 1420SA, Promise TX4300?
Tenebrae [EMAIL PROTECTED] writes: On Sat, 1 Apr 2006, Matthias Andree wrote: RAID1 is _not_ a backup, but an availability aid. If going for RAID1, be sure to add a backup solution. More to think about...thank you. I am trying to get some peace of mind on a budget, though. I suppose I need to give more consideration to what my priorities are since I don't think I will be able to do all that should be done. Yup. In doubt, prefer backup hardware (and if only two external 300 GB drives with USB 2.0 Hi-Speed or IEEE 1394 connector) over RAID. People will forgive you if the machine is down for a few hours, but they'll jump on you if you lose their data for good. And having backups on disconnected media that don't break if a surge manages to pass through your power supply is essential. Be sure to get something that is real hardware RAID. You don't need to pay for software RAID, you usually get that for free with the onboard chipset these days. The motherboard in question is a Tyan Thunder HEsl-T (S2688). It's a hand-me-down, but still beats the pants off of anything else I've got at the moment. Well, that board has two(!) onboard Ultra160 SCSI channels, good enough for 30 UW/U2W/U160/U320 drives (software RAID), and it has a Zero-Channel-RAID option if you want hardware RAID. SCSI drives are usually longer-lasting than SATA commodities. Speaking from experience with SATA RAID and SCSI RAID, the latter is much better worked-out. No way. Real RAID costs more than twice as much for 4 ports. 150 bucks suffice only for the 2 port warm-plug (i. e. you need to manually mark the drive for removal in the software or BIOS, then exchange it , then manually start the rebuild operation in software or BIOS) 3Ware (now AMCC) Escalade 8006-2LP. Ah, I see. The 8506-4LP seems to be discontinued from my vendor, but they do carry the 8006-2LP in that price range. If you can do with 2 drives that is, and can do without being able to Alt+3 from your remote management board. If you want remote management, you need to get the 9000 series AFAIR. -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA RAID: Adaptec 1420SA, Promise TX4300?
Tenebrae [EMAIL PROTECTED] writes: I'm interested in this newfangled serial ATA stuff I've been hearing about (heh) and thought I might try my hand at getting a RAID1 mirror going on for my home dirs. Sadly, I have no experience with RAID. I had initially planned on just setting up two identical drives and using one to periodically back up the data, but have been told RAID1 is a better way to do this. Now I need to figure out what type of controller card to get and was hoping for some input on affordable cards. RAID1 is _not_ a backup, but an availability aid. If going for RAID1, be sure to add a backup solution. Simple scenario: If you type rm, your files are gone from both disks with RAID1. With regular synching, even without versioning files, you have time until the next synch operation to retrieve accidentally deleted files. With real backups, the deleted files will be available for longer. I was looking at the Adaptec Serial ATA II RAID 1420SA and Promise FastTrak TX4300 4-port SATA RAID PCI adapters. I did find a note on the Promise card that it is now supported in Current. Is this something that might make its way into the 6.x-STABLE branch at some point? Also, I have heard that there is bad blood of some sort between Adaptec and FreeBSD. I am not interested in a flame war ensuing, but if there is limited to no support, I'd like to know so that I can avoid their cards. Forget both cards. Neither of the two is hardware RAID, see: http://www.brentnorris.net/blog/?p=158 http://linuxmafia.com/faq/Hardware/sata.html Cheating people and selling software RAID cards where the BIOS or driver has to do the mirroring has become quite popular with SATA RAID. Be sure to get something that is real hardware RAID. You don't need to pay for software RAID, you usually get that for free with the onboard chipset these days. BTW, does FreeBSD 6.1 support the ICH7-R already? 6.0 did not. Hopefully those two cards give an idea of the price range and requirements of the cards I'm looking at: 4 ports for future expansion, around $150 US (or less), No way. Real RAID costs more than twice as much for 4 ports. 150 bucks suffice only for the 2 port warm-plug (i. e. you need to manually mark the drive for removal in the software or BIOS, then exchange it , then manually start the rebuild operation in software or BIOS) 3Ware (now AMCC) Escalade 8006-2LP. This is quite a long card, it doesn't fit the LP slot in the Fujitsu-Siemens Primergy RX100S3 because the humongous CPU cooler gets in the way. So check the dimensions before ordering anything. FreeBSD's driver for the AMCC/3Ware/Escalade 5000 - 8000 series is twe(4), the newer 9500 series adaptors are supported by the twa(4) driver, and the driver for the better MegaRAID SATA cards is amr(4). I don't know though which of these have working FreeBSD monitoring/administration utilities, I'm using Escalade 8000 and MegaRAID SCSI with Linux. low profile PCI for a rack-mount case. Are either of these two cards supported in FreeBSD 6.x-STABLE? If it makes any difference, I plan to buy a pair of these drives for it: Maxtor DiamondMax 10 300GB Hard Drive 6V300F0, Serial ATA 3.0Gb/s, 7200 RPM, 16MB Cache. Are you fixed on Maxtor? Personally, I'd prefer Samsung, Seagate, Western Digital (in alphabetic order). Note that some better real Hardware RAID cards have one controller per SATA channel, there it doesn't actually matter if you get a SATA-I drive/controller or a SATA-II drive for those, you aren't going to max out 1.5 Gb/s with any drive, not even the newer Raptors. If you want NCQ, check if the controller supports it, or forget about NCQ and get a controller with battery backup unit (rare with SATA) and use copyback (writeback) caching. But don't ever dare use write caching without at least a dedicated UPS: the corruption patterns of UFS with write caches on are extremely destructive, been there, seen that -- with a test machine and only a small 2 MB on-drive write cache. -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Which PCI SATA controller?
[EMAIL PROTECTED] writes: Sorry ... just to clarify, this would be running 6.0 and it needs to be a 32bit card ... so as awesome as 3ware cards might be, it does me little good ... What's the problem with 64-bit cards? Aren't PCI cards exchangable as long as 1. the voltages match (i. e. your card must cope with 5 V if your PCI slots are 5 V), 2. the card fits mechanically? I know some 3Ware cards are too long; for instance, the 8006-2LP doesn't fit into a FSC Primergy RX100S3's LP slot - it would bump into the monstrous CPU cooler. There are PCI cards that work with 3.3 and 5 V, they have two of these notches. See http://www.digi.com/pdf/prd_msc_pcitech.pdf for discussion of voltages in PCI cards. -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
Erik Trulsson [EMAIL PROTECTED] writes: Hardcoded paths in scripts are a mess. What if I installed Perl into /opt/mumble on some other machine? /usr/freeware? /what/ever? Changed $PREFIX and/or $LOCALBASE? Then you would have nobody but yourself to blame. So ports not heeding PREFIX or LOCALBASE aren't buggy? Interesting POV. And what about all the scripts that administrators and users write that are not part of any port? Scripts that were written according to the de-facto standard that having '#!/usr/bin/perl' on the first line of the script will work correctly. As mentioned before, #! /usr/bin/env perl is the canonic SHORT way to run perl, longer ways are in perlrun(1). -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
Kris Kennaway [EMAIL PROTECTED] writes: In other words, it's an impossible dream to hope that all scripts will conform to this or any of the other possible choices (remember the perl motto). Even making everything perl in the ports collection use a uniform style is probably an infeasible task (recall 840 ports use /usr/bin/perl, and that's not counting the others that use another hardcoded variant of /usr/local/bin/perl). Well, broken ports are marked broken and removed after some months. How would broken Perl ports justify special treatment? -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
Holger Kipp [EMAIL PROTECTED] writes: a) we had perl at /usr/bin/perl = many scripts are using #!/usr/bin/perl b) we have a symlink now = many new scripts are using #!/usr/bin/perl c) many ISPs have even more users who assume #!/usr/bin/perl works. = removing a symlink to create lots_of_trouble(tm) is not the freebsd-ish way of live. this single symlink is needed. The admin who wishes to have that symlink can place one himself. Why burden the base system with it if it has no use for Perl? -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
Holger Kipp [EMAIL PROTECTED] writes: It violates POLA on 5-STABLE, and it will violate POLA on 6-CURRENT, especially as most perl programmers assume /usr/bin/perl to be the correct path. POLA doesn't apply to -CURRENT. -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
Oliver Lehmann [EMAIL PROTECTED] writes: Anton Berezin wrote: In practical terms this will mean a one-time sweep of your scripts in order to convert them, in a typical case, from #! /usr/bin/perl to #! /usr/local/bin/perl. Wouldn't that break most of the 3rd party scripts out in the world? Hardcoded paths in scripts are a mess. What if I installed Perl into /opt/mumble on some other machine? /usr/freeware? /what/ever? Changed $PREFIX and/or $LOCALBASE? I'd say let the ports patch the right location at install time and if they break after upgrading both perl and the port, they deserve no better. -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
4.11-RC3: SCSI+UFS+softupdates corruption (write cache DISABLED!)
Hi, I had a FreeBSD 4.11-RC3 machine reboot without advance notice, the last logging the network syslogd captured was attempted aic0 (Adaptec 2940 UW Pro) recovery. Syslog excerpt as captured by the remote machine, with date and hostname /kernel: and card state dumps removed (can be provided if necessary). I wonder if the SCSI error recovery attempts caused the reboot, I have no hints either way, but this machine is otherwise stable. 13:28:35 ahc0: Recovery Initiated 13:28:53 (da0:ahc0:0:0:0): SCB 0x16 - timed out 13:28:53 sg[0] - Addr 0x6da3800 : Length 2048 13:28:53 (da0:ahc0:0:0:0): Other SCB Timeout 13:28:53 ahc0: Timedout SCBs already complete. Interrupts may not be functioning. 13:28:53 ahc0: Recovery Initiated 13:29:02 (da0:ahc0:0:0:0): SCB 0x1b - timed out 13:29:04 (da0:ahc0:0:0:0): BDR message in message buffer 13:29:04 ahc0: Timedout SCBs already complete. Interrupts may not be functioning. 13:29:04 ahc0: Recovery Initiated 13:29:16 Kernel Free SCB list: 9 4 15 20 13:29:17 sg[7] - Addr 0x3bea000 : Length 4096 13:29:18 ahc0: Issued Channel A Bus Reset. 25 SCBs aborted As the machine rebooted up, it remained in single user due to a softupdates inconsistency fsck reported: | # fsck -p /usr | /dev/da0s1g: DIRECTORY CORRUPTED I=175105 OWNER=root MODE=40755 | /dev/da0s1g: SIZE=512 MTIME=Jan 18 15:14 2005 | /dev/da0s1g: DIR=? | | /dev/da0s1g: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY. I have not yet run fsck for interactive repair, because I want to know what is going on here and allow debugging this. At the time of the crash, these tasks were running: 1. amanda was running a dump(8) 2. I was installing manpages from /usr/src/share/man/man4 3. a cvsup for the ports tree was running (this is likely related to the problem) | # fsdb -r /dev/da0s1g | fsdb (inum: 2) inode 175105 | current inode: directory | I=175105 MODE=40755 SIZE=512 | MTIME=Jan 18 15:14:48 2005 [0 nsec] | CTIME=Jan 18 15:14:48 2005 [0 nsec] | ATIME=Jun 19 03:05:43 2003 [0 nsec] | OWNER=root GRP=wheel LINKCNT=2 FLAGS=0 BLKCNT=4 GEN=4e5151f9 | fsdb (inum: 175105) cd .. | component `..': fsdb: name `..' not found in current inode directory I checked with camcontrol, the write cache is off (see below), but the queue algorithm modifier is on and cannot be switched off. Digging through the old structures, with find, reveals: | 1751014 drwxr-xr-x3 root wheel 512 Sep 1 2002 /usr/X11R6/lib/perl5/site_perl/5.005/i386-freebsd | 1751024 drwxr-xr-x2 root wheel 512 Sep 1 2002 /usr/X11R6/lib/perl5/site_perl/5.005/i386-freebsd/auto | 1751034 drwxr-xr-x5 root wheel 512 Aug 23 2002 /usr/sup | 1751044 drwxr-xr-x2 root wheel 512 Jan 19 13:29 /usr/sup/src-all 1751054 drwxr-xr-x2 root wheel 512 Jan 18 15:14 /usr/sup/ports-all | 1751064 drwxr-xr-x2 root wheel 512 Jan 18 15:14 /usr/sup/doc-all | 1751074 drwxr-xr-x 22 root wheel1024 Sep 28 19:47 /usr/doc | 1751084 drwxr-xr-x6 root wheel 512 Dec 19 13:26 /usr/doc/de_DE.ISO8859-1 | 1751094 drwxr-xr-x5 root wheel 512 Dec 27 2003 /usr/doc/de_DE.ISO8859-1/books And, as expected: | # ls -la /usr/sup/ports-all/ | # Why can, under such circumstances, a softupdates filesystem become corrupt so that fsck -p cannot fix it, and it loses has directories without . and ..? kernel/softupdates bug? How can this directory become empty? locate has this information recorded: /usr/sup/ports-all /usr/sup/ports-all/#cvs.cvsup-2279.0 /usr/sup/ports-all/checkouts.cvs:. so apparently, three (checkouts.cvs:., . and ..) or four files (perhaps the # file) have disappeared. I'm not sure if fsck will revive them, I want to avoid destroying data useful for debugging. Is the Queue Algorithm Modifier a problem? (see below) I cannot set this to 0 on this drive, camcontrol: error sending mode select command with -P0 and -P3. (Micropolis 4345WS) How do I go about providing the file system metadata so someone can take a look at it? The file system is 3.5 G in size, so anything that goes beyond meta data is not feasible. Providing SSH access to the failed machine may work though if I'm sent your OpenSSH v2-format key. # camcontrol inquiry da0 pass0: MICROP 4345WS x43h Fixed Direct Access SCSI-2 device pass0: Serial Number 77HT45 pass0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled # camcontrol modepage da0 -m8 IC: 0 ABPF: 0 CAP: 0 DISC: 0 SIZE: 0 WCE: 0 MF: 0 RCD: 0 ... # camcontrol modepage da0 -m10 RLEC: 0 Queue Algorithm Modifier: 1 QErr: 0 DQue: 0 ... -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman
Re: 4.11-RC3: SCSI+UFS+softupdates corruption (write cache DISABLED!)
Matthias Andree [EMAIL PROTECTED] writes: so apparently, three (checkouts.cvs:., . and ..) or four files (perhaps the # file) have disappeared. I'm not sure if fsck will revive them, I want to avoid destroying data useful for debugging. OK, I dd'd the whole partition to an SLR tape and ran fsck for interactive repairs. | ** /dev/da0s1g | ** Last Mounted on /usr | ** Phase 1 - Check Blocks and Sizes | ** Phase 2 - Check Pathnames | DIRECTORY CORRUPTED I=175105 OWNER=root MODE=40755 | SIZE=512 MTIME=Jan 18 15:14 2005 | DIR=? | | UNEXPECTED SOFT UPDATE INCONSISTENCY | | SALVAGE? [yn] y | | MISSING '.' I=175105 OWNER=root MODE=40755 | SIZE=512 MTIME=Jan 18 15:14 2005 | DIR=? | | UNEXPECTED SOFT UPDATE INCONSISTENCY | | FIX? [yn] y | | MISSING '..' I=175105 OWNER=root MODE=40755 | SIZE=512 MTIME=Jan 18 15:14 2005 | DIR=/sup/ports-all | | UNEXPECTED SOFT UPDATE INCONSISTENCY | | FIX? [yn] y | | ** Phase 3 - Check Connectivity | ** Phase 4 - Check Reference Counts | UNREF FILE I=176801 OWNER=root MODE=100644 | SIZE=14098161 MTIME=Jan 18 15:14 2005 | RECONNECT? [yn] y | | NO lost+found DIRECTORY | CREATE? [yn] y | | UNREF FILE I=179558 OWNER=root MODE=100644 | SIZE=8327913 MTIME=Mar 20 03:11 2004 | RECONNECT? [yn] y | | ** Phase 5 - Check Cyl groups | FREE BLK COUNT(S) WRONG IN SUPERBLK | SALVAGE? [yn] y | | SUMMARY INFORMATION BAD | SALVAGE? [yn] y | | BLK(S) MISSING IN BIT MAPS | SALVAGE? [yn] y | | 243085 files, 1465923 used, 274252 free (102444 frags, 21476 blocks, 5.9% fragmentation) | | * FILE SYSTEM MARKED CLEAN * | | * FILE SYSTEM WAS MODIFIED * Turns out the missing two files ended up in lost+found. Is this a failure mode that is allowed to happen for softupdates? -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: remaining FreeBSD 4.11-RC3 bugs
Ken Smith [EMAIL PROTECTED] writes: On Mon, Jan 17, 2005 at 10:28:53AM +0100, Matthias Andree wrote: critical: kern/60313 (silent data corruption on block devices) still open, may be FreeBSD 4 specific after the GEOM flurry in FreeBSD 5 and 6. I took a look at that one. The patch provided doesn't map exactly into RELENG_4 but I gave this a try: Some (similar) attempts are in the mailing list archives, but none ended as a complete fix and stopped halfway for various reasons, usually lack of time or interest. I know too little about kernel internals as to be of any help here, besides testing. With that in place the kernel won't boot because the stuff dealing with disk labels in at least two places on my machine didn't set the offset properly in the buf structures it used. Once I fixed that the machine booted but *some* executables wouldn't start because spec_getpages() was doing reads with an offset of 256 (DEV_BSIZE is 512). These some executables may well have been reading the wrong data since the block devices have become unbuffered... if unaligned, the seek offset is silently rounded down to the previous block margin. I'll see if I can follow up on this and eventually get RELENG_4 fixed (and perhaps even an Errata) but there is no way I'd be comfortable with a fix for this going into 4.11 unless an expert worked on it and we did an RC4. I can understand that. serious: bin/71453 (tcpdump ipv6 crash, trivial fix -- MFC sufficient) still open It looks like the right way to fix this is with a fresh vendor import if I'm understanding things correctly. Again something that would require more time than we have and might be best handled as an Errata item after the release. If the FreeBSD 4.11-RC tcpdump is essentially the same as the FreeBSD tcpdump around 5.3, the import of a single fix may be sufficient. It's only that the tcpdump executable does The Wrong Thing when encountering PPP packets to negotiate IPv6 - it faults, rather than reporting an unknown packet and moving on. The patch quoted in the PR fixes only that bogus abort. bin/46866 (false data from getpwent, easy to fix) still open There has been ongoing disagreements about how best to handle this one, as far as I can tell the disagreements are still ongoing. If FreeBSD prefers non-deterministic results with all non-repeatable and hard to debug consequences such as mail bouncing, users denied login and so on, well. The only reason brought forth in support of the current behavior was the measly we've always done it this way and perhaps we don't know what will break if. Neither is a valid justification to keep the bug in. Note this change need only happen for functions with insufficient interfaces, i. e. those that cannot report a difference between temporary and permanent error, such as getpwent(), and AFAICT the lookups happen in user-space, so SIGINT would work. -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
remaining FreeBSD 4.11-RC3 bugs
Ken Smith [EMAIL PROTECTED] writes: Announcement The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 4.11-RC3. This will be the last Release Candidate for the FreeBSD 4.11 release unless a show-stopper problem is found while testing RC3. critical: kern/60313 (silent data corruption on block devices) still open, may be FreeBSD 4 specific after the GEOM flurry in FreeBSD 5 and 6. serious: bin/71453 (tcpdump ipv6 crash, trivial fix -- MFC sufficient) still open bin/46866 (false data from getpwent, easy to fix) still open non-critical: kern/44260 (missing device in LINT configuration) is long-standing although trivial to fix (patch included) -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: remaining FreeBSD 4.11-RC3 bugs
[Cutting down Cc: list.] On Mon, 17 Jan 2005, Wilko Bulte wrote: Why is it that people always wait til at least RC3 to scream murder about their favorite PR? I for one have regularly reported these PR numbers, last time after 4.11-RC1. I haven't re-reported them against -RC2 because I was too busy to do that at the time, and when I had the time, -RC3 was already out. So... are we supposed to flood developers with reminders weekly? Most certainly not, we still want them to be able to do actual work. And it's certainly not my fault that bugs reported against 4.7 or so with patches attached remain unfixed in 4.11-RC3 when a reminder has been sent after 4.11-RC1... What this means for code quality is left to the reader's appreciation. -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: remaining FreeBSD 4.11-RC3 bugs
My open 4.11* bug list is now down to: critical: kern/60313 (silent data corruption on block devices) still open, may be FreeBSD 4 specific after the GEOM flurry in FreeBSD 5 and 6. serious: bin/71453 (tcpdump ipv6 crash, trivial fix -- MFC sufficient) still open bin/46866 (false data from getpwent, easy to fix) still open -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 4.11-RC3 GCC preprocessor failure
Submitter-Id: current-users
Originator:Matthias Andree
Organization:
Confidential: no
Synopsis: FreeBSD 4.11-RC3 GCC preprocessor failure
Severity: critical
Priority: high
Category: gnu
Class: sw-bug
Release: FreeBSD 4.11-RC3 i386
Environment:
System: FreeBSD libertas.emma.line.org 4.11-RC3 FreeBSD 4.11-RC3 #17: Mon Jan
17 21:44:19 CET 2005 [EMAIL PROTECTED]:/usr/src/sys/compile/LIBERTAS i386
Description:
GCC 2.95.4 cannot compile e2fsprogs development version while GCC 3.3 is fine.
The preprocessor fails to expand a macro with a longish name, error message:
making all in lib/e2p
gmake[2]: Entering directory `/tmp/e2fsprogs/build/lib/e2p'
CC ../../../lib/e2p/feature.c
../../../lib/e2p/feature.c:50: `EXT3_FEATURE_INCOMPAT_EXTENTS' undeclared here
(not in a function)
../../../lib/e2p/feature.c:50: initializer element is not constant
../../../lib/e2p/feature.c:50: (near initialization for `feature_list[12].mask')
gmake[2]: *** [feature.o] Error 1
type: less lib/e2p/feature.iand type /EXT3 and press the enter key
to see the problem area:
{ 1 , 0x0008 ,
journal_dev },
{ 1 , EXT3_FEATURE_INCOMPAT_EXTENTS,
extents },
{ 1 , 0x0010 ,
meta_bg },
GCC 3.3 will properly replace EXT3_FEATURE_INCOMPAT_EXTENTS with 0x0040
(install lang/gcc33, then gmake CC=gcc33)
How-To-Repeat:
- install devel/gmake port
- install devel/bibktkeeper port (see PR #76208 if it's uncommitted)
- cd to a writable directory with some 30 MB room
- type these commands to check out, configure and build the code:
#
# the next three commands will clone the repository and check it out
#
bk clone -qr'[EMAIL PROTECTED]|ChangeSet|20050117193220|14963' \
bk://thunk.org:5000/ e2fsprogs/
cd e2fsprogs
bk -Ur get -Sq
#
# now do the build
#
mkdir build
cd build
../configure -C CFLAGS=-O -save-temps
gmake
Fix:
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gnu/76381: FreeBSD 4.11-RC3 GCC preprocessor failure
Oops. The port is devel/bitkeeper. As this requires registration, I made a tarball, which will not lie around forever though. http://home.pages.de/~mandree/tmp/e2fsprogs-1.36rc2.tar.gz (3.3 MB) MD5 (e2fsprogs-1.36rc2.tar.gz) = 441c54b116d3426f7c16eb3bb3657648 After downloading, unpack the tarball, cd e2fsprogs-1.36rc2, then proceed with mkdir build ; cd build ... as shown above. -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck: broken file system with background check remains broken after bootup
Rob [EMAIL PROTECTED] writes: I had following situation: Someone suddenly cut the power of a FreeBSD 5.3 PC, leaving the /usr filesystem in a very broken state. During next bootup, there was indeed the message telling 'not properly unmounted', but boot continued with background fsck after 60 seconds; although I have fsck_y_enable=YES in /etc/rc.conf. That is the one that may cause problems. The default fsck settings are conservative so as to only make safe changes. fsck -y also makes more radical changes to your file system. OTOH, I am not convinced that fsck (particularly bgfsck) is bug-free, I have seen file system corruption on a FreeBSD 4.10 system that went with the write caches disabled. This scared me. What if /usr was such broken that even single user mode would hang!?! Don't worry as long as /usr is separate from /. Moreover, the main user of this PC is not a Unix guru and I hoped that the configuration setting in /etc/rc.conf of fsck_y_enable would do an automatic fix at bootup, like it used to do with 4.10. However, that apparently does not happen anymore. What can I do to enforce an immediate fix of the filesystems at bootup with FreeBSD 5.3, when a filesystem is not properly unmounted at shutdown? I suppose I should not change default background_fsck (YES). How about the background_fsck_delay? Should I set this to 0? Setting background_fsck=NO should be safe and cause the fsck to run in foreground - exactly your desire. I would avoid touching the background_fsck_delay. If, as you say, the main user of the PC is not a guru and shuts down the machine improperly, consider disabling the write cache. For ATA drives, place hw.ata.wc=0 into /etc/loader.conf.local and reboot, for SCSI drives, use camcontrol modepage da0 -m8 -e -P3 and change the figure on the WCE: line to 0, then save and exit; repeat for all further da* drives if you have more than one. That will limit the potential damage on the disk to one block rather than the whole of the cache, which is between 2 and 8 MB on the common drives sold today. -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck: broken file system with background check remains broken after bootup
Matthias Andree [EMAIL PROTECTED] writes: OTOH, I am not convinced that fsck (particularly bgfsck) is bug-free, I Make that fsck and ufs are bug-free... -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [FreeBSD-Announce] FreeBSD-4.11 Release Candidate 1 Available
Ken Smith [EMAIL PROTECTED] writes: Announcement The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 4.11-RC1, which marks the beginning of the FreeBSD 4.11 Release Cycle. This will be the last of the FreeBSD 4.X releases. It is meant These long-standing bugs are still open, in decreasing order of importance. I checked 60313 and 44260 a few moments ago with a current RELENG_4_11 CVS, and haven't seen any followups on 46866 and 71453. kern/60313 data destruction (kernel access wrong address on block device) bin/46866 nondeterministic NIS returns (this has been messing up NIS-based systems for ages with users gone one moment and appearing the next) bin/71453 tcpdump segfaults on PPP IPV6CP traffic (includes a suggested solution, perhaps MFC suffices) kern/44260 LINT does not list pseudo-device tap (trivial to fix) -- Matthias Andree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: the best graphicscard for FreeBSD
Matthias Buelow [EMAIL PROTECTED] writes: (but are probably well-known to the competitor). With the drivers getting bigger and bigger (the ATI Catalyst graphics driver component alone is over 8 megs), maybe a lot of the logics is actually in the proprietary driver code? Likely. The same can be seen for CPUs, more and more specialization is in the compiler. Ask Intel, Sun or Mips how much they're spending on chip development and how much on compiler development. :) -- Matthias Andree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
5-STABLE softupdates issue?
Greetings, out of fun and to investigate claims about alleged bgfsck resource hogging (which I could not reproduce) posted to news:de.comp.os.unix.bsd, I pressed the reset button on a live FreeBSD 5-STABLE system. Upon reboot, fsck -p complained about an unexpected softupdates inconsistency on the / file system and put me into single user mode, the manual fsck / then asked me to agree to increasing a link count from 21 to 22 (and later to fix the summary, which I consider a non-issue). A subsequent fsck -p / ended with no abnormality detected. Unfortunately, I haven't copied the details, assuming they would be copied into the log, but they haven't. Is this a situation the current 5-STABLE softupdates code (on a UFS1 FS that I kept from FreeBSD 4) is allowed to cause? Is that a bug in the file system, say, write ordering goofed up? Or is that a bug in the firmware of my disk drive (Western Digital Caviar AC420400D, a rebranded IBM DJNA drive)? I gather that ATA drives are supposed to flush their caches on software (command) and hardware resets (reset line active). I did not power cycle. -- Matthias Andree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-STABLE softupdates issue?
Scott Long [EMAIL PROTECTED] writes: No, this in theory should not happen. YOu could have caught it right at the instance that it was sending a transaction out to disk, or you could have caught an edge case that isn't understood yet. Unfortunately, ATA drives also cannot be trusted to flush their caches when one would expect, so this leaves open a lot of possible causes for your problem. That's why I added that question about drive cache flushing. I'll see to running with forced hw.ata.wc=0 and see if I can reproduce that problem. May be a while while before I see the problem again, these are very scarce fortunately (actually, the first SOFTDEP issue on this machine at all). OTOH, this is an IBM desktop drive in disguise, so the blatant firmware errors should be known by now. -- Matthias Andree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-STABLE softupdates issue?
Scott Long [EMAIL PROTECTED] writes: I wonder if this points to dependencies not being pushed out of the buffer/cache correctly. So do I. Is there a good way to debug this, i. e. more systematic than just trying to trash the FS and see if fsck can recover? That said, I rarely, if ever, see softupdate problems on my SCSI development systems, but that might just be coincidence. I posted about softupdate problems on a SCSI system with DISABLED WRITE CACHE, on a somewhat flakey Micropolis drive that froze and caused massive ffs+softupdates corruption in February 2004 (on FreeBSD 4 though), see URL:http://docs.freebsd.org/cgi/mid.cgi?m38yj15m59.fsf for the archived post, including logs. So that makes two for me and some more for Dan. -- Matthias Andree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New 5.x packages uploaded
Kris Kennaway [EMAIL PROTECTED] writes: I've uploaded new packages for 5.3-stable; they'll make their way onto the ftp mirrors over the next day or so. Included are the new versions of GNOME and KDE, among others. BTW, are we getting long-standing security issues in ports fixed, for instance cups-base, open-motif, others? Yeah I know send patches, but my ressources are limited and committers are also overworked already... The general question I'd like to raise is how long will we allow ports with known security flaws linger around before they are marked BROKEN? -- Matthias Andree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of 4-STABLE branch.
alexander [EMAIL PROTECTED] writes: As far as I know there will be another 4.11-RELEASE. Doesn't this mean that patches should still be comitted to the source tree? I reported a problem a few weeks ago. LBA48 support for the Promise UDMA100 controller (PDC20265) seems to be broken. It's not a big problem to fix it, because it looks as if some previous patch got abandoned during a recent version change of some ata files. Here's the PR, btw: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/69009 Time to find a new ata maintainer for FreeBSD 4 perhaps? Søren may not have the resources (time, interest, funds) of supporting multiple trees at the same time -- however, leaving the bug open and unassign it would have been the right thing to do. -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
HELP: ServerWorks data corruption after 350 MB with BerkeleyDB 4.0?
Hi, I received a bug report against BerkeleyDB 4 that may not be BerkeleyDB related, but a problem with FreeBSD or specific hardware in general. Jie Song (CC'd) reported that writing files with BerkeleyDB (no threading or something) on his ServerWorks machine causes data corruption (detected by BerkeleyDB 4.0 library functions) when the file sizes grow beyond 350 MB. For details, see PR #55252. Jie Song has answered in private mail that the problem persists with both current 4.X and current 5.X FreeBSD versions. Does this ring a bell somewhere? Are there issues with BIOS versions usually used on ServerWorks boards, are there hardware detection/configuration issues in the kernel? Anything known? Thanks in advance, -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: help needed debugging SCSI bus problem
Joan Picanyol [EMAIL PROTECTED] writes: ahc0: Adaptec 2940 Ultra2 SCSI adapter port 0x1000-0x10ff mem cd0: YAMAHA CRW2100S 1.0G Removable CD-ROM SCSI-2 device Nothing more needs to be said. I have bad experience with both Adaptec SCSI adaptors (1542CF, 2842VL and 2940UW Pro) and with YAMAHA CD-writers (CD-R 200T, CRW 4416S). I've never had issues with AMD-based Tekram DC-390. I've had minor issues with wide drive on narrow SYM53C875 configuration (see NetBSD PR kern/6849 for the full round-up -- and some FreeBSD versions, same problem) that seem to be solved in recent -STABLE versions. I do look after two Linux machines with a solid 2940UW setup (the adaptors are from 1998, one is driving a Fujitsu U320 10,025/min drive) though, so not all are bad. My Adaptec 2940UW Pro would lock up every other week. (I wonder if it would lock with Windows and who'd take the blame, but I'm digressing.) My Yamaha 200T would go faulty early, it can no longer write disks, but is fine reading. The Yamaha 4260S and 4416S had an awful firmware, Yamaha has never been able to deliver a robust firmware, there's always something that could lock the driver in a state that might block the whole bus. Don't mount these into servers. I wonder if the 2100S fares much better. I've now replaced the adaptor by a used Tekram DC-390F (15 EUR) and a new Plextor PX-W4824TA (hum, 119 EUR last winter). There are Plextor SCSI CD writers available (IIRC the fastest is the PX-W4012TS) if you want one, but they're around twice as expensive as their flagship ATAPI CD writer. I'm sure there are other good alternatives for either component (SCSI HA and CD writer), but I can only talk about those I know first-hand. -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 4.9 RC1 (i386) now available
Murray Stokely [EMAIL PROTECTED] writes: ftp.FreeBSD.org/pub/FreeBSD/releases/i386/4.9-RC1 ftp.FreeBSD.org/pub/FreeBSD/releases/i386/ISO-IMAGES/4.9-RC1-i386-disc1.iso We are particularly interested in having people test this release candidate on a heavily loaded system, or on large memory machines, so that the stability of the PAE merge can be tested. Well, I did an FTP install (rather than ISO) from ftp7.de.freebsd.org and it went mostly smooth, two issues: 1. ports collection is claimed to not be found (what the heck...) but some INDEX file is available, so pkg_add works. 2. at some point in time, usually around Remaking all devices, the machine throws a handful of segfaults and boom. I'm unsure whether this might be the hardware, it's an old Cyrix MII/233 (PR300) Super7 CPU in a VIA MVP3 board (PCChips M577), 32 MB PC66 + 64 MB PC100 RAM (66 MHz FSB), nothing server-class, but it seems to be fine even under load with SuSE Linux 8.1 or 8.2 (dual-boot). -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: postfix
Kovács Péter [EMAIL PROTECTED] writes: I have a system running Postfix. I would like to use it with SSL. It works fine, but I have one problem. This question is better asked on the postfix-users mailing list. Check http://www.postfix.org/ for directions (AND READ THEM CAREFULLY!) -- Matthias Andree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
disable ata in kernel configuration not working?
Hi, I have an up-to-date FreeBSD 4-STABLE system with onboard ATA controller (VIA 82C586-mumble) but no ATA/ATAPI devices (SCSI only). I tried putting disable ata disable ata0 disable ata1 quit into /boot/kernel.conf to skip probing these devices (it hangs until timeout), but to no avail, the kernel still sees ata0 and ata1 and probes for drives (which takes several dozen seconds). I see at boot-up that these disable instructions are executed (the corresponding loader.conf flag is set). I also tried disabling atapci0 which is what I see, but that one is rejected with something like no such device. Is this a known issue or should I file a PR? TIA, -- Matthias Andree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Saving a partially rotten IBM DTLA-307030 Harddisk
Andreas Ntaflos [EMAIL PROTECTED] writes: On Thu, Jan 02, 2003 at 03:11:56PM -0600, Dave Uhring wrote: On Thursday 02 January 2003 02:50 pm, Andreas Ntaflos wrote: Hello list (sorry for crossposting, hope I am doing the right thing), I've got the following problem which I hope someone could help me with: One of my boxes running FreeBSD 4.7-STABLE has an IBM DTLA-307030 (30GB) which worked very well for more than 2 years now, but I think it starts rotting away according the following: Download the dft utility from IBM. http://www.storage.ibm.com/hdd/support/download.htm When you get the failure code e-mail IBM and get the drive replaced if it is less than 3 years old. Wow, that worked like a charm, the Disk Fitness Test was able to repair the bad sectors without any major problems. Really good. Nope. It hid the problems at the expense of spare sectors. Backup your data and have the drive replaced. See the pertinent DTLA FAQs on the web. These drives need special treatment. -- Matthias Andree To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Any users of matcd(4), mcd(4), or scd(4)?
John Baldwin [EMAIL PROTECTED] writes: Are there any users who use the matcd(4), mcd(4) or scd(4) drivers? Yes, I'm using mcd, but it doesn't quite work. Bigger reads (package file size) break. The same hardware is fine with W*nd*ws NT 4 (dual-boot). These drivers are for rather old non-standard CD-ROM controllers most of which only support 1x speeds. :) I beg to differ. There's also 2x speed, and it's still sufficient to a) read a data file occasionally or b) install software occasionally or c) play audio. There are several changes being made to the kernel API's used by device drivers in -current. Unless we can find some people who actually use these devices and can test patches for these drivers we will have to drop support for them. The mcd(4) issues that are already in 4.7-RELEASE would need to be figured. I'm not entirely sure that it's NOT the board I/O timing, but if it was, I'd shrug over why NT then worked. However, if the changes are NOT to 4-STABLE, then I'm out. I cannot migrate that machine to 5-CURRENT, in that case, testing would have to wait until 5-STABLE. -- Matthias Andree To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: How do I know the 'bogomips' of my system ?
Brossin Pierrick [EMAIL PROTECTED] writes: Under Linux it was easy to find it.. /proc Under FreeBSD I can't find it.. Reboot into Linux, look at the BogoMIPS, then boot FreeBSD :-) Run real benchmarks if you want hard figures. BogoMIPS only calibrates delay loops. -- Matthias Andree To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: ATA Atapi 4.6 Release
David W. Chapman Jr. [EMAIL PROTECTED] writes: On Mon, Jun 17, 2002 at 04:19:49PM -0500, John Prince wrote: Hello David Is this the only other problem? I think instead of asking is this the only problem, we should be saying How does this impact our existing Users? And we can't get a full scope of how it is affecting our existing users until we have a list of all the problems. ATA-related problems I am aware of: Known Problem: IBM DTLA-307045 (75 GXP series) + VIA 82C686 south bridge (KT133) locks up on TCQ, times out and falls back to PIO. (I cannot try my onboard PDC-20265R because FreeBSD avoids TCQ on this chip.) Works, but slowly. 4-STABLE before MFC was fine in UDMA/66 with TAGGED. Compatibility: (already reported) Linux 2.5 ATA ships with working tagged command queueing on Western Digital AC420400D (which looks like an IBM DJNA-352030 clone). FreeBSD does not dare use TCQ on this drive, and as I hacked up 4-STABLE in spring to try it, it locked up. (I have a dual-boot FreeBSD/Linux machine, so no worries about differing hardware.) Performance: Linux 2.4 and 2.5 ATA sub systems have higher troughput on sequential read than FreeBSD 4.6-RC ATA. Never looked for latency through the file system (and cannot, as the Linux 2.4.19-pre BSD FFS file system is hosed.) (OTOH, FreeBSD 4.6-RC SCSI -- at least the aic stuff with an Adaptec 2940 UW Pro -- has better throughput than Linux with my U160 drive.) -- Matthias Andree To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: ATA Atapi 4.6 Release
David W. Chapman Jr. [EMAIL PROTECTED] writes: On Mon, Jun 17, 2002 at 11:38:01AM -0500, John Prince wrote: I have to say, I am a bit disappointed in the 4.6 release, as well as the way problems have been identified, and swept under the carpet.. Why didn't you express these concerns for the past few months? There have been several reports of ATA and ATAPI brokenness after the MFC. After I brought the TCQ brokenness up again at 4.6-RC time, Søren fixed the boot panic I experienced, and in late May he wrote he could reproduce the other known TCQ-timeout-and-fall-back-to-PIO problem, but I've never seen anything since. But what is bringing up a known problem again of help? Do you want people to scream their problem list every week? The PRs are there, and are open, so you cannot say these concerns had not been expressed. They have indeed. And I agree with those who say that 4.6 should NOT have been released with ATA(PI) in /this/ shape. I have been told (on this list) by the RE team that the MFC cannot be backed out and that 5.0DP2 is close, and I understand they want to keep the schedule as good as possible, but all these objections do not help the regression or displeasing users. And the latter is a Bad Thing®. -- Matthias Andree To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: 4.6-RELEASE delayed
[EMAIL PROTECTED] (Bruce A. Mah) writes: We'll be doing another release candidate (4.6-RC4...for various reasons I appreciate this. there won't be a 4.6-RC3) on Monday, in which we hope to see the major remaining issues addressed. We encourage you to see the testing page for this release at: http://www.freebsd.org/releases/4.6R/qa.html It says ata(4) tags problems were related to motherboard-based ATA channels. I see that Søren's patch to fix the panic on boot that I observed has now been merged into 4-STABLE, however, it seems as though the timeout and fall-back to PIO issue is still unfixed in 4-STABLE. My main board, a Gigabyte 7ZX-R rev. 1.0, offers four ATA channels. Two are driven by the south bridge, VIA KT133 (VT82C686 stuff), the other two are driven by a Promise PDC-20265R (in UDMA/100 mode). IIRC, this Promise chip is in the doesn't to tags, but freezes blacklist. VIA chips are not blacklisted, and AFAICS, tagged queueing not working on my system is a regression over 4.5-RELEASE which had working tagged queueing. Søren said he was able to reproduce the timeout problem with tags, and we should expect a fix real soon now. This is the only list I follow, but I haven't yet seen anything ata-related since. What's the release engineering team's opinion on this ata issue? Will 4.6 be delayed until the tagged stuff is fixed? Will 4.6 ship with ata tagged stuff disabled altogether? Or will 4.6 ship with ata as it is today, with the risk that it breaks some systems 4.5 ata did work on? -- Matthias Andree To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
tcpd not installed on 4.5-PRERELEASE
Hello, I just cleandir'ed out my whole /usr/obj/src and rebuilt the world (4.5-PRERELEASE), installed it, and figured that tcpd seems to be missing from the install, while tcpdchk and tcpdmatch are installed. What's up here? Did I do something wrong? Is this worth a send-pr? Or is tcpd just not part of the system? -- Matthias Andree They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. Benjamin Franklin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
fsync semantics and directory changes
Hail, I'm wondering how to fsync() changes to a directory such as link() with softupdates or async mode. Linux has the open and fsync the directory approach. With softupdates, fsync() syncs directory corresponding to the open file handle. However, how do I sync unlinks, for example? Would opening a directory and fsync()ing flush all pending changes to the directory and guarantee fsync() does not return before writes are written (assuming write caches in the disk drive are switched off, of course)? -- Matthias Andree To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: [NFS] Incompatible: FreeBSD 4.2 client, Linux 2.2.18 nfsv3 server, read-only export (was: Incompatible: FreeBSD 4.2 client, Linux 2.2.18 nfsv3 server, ReiserFS)
Note: when replying, please remove the (was: ) part of the Subject and the reiserfs-list from the recipients. On Tue, 23 Jan 2001, Guy Harris wrote: Perhaps the Linux server should, in "nfsd_access()", treat "nfserr_rofs" the same way it treats "nfserr_perm" and "nfserr_acces", and just say the access type is denied but the access query succeeded, doing the same thing that Solaris and a future release of the NetApp software will do. (It looks as if the FreeBSD NFS server already does that - it treats all errors from "nfsrv_access()" as meaning "access denied", not "access call failed", so it treats EROFS in that fashion. The same probably applies to other BSDs.) As for why the V2 client doesn't appear to have this problem, the V2 client doesn't make an ACCESS call, because NFS V2 doesn't have an ACCESS call to make. Ah, so it's a protocol difference which keeps Linux server - FreeBSD client compatibility here. If it *was* mounted read-only, was the ext2 file system also mounted read-only? If not, that might explain it. I looked again, closely, and found in /etc/exports: /space 192.168.0.0/255.255.255.0 /home 192.168.0.0/255.255.255.0(rw) I looked into exports(5) and found that exports assumes ro unless overriden with rw. Not reporting this and attributing the problem to ReiserFS instead of the RO mount (which looks strange to me as a response to a READ request) was my fault, and I apologize to the ReiserFS people for this bogus allegation. ReiserFS is now out of the play. As for why it's a problem with the FreeBSD client but not the Solaris client, I'm not sure - a quick look at the 4.2 client code doesn't seem to show any way in which the EROFS is "sticky" to the extent that it affects all client accesses, as it doesn't cache the result of an ACCESS call that failed. It may just be that the Solaris client just ignores NFS3ERR_ROFS from an ACCESS call and does an access check based on the permission bits, rather than returning EROFS, whilst the FreeBSD client returns EROFS; if ReiserFS is returning EROFS bogusly, that might cause the symptoms in question. Okay. So, as a conclusion, my original bug report boils down to: "You cannot mount read-only file systems with NFS v3 from a Linux 2.2.18 server to a FreeBSD 4.2-STABLE client. Use NFS v2 instead." The question remains: Linux kernel problem or FreeBSD client problem? -- Matthias Andree To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ftpd incoming security
On Wed, 27 Dec 2000, Vivek Khera wrote: MA Can people change the permissions afterwards or the umask before MA uploading, thus circumventing these settings? I'm not too deep in ftpd. Hmmm. Yes. According to the ftpd man page, there are commands "SITE CHMOD" and "SITE UMASK" that will allow that... I guess it is back to using an alternate ftpd for complete security... I feared just that, that's why I asked. You might of course disable those SITE commands or restrict them. -- Matthias Andree To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
