As discussed a few days ago, I've just committed the changes to libc
and libc_r to allow them to be linked together via -lc_r. If you're
running -current and have any threaded apps built using libc_r.so.5,
you'll need to rebuild them without the -pthread option using -lc_r.
For porters, the __Fr
Many weeks ago, I noticed that pccardd died with a SIGSEGV when
I inserted my Motorola Montana 33.6 fax/modem. I'm not sure of
the exact time as to when this occurred, but I know that pccardd
had been working just fine with this card. I finally found the
time to track down the problem (now that
[EMAIL PROTECTED] wrote:
>
> In article
> <[EMAIL PROTECTED]>, Daniel
> Eischen <[EMAIL PROTECTED]> wrote:
>
> > For SCHED_FIFO and SCHED_RR, we don't have a problem because both
> > the threads library and kernel now agree that the range is 0..31.
> > SCHED_OTHER is a problem because the thread
[ Moved to -current ]
Mitja Horvat wrote:
>
> Hi Dan,
>
> > I have implemented {make,get,set,swap}context as library routines
> > for FreeBSD. They're gathering dust somewhere and need a bit of
> > polishing. If you give me some time I can dust them off and
> > send them to you.
>
> I would
Daniel Eischen wrote:
>
> On Tue, 29 Feb 2000, John Polstra wrote:
>
> > In article <[EMAIL PROTECTED]>,
> > Daniel Eischen <[EMAIL PROTECTED]> wrote:
> > > On Tue, 29 Feb 2000, John Polstra wrote:
> > >
> > > > Shouldn't the test against PS_SUSPENDED be "==" instead of "!="?
> > >
> > > Yes, i
Hi,
I've got sound working on my laptop with ESS1878 with -current as of Jan 10th:
sbc1: at port 0x220-0x22f,0x388-0x38b,0x300-0x301 irq 7 drq 1,0 on isa0
pcm0: on sbc1
Anyone mind if I commit the following patch to add support for this chip?
Index: sbc.c
Fritz Heinrichmeyer wrote:
>
> with todays freebsd-current, pythons "test_select.py" fails. Is this harmful?
>
Hmm, is this using libc_r?
I just found and fixed (not committed yet) a bug that may cause errant wakeups
due to SIGCHLD for threads in wrapped system calls (select included).
Dan Ei
Daniel Eischen wrote:
> OK, I originally did that to no avail, but I didn't make the change to
> the correct file (sys/isa/sio.c, not sys/dev/sio/sio.c)! So with the
> following change:
>
> Index: sio.c
> ===
> RCS file: /opt/b/CVS/
Doug Rabson wrote:
>
> > Here, it might be the opposite. The normal sio probes pick up the
> > pnp modem just fine, and then perhaps pnp comes along and trounces
> > on what has already been setup/configured.
>
> Could you try this patch for me. It attempts to disable pnp devices before
> runni
More info on the kernel hang.
Removing pnp from the kernel configuration will allow me to boot
and successfully detects my pnp modem. So the culprit seems to
be the new pnp code. Suggestions welcome.
Here's a successful verbose boot with a kernel from Sept 30th
sources.
intpm0: at devi
I have a pnp modem "SupraExpress 56i Sp V.90" that works fine with a
kernel from Aug 22. Here is an excerpt from a successful boot:
atkbdc0: at port 0x60-0x6f on isa0
atkbd0: irq 1 on atkbdc0
vga0: at port 0x3b0-0x3df iomem 0xa-0xb on isa0
sc0: on isa0
sc0:
11 matches
Mail list logo