Re: IPMI shared ethernet ports (again).
I posted here a month or two ago about being amazed that some system management cards can share a physical ethernet port. Some of you responded that it doesn't always work. Well... I've encountered this and I'm wondering if I can work around it somehow. The ones that work are in Dell 1950-III servers (The R-200 seem to work, too). They have bce driver ports. The HP DL/360 that I have here today have bge driver ports and the IPMI console appears to stop working just as soon as FreeBSD probes the port. Is this something that can be configured in BGE or is it just not going to work? set hw.bge.allow_asf=1 in /boot/loader.conf from man bge: hw.bge.allow_asf Allow the ASF feature for cooperating with IPMI. Can cause sys- tem lockup problems on a small number of systems. Disabled by default. cheers, danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Small change to wc
On Fri, 5 Dec 2008 18:46:00 -0800, Sheldon Givens [EMAIL PROTECTED] wrote:
On Fri, Dec 5, 2008 at 4:17 PM, Giorgos Keramidas [EMAIL PROTECTED]wrote:
Adding the option to increase finger-compatibility and make shell
scripts a bit easier to port over sounds fine by me :)
My apologies if this is in the wrong format. I don't often post here.
---snip---
[patch]
---unsnip---
Can you post a `diff -u' or `diff -c' version of the patch? I like the
idea of the new option but it would be easier to read in -u/-c format.
New diff -u:
Excellent, thanks! Other than a few minor style-bugs, which can be
fixed before committing it (see inline comments for details), the patch
looks great to me :-)
--- /usr/src/usr.bin/wc/wc.c2004-12-27 14:27:56.0 -0800
+++ wc/wc.c 2008-12-05 14:33:21.0 -0800
@@ -167,9 +172,13 @@
return (1);
}
charct += len;
- for (p = buf; len--; ++p)
- if (*p == '\n')
+ for (p = buf; len--; ++p)
+ if (*p == '\n') {
+ if (tmpll llcnt)
+ llcnt = tmpll;
+ tmpll = 0;
++linect;
+ } else {tmpll++;}
It's probably more 'stylish' to write the else part as:
if (*p == '\n') {
if (tmpll llcnt)
llcnt = tmpll;
tmpll = 0;
++linect;
} else
tmpll++;
@@ -194,7 +207,7 @@
(void)printf( %7lld, (long
long)sb.st_size);
tcharct += sb.st_size;
(void)close(fd);
- return (0);
+ return (0);
This change only removes indendation from a return statement. We should
probably keep it out of the final commit.
Thanks for writing posting the patch :-)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Small change to wc
On Sat, 06 Dec 2008 13:57:53 +0200, Giorgos Keramidas [EMAIL PROTECTED] wrote:
Can you post a `diff -u' or `diff -c' version of the patch? I like the
idea of the new option but it would be easier to read in -u/-c format.
New diff -u:
Excellent, thanks! Other than a few minor style-bugs, which can be
fixed before committing it (see inline comments for details), the patch
looks great to me :-)
Ok, I've fixed a few minor bugs I noticed:
* When only -L is specified it should not enable the default 'cwl' set
of options.
* The tlongline total length should not be overwritten by each input
file, unless we *did* find a longer line in the particular file.
* The (llct - 1) trick is not needed when printing llcnt if we only
count != '\n' characters near line 229.
The updated patch, and a manpage change to document the new option is
attached below. Konstantin, if you like this version of the patch, I'll
commit it to /head and schedule an MFC after a week or so.
The longer line length that -L reports seems to work like this here:
: [EMAIL PROTECTED]:/hg/bsd/src/usr.bin/wc$ ./wc /etc/rc.conf
: 114 2222632 /etc/rc.conf
: [EMAIL PROTECTED]:/hg/bsd/src/usr.bin/wc$ ./wc -L /etc/rc.conf
: 82 /etc/rc.conf
: [EMAIL PROTECTED]:/hg/bsd/src/usr.bin/wc$ ./wc -lwc -L /etc/rc.conf
: 114 2222632 82 /etc/rc.conf
: [EMAIL PROTECTED]:/hg/bsd/src/usr.bin/wc$ ./wc -lwc -L /etc/rc.
: 114 2222632 82 /etc/rc.conf
: 15985648 36725 85 /etc/rc.subr
: 17125870 39357 85 total
: [EMAIL PROTECTED]:/hg/bsd/src/usr.bin/wc$
Here's the current patch version...
%%%
diff -r fb56dd4c9c47 usr.bin/wc/wc.1
--- a/usr.bin/wc/wc.1 Sat Dec 06 17:04:51 2008 +0200
+++ b/usr.bin/wc/wc.1 Sat Dec 06 17:39:17 2008 +0200
@@ -43,7 +43,7 @@
.Nd word, line, character, and byte count
.Sh SYNOPSIS
.Nm
-.Op Fl clmw
+.Op Fl Lclmw
.Op Ar
.Sh DESCRIPTION
The
@@ -71,6 +71,15 @@
.Pp
The following options are available:
.Bl -tag -width indent
+.It Fl L
+The number of characters in the longest input line
+is written to the standard output.
+When more then one
+.Ar file
+argument is specified, the longest input line of
+.Em all
+files is reported as the value of the final
+.Dq total .
.It Fl c
The number of bytes in each input file
is written to the standard output.
@@ -129,6 +138,10 @@
as well as the totals for both:
.Pp
.Dl wc -mlw report1 report2
+.Pp
+Find the longest line in a list of files:
+.Pp
+.Dl wc -L file1 file2 file3 | fgrep total
.Sh COMPATIBILITY
Historically, the
.Nm
@@ -154,6 +167,16 @@
.Xr iswspace 3
function, as required by
.St -p1003.2 .
+.Pp
+The
+.Fl L
+option is a non-standard
+.Fx
+extension, compatible with the
+.Fl L
+option of the GNU
+.Nm
+utility.
.Sh SEE ALSO
.Xr iswspace 3
.Sh STANDARDS
diff -r fb56dd4c9c47 usr.bin/wc/wc.c
--- a/usr.bin/wc/wc.c Sat Dec 06 17:04:51 2008 +0200
+++ b/usr.bin/wc/wc.c Sat Dec 06 17:39:17 2008 +0200
@@ -62,8 +62,8 @@
#include wchar.h
#include wctype.h
-uintmax_t tlinect, twordct, tcharct;
-int doline, doword, dochar, domulti;
+uintmax_t tlinect, twordct, tcharct, tlongline;
+int doline, doword, dochar, domulti, dolongline;
static int cnt(const char *);
static voidusage(void);
@@ -75,7 +75,7 @@
(void) setlocale(LC_CTYPE, );
- while ((ch = getopt(argc, argv, clmw)) != -1)
+ while ((ch = getopt(argc, argv, clmwL)) != -1)
switch((char)ch) {
case 'l':
doline = 1;
@@ -87,6 +87,9 @@
dochar = 1;
domulti = 0;
break;
+ case 'L':
+ dolongline = 1;
+ break;
case 'm':
domulti = 1;
dochar = 0;
@@ -99,7 +102,7 @@
argc -= optind;
/* Wc's flags are on by default. */
- if (doline + doword + dochar + domulti == 0)
+ if (doline + doword + dochar + domulti + dolongline == 0)
doline = doword = dochar = 1;
errors = 0;
@@ -125,6 +128,8 @@
(void)printf( %7ju, twordct);
if (dochar || domulti)
(void)printf( %7ju, tcharct);
+ if (dolongline)
+ (void)printf( %7ju, tlongline);
(void)printf( total\n);
}
exit(errors == 0 ? 0 : 1);
@@ -134,7 +139,7 @@
cnt(const char *file)
{
struct stat sb;
- uintmax_t linect, wordct, charct;
+ uintmax_t linect, wordct, charct, llct, tmpll;
int fd, len, warned;
size_t clen;
short gotsp;
@@ -143,7 +148,7 @@
wchar_t wch;
mbstate_t mbs;
- linect = wordct = charct = 0;
+ linect = wordct = charct = llct = tmpll = 0;
if (file == NULL) {
file = stdin;
fd = STDIN_FILENO;
@@ -168,8 +173,13 @@
Syscons with xterm emulation: one step closer to UTF-8 support?
Hello all, I may have mentioned this to some people some time ago, but I thought it would be nice to start a thread about this here on -hackers: A couple of weeks ago I started working on a library (libteken) that implements a subset of features (escape sequences) of xterm, our trusty X11 terminal application. I've done most hacking/testing in userspace, but this week I experimented with removing the terminal emulation from syscons and replaced it by the library. The result: - We can finally SSH to other operating systems, network switches, etc. without messing up our terminals. Almost any operating system out there has termcap entries for `xterm', which means stuff should Just Work (tm). - My library only accepts one character set of input: UTF-8. Right now it just directly forwards the character codes to Syscons, hoping Syscons has a character map that is capable of displaying them (which doesn't work). There are still many small issues I have to fix in the terminal emulation library, but also in the Syscons - libteken code. I won't commit it on short notice, obviously. If people want to test it, the code is in the MPSAFE TTY branch in Perforce. Diffs are available at: http://people.FreeBSD.org/~ed/mpsafetty/ My question is if there are people out there who could help me implementing UTF-8 font rendering. I wouldn't have a clue where to start (yet). Yours, -- Ed Schouten [EMAIL PROTECTED] WWW: http://80386.nl/ pgpCdyLLsDuws.pgp Description: PGP signature
Re: Small change to wc
On Sat, 06 Dec 2008 17:40:14 +0200, Giorgos Keramidas [EMAIL PROTECTED] wrote: The updated patch, and a manpage change to document the new option is attached below. Konstantin, if you like this version of the patch, I'll commit it to /head and schedule an MFC after a week or so. Committed to /head as change 185714: http://svn.freebsd.org/viewvc/base?view=revisionrevision=185714 Sheldon, thanks for the patch. I will merge it to the stable branches after about a few days :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unionfs kernel panic on 7.1-PRERELEASE
Did you have any ideas where the root of this problem may lie Kostik? - Original Message - From: Steven Hartland [EMAIL PROTECTED] Yes every time, I've got a half life 2 dedicated install mounted under unionfs:- mount -t unionfs -o noatime -o below /usr/local/games/hl2ds /usr/local/games/servers/1 As soon as I start the server from under servers/1 the machine panics I'm thinking its a combination of the Linux ABI and unionfs interaction which is causing the issue. Regards Steve - Original Message - From: Kostik Belousov [EMAIL PROTECTED] To: Steven Hartland [EMAIL PROTECTED] Cc: freebsd-hackers@freebsd.org Sent: Tuesday, December 02, 2008 8:39 PM Subject: Re: unionfs kernel panic on 7.1-PRERELEASE Is it reproducible ? The start of *fdp structure looks very suspicious, fd_ofiles = 0x140, fd_ofileflags = 0x154, fd_cdir = 0x168, fd_rdir = 0x17c, fd_jdir = 0x18c The values are consequently increasing by 0x14, except fd_jdir, and pointer values are wrong for kernel. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Problems with zfsboot loader if raidz present on any drive
Hello Hackers, Recently and friend and I have been trying to get the new gptzfsboot working on our machines and ran into a interesting problem. Initially I was building the world without the environment variable LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of course, didnt work very well. Every time the machine booted, it would throw 2 lines after the pin-wheel and then reboot. I couldent read what the lines were it went so fast. My friend had a bit more luck and got his machine working OK with a single drive and later a mirror drive added. I added the environment variable and rebuilt everything and installed. This time, I could see the bios drives and a further 2 lines of ZFS something and a reboot... No matter what I tried, I couldent get the machine to boot up to a point where I could try and fix the problem, so I started pulling devices out and found the following: If there is a raidz pool on any drive (not necessarily the one that you are trying to boot from) the loader dies and reboots the machine. My friend, as an experiment created 3 gpt partitions (in addition to the single partition that he had been previously booted from) on his single drive and made a raidz pool for testing. His machine showed the same condition as mine, however he was able to capture the message before the machine rebooted: message ZFS: can only boot from disk or mirror vdevs ZFS: inconsistent nvlist contents / /message ~Peg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
