On Friday, 10th February 2012, Eitan Adler wrote:
>-alias la ls -a
>+alias la ls -aF
> alias lf ls -FA
>-alias ll ls -lA
>+alias ll ls -lAF
>+alias ls ls -F
>
>Two people didn't like these changes but didn't explain why. This is
>incredibly helpful, especially f
On Friday, 20th September 2002, Martin Blapp wrote:
>mbr 2002/09/20 08:18:13 PDT
>
> Modified files:
>sys/pci if_dc.c
> Log:
> Fix the support for the AN985/983 chips, which do not set the
> RXSTATE to STOPPED, but to WAIT. This should fix hangs which
> could only b
On Friday, 20th September 2002, Martin Blapp wrote:
>I think we would have to test all cases with all cards. What cards
>do you have Stephen, with which clone Chipsets ? Can you make a list
>of them ?
I've only got DE500 (genuine Intel 21143) and Macronix 98715AEC cards.
Nothing PCMCIA or CardBu
On Friday, 20th September 2002, John Baldwin wrote:
>On 20-Sep-2002 Stephen McKay wrote:
>> Not quite. Davicom cards (and your card) fail to idle the receiver.
>> PNIC cards fail to idle the transmitter. So it makes just as much
>> sense as any other idea to check those bi
On Friday, 20th September 2002, John Baldwin wrote:
>On 20-Sep-2002 Stephen McKay wrote:
>> Sadly this change is insufficient to satisfy all cards.
>
>Well. I think we can keep the check for TX going idle and just not do
>the check for RX going idle. The original code basica
On Thursday, 19th September 2002, John Baldwin wrote:
>--- if_dc.c 4 Sep 2002 18:14:17 - 1.77
>+++ if_dc.c 19 Sep 2002 20:57:03 -
>@@ -1366,7 +1370,8 @@
>for (i = 0; i < DC_TIMEOUT; i++) {
>isr = CSR_READ_4(sc, DC_ISR);
>
On Wednesday, 4th September 2002, Martin Blapp wrote:
>And this patch here together with patch III made the annoying messages (dc0:
>failed to force tx and rx to idle mode) go away. And I can use now my card
>without to replug the cable over again)
I've been meaning to remove the annoying messag
On Monday, 25th March 2002, Robert Watson wrote:
>I think I have an identical problem involving a Linksys ethernet card
>using if_dc. I have to force it to negotiate 10mbps, since it fails to
>negotiate anything higher with my 10/100 switch. No idea why at all.
>
>dc0: port 0xe800-0xe8ff mem
>
On Monday, 25th March 2002, "Ilmar S. Habibulin" wrote:
>On Mon, 25 Mar 2002, Stephen McKay wrote:
>
>> What sort of card do you have? The output of dmesg would help. Have you
>> tried 4.5 on this machine?
>I have some noname nic with Intel 21143 chip.
On Friday, 22nd March 2002, "Ilmar S. Habibulin" wrote:
>On Sat, 23 Mar 2002, Stephen McKay wrote:
>
>> It's been quite a while since I updated my -current box, but when I did,
>> I was surprised to find that my DE500 network card (21143 chip) had stopped
>&
It's been quite a while since I updated my -current box, but when I did,
I was surprised to find that my DE500 network card (21143 chip) had stopped
working. The switch showed no link. Ifconfig showed "no carrier".
After some fiddling, I reverted revision 1.56 (removal of mii_pollstat call)
of
On Saturday, 5th January 2002, Søren Schmidt wrote:
>I forgot to say that I already committed the change to current...
:-)
I try to keep up with -current, but that's too current for me!
I'll hassle the REs tomorrow about permission to merge.
Thanks,
Stephen.
To Unsubscribe: send mail to [EM
On Saturday, 5th January 2002, Søren Schmidt wrote:
>It seems Stephen McKay wrote:
>>
>> Are these changes intended for 4.5? I'm hoping the small change I
>> proposed would be accepted into 4.5, before anybody starts using
>> "burncd msinfo" in practic
On Saturday, 5th January 2002, Søren Schmidt wrote:
>It seems Stephen McKay wrote:
>> Now that "burncd msinfo" returns the correct values I noticed another small
>> problem: it displays the result on stderr instead of stdout.
>
>Hmm, that was intentional...
C
Now that "burncd msinfo" returns the correct values I noticed another small
problem: it displays the result on stderr instead of stdout.
Since very few people (nobody?) would be using this option yet because
of the previous problem, it seems like nobody would be adversely affected
by changing the
A number of people have complained that "burncd msinfo" returns the wrong
value when there are already multiple sessions on a CD. This is true,
and is bug bin/27593.
Since I burn a lot of multisession CDs, and have been working out the mkisofs
-C values by hand with the help of "cdcontrol info",
cp -r foo bar1
$ patchedcp -r foo bar2
$ ls -ld foo bar?
drwxrwxrwx 2 mckay wheel 512 10 Dec 00:29 foo
drwxrwxrwx 2 mckay wheel 512 10 Dec 00:29 bar1
drwxr-x--- 2 mckay wheel 512 10 Dec 00:29 bar2
$
I believe the new behaviour is correct. It follows SUSv2, and matches
GNU cp. I know of no
On Tuesday, 14th August 2001, Daniel Eischen wrote:
>> > So do we allow FILE to be extended only after bumping the library
>> > version once (after 5.0-release)? And thereafter all extensions to
>> > FILE do not need a version bump?
>>
>> We've already bumped libc for 5.x. Assuming this works
On Thursday, 22nd March 2001, Bruce Evans wrote:
>On Wed, 21 Mar 2001, Stephen McKay wrote:
>> On the contrary, I prefer CTM over CVSup, even on a fast connection (which
>> I don't currently have). On a slow or intermittent connection, CTM beats
>> CVSup by a large mar
On Tuesday, 20th March 2001, Ulf Zimmermann wrote:
>On Mon, Mar 19, 2001 at 04:53:33PM -0800, John Baldwin wrote:
>>
>> On 20-Mar-01 Michael C . Wu wrote:
>> > For all connections greater than 9600baud modems, we recommend
>> > using CVSup to get src-all and ports-all updated. At the worst case,
[Noted that you don't like being cc:'d, David. On the other hand,
I like to be kept in the cc: list.]
On Tuesday, 26th December 2000, "David O'Brien" wrote:
>On Wed, Dec 27, 2000 at 02:01:24AM +1000, Stephen McKay wrote:
>> I'll try to summarise the
I'll try to summarise the position so far:
1) Legacy a.out executable support is broken for a subset (size unknown)
of such executables.
2) We can ignore this or repair this.
3) We can build a new binary or just look around on old 3.x CDs until
we find one that works.
4) We can generate a work
On Wednesday, 20th December 2000, "Donald J . Maddox" wrote:
>On Wed, Dec 20, 2000 at 10:14:09AM -0800, David O'Brien wrote:
>> On Wed, Dec 20, 2000 at 11:15:55PM +1000, Stephen McKay wrote:
>> > Correcting slightly for your slightly off assumption: The X11 libs
On Wednesday, 20th December 2000, "Donald J . Maddox" wrote:
>> > Looks good. Can you install the XFree896-aoutlib port? You may have
>> > seen were someone posted the a.out libs from 3.3.6 are known to not be
>> > the the best to use for compatibility use.
>
>Interesting. After I installed the
On Wednesday, 20th December 2000, "David O'Brien" wrote:
>On Mon, Dec 18, 2000 at 02:58:16AM +1000, Stephen McKay wrote:
>> This has been broken for new users for some time. :-( Those of us
>> upgrading from source have been immune to this problem, because we
On Tuesday, 19th December 2000, "Donald J . Maddox" wrote:
>Why are you (or your ISP) refusing to accept mail from people
>with cable modems? Enquiring minds want to know... ;-)
> - Transcript of session follows -
>... while talking to frmug.org.:
MAIL From:<[EMAIL PROTECTED]>
><
On Monday, 18th December 2000, Jordan Hubbard wrote:
>> The generated ld.so has bloated a bit :-) but works fine. So we could
>> in principle build ld.so for every release. It's just a question of
>> whether we should. I think we should. But it might be just as easy
>> to copy it off the 3.3
On Tuesday, 19th December 2000, Stephen McKay wrote:
>But it might be just as easy to copy it off the 3.3 CD every time.
Oops! As I wrote earlier, 3.3 and onward have the broken ld.so. Good
copies are found on 3.0 though to 3.2.
Sorry for veering off the road there. :-)
Stephen.
On Monday, 18th December 2000, "Donald J . Maddox" wrote:
>On Mon, Dec 18, 2000 at 04:41:17PM +1000, Stephen McKay wrote:
>>
>> I expected some build tool expert to say "Just compile with these
>> options". But they haven't. So I'll see
On Sunday, 17th December 2000, "Donald J . Maddox" wrote:
>Under the circumstances, it seems silly to have aout conpat
>bits installed at all, seeing as how they cannot work.
Old programs that don't depend on recompiled libraries are fine. I can't
guess at the percentages though. Also, nearly
On Saturday, 16th December 2000, "Donald J . Maddox" wrote:
>The other day, on a whim, I decided to try running an old binary
>of SimCity (the same one found in the 'commerce' directory on
>many FBSD cds), and it failed in a odd way...
You and I may be the only people in the world that run old b
I was trying to get FreeBSD 4.2-BETA to compile under FreeBSD 3.4 when
I found that the use of the new setresgid() and setresuid() system
calls were causing the perl5 compile to fail. I got around this using
NOPERL=yup but while investigating I noticed an apparent bug in the use
of setresgid() an
Well, I've failed in my main objective (to deuglify the shutdown messages),
but an interesting debate has resulted instead, so I can't feel too bad.
I did a little research to support my position on sleep/wakeup, and here's
the best I have. This is pretty long, and unlikely to shake your world v
> * Mike Smith <[EMAIL PROTECTED]> [000807 01:25] wrote:
> > > * Stephen McKay <[EMAIL PROTECTED]> [000805 08:49] wrote:
> > > >
> > > > ... every sleeping process should expect
> > > > to be woken for no reason at all. Basic kernel p
I'm off in a few days for a couple months of tourism in Europe (no, no need
for sympathy!), so I'm dumping these couple ideas on you and running.
I think shutdown time has gotten uglier and slower than it needs to be.
I want to apply these patches (well, at least the first one) before I escape
ra
On Friday, 14th July 2000, "Rodney W. Grimes" wrote:
>> I suspect an interaction between the ATA driver and VIA chipsets,
>> because other than the network, that's all that is operating when I see
>> the underruns. And my Celeron with a ZX chipset is immune.
>
>I've seen them on just about ever
On Friday, 14th July 2000, Matthew Jacob wrote:
>
>> That theory is not correct, I have seen multiple Alpha machines reporting
>> buffer underruns as well. No ATA disk in sight there..
>
>This has been a reported feature of the tulip chip and alphas (de driver
>usually) forever forever forever.
On Thursday, 13th July 2000, "Rodney W. Grimes" wrote:
>>On Thu, 13 Jul 2000, Stephen McKay wrote:
>>
>>>Does anyone here actually measure these latencies? I know for a fact
>>>that nothing I've ever done would or could be affected by extra late
On Monday, 10th July 2000, Stefan Esser wrote:
>On 2000-07-09 20:52 +1000, Stephen McKay <[EMAIL PROTECTED]> wrote:
>> On Saturday, 8th July 2000, Stefan Esser wrote:
>>
>>>Oh, there are renegotiations after each overrun ???
>> The code at the p
I found out much to my surprise that our SMP box is not collecting ANY
entropy for /dev/random. All the interesting IRQs are over 16, and
nobody uses the console.
>From sys/i386/i386/mem.c 1.79:
/*
* XXX the data is 16-bit due to a historical botch, so we use
* magic 1
On Thursday, 27th January 2000, "Rodney W. Grimes" wrote:
>> <
>said:
>>
>> >> 3. On the first reboot after installing, the keyboard was in a funny
>> >> state.
>I have seen this on numerious occasion, but have never tracked it down
>to any one specific thing. All on desktop and servers, but
Hi, Brian!
I'm concerned that your fix won't make it before the code freeze. Is
there a problem with it? I admit I haven't actually tested it. :-(
My excuse is that I assumed you had.
Or should I just do a quick test on your patch (+ bde fixes) and commit
it myself?
Stephen.
To Unsubscribe:
On Tuesday, 18th January 2000, "Leif Neland" wrote:
>I've been hit by a "forgotten ping" again.
>
>I still do not see a reason for not having a default number of pings, instead
>of infinite. The only reason I've seen is "It's always been so".
I find this argument rather odd. Train yourself to
I'm currently giving 4.0 a thrashing in the best way I know. I run way too
much stuff and let it page madly all day. Here's how I killed it:
1) pick a 32MB box
2) make -j20 buildworld
3) lean on ^T and let autorepeat go for it
Soon it dies in calcru() called from ttyinfo(). The stack trace sh
On Thursday, 6th January 2000, Yoshinobu Inoue wrote:
>Does these patches fix your problem, or should another better
>fix is desired? Please give me any opinions.
It passes all my tests. Please commit it. Thank you!
And earlier you wrote:
>Because now there is interface statistics display mo
I've got very used to an alias ns='netstat -f inet' which lets me do all
the things I like to do without annoying me with stuff I don't want to
see. All the options that don't care about the address family just ignore
that option. Or, used to.
Recently that changed, and "netstat -f inet -i" in
On Friday, 10th December 1999, Mike Smith wrote:
>The same mentality that made the CAM cutover a "debacle" is making the
>ata cutover a "debacle".
This "mentality" might be an unavoidable part of human nature. I found
my first reaction was "How dare they take away something I have now?!"
and
On Friday, 10th December 1999, "Kenneth D. Merry" wrote:
>Brad Knowles wrote...
>> At 3:05 PM -0700 1999/12/10, Kenneth D. Merry wrote:
>>
>> > I agree that the CAM integration shouldn't be used as a precedent here.
>> > I don't agree with your characterization of it as a "debacle", though.
>>
On Monday, 22nd November 1999, Bernd Walter wrote:
>On Mon, Nov 22, 1999 at 02:57:39PM +1000, Stephen McKay wrote:
>> I think there is a fault in fsck. Possibly it is because softupdates
>> changed the rules. Having run md5 over the good copy and the broken
>> (power fail
On Sunday, 21st November 1999, Christopher Masto wrote:
>On Sun, Nov 21, 1999 at 10:36:32PM +1000, Stephen McKay wrote:
>> When the system came back up, fsck -p didn't like the vinum volume.
>> No sweat, I ran it manually. There were many
>>
>> INCORRE
I was giving vinum + softupdates a bit of a workout on 4 really old
SCSI disks (Sun shoeboxes, if you must know) attached to an aha1542B.
The rest of the machine is a Pentium 133 with 64MB of parity ram, a
few more disks, and another aha1542B. It runs -current (about 10 days
old now).
I was copy
On Thursday, 9th September 1999, "John W. DeBoskey" wrote:
> The following patch to /usr/src/release/Makefile allows the
>specification of the variable FASTCLEAN, which instead of doing
>a recursive rm on CHROOTDIR, simply umounts/newfs/mounts.
>+ -device=`df | grep '${CHROOTDIR}' | cut -
[I'm trying my first crosspost experiment here. Please follow up to -scsi.]
A week ago I posted my strange crash and subsequent doubts about the proper
functioning of softupdates. This is more of the story.
I examined the lost+found directory more closely and of the few files that
I traced, th
On Tuesday, 24th August 1999, Wilko Bulte wrote:
>Hmm. I would generally expect SCSI errors etc to occur. Assuming the driver
>reports those one would at least know the bus was whacko.
I saw no errors, but that's not entirely surprising since I was running X11
and by that time xconsole was proba
On Tuesday, 24th August 1999, "Brian F. Feldman" wrote:
>On Tue, 24 Aug 1999, Richard Tobin wrote:
>
>> > > Origin = "AuthenticAMD" Id = 0x580 Stepping=0
>>
>> > You have one of the first K6-2s off the line. There were definite problems
>> > with these, and as such, they were specially disti
On Tuesday, 24th August 1999, Peter Jeremy wrote:
>The exact order of events is not clear from this. In general, I'd say
>that if something managed to upset the SCSI bus sufficiently to
>confuse every target on it, then there's a reasonably likelihood that
>data transfers were also corrupted. A
I had a recent crash on my home box that makes me question the reliablity
of softupdates. My home box runs 3.2-R, but as far as I can determine,
there have been no reliablity fixes to softupdates since then. So a failure
here should be relevant to -current.
Hardware: K6-2/300, 64MB ECC SDRAM, F
On Saturday, 10th July 1999, Matthew Dillon wrote:
>I'm trying to simulate your 486 setup. You must love pain! A make -j5
>buildworld on a 16MB-limited machine pages like hell (200-400 pageins/sec
>AND 200-400 pageouts/sec simultaniously, almost continuously).
Maximal pain, maximal
On Thursday, 8th July 1999, Matthew Dillon wrote:
>There is a way we can find out for sure. For any of you with processes
>stuck in objtrm, see if you can gdb the kernel and get a backtrace
>of that process to see if it might be in a state where a previous
>call context is holdin
On Tuesday, 6th July 1999, Andrew Gallatin wrote:
>Yes. say 'proc pidhashtbl[PID & pidhash]->lh_first' in kgdb.
>I suspect that it will be in exit() also..
Magic!
It looks like a plain old exit() to me.
(kgdb) proc pidhashtbl[27157&pidhash]->lh_first
(kgdb) bt
#0 mi_switch () at ../../kern/k
On Tuesday, 6th July 1999, Stephen McKay wrote:
>the make world hangs with cc1 in "objtrm"...
I'm having a fun old conversation with myself here! ;-)
Here's some concrete info:
(kgdb) p/x *(struct vm_object*) 0xc32ea21c
$13 = {object_list = {tqe_next = 0xc3389e58
On Friday, 2nd July 1999, Stephen McKay wrote:
>I have an old 486 here that I thrash to death occasionally. Well, at least
>I try to get it to page to death. I started a make world last week and
>forgot about it.
>
>Today I noticed that it's been stuck for most of the week
I have an old 486 here that I thrash to death occasionally. Well, at least
I try to get it to page to death. I started a make world last week and
forgot about it.
Today I noticed that it's been stuck for most of the week. Almost everything
is fine, but one cc1 process is stuck in "objtrm". Oh
On Sunday, 2nd May 1999, Chuck Robey wrote:
>On Mon, 3 May 1999, Jean-Marc Zucconi wrote:
>
>> This one did not arrive in my mailbox. Can someone send it to me? I
>> would like to avoid downloading 6Mbytes again.
>
>I'm going to mail it to you separately, but it might not look like it
>came from m
On Sunday, 11th April 1999, Brian Feldman wrote:
>This has nothing to do with DOS. In case you didn't get my other hint:
>{"/home/green"}$ dd if=/dev/zero count=1 2>/dev/null | file -
>standard input: MS Windows COFF Unknown CPU
Don't ya just hate it when your mail is slow! Sigh...
On Sunday, 11th April 1999, Alfred Perlstein wrote:
>On Sun, 11 Apr 1999, Matthew Dillon wrote:
>
>> doing a 'file cd9660_bmap.o' on laptop (NFS client) gives me a
>> cd9660_bmap.o: MS Windows COFF Unknown CPU
>>
>> An MS Windows binary? Do you have any msdos mounts on
>> the client or
[I posted this to -current because the technology is the same in -current
even though this box will never run -current. Bear with me.]
We've just got a new Dell PowerEdge (very nice) with 512MB of ram. By
default, 3.1-stable sees only 64MB. Looking carefully, it sees 8KB less
than 64MB, so it d
On Monday, 5th April 1999, Matthew Dillon wrote:
>:char sccs[] = { '@', '(', '#', ')' };
>:char version[] = blahhhfoo;
>:Was contiguous.
>'what' is broken. C does not impose any sort of address ordering
>restriction on globals or autos that are declared next to each other.
Well,
I've just got what seems an unlikely panic. How could I get a privileged
instruction fault while in kernel mode?
This is from a week old 4.0-current kernel on a 16Mb 486. It has an AHA1542CF
a slow SCSI-1 disk, and a rebadged TDC4200 (2GB QIC). I run soft updates
but nothing else fancy. I was
On Sunday, 21st March 1999, Richard Wackerbarth wrote:
>Why do we need to have ANY of the file inclusion in /etc/defaults/rc.conf?
>Shouldn't that file simply be definitions of variables?
>IMHO, the "logic" should be in "rc" itself.
Yeah! What he said!
Having code in rc.conf sucks. If there is
Hardware: 486DX2/66 16Mb ram, aha1542CF, 2x1Gb SCSI disks
Software: 4.0-current 1-2 days old, softupdates
(vm_map.c is at rev 1.146, for example)
I was running 'make -j5 buildworld'. It swaps like crazy when I do this. :-)
Here's what gdb -k tells me:
...
#9 0xf01425e0 in panic (
71 matches
Mail list logo
