Re: bin/121684: : dump(8) frequently hangs
On Tue, Sep 02, 2008 at 09:39:20AM +0300, Danny Braniss wrote: take a look at: http://www.freebsd.org/cgi/query-pr.cgi?pr=117603 danny That PR may or may not be relevant, depending upon what FreeBSD version users are using, and what kernel build date. The bug mentioned in that PR got addressed in HEAD on March 13th, 2008, and the fix MFC'd to RELENG_7 on April 19th, 2008. It was never MFC'd to RELENG_6. If there are users on RELENG_7 with kernels built with sources after April 19th 2008 who are experiencing the problem, then the PR is probably not relevant. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bin/121684: : dump(8) frequently hangs
take a look at: http://www.freebsd.org/cgi/query-pr.cgi?pr=117603 danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bin/121684: : dump(8) frequently hangs
On Mon, 1 Sep 2008, Jeremy Chadwick wrote: On Tue, Sep 02, 2008 at 09:39:20AM +0300, Danny Braniss wrote: take a look at: http://www.freebsd.org/cgi/query-pr.cgi?pr=117603 danny That PR may or may not be relevant, depending upon what FreeBSD version users are using, and what kernel build date. The bug mentioned in that PR got addressed in HEAD on March 13th, 2008, and the fix MFC'd to RELENG_7 on April 19th, 2008. It was never MFC'd to RELENG_6. If there are users on RELENG_7 with kernels built with sources after April 19th 2008 who are experiencing the problem, then the PR is probably not relevant. Part of the problem here is that a whole class of possible bugs have near-identical symptoms. While each of the following means quite different things to a kernel developer working on the problem, and may reflect quite different types of bugs, they are all often described as dump hangs or dump wedges: - the system deadlocks - dump fails to complete and/or exit, but cannot be killed - dump fails to complete and/or exit, but can be killed When snapshots were first introduced, the problems tended to be at the top end of that list, corresponding to VFS locking and resource starvation deadlocks. As the snapshot code has matured, new problems in both the kernel scheduler and dump code have arisen as parallelism has increased, reflecting a combination of old bugs in the dump code and new bugs in the kernel scheduler. Unfortunately, these bugs don't tend to get discovered much during testing in -CURRENT -- perhaps people don't back up their -CURRENT boxes much :-). I think we need to rigorously do the following: - For each bug report, determine whether it is reporting one or more of the above types of hangs. If multiple types are reported, track them with different bug reports. - Establish as early as possible whether a fix resolves the problems in each report. Because we're dealing with many bugs over time, it's possible to end up with accidentally omnibus reports that remain open and are never closed, even though committed and released fixes may correct the problems experienced by the reporter. It is almost impossible, btw, to rewind and years later determine if any particular fix would have corrected any particular report, because the original submitter will have moved on. Dump happens to be particularly sensitive to bugs of these sorts because it uses snapshots and it uses multiple workers that signal each other, so it's a good lithmus test of stability of both of those features. However, it's easy to conclude that dump is much less stable than it proves in practice because we have a lot of stale and confusing bug reports. What we do need is a dump bug report owner, who can keep track of the outstanding set, try to agressively close the ones that are fixed, which will among other things allow us to better track regressions vs bugs from inception. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
nVidia driver update today: renders X11 unusable
Just upgraded my ports and installed the new xf86-video-nv driver. Well, loggin out works now without crashing the Xorg server, but most fonts now show up as balck bars - unreadable and ugly :-( ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nVidia driver update today: renders X11 unusable
O. Hartmann wrote: Just upgraded my ports and installed the new xf86-video-nv driver. Well, loggin out works now without crashing the Xorg server, but most fonts now show up as balck bars - unreadable and ugly :-( Same for me, just some transparent pictures render transparency as black, good example is reader.google.com. This also isn't new to me, some pictures was shown like this in previous driver versions. I was just a bit unsure who was bad at it. -- Sphinx of black quartz judge my vow. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nVidia driver update today: renders X11 unusable
Volodymyr Kostyrko wrote: O. Hartmann wrote: Just upgraded my ports and installed the new xf86-video-nv driver. Well, loggin out works now without crashing the Xorg server, but most fonts now show up as balck bars - unreadable and ugly :-( Same for me, just some transparent pictures render transparency as black, good example is reader.google.com. This also isn't new to me, some pictures was shown like this in previous driver versions. I was just a bit unsure who was bad at it. Well, everything with a transparency, as you stated above, seems to be broken, reading Email is a horror, most web sites are rendered broken in Firefox 3. Luckily, within xterm everthing is ok. I recompiled xorg and my windowmanager, no effect. Even xdm shows up with black bars were normally 'LOGIN:' and 'PASSWORD:' shows up ... Is there a solution? The situation is serious ... -- Oliver Hartmann Freie Universitaet Berlin Planetologie und Fernerkundung Malteserstr. 74 - 100/Haus D D-12249 Berlin Tel.: +49 (0) 30 838 70 508 FAX: +49 (0) 30 838 70 539 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nVidia driver update today: renders X11 unusable
O. Hartmann wrote: Well, everything with a transparency, as you stated above, seems to be broken, reading Email is a horror, most web sites are rendered broken in Firefox 3. Luckily, within xterm everthing is ok. I recompiled xorg and my windowmanager, no effect. Even xdm shows up with black bars were normally 'LOGIN:' and 'PASSWORD:' shows up ... Is there a solution? The situation is serious ... Back out of the upgrade, back to the previous version? The current _binary_ package is still the old version, so you could try to force-install that one (e.g. by using portupgrade -fPP xf86-video-nv-2.1.11) until the port gets fixed, I guess. Haven't tried this (haven't upgraded yet), but it should revert your upgrade and get you up and running for now (but ymmv). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nVidia driver update today: renders X11 unusable
O. Hartmann wrote: Just upgraded my ports and installed the new xf86-video-nv driver. Well, loggin out works now without crashing the Xorg server, but most fonts now show up as balck bars - unreadable and ugly :-( flz@ has committed an updated version (2.4.2) an hour ago. You could try if that fixes your problems. Cheers, Florian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nVidia driver update today: renders X11 unusable
Florian Smeets wrote: O. Hartmann wrote: Just upgraded my ports and installed the new xf86-video-nv driver. Well, loggin out works now without crashing the Xorg server, but most fonts now show up as balck bars - unreadable and ugly :-( flz@ has committed an updated version (2.4.2) an hour ago. You could try if that fixes your problems. Gah. Never mind. It was the xf86-video-intel driver which was updated. I think i need a pair of glasses :-( Sorry, Florian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nVidia driver update today: renders X11 unusable
O. Hartmann wrote: Volodymyr Kostyrko wrote: O. Hartmann wrote: Just upgraded my ports and installed the new xf86-video-nv driver. Well, loggin out works now without crashing the Xorg server, but most fonts now show up as balck bars - unreadable and ugly :-( Same for me, just some transparent pictures render transparency as black, good example is reader.google.com. This also isn't new to me, some pictures was shown like this in previous driver versions. I was just a bit unsure who was bad at it. Well, everything with a transparency, as you stated above, seems to be broken, reading Email is a horror, most web sites are rendered broken in Firefox 3. Luckily, within xterm everthing is ok. I recompiled xorg and my windowmanager, no effect. Even xdm shows up with black bars were normally 'LOGIN:' and 'PASSWORD:' shows up ... Is there a solution? The situation is serious ... 1. portdowngrade 2. Kick upstream, the problem isn't that new, it's just getting sharper. 3. Quick look through Xephyr at KDE4 gives me no quirks in displaying images. It maybe gtk2-only thingy, or it maybe Xephyr already fixes it somehow... dunno... -- Sphinx of black quartz judge my vow. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nVidia driver update today: renders X11 unusable
Florian Smeets wrote: O. Hartmann wrote: Just upgraded my ports and installed the new xf86-video-nv driver. Well, loggin out works now without crashing the Xorg server, but most fonts now show up as balck bars - unreadable and ugly :-( flz@ has committed an updated version (2.4.2) an hour ago. You could try if that fixes your problems. Cheers, Florian I guess we are already talking about this aupdate because I updated approx. 1 hour ago when the probems took place. Regards, Oliver ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nVidia driver update today: renders X11 unusable
Question to those having this problem - what kind of nVidia hardware do you have? Is that something that is based on G80 GPU or later (GeForce 8XXX or later)? I see that there is already version 2.1.12 of nv driver (in xorg repository) that is supposed to fix CPUToScreenColorExpandFill function for G80 cards. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nVidia driver update today: renders X11 unusable
Andriy Gapon wrote: Question to those having this problem - what kind of nVidia hardware do you have? Is that something that is based on G80 GPU or later (GeForce 8XXX or later)? I see that there is already version 2.1.12 of nv driver (in xorg repository) that is supposed to fix CPUToScreenColorExpandFill function for G80 cards. Well, the problems I have are related to a nv8600GTS based board, this is, as far as I know, a G8X-based graphics board. Nearly 3 months ago some weird behaviour started to be static on the same hardware, Xorg wasn't capable of resetting the terminal is was bound to and presented me funny blinking block graphics on the screen. The Xorg server could oly be revived remotelly by killing the Xorg or within a running session by killing the Xorg for logging off. This problem has gone with today's update, but now my box (nv8600GTS) and the one of a collegue is rendered unusable. My private box runs with a nv6800GT board and there Xorg freezes now very often and renders the box unusable, too. I'm very unpleased about the situation, because it is impossible to do reasonable work. How can I selectively 'downgrade' a port? Regards, Oliver P.S. Sorry about some weird formatting, I'm typing blind, I see 'censor black bars' all over my screen, even in Thunderbird, Firefox ...). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nVidia driver update today: renders X11 unusable
On Tue, 02 Sep 2008 16:28:20 +0200, O. Hartmann [EMAIL PROTECTED] wrote: Andriy Gapon wrote: Question to those having this problem - what kind of nVidia hardware do you have? Is that something that is based on G80 GPU or later (GeForce 8XXX or later)? I see that there is already version 2.1.12 of nv driver (in xorg repository) that is supposed to fix CPUToScreenColorExpandFill function for G80 cards. Well, the problems I have are related to a nv8600GTS based board, this is, as far as I know, a G8X-based graphics board. Nearly 3 months ago some weird behaviour started to be static on the same hardware, Xorg wasn't capable of resetting the terminal is was bound to and presented me funny blinking block graphics on the screen. The Xorg server could oly be revived remotelly by killing the Xorg or within a running session by killing the Xorg for logging off. This problem has gone with today's update, but now my box (nv8600GTS) and the one of a collegue is rendered unusable. My private box runs with a nv6800GT board and there Xorg freezes now very often and renders the box unusable, too. I'm very unpleased about the situation, because it is impossible to do reasonable work. How can I selectively 'downgrade' a port? Mmmm... # whereis portdowngrade portdowngrade: /usr/ports/ports-mgmt/portdowngrade Cheers, Ronald. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bin/121684: : dump(8) frequently hangs
Date: Tue, 02 Sep 2008 09:39:20 +0300 From: Danny Braniss [EMAIL PROTECTED] take a look at: http://www.freebsd.org/cgi/query-pr.cgi?pr=117603 Danny, Thanks for the suggestion, but my system is a P-III so there is only one CPU. At 1GHz, I think that this easily qualifies as an older, slower, non-smp host. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgplbUu7DQdWy.pgp Description: PGP signature
Re: nVidia driver update today: renders X11 unusable
## Volodymyr Kostyrko ([EMAIL PROTECTED]): Just upgraded my ports and installed the new xf86-video-nv driver. Well, loggin out works now without crashing the Xorg server, but most fonts now show up as balck bars - unreadable and ugly :-( Same for me, just some transparent pictures render transparency as black, good example is reader.google.com. This also isn't new to me, some pictures was shown like this in previous driver versions. I was just a bit unsure who was bad at it. Seems you've got an issue between X and firefox3; at least there's a note in the firefox3 release notes which desribes similar effects: https://bugzilla.mozilla.org/show_bug.cgi?id=411831 Oh, but by the way, it's not an nvidia/nv issue; I've got the exactly same issues with radeonhd... Luckily, I do not depend that much on web browsers, let alone firefox3. Regards, Christoph -- Spare Space ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RELENG_7/amd64: booting from gpt failed.
Dear colleagues, I'm trying to set up new machine with RAID array slightly larger than 2T, so I'm forced to use gpt. I did successfully gpt create gpt boot gpt add newfs tar base system gpt show output looks like: startsize index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 128 1 GPT part - FreeBSD boot 162 1048576 2 GPT part - FreeBSD UFS/UFS2 104873833554432 3 GPT part - FreeBSD swap 34603170 4359862077 4 GPT part - FreeBSD ZFS 4394465247 32 Sec GPT table 4394465279 1 Sec GPT header and I hope it boots from da0p2, but it fails: /boot.config: -Dh -S115200 FreeBSD/i386 boot Default: 0:ad(0p2)/boot/loader boot: Consoles: internal video/keyboard serial port BIOS drive C: is disk0 BIOS 628kB/3405248kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Wed Feb 20 17:29:26 MSK 2008) can't load 'kernel' Type '?' for a list of commands, 'help' for more detailed help. OK ls bad path '' OK show loaddev disk0s2`: OK show currdev disk0s2`: Quick googling does not help much. Any hints? Thanks in advance. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Is it safe to delete /bin/[ /usr/bin/false?
Greetings,
Well, I en devoured to install a copy of 7 as an effort to upgrade
one of our servers. After installing a few ports, I began to notice:
[: -le: argument expected messages being emitted during the configure/make
process. I've already invested a fair amount of time on this upgrade,
and /really/ don't want to wipe the disk(s) and start all over. This
issue is not new to me - see thread:[: -le: argument expected for details.
But I have /yet/ to discover a solution. When I started the upgrade (install),
I had an /etc/make.conf. Thinking that this might be the culprit when
these messages starting to appear, I looked it over for possible typos.
The only possible issue I could see was the reference to databases/mysql:
.if ${.CURDIR:M*/databases/mysql*}
WITH_OPENSSL=yes
WITH_CHARSET=latin1
WITH_XCHARSET=complex
WITH_COLLATION=latin1_general_ci
WITH_PROC_SCOPE_PTH=yes
BUILD_OPTIMIZED=yes
WITH_ARCHIVE=yes
WITH_CSV=yes
.endif
NOTE the YES | NO, as opposed to TRUE | FALSE. I changed them to true v false.
But I have already built MySQL with the YES | NO. Could this be the issue?
Source(s) cvsupped 08-09-01
Thank you for all your time and consideration.
--Chris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is it safe to delete /bin/[ /usr/bin/false?
No it isn't safe to delete these as many, many scripts depend on them. Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax:(206) 232-9186 One man's brain plus one other will produce one half as many ideas as one man would have produced alone. These two plus two more will produce half again as many ideas. These four plus four more begin to represent a creative meeting, and the ratio changes to one quarter as many ... -- Anthony Chevins ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is it safe to delete /bin/[ /usr/bin/false?
Quoting Bill Campbell [EMAIL PROTECTED]: No it isn't safe to delete these as many, many scripts depend on them. LOL yes, I knew that :) My chosen title for the thread is more a reflection of my frustration with this problem. I'm hoping that a solution is possible. Because /bin/[ /usr/bin/false are used to evaluate conditionals. It is /quite/ necessary for me to resolve /why/ this keeps happening. As nothing (many||most) things will not work as intended - if at all until the problem is found fixed. Thank you for taking the time to respond. --Chris Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax:(206) 232-9186 One man's brain plus one other will produce one half as many ideas as one man would have produced alone. These two plus two more will produce half again as many ideas. These four plus four more begin to represent a creative meeting, and the ratio changes to one quarter as many ... -- Anthony Chevins ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ICRC's
* Jeremy Chadwick ([EMAIL PROTECTED]) wrote: On Mon, Aug 11, 2008 at 07:58:22AM +0100, Thomas Hurst wrote: * Larry Rosenman ([EMAIL PROTECTED]) wrote: ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=154593293 NAMESTATE READ WRITE CKSUM ad8 ONLINE 0 017 Having just experienced NTFS corruption in Windows thanks to a slightly kinked SATA cable (hint: *never* chkdsk/fsck/etc until you're sure the cables are fine), I would *love* to know why this causes a checksum error at ZFS level rather than a read error that any filesystem (or indeed RAID layer) will notice. The ad8 errors you're quoting come from the ATA subsystem in FreeBSD. That is lower-level (e.g. closer to the hardware) than ZFS's checksum method is. Yes, but ZFS is clearly still seeing corrupt data from its reads because the CKSUM counter's going up, not READ, which would indicate it's reads were actually failing at ATA level. If Larry was using UFS, he'd also see the above errors from the kernel. FreeBSD reports the CRC errors reported by the ATA device, ZFS reports the said data as corrupted during scrubbing or standard usage (hence the CKSUM field in 'zpool status'), ZFS should only see corruption that's undetected by ATA's CRC's though (or the disk's own error correction); if it's actually causing a CRC error at protocol level, ZFS should not see it, because that IO operation failed. and ZFS also *repairs* the corrupted data. I can't explain how the repair works, It repairs by having duplicate copies of data and metadata; in the case of vital metadata it stores ditto-blocks so there are always multiple copies of it about, similar to UFS's superblock being spread all over the disk. For most data you generally want some level of ZFS RAID, but I'm pretty sure you can make it store multiple copies on the same disk (zfs set copies=2 on a 1-disk ZFS, for example). In the event of IO errors, I believe some Linux software RAID levels can perform similar recovery; rewriting the erroring blocks from another device to force the disk to rewrite the broken block. I believe journalling filesystems (e.g. ext3fs and gjournal) have this ability, while Standard UFS, UFS2, NTFS, FAT, and many others do not. No, journalling has nothing to do with this kind of self-healing; a journal allows a filesystem to be made consistent when interrupted (i.e. by a crash or power failure) with a very small number of operations because it has a log of what has or was about to happen. Journalling filesystems are just as vulnerable to corruption as non-journalling ones. NTFS is journalling, BTW. What's the point in having the connection protected by a CRC if it's just going to let bogus data through anyway? A CRC (or checksum) acts as a method of differential detection, e.g. detect corruption between X and Y. CRCs are not the same thing as error correction or retransmittal; they only result in reporting data corruption, and cannot repair it. Yes, I know what CRC's are; my point is, a CRC error should mean the corrupt data doesn't make it to the higher layers; ZFS, UFS, gmirror, whatever, should get an IO error if the data can't be retrieved after retries fail, they shouldn't get an apparently successful read with corrupt data in it. Perhaps this is the case, and (S)ATA's CRC's are just so poor a couple of retries is enough to get corrupt data which happens to have a correct CRC. -- Thomas 'Freaky' Hurst http://hur.st/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is it safe to delete /bin/[ /usr/bin/false?
On 2008-Sep-02 10:49:43 -0700, [EMAIL PROTECTED] wrote: Well, I en devoured to install a copy of 7 as an effort to upgrade one of our servers. After installing a few ports, I began to notice: [: -le: argument expected messages being emitted during the configure/make process. This probably indicates badly written configure scripts that have things like [ 23 -le $x ] but don't set $x. The solution is to write patches for the configure scripts and feed them back upstream. I've already invested a fair amount of time on this upgrade, and /really/ don't want to wipe the disk(s) and start all over. I'm not sure how this will help. This issue is not new to me - see thread:[: -le: argument expected for details. You haven't mentioned where this thread exists - definitely not here. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgp1y0WTnMeFm.pgp Description: PGP signature
Re: Is it safe to delete /bin/[ /usr/bin/false?
Hello, and thank you for your reply. Quoting Peter Jeremy [EMAIL PROTECTED]: On 2008-Sep-02 10:49:43 -0700, [EMAIL PROTECTED] wrote: Well, I en devoured to install a copy of 7 as an effort to upgrade one of our servers. After installing a few ports, I began to notice: [: -le: argument expected messages being emitted during the configure/make process. This probably indicates badly written configure scripts that have things like [ 23 -le $x ] but don't set $x. The solution is to write patches for the configure scripts and feed them back upstream. Bummer. I've already invested a fair amount of time on this upgrade, and /really/ don't want to wipe the disk(s) and start all over. I'm not sure how this will help. Good. Perhaps you (or anyone) can suggest how I might debug /when/where/ these eval are called. I could use /usr/bin/script, but not sure how to (e)grep the culprit(s). This issue is not new to me - see thread:[: -le: argument expected for details. You haven't mentioned where this thread exists - definitely not here. Ahem... Quoting Jeremy Chadwick [EMAIL PROTECTED]: On Fri, Feb 01, 2008 at 10:18:14AM -0800, Chris H. wrote: I wanted to sync up my ports database before hand. So ran a portsdb -uU. ---8---[huge snip]---8--- Hello again Jeremy, Well, after carefully examining your reply; emptying /etc/make.conf; searching for any sign of another Apache APR, and finding none.; performing a cvsup -g -L 2 ports-supfile portsdb -uU pkgdb -F; which resulted in many [: -le: argument expected's, and [: -eq: argument expected's; I performed a: cd /usr/ports/lang/php5 make extract; Yep! You guessed it, [: -le: argument expected again! Well, what was expected to be a 3 day affair, has turned into a 2 week affair. At least that's been my past experience with installing a FreeBSD server (3 days). :) Anyway, I've run out of patience (and time) debugging this issue. So I think it would be more expedient to wipe the disk and start anew. :) If I should run into this again on the new install. I guess a send-pr would be in order. Oh, and expect /alot/ of noise in the list. :) Thank you again for your continued (and valued) input. Best wishes. --Chris H [Hide Quoted Text] -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] I didn't mean to sound argumentative but the above was my last posting to the thread: [: -le: argument expected in freebsd-stable on Feb 2008. :) Thanks again for taking the time to respond. --Chris -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPMI and Dell ERA/O
On Saturday 30 August 2008 11:56:01 am Jonathan Bond-Caron wrote: On Fri Aug 29 11:24 AM, John Baldwin wrote: If your BIOS doesn't tell us about the IPMI BMC via ACPI or SMBIOS, you can try using hints (I've seen machines thave a BMC, but the BIOS doesn't bother to tell you about it). Dell boxes I've seen have KCS at the default address, so you can just do: hint.ipmi.0.at=isa0 hint.ipmi.0.mode=KCS Either add that to /boot/device.hints or for a test just explicitly set those variables at the loader prompt before booting. Thanks, that works! Although I don't really understand why? After some digging, I found this: (man 4 ipmi) BUGS Not all features of the MontaVista driver are supported. Currently, IPMB and BT modes are not implemented. But the interface for the Dell 1750 with ERA/O seems to be BT. Luckily it works enough for me with KCS (hint.ipmi.0.mode=KCS) http://linux.dell.com/ipmi.shtml Not the same BT. BT is a different transport for the host OS to talk to the BMC that allows for a more asynchronous model. I've not seen any hardware that supports BT yet. I'm saying 'works enough' because some readings show as 'disabled', I'm not sure if that's because the interface is not BT or the supported IPMI version is 1.0 (on the BMC): [EMAIL PROTECTED] /home/jbondc]# ipmitool -I open sdr CPU 1| disabled | ns CPU 2| disabled | ns CPU 3| disabled | ns CPU 4| disabled | ns CPU Planar | 35 degrees C | ok Ambient | 27 degrees C | ok CPU | 1.48 Volts| ok CPU 2| disabled | ns CPU 3| disabled | ns CPU 4| disabled | ns +5 | 5.05 Volts| ok +12 | 11.97 Volts | ok +3.3 | 3.29 Volts| ok Battery | 3.06 Volts| ok +2.5 | 2.55 Volts| ok NIC +2.5 | disabled | ns NIC +1.8 | disabled | ns MemCard A +2.5 | disabled | ns MemCard B +2.5 | disabled | ns MemCard A +1.25 | disabled | ns MemCard B +1.25 | disabled | ns Cover Intrusion | 0x00 | ok Fan Control | 0x17 | ok Fan 1| 6240 RPM | ok Fan 2| 6120 RPM | ok ... This is a property of your BMC. The fact that you can talk to it at all means communication with the BMC is working, and that is all the ipmi(4) driver provides (communication with the BMC). -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
IPV6_V6ONLY and UDP
I see in the release notes for 7.0; and seperately CURRENT on alpha; that IPV6_V6ONLY is now fully supported for UDP. Can someone point me to code/text that explains what exactly was broken about it? In what case(s) udp sockets set with IPV6_V6ONLY accepted V4 packets? Thanks in advance.. -- Jason Fesler, email/jabber [EMAIL PROTECTED] resume: http://jfesler.com Give a man fire, and he'll be warm for a day; set a man on fire, and he'll be warm for the rest of his life. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
