On Sat, Aug 25, 2001 at 02:02:21PM +0200, Oliver Fromme wrote:
> Probably because it's just too late. During the initial
> discussion, the voices pro and contra were about 50:50 (at
> least that was my impression), and finally the pro ones
> succeeded, probably because they had more "weight" (thi
On Fri, Aug 24, 2001 at 11:10:53PM -0500, Matthew D. Fuller wrote:
> > Then please enumerate them so that they can be given due attention.
> > This is exactly the sort of detailed feedback that was requested when
> > we first raised the issue of switching over, and nobody could come up
> > with an
>In message <[EMAIL PROTECTED]> "David W. Chapman
> Jr." writes:
>: I'm running -current as of an hour ago. I've gotten this since I've
>: been running 4.2-stable, any ideas on how I can find out what it
>: belongs to?
>:
>: unknown: can't assign resources
>: unknown: can't assign resources
David O'Brien <[EMAIL PROTECTED]> wrote:
> > _But_ my vote would be for still having a "real" csh in
> > /bin, additionally. (And don't tell me that tcsh is a
> > real csh -- it's not, see below.)
>
> By chance have you looked at the csh source in the CSRG SCCS files?
> How about the tcsh
On Sun, Aug 26, 2001 at 13:20:23 +0200, Oliver Fromme wrote:
> "Our" csh still behaves differently like any /bin/csh on
> any other system that I know, and can't be easily made to
> behave like them.
>
> When I wrote "real csh", I meant a csh which exhibits the
> traditional behaviour and user in
>Date: Sun, 26 Aug 2001 02:43:56 -0400 (EDT)
>From: "Brandon D. Valentine" <[EMAIL PROTECTED]>
>On Sat, 25 Aug 2001, Jim Bryant wrote:
>>> Wow. Why not use xdm? 8)
>>Too lazy?
>Heh. You just uncomment one line in /etc/ttys and HUP init. It's not
>compilicated.
Indeed. However, there are
I believe that I have a real fix for the SCB timeout problems
that have been plauging users of recent Intel fxp boards.
If you have a board that uses the Intel ICH2/ICH2-M chipset
(usually 815E style boards) and feel comfortable applying
patches to the system, please contact me to test a fix
In message <[EMAIL PROTECTED]> Kazutaka YOKOTA
writes:
: Shouldn't we just suppress the message? It just confuses users.
:
: The attached patch will print this message only when we boot
: the kernel by 'boot -v'.
They are there to remind certain folks that the ISA PnP code is broken
slightly
> >>> Wow. Why not use xdm? 8)
>
> >>Too lazy?
>
> >Heh. You just uncomment one line in /etc/ttys and HUP init. It's not
> >compilicated.
>
> Indeed. However, there are some differences in startup of which to be
> aware (.xinitrc vs. .xsession).
I just hard-link the two files together. :)
>: unknown: can't assign resources
>: unknown: can't assign resources
>: unknown: can't assign resources
>: unknown: can't assign resources
>: unknown: can't assign resources
>: unknown: can't assign resources
> Shouldn't we just suppress the message? It just confuses users.
I would be s
On Sun, Aug 26, 2001 at 09:51:57AM -0600, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Kazutaka YOKOTA
>writes:
> : Shouldn't we just suppress the message? It just confuses users.
> :
> : The attached patch will print this message only when we boot
> : the kernel by 'boot -v'.
>
> They
>In message <[EMAIL PROTECTED]> Kazutaka YOK
>OTA writes:
>: Shouldn't we just suppress the message? It just confuses users.
>:
>: The attached patch will print this message only when we boot
>: the kernel by 'boot -v'.
>
>They are there to remind certain folks that the ISA PnP code is broken
>
> >: unknown: can't assign resources
> >: unknown: can't assign resources
> >: unknown: can't assign resources
> >: unknown: can't assign resources
> >: unknown: can't assign resources
> >: unknown: can't assign resources
>
> > Shouldn't we just suppress the message? It just confuses us
In message <[EMAIL PROTECTED]> Wilko Bulte writes:
: They are also in RELENG_4..
Those should be hidden by -v then :-)
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
I have it on two machines with this chipset and it looks good so
far. After installing, dmesg shows
fxp0: port 0xc400-0xc43f mem 0xd5001000-0xd5001fff
irq 11 at device 8.0 on pci1
fxp0: *** DISABLING DYNAMIC STANDBY MODE IN EEPROM ***
fxp0: New EEPROM ID: 0x49a0
fxp0: EEPROM checksum @ 0xff:
In message <[EMAIL PROTECTED]> Jim Bryant writes:
: > Wow. Why not use xdm? 8)
:
: Too lazy?
vi /etc/ttys; s/off/on on xdm line; kill -1 1
Too lazy to do even that? Wow! That's Lazy :-)
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of
On Sat, 25 Aug 2001, Kris Kennaway wrote:
> On Sat, Aug 25, 2001 at 01:50:33AM -0500, Jim Bryant wrote:
>
> > For 5.0, I maybe the black sheep in saying this, but I'd like to see
> > /bin/csh be the real thing for 5.0. By all means, leave tcsh in
> > /bin, but for the sake of backwards compatab
> The motto used to be "do it right", not "do it the way WE want it on OUR
> machines, and screw the people who don't make the decisions or cause to much
> trouble to ignore."
It still is. And recognising that csh has evolved over the last decade
is part of "doing it right".
What you're really
On Sun, 26 Aug 2001, Mike Smith wrote:
> > The motto used to be "do it right", not "do it the way WE want it on OUR
> > machines, and screw the people who don't make the decisions or cause to much
> > trouble to ignore."
>
> It still is. And recognising that csh has evolved over the last decade
On Sun, Aug 26, 2001 at 02:57:31PM -0500, Kaila wrote:
> On Sun, 26 Aug 2001, Mike Smith wrote:
>
> Naming linking it to csh broke things for people who weren't informed it was
> happeneing, and then had to go and spend hours tracking down the problem and
> fixing it.
>
How could you be uninfor
On Sun, Aug 26, 2001 at 01:20:23PM +0200, Oliver Fromme wrote:
> "Our" csh still behaves differently like any /bin/csh on
> any other system that I know, and can't be easily made to
> behave like them.
This is an assertion. Where is your supporting evidence?
Kris
PGP signature
Kazutaka YOKOTA wrote:
> >: I'm running -current as of an hour ago. I've gotten this since I've
> >: been running 4.2-stable, any ideas on how I can find out what it
> >: belongs to?
> >:
> >: unknown: can't assign resources
> >: unknown: can't assign resources
> >: unknown: can't assign resou
In message <[EMAIL PROTECTED]> Terry Lambert writes:
: Shouldn't we just take the Linux/NetBSD information, and
: actually identify the things instead of saying "Unknown",
: instead, and leave them printing to encourage someone the
: messages annoy to do the work?
I'd guess that's too much work.
"Andrey A. Chernov" wrote:
> > When I wrote "real csh", I meant a csh which exhibits the
> > traditional behaviour and user interface ("look and feel",
> > if you prefer) of a csh. tcsh does not. Someone used to
> > work with a "real csh" simply can't be happy with tcsh,
> > especially if he has
On Sun, Aug 26, 2001 at 14:14:48 -0700, Terry Lambert wrote:
>
> While we may be stuck with this bait-and-switch "upgrade", I
> think his complaints are not co easily addressed. Certainly,
> the "exec" complaint remains valid, in any case: it's a bug
> that csh didn't have.
Complaints _are_ eas
Thus spake Warner Losh ([EMAIL PROTECTED]):
> I'd guess that's too much work. Maybe someone can prove me wrong with
> trivial patches.
Maintaining the device-table is probably the most work (since
we already have the PNP string and most lists are sortedc
by this string as well).
Alex
To
> > It still is. And recognising that csh has evolved over the last decade
> > is part of "doing it right".
>
> No, doing it right would have been including tcsh and deprecating csh, then
> dropping it later as has been done with other things.
This is what was done. The old csh is deprecated,
Steve Kargl wrote:
> On Sun, Aug 26, 2001 at 02:57:31PM -0500, Kaila wrote:
> > Naming linking it to csh broke things for people who weren't
> > informed it was happeneing, and then had to go and spend hours
> > tracking down the problem and fixing it.
>
> How could you be uninformed about this c
Kris Kennaway wrote:
> On Sun, Aug 26, 2001 at 01:20:23PM +0200, Oliver Fromme wrote:
> > "Our" csh still behaves differently like any /bin/csh on
> > any other system that I know, and can't be easily made to
> > behave like them.
>
> This is an assertion. Where is your supporting evidence?
Hit
Kazutaka YOKOTA wrote:
> Um, we see these messages not only because our ISA PnP driver needs
> some update, but also because we create ISA device instances TWICE for
> each motherboard ISA devices, such as sio and atkbdc, due to
> /boot/device.hints.
>
> We need to have /boot/device.hints for tho
Comparative times for 'make buildworld'
for unmodified and KSE (milestone-2) kernels
unmodified -current
2138.464u 3358.378s 1:37:39.77 93.8%842+1080k 45105+176988io 3208pf+0w
modified KSE kernel
2143.716u 3363.311s 1:37:50.33 93.8%841+1081k 45435+176988io 3214pf+0w
I'm very glad to see
> > >: unknown: can't assign resources
> > >: unknown: can't assign resources
> > >: unknown: can't assign resources
> > >: unknown: can't assign resources
> > >: unknown: can't assign resources
> > >: unknown: can't assign resources
> > >
> > >Don't worry about these.
> >
> > Shouldn't we
> So, you are saying that this is because there is not a seperate
> "No BIOS" and "BIOS" section (or entry prefix) in the hints file,
> so that in a non-PnP system, both the "No BIOS" and "BIOS"
> entries will be examined, whereas on a PnP system, only the "BIOS"
> entries will be examined?
This
Warner Losh wrote:
> : Shouldn't we just take the Linux/NetBSD information, and
> : actually identify the things instead of saying "Unknown",
> : instead, and leave them printing to encourage someone the
> : messages annoy to do the work?
>
> I'd guess that's too much work. Maybe someone can pro
In message <[EMAIL PROTECTED]> Terry Lambert writes:
: So, you are saying that this is because there is not a seperate
: "No BIOS" and "BIOS" section (or entry prefix) in the hints file,
: so that in a non-PnP system, both the "No BIOS" and "BIOS"
: entries will be examined, whereas on a PnP syste
Mike Smith wrote:
> > So, you are saying that this is because there is not a seperate
> > "No BIOS" and "BIOS" section (or entry prefix) in the hints file,
> > so that in a non-PnP system, both the "No BIOS" and "BIOS"
> > entries will be examined, whereas on a PnP system, only the "BIOS"
> > entr
Warner Losh wrote:
> Since that's not how it works, the solution is a non-starter.
>
> We just need to carefully order the ISA code probing sections to get
> the desired effects. We haven't done that yet. All PnP devices are
> probed together at the end, which isn't quite right.
The problem wa
David Wolfskill wrote:
>>Date: Sun, 26 Aug 2001 02:43:56 -0400 (EDT)
>>From: "Brandon D. Valentine" <[EMAIL PROTECTED]>
>>
>
>>On Sat, 25 Aug 2001, Jim Bryant wrote:
>>
>
Wow. Why not use xdm? 8)
>
>>>Too lazy?
>>>
>
>>Heh. You just uncomment one line in /etc/ttys and HUP init. I
In message <[EMAIL PROTECTED]> Terry Lambert writes:
: Warner Losh wrote:
: > Since that's not how it works, the solution is a non-starter.
: >
: > We just need to carefully order the ISA code probing sections to get
: > the desired effects. We haven't done that yet. All PnP devices are
: > pro
Nate Williams wrote:
>Wow. Why not use xdm? 8)
>
Too lazy?
>>>Heh. You just uncomment one line in /etc/ttys and HUP init. It's not
>>>compilicated.
>>>
>>Indeed. However, there are some differences in startup of which to be
>>aware (.xinitrc vs. .xsession).
>>
>
> I just
> I think the reason the hints are not just ignored is to allow
> people to fix "rogue" hardware. I'm willing to be corrected,
Good. It's like it is right now because the PnP stuff was bolted on as
an afterthought.
> since this looks like about 12 lines of code would make it
> ignore device.h
On Sun, Aug 26, 2001 at 03:01:33PM -0700, Terry Lambert wrote:
> Kris Kennaway wrote:
> > On Sun, Aug 26, 2001 at 01:20:23PM +0200, Oliver Fromme wrote:
> > > "Our" csh still behaves differently like any /bin/csh on
> > > any other system that I know, and can't be easily made to
> > > behave like
Kris Kennaway wrote:
> On Sun, Aug 26, 2001 at 03:01:33PM -0700, Terry Lambert wrote:
> > Kris Kennaway wrote:
> > > On Sun, Aug 26, 2001 at 01:20:23PM +0200, Oliver Fromme wrote:
> > > > "Our" csh still behaves differently like any /bin/csh on
> > > > any other system that I know, and can't be ea
> Then go look them up. I'm not about to stuff the entire PnP device
> database into the kernel just to satisfy your curiosity. 8(
I was going to ask where, but I see they are in
/usr/src/sys/boot/common/pnpdata.
thanx,
brad
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe f
Terry Lambert wrote:
> I was still grumpy about the change, but that at least was
> enough to mollify me into not objecting loudly and persitantly
> up to the import.
>
> Let me get this straight, though: _now_ you are saying that
> the system wide defaults and account template defaults will
>
>: Whether it's perfect or not, making the device.hints "go away"
>: in the presents of PnP BIOS on the machine would seem to be
>: able to address the issue of doubled entries... right?
>
>Not entirely. There are ISA devices in devices.hints that aren't plug
>and play and aren't in the PnP BIOS
>
> > Then go look them up. I'm not about to stuff the entire PnP device
> > database into the kernel just to satisfy your curiosity. 8(
>
> I was going to ask where, but I see they are in
> /usr/src/sys/boot/common/pnpdata.
That's a useful subset that I keep forgetting about; thanks for remi
Warner Losh wrote:
> : Whether it's perfect or not, making the device.hints "go away"
> : in the presents of PnP BIOS on the machine would seem to be
> : able to address the issue of doubled entries... right?
>
> Not entirely. There are ISA devices in devices.hints that aren't plug
> and play an
> I once wrote the following patch to deal with this problem by
> probing ISA devices in the following order.
>
> 1. sensitive ISA devices described in device.hints
> 2. PnP BIOS ISA devices
> 3. other ISA devices described in device.hints
> 4. PnP ISA devices
This order is still slightly wrong.
> I remember an ACER system with a bus mouse on the motherboard
> which was unknown to the PnP BIOS, and Windows 95 trying to
> be a "PnP OS" used to always do what above looks to be the
> "PnP ISA devices" phase of things, and gave IRQ 12 to the
> second IDE disk interface, instead of the on-boar
After being informed of the paragraph in UPDATING on this topic, I went to
/usr/src/etc to see what the settled-upon UID/GID of
"bind" is...
Ummm... Did someone forget to commit changes to the /usr/src/etc/group and
/usr/src/etc/passwd baseline files?
What UID/GID should be used?
jim
--
ET
On Sun, Aug 26, 2001 at 06:10:53PM -0500, Jim Bryant wrote:
> After being informed of the paragraph in UPDATING on this topic, I
> went to /usr/src/etc to see what the settled-upon UID/GID of "bind"
> is... Ummm... Did someone forget to commit changes to the
> /usr/src/etc/group and /usr/src/etc
Okay, please don't say it... I'm blind...
Boot to the head!
I see it now, as GID 53...
Jim Bryant wrote:
> After being informed of the paragraph in UPDATING on this topic, I went
> to /usr/src/etc to see what the settled-upon UID/GID of "bind" is...
>
> Ummm... Did someone forget to commit
In message <[EMAIL PROTECTED]> "Andrey A. Chernov" writes:
: Complaints _are_ easily addressed, tcsh author is responsible and fix all
: thing that I report to him. If you complain about 'upgrade' problem, i.e.
: we don't have latest tcsh, ask our tcsh maintainer for upgrade.
I'm our tcsh maintai
Well it seems the www.spawndevices.com $15 - $25 buck boots and emu\'s made a few of
you happy good... glad to hear it... Well the special for you this weekend is all
Combo Packages are $79.99... Your choice an Emu or a Bootstrap (DPBB) with either a
Dual Crystal ISO or a WT2-X unlooper...
Having overcome a small issue with buildworld in
games/fortune/strfile, there's a new
+issue: buildworld fails in /usr/src/secure/lib/libssl
make's output is a bit lengthy at this point, so I've slightly
clipped it:
===> libssl
( echo "#ifndef MK1MF_BUILD"; echo " /* auto-generated by
crypto/M
I am ready to do my megga-commit to add the first stage of KSE-threading support
to
the kernel. If there is any argument as to the wisdom of this move,
then this is the time to speak up!
At this stage a commit would break alpha and ia64 until
they are patched. From experience I can say that it'
Can the IA64 and Alpha developers (Arm too?)
look at the KSE patch set at
http://www.freebsd.org/~julian/thediff
This compiles and runs pretty solidly on 386.
it needs people who understand the other architectures to make
the appropriate changes and send them to me (or check them int P4)
so that
58 matches
Mail list logo
