On 2006-07-21, [EMAIL PROTECTED] wrote:
This problem is also present in 6.0. Why haven't a whole bunch of
people already run into it? Am I the only person still using a
parallel port printer and (at first) a generic kernel?
I use parallel printers under 6.0 and 6.1 on i386 and amd64
generic
On Saturday 22 July 2006 08:01, Greg Black wrote:
On 2006-07-21, [EMAIL PROTECTED] wrote:
This problem is also present in 6.0. Why haven't a whole bunch of
people already run into it? Am I the only person still using a
parallel port printer and (at first) a generic kernel?
I use
On Fri, 2006-Jul-21 22:46:52 -0700, [EMAIL PROTECTED] wrote:
sprinkled in). I'm guessing that if_plip.c has requested it and not
released it, which apparently happens when there's been an ioctl on
the plip. There's no plausible reason why anythhing should be
happeneing on plip, as far as I can
I suspect plip has outlived its usefulness.
PL-IP is still useful. Like ed, one wouldnt want to use it every day,
but it's useful for fallback bootstrapping / rescue / 1st install,
if ether fails etc.
--
Julian Stacey. Consultant Unix Net Sys. Eng., Munich. http://berklix.com
Mail in Ascii,
As was suggested, the problem is that when the system automatically
brings up the plip0 interface, it grabs the ppbus and doesn't let it
go until someone takes the interface down. I now believe this problem
was present even in 5.3, but I didn't see it because I routinely
compiled custom 5.x
Dear -hackers and -emulation readers,
I would like to call your attention to a few long-standing problems that have
so far prevented WINE from living up to its capabilities on FreeBSD.
I am afraid that I still don't fully grasp the scope of the problem, nor do I
have a clear idea of what the
On Sat, Jul 22, 2006 at 10:03:25AM -0700, [EMAIL PROTECTED] wrote:
So the real simple fix is to prevent the plip0 interface from coming
up. I thought the simple fix for this was to put:
ifconfig_plip0=noauto
This is supposed to work? I thought the values to the ifconfig_* variables
were
Thanks for your input.
The relative merits of the different threading libraries is currently
under discussion. Could you also try it with libthr (it may not work
at all), I'd like to hear what happens. Thanks.
-Kip
On 7/22/06, Michael Nottebrock [EMAIL PROTECTED] wrote:
Dear -hackers and
On Saturday, 22. July 2006 21:20, Kip Macy wrote:
Thanks for your input.
The relative merits of the different threading libraries is currently
under discussion. Could you also try it with libthr (it may not work
at all), I'd like to hear what happens. Thanks.
WINE crashes in roughly the same
Thanks. That is a useful data point but David Xu has done a lot of
work on libthr that has probably not been MFC'd back to 5.x. When I
get the chance I'll try building KDE on my desktop which runs a
derivative of -CURRENT. It may well be a general kernel bug, as I
recall seeing the same error
On Friday, 21 July 2006 at 14:32:04 +0100, Robert Watson wrote:
On Fri, 21 Jul 2006, Greg 'groggy' Lehey wrote:
I've been keeping a closer eye on my problem. I'm using fvwm1 with
click-to-focus and lose-focus-on-screen-switch. If I move from one
screen to another and quickly click on a
On Friday, 21 July 2006 at 23:38:00 +0930, Daniel O'Connor wrote:
On Friday 21 July 2006 23:02, Robert Watson wrote:
I've occasionally also had weird focus problems with KDE. Among other
things, it looks like occasionally the mouse release event is lost
somewhere in the system (or something
On Sat, 22 Jul 2006, Michael Nottebrock wrote:
On Saturday, 22. July 2006 21:20, Kip Macy wrote:
Thanks for your input.
The relative merits of the different threading libraries is currently
under discussion. Could you also try it with libthr (it may not work
at all), I'd like to hear what
I'm working on a project that relies on me building kernels outside
of the standard /usr/src (typically ~/perforce/projects/ ) on my
relatively standard 6.1-STABLE workstation. I'm wondering if I'd be
best suited by setting up a jail for kernel builds, I'm following
this doc:
I'm just wondering, the machine-dependent assembly tied into the i386
kernel, that's all named ${FILENAME}., while in the arm/ kernel
machine-dependent code is named ${FILENAME}.S, what's the difference?
Or is there none, just a change in convention?
Cheers,
-R. Tyler Ballance
15 matches
Mail list logo
