Sorry for the delay, here's the patch which should properly implement
watchdog timeout handling in the fxp driver. If you're one of the people
seeing the false watchdog timeout messages, please give this a whirl and
tell me how it worked.
Thanks,
Mike "Silby" Silbersack
--- if_fxp.cThu Ju
I'm quite certain this was discussed recently, but I can't find it in
the mailing list archives.
I'm getting a few "fxp0: device timeout" on my supermicro 6010H (dual
1GHz PIII with onboard fxp). Was this resolved?
thanks,
dave c
--
Dave Cornejo @ Dogwood Media, Fremont, California (also [EMA
On 18-Jul-2002 Matthew Dillon wrote:
>
>:>:--
>:>:
>:>:John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
>:>
>:> Yes, that makes sense... and it would be fairly trivial
>:> optimization to make. I suppose you could have fdalloc()
>:> return EAGAIN or something li
On Thu, Jul 18, 2002 at 02:00:14PM -0700, Julian Elischer wrote:
> set radix 16
> and then print the trap frame again.. (#12)
#12 0xc02a0ce5 in trap (frame= {tf_fs = 0xc02a0018, tf_es = 0xc0320010,
tf_ds = 0xc0310010, tf_edi = 0xc191d094, tf_esi = 0xc0bc0f00, tf_ebp =
0xc8880c8c, tf_isp = 0xc8880
Matthew Dillon wrote:
> The issue with dup2() was a race against open() or close()
> I believe, where dup2() could potentially dup into a
> descriptor that open() was about to use. Unfortunately, it
> does appear that dup() has the same issue.
>
> fdalloc() does not reserve t
if you have ddb it would be instructive to ss what IT thinks the stack
looks like: heres' what I think is line 557 of kern_synch.c is:
554 if (td->td_wchan != NULL) {
555 p->p_stats->p_ru.ru_nvcsw++;
556 td->td_state = TDS_SLP;
557
:>:--
:>:
:>:John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
:>
:> Yes, that makes sense... and it would be fairly trivial
:> optimization to make. I suppose you could have fdalloc()
:> return EAGAIN or something like that to indicate that
:> it had to cycle
On Thu, Jul 18, 2002 at 10:48:09AM +0200, Mark Santcroos wrote:
> panic: vm_fault: fault on nofault entry, addr: c8856000
>
> (kgdb) bt
> I didn't have a kernel with debugging info so I am building that now in
> case it happens again.
Catched it again and now with debugging kernel.
panic: vm
On 18-Jul-2002 Matthew Dillon wrote:
>
>:
>:* Matthew Dillon <[EMAIL PROTECTED]> [020718 11:40] wrote:
>:>
>:> fdalloc() does not reserve the descriptor number it
>:> returns, it simply finds a free slot and says 'this
>:> index is a free slot'. Even in the latest -current,
>:>
On 18-Jul-2002 Matthew Dillon wrote:
>
>:> The issue with dup2() was a race against open() or close()
>:> I believe, where dup2() could potentially dup into a
>:> descriptor that open() was about to use. Unfortunately, it
>:> does appear that dup() has the same issue.
>:>
>:>
Try this:
$ csh
% su
Password:
% stop $$
Suspended (signal)
%fg
At which point you will lose you login shell.
Prior to KSE one could switch between an su'ed shell and a
normal shell at will by using stop $$ and fg.
Is this breakage considered a bug or a feature?
To Unsubscribe: send mail to
:
:* Matthew Dillon <[EMAIL PROTECTED]> [020718 11:40] wrote:
:>
:> fdalloc() does not reserve the descriptor number it
:> returns, it simply finds a free slot and says 'this
:> index is a free slot'. Even in the latest -current,
:> fdalloc() releases the fdp lock when it goes t
:> The issue with dup2() was a race against open() or close()
:> I believe, where dup2() could potentially dup into a
:> descriptor that open() was about to use. Unfortunately, it
:> does appear that dup() has the same issue.
:>
:> fdalloc() does not reserve the descriptor n
At 7:53 PM -0600 7/17/02, Eric Anholt wrote:
>On Wed, 2002-07-17 at 18:40, Garance A Drosihn wrote:
>
> > XDM generally did still seem to come up okay, although occasionally
> > the system would panic right at that initial XDM startup. While
> > I tried a few things to fix this (including vari
On 18-Jul-2002 Matthew Dillon wrote:
>
>:
>:In revision 1.94 of kern_descrip.c, in the dup2() syscall a goto
>:retry loop was added so that if we did a fdalloc() we always retested
>:everything. Since fd_nfiles can't shrink and new and old can't
>:change, I don't see why the loop is necessary.
* Matthew Dillon <[EMAIL PROTECTED]> [020718 11:40] wrote:
>
> fdalloc() does not reserve the descriptor number it
> returns, it simply finds a free slot and says 'this
> index is a free slot'. Even in the latest -current,
> fdalloc() releases the fdp lock when it goes to
> M
On Thu, Jul 18, 2002 at 01:40:48PM -0400, Bosko Milekic wrote:
> As pointed out, the change was fairly bogus. There's a new change
> that should be committed soon that fixes the problem in a "sort of"
> less bogus way. When Peter gets around to reviewing it, it'll be
> committed and you
:
:In revision 1.94 of kern_descrip.c, in the dup2() syscall a goto
:retry loop was added so that if we did a fdalloc() we always retested
:everything. Since fd_nfiles can't shrink and new and old can't
:change, I don't see why the loop is necessary. Neither dup() or
:the F_DUPFD fcntl() were m
>>> On Thu, 18 Jul 2002 09:50:54 -0600 (MDT), "M. Warner Losh" <[EMAIL PROTECTED]> said:
> In message: <[EMAIL PROTECTED]>
> Hideyuki KURASHINA <[EMAIL PROTECTED]> writes:
> : Jul 19 00:34:49 hoge pccardd[1363]: driver allocation failed for MELCO(LPC3-TX):
>Inappropriate ioctl for
On 18-Jul-2002 John Baldwin wrote:
> In revision 1.94 of kern_descrip.c, in the dup2() syscall a goto
> retry loop was added so that if we did a fdalloc() we always retested
> everything. Since fd_nfiles can't shrink and new and old can't
> change, I don't see why the loop is necessary. Neither
In revision 1.94 of kern_descrip.c, in the dup2() syscall a goto
retry loop was added so that if we did a fdalloc() we always retested
everything. Since fd_nfiles can't shrink and new and old can't
change, I don't see why the loop is necessary. Neither dup() or
the F_DUPFD fcntl() were modified
On Thu, Jul 18, 2002 at 07:38:39PM +0200, Szilveszter Adam wrote:
> Hello everybody,
>
> I would like to report that after incorporating today's fixes into the
> kernel source and recompiling, the panic does not occur again.
>
> This is probably due to the commit to pmap.c (rev 1.345 by Peter W
OK; I built today's -CURRENT (running yesterday's, as usual) on my SMP
build machine without incident earlier today.
And, as usual, I'm trying the same thing with my (UP) laptop.
But this time, the sequence has come to a halt; here's what I see so far:
>>> stage 4: populating /usr/obj/usr/src/i
Hello everybody,
I would like to report that after incorporating today's fixes into the
kernel source and recompiling, the panic does not occur again.
This is probably due to the commit to pmap.c (rev 1.345 by Peter Wemm).
Although the log only talks about SMP, this UP box likes it too.
So anyw
The following patch fixes this problem for me. When a tcp6 was
encountered then v6bind is set to 1 and was not being cleared
after the check to ignore IPv6. This patch may not be entirely
correct, but its simple and does fix the problem I reported
earlier. The v4bind check that should have result
In message: <[EMAIL PROTECTED]>
Hideyuki KURASHINA <[EMAIL PROTECTED]> writes:
: Jul 19 00:34:49 hoge pccardd[1363]: driver allocation failed for MELCO(LPC3-TX):
:Inappropriate ioctl for device
recompile pccardd. The inappropriate ioctl for device is due to a
slight mismatch betwe
Hi,
>>> On Thu, 18 Jul 2002 02:06:15 -0600 (MDT), "M. Warner Losh" <[EMAIL PROTECTED]> said:
> In message: <[EMAIL PROTECTED]>
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> : Just upgraded my laptop to the latest -CURRENT ... everything boots fine,
> : but my ethernet no longer
On Thu, 18 Jul 2002, Jeroen C.van Gelderen wrote:
> On Thursday, July 18, 2002, at 04:47 , Gavin Atkinson wrote:
> > Jul 18 09:21:24 epsilon login: getting vmemoryuse resource limit:
> > Invalid argument
>
> Did you run mergemaster? You should have a line like
> :vmemoryuse=unlimited:\
> in you
On Thu, Jul 18, 2002 at 08:52:43AM -0600, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Ian Dowse <[EMAIL PROTECTED]> writes:
> : I think the "ed" problem is that without pccardd, the 0x8 flag
> : is no longer being passed to the driver, so it doesn't try probing
> : it
In message: <[EMAIL PROTECTED]>
Ian Dowse <[EMAIL PROTECTED]> writes:
: I think the "ed" problem is that without pccardd, the 0x8 flag
: is no longer being passed to the driver, so it doesn't try probing
: it as a Linksys card (I haven't checked for sure, but that would
: be consis
So, how much does this have to do with my laptop's sound (DSP) dumping out
after about 10 seconds? (Toshiba had the great idea of hard-wiring most
everything through IRQ 11, although pccardd seems to be able to use
others)
> Longer Answer: For some time now MS has had the notion of a Plug and
> P
I cvsup'ed last night at and rebuild around 2000 CDT. The world and
kernel portions completed, but upon rebooting I was greeted with:
pccbb: unable to map IRQ...
pccbb: resource_list_release: can't find resource
and am then dropped to the debugger. Booting with unset acpi_load
results in the sam
Andrew Kolchoogin wrote:
> Hi!
>
> On Wed, Jul 17, 2002 at 07:40:47PM -0400, Garance A Drosihn wrote:
>
>
Hey all (ab)users of -current. Please try to work on getting -current
as stabilized as possible in the next few days and hold off on any
large changes until after re@ creates t
In message <[EMAIL PROTECTED]>, "M. Warner Losh" writes:
>Used to work for me, but something seems to have busted it in recent
>versions of the kernel. So NEWCARD appears to be broken for ata, sio
>and ed. Wonderful. These all used to work at one point in the past.
I think the "ed" problem is
On Thu, Jul 18, 2002 at 01:28:22AM -0700, Lamont Granquist wrote:
> I just cvsup'd and about 1.5h later got a crash+reboot with no dump. I
> think someone else mentioned problems with fsck and I saw something like
> that too -- it looked like the rc scripts errored out after the fsck and
> droppe
Hi!
On Wed, Jul 17, 2002 at 07:40:47PM -0400, Garance A Drosihn wrote:
>>>Hey all (ab)users of -current. Please try to work on getting -current
>>>as stabilized as possible in the next few days and hold off on any
>>>large changes until after re@ creates the Perforce branch for DP2 on
>>>Friday
Getting this since updating kernel/word to a cvsup a couple of days ago.
Jul 18 09:21:24 epsilon login: getting vmemoryuse resource limit: Invalid argument
Jul 18 09:22:00 epsilon /usr/sbin/cron[342]: getting vmemoryuse resource limit:
Invalid argument
Jul 18 09:25:00 epsilon /usr/sbin/cron[355
I just cvsup'd and about 1.5h later got a crash+reboot with no dump. I
think someone else mentioned problems with fsck and I saw something like
that too -- it looked like the rc scripts errored out after the fsck and
dropped me into single user...
To Unsubscribe: send mail to [EMAIL PROTECTED]
In message: <[EMAIL PROTECTED]>
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
: Just upgraded my laptop to the latest -CURRENT ... everything boots fine,
: but my ethernet no longer exists (it worked great on my June 6th kernel)
: ...
Used to work for me, but something seems to have
In message: <[EMAIL PROTECTED]>
Ronald van der Pol <[EMAIL PROTECTED]> writes:
: On Wed, Jul 17, 2002 at 23:33:13 -0600, M. Warner Losh wrote:
:
: > It is a tiny piece of a larger puzzle that will be fixed as we do
: > proper resource allocation now that the BIOS specifications have b
On Wed, Jul 17, 2002 at 23:33:13 -0600, M. Warner Losh wrote:
> It is a tiny piece of a larger puzzle that will be fixed as we do
> proper resource allocation now that the BIOS specifications have been
> changed by MS to move that into the OS.
Can you elaborate on that or give some pointers?
41 matches
Mail list logo
