Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
Stephen Hurd wrote: Jeremy Chadwick wrote: SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 253 253 063Pre-fail Always - 4 This shows you've had 4 reallocated sectors, meaning your disk does in fact have bad blocks. In 90% of the cases out there, bad blocks continue to "grow" over time, due to whatever reason (I remember reading an article explaining it, but I can't for the life of me find the URL). This is unusual now? I've always "known" that a small number of bad blocks is normal. Time to readjust my knowledge again? I have bought disks where the value of Reallocated_Sector_Ct was not 0, at least by the time I looked at it with smartctl. Nothing bad has happened to those disks in several years (hope that's not tempting fate). I have always assumed that what matters is when this value *changes*. If it's not changing, who cares? smartd will monitor disks and email you when certain attributes change (e.g. Pre-fail attributes like Reallocated_Sector_Ct). If it changed, it would mean that an attempt to write data had failed and that reallocation had happened. e.g. from smartd.conf /dev/ad4 -o on -S on -a -m root -M daily If your Current_Pending_Sector were non-zero you'd be in trouble, I believe. 0.02, pinch of salt, not an expert, slippery when hot, long time since I read the specs, etc etc. --Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dumping large partition to USB drive fails
Roland Smith wrote: I'll disassemble the malfunctioning drive, put it in an old PC and run smartctl on it. Are there any other tests that might be worthwhile? Manufacturer's diagnostics. Usually: download from manufacturer site, burn onto CD, reboot from CD, voila. If you are seriously dubious about the disk then run SMART long test. The smartctl man page has the details. But no manufacturer ever wants to accept a return unless their own diagnostics fail :-( --Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rm(1) bug, possibly serious
Dan Nelson wrote: In the last episode (Sep 26), Oliver Fromme said: Bob Johnson wrote: > Maybe. But I expect that the behavior for "rm -rf .." is there so > that things don't get REALLY astonishing when you do "rm -rf *". The expansion of "*" does not include "." or "..". Under /bin/sh, ".*" does match "." and "..", so be careful :) .??* is a standard workaround that works most of the time. Won't match .a .b etc but such antisocial files are the exception, one might hope. --Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/share/man/man8/MAKEDEV.8
Giorgos Keramidas wrote:
On 2007-10-28 12:54, Andrew Lankford <[EMAIL PROTECTED]> wrote:
Thbbt! I'm reading the catman version of MAKEDEV. Wish I could
disable that "feature". Oh well. I'll delete it all and rebuild it
again if needed. Thanks!
Ah, that's it then :)
My usual `installworld' steps include this too:
# cd /usr/share/man
# find cat[0-9] \! -type d -exec rm {} +
This takes care of deleting any `stale' preformatted manpages, so the
next time I ask for a manpage, it's going to be reformatted.
Seems to me that there must a logic error in man. Man makes the effort
to check to see if the unformatted manpage is newer than the cat-ed
manpage, and if it is, it will try to re-create the cat-ed manpage, and
will show you an nroff'ed version of the unformatted manpage if it
cannot recreate the cat-ed version.
Clearly that's breaking in this scenario, because the mtime of the new
unformatted manpage, while presumably newer than that of the old
unformatted man page is still older than the mtime of the cat-ed page.
What seems to be missing, is that when the cat-ed manpage is first
created, it should have its mtime set to the same as the mtime of the
unformatted manpage, not the time at which you happened to read the man
page. I don't see any evidence of that is the sources on my system
(which is quite old, but it certainly looks like the bug persists).
A bit of stat and utimes jiggery pokery looks like it would solve this
problem. An else clause for " else if (rename(temp, cat_file) == -1)
{" in /usr/src/gnu/usr.bin/man/man/man.c would look like the place to do
that.
(Alternatively, you could view it as a bug of the install/upgrade
process, since it could be argued that the mtime of the unformatted
manpage should be the time that the manpage was installed. Presumably
that isn't happening, else you wouldn't be seeing the cat-ed version).
Of course, with modern systems where nroff-ing a man page takes
negligible time and system resources, it could also be argued that
cat-ed man pages should be a thing of the past :-)
--Alex
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/share/man/man8/MAKEDEV.8
Matthew D. Fuller wrote: On Thu, Nov 01, 2007 at 01:43:41PM +0100 I heard the voice of Bernd Walter, and lo! it spake thus: Show me the positives that outweights the negatives and I'm on your side. Why do you think we're on different sides to begin with? I've not advocated removing catman capability, or denied that different situations have different needs, or that those needs may include catman, or for that matter said anything at all applicable to tiny environments or appliance building. As the author of the original statement creating this little furore, I don't think I said anything of the kind either! It's kind of depressing that a throwaway comment at the end of an email gets turned into a straw man argument that even I could have knocked down, but no-one has bothered to comment on the, to my mind, clear logic error in man/catman which allows the wrong manual page to get displayed in the first place. When the cat-ed man page concept was invented (when even the slowest machine cited here would have looked like science fiction) the notion that an upgrade process could install a manual page older than a pre-existing cat-ed version would have been unthinkable. With FreeBSD as it is now, it clearly isn't unthinkable since two experienced upgraders already had their own personal steps in the upgrade process to avoid the issue. At the very least, it would seem like adding that step to /usr/src/UPDATING and the handbook would be in order, but fixes to man and catman could make this issue happening a near impossibility. (A scheme using something like md5 sums could make it even more improbable, but hardly seems worth the effort). In addition, considering an *option* to simply not have cat-ed manual pages (for people with machines fast enough to just not care, or who have machines where you just don't read man pages often enough to care) does not seem out of order. An option. Not behaving like Microsoft. Not discriminating against anyone. On Thu, Nov 01, 2007 at 01:43:41PM +0100 Bernd Walter said: My point was against retirement, which was mentioned by Alex. No, it was not. I said: Of course, with modern systems where nroff-ing a man page takes negligible time and system resources, it could also be argued that cat-ed man pages should be a thing of the past "with modern systems where nroff-ing a man page takes negligible time and system resources". All your arguments have been about systems which do not, by any stretch, meet that very specific criterion, and, for which, I therefore advocated nothing at all. If you had wanted a clarification, you only had to ask. jonathan michaels wrote: sorry for my noise, i am not complaining rather asking for a bit of thinkings and for some tolerance fro people who still use "old" machines .. I'm sorry that you've seen intolerance, but I assure you that none was intended. I think you are reading far more in to what was said, than was actually said. --Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sio0: port may not be enabled
Marcel Moolenaar wrote: On Apr 20, 2007, at 8:23 AM, Jeremy Chadwick wrote: Look closely at the dmesg line, note what device sio0 is claiming to be associated with (acpi0, not isa0): sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 This is one of the drawbacks to using ACPI. Could you try uart(4) instead. It seems quite excessive to have to disable ACPI just to get a serial port working. I'd like to know if this is related to the sio(4) driver or something else. Just a note that I get exactly the same issues with my BIOS/ACPI but *my serial port works*. I have not needed to disable ACPI nor to use uart(4). The sio0 line has an IRQ associated with it (4) and I think if there were really a problem there would be no IRQ here. IIRC, the issue is something to do with ACPI presenting the serial ports backwards wrt the BIOS. I know I got concerned about this when I first encountered it, and tried stuff to swap the two ports I have over, but nothing I did made the initial "ACPI probed irqs" error go away so I just tried the serial port and it worked. --Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: howto update freebsd 4.7 release to 4.7 stable
Khanh Cao Van wrote: My custom use freeBSD 4.7 release and ask me to install JDK1.4 on it . But when I use ports to compile JDK , the system show me a message : You must have a version of FreeBSD later than 4.7-STABLE February 2003 or 5-CURRENT February 2003 to compile and use JDK 1.4.2. So I have to update my 4.7 release to 4.7 stable . But I do not know how to do make it . I've looking everywhere but could not find any clear document about it . Please help me ! AFAIK there is no such thing as 4.7-STABLE, just 4-STABLE and the handbook page on tags bears this out. (4-STABLE would be improvements from the *latest* 4 release which is 4.11. If you won't go to 4.8 then 4-STABLE is the stuff of your nightmares. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvs-tags.html says: RELENG_4 The line of development for FreeBSD-4.X, also known as FreeBSD 4-STABLE PS : I'm not going to upgrade my kernel 4.7 to 4.8 or anything else , just 4.7 only . Thank for reading ! No-one here can stop you shooting yourself in the foot. The release engineering page clearly states: FreeBSD 4.7 security fix branch (not officially supported). so I guess you are own your own. Not upgrading a critical machine to 5.X I could understand, but not upgrading from 4.7 another 4.X release I find incomprehensible. --Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
