(CC's trimmed, I'm sure I'm boring people at this stage.)
>Peter Edwards wrote:
>> >>>On Wed, Nov 12, 2003 at 06:04:00PM -0800, Kris Kennaway wrote:
>> >>>>...my sparc machine reports that my i386 nfs server has 15 exabytes
>of
>> >
>On Fri, 14 Nov 2003, Peter Edwards wrote:
>
>> Bruce Evans wrote:
>>
>> > On Fri, 14 Nov 2003, Peter Edwards wrote:
>
>> >> The NFS protocols have unsigned fields where statfs has signed
>> >> equivalents: NFS can't represent negativ
Bruce Evans wrote:
On Fri, 14 Nov 2003, Peter Edwards wrote:
Bernd Walter wrote:
On Thu, Nov 13, 2003 at 12:54:18AM -0800, Kris Kennaway wrote:
On Thu, Nov 13, 2003 at 06:44:25PM +1100, Peter Jeremy wrote:
On Wed, Nov 12, 2003 at 06:04:00PM -0800, Kris Kennaway wrote:
...my sparc machine
John Baldwin wrote:
On 14-Nov-2003 Peter Edwards wrote:
(Aplogies if this message is a duplicate: The original is AWOL for quite
a while now)
Hi,
I'm getting a crash in propagate priority, as mentioned by a few people recently. Bug
reports and
comments about it seemed to have droppe
Bernd Walter wrote:
On Thu, Nov 13, 2003 at 12:54:18AM -0800, Kris Kennaway wrote:
On Thu, Nov 13, 2003 at 06:44:25PM +1100, Peter Jeremy wrote:
On Wed, Nov 12, 2003 at 06:04:00PM -0800, Kris Kennaway wrote:
...my sparc machine reports that my i386 nfs server has 15 exabytes of
free
(Aplogies if this message is a duplicate: The original is AWOL for quite
a while now)
Hi,
I'm getting a crash in propagate priority, as mentioned by a few people recently. Bug
reports and comments about it seemed to have dropped off, so given that I can reliably
reproduce it, I was trying to wo
t;sectorsize;
struct bio *bp2;
- for (pos = 0; pos < bp->bio_length; pos += bp->bio_length) {
+ for (pos = 0; pos < bp->bio_length; pos += size) {
if (!(bp2 = g_clone_bio(bp))) {
bp->bio_error = ENOMEM;
Hi,
Looking over the code for nmount(), I think I noticed a few bugs.
(tried send-pr, but the lack of a web-front-end at freebsd.org,
and a decent mail system locally means that's not a runner)
nmount() calls vfs_nmount() pretty much directly after copying in
the io vector from userland.
vfs_nmount
>> For giggles I'm rolling back vfs_default.c back to 1.87 since its along
>> the backtrace path.
>
>This didn't work so -CURRENT is fully broke.
>
>I'd suggest staying on 10/30 not before 4PM PST if you want to not crash
>on shutdown.
>
The patch worked for me. (Well, a slightly modified one: I
>I can confirm the lockmgr panic on shutdown reported by someone else
>earlier (whose message I mistakenly deleted).
>
>It looks like swapper is trying to undo a lock from pagedaemon and runs
>into trouble. This is probably related to the Giant pushdown of
>vm_pageout() that alc did last week.
>
Andreas Klemm wrote:
Hi,
Urgend question, wanna help a collegue, who secured a router,
but trying to scan ports fails with -current.
I don't want to blame anybody, I know what the policy of current
is. If I can't get quick help on this I use a Windows tool,
no problem. I only want to save me the
Terry Lambert wrote:
Wesley Morgan wrote:
It's also unfortunate that this protection does not seem to extend to
libaries. I've had some in-use X libraries get overwritten with some very
colorful results.
So send patches.
I did a year ago :-) See PR 37554. (Not the original patch, the
s
be awakened when completed async writes bring it
under the low threshold. However, a large chunk of the running buf
space is sitting queued for the md thread to process. The md thread
can't continue without the vnode lock, so the running buffer space
will not fall, and the bufdaemon cannot
On Wed, 2003-08-20 at 22:11, Yogeshwar Shenoy wrote:
> While using 5.1-RELEASE, I find that if my application program seg
> faults, it produces "programname.core"; but it is 0 bytes.
> I ran the exact same program on another machine that was running
> 4.4-RELEASE, and I do get a core file that I
On Wed, 2003-08-13 at 07:38, Terry Lambert wrote:
> Peter Edwards wrote:
> > > ... He might also want to look for any function pointer
> > > that takes 5 arguments;
> >
> > Nice tactic, but misleading in this case, methinks.
> >
> > I assume you
On Tue, 2003-08-12 at 20:39, Poul-Henning Kamp wrote:
> I'm not of a gdb wizard either, but I think you type "up" or "down" until
> you are at stack frame #12, and the simply say "print *bp->b_dev"
This might help.
The original stack trace had this:
> #10 0xc04f3c65 in trap (frame=
> {tf_f
On Tue, 2003-08-12 at 12:52, Terry Lambert wrote:
> Bosko Milekic wrote:
> > > db> trace
> > > _mtx_lock_flags(0,0,c07aa287,11e,c0c21aaa) at _mtx_lock_flags+0x43
> > > vm_fault(c102f000,c000,2,0,c08205c0) at vm_fault+0x2b4
> > > trap_pfault(c0c21b9e,0,c4d8,10,c4d8) at trap_pfault+0x
Hi.
This might be of interest to anyone who has tried debugging
multi-threaded programs (of the libc_r variety) with gdb. This has been
bugging me for months, and I finally got frustrated enough to find out
what was going on.
The symptom:
Once you call any function that puts a thread to sleep, th
Ok. After all that, and given I've gone this far...
Boris, does the patch included fix your problem?
--
Peter Edwards.
Index: sys/dev/bge/if_bge.c
===
RCS file: /pub/FreeBSD/development/FreeBSD-CVS/src/sys/dev/bge/if_bg
John Polstra <[EMAIL PROTECTED]> wrote:
> No, you are right. I didn't read the posting carefully enough.
> Sorry!
No problem.
[snip]
>> I assume you mean, that after setting if_hdrlen,
[snip]
> I think you also have to set if_data.ifi_hdrlen as I said
[snip]
My fault: I jumped from one term fo
John Polstra <[EMAIL PROTECTED]> wrote:
> Peter Edwards <[EMAIL PROTECTED]> wrote:
> > > CSR_WRITE_4(sc, BGE_RX_MTU, ifp->if_mtu +
> > > ETHER_HDR_LEN + ETHER_CRC_LEN + ETHER_VLAN_ENCAP_LEN);
> Good guess, but the approved way of doing
Hm. A bit of a stab in the dark, but from sys/dev/bge/if_bge.c, line
3185 (on 5.1 release, 2399)
> /* Specify MTU. */
> CSR_WRITE_4(sc, BGE_RX_MTU, ifp->if_mtu +
> ETHER_HDR_LEN + ETHER_CRC_LEN);
>
>
Wonder if this should be
> /* Specify MTU. */
> C
Hi,
> > All the files are 0-sized, dates are set back to the epoch and
> > directories are seen as files. Exporting ufs2 filesystems works as
> > expected.
I've had problems like this exporting CDs via NFS to solaris.
Sorry the details are murky, but if its the same problem, there's a
work-aroun
On Sat, 2003-06-07 at 10:13, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, David Yeske writes:
>> imgact_gzip.c seems to be pretty stale. Has anyone considered fixing this? If
>> this were fixed
>> then kldload() / linker_load_module() could deal with a gzipped .ko file, and
>> gz
Sorry if this appears twice: my webmail client appears to have dropped
the original message on the floor.
gdb didn't find threads in corefiles: The support was just missing.
The attached patch does the job.
Also attached is a small test program which easily generates a corefile
with threads in
quot;, "MWCHAN", NULL, LJUST, mwchan, NULL, 6, 0, CHAR, NULL, 0},
{"ni", "", "nice", 0, NULL, NULL, 0, 0, CHAR, NULL, 0},
{"nice", "NI", NULL, 0, kvar, NULL, 2, KOFF(ki_nice), CHAR, "d",
--
Peter Edwards.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
[EMAIL PROTECTED] wrote:
>
> In message <[EMAIL PROTECTED]>, "Peter Edwards" writes:
>
> >The problem is in kern/tty_tty.c:ctty_clone. It's assuming that if the process
> >has its P_CONTROLT flag set, then it's session has a valid vnode for it&
terminal was revoked.
Cheers,
Peter Edwards.
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" t
Hi,
Debugging trivial C++ programs in GDB is knackered, complaining about "ABI
doesn't define required function XXX" when doing operations such as printing
classes and structures which inherit from others, and setting breakpoints in
virtual functions, etc.
Adding "gnu-v2-abi.c" and "gnu-v3-abi.c"
L PROTECTED]
> http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking!
>
--
Peter Edwards.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
ances
failed to produce any positive results after about 5 mins., which is
3-4 times longer than its ever been up before under the same stress. I'll
report back in about 24 hours either way, but I think that's cured it.
--
Peter.
Bruce Evans <[EMAIL PROTECTED]> wrote:
>
> On
a_flags = 0;
sigemptyset(&sa.sa_mask);
sigaction(SIGINT, &sa, 0);
while (count < 30) {
d = x / y;
err = 2.0 - d;
if (err != 0.0) {
fprintf(stderr, "err %f!\n", err);
exit(-1);
}
}
}
--
Peter E
s/ntfs/ntfs_vfsops.c 13 Oct 2002 15:30:01 -
@@ -508,6 +508,7 @@
vinvalbuf(ntmp->ntm_devvp, V_SAVE, NOCRED, td, 0, 0);
+ ronly = (mp->mnt_flag & MNT_RDONLY) != 0;
error = VOP_CLOSE(ntmp->ntm_devvp, ronly ? FREAD : FREAD|FWRITE,
NO
wouldn't produce a useable array of struct X of length arrayLen?
That can't be right.
--
Peter Edwards.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Solaris has something similar in /usr/proc/bin/ptree. One of the things
it lets you do is specify _which_ user to use.
Isn't the kvm_*() interface somewhat frowned upon? Is there anything
missing from /proc that you need kvm_* for?
--
Cheers,
Peter.
Juli Mallett wrote:
> Hej,
>
> As some of
>Compare them without the ELF headers, a section at a time, so
>that the timestamps are irrelevent.
>From what I recall, there _are_ no timestamps in ELF images,
and compiling the same executable multiple times locally here
seems to bear out the fact: "cmp" on two successive outputs
is identical
I mentioned something similar for a different reason. Go look at the last
part of the following message in the recent -hackers archives:
> Subject: ptrace bug?
> MessageId: <[EMAIL PROTECTED]>
(this was for -stable, BTW)
Having the suspend for the ptrace()ing parent done in issignal is a pain
Nick Hibma wrote:
>
> Correct me if I am wrong, but I don't think you actually have to
> disassociate any dev_t's from the driver (by clearing the si_drv[12]
> fields) because we call destroy_dev and cdevsw_remove, so any later uses
> of dev_t's get an error because the device has gone away.
>
>
I had a longer look at this, and a more complete patch is logged as PR
kern/18270 (try at your own risk: it works for me).
I'd appreciate someone more experienced having a look at it and
commenting.
Cheers,
Peter.
Wilko Bulte wrote:
>
> On Wed, Apr 26, 2000 at 04:25:46PM +0100, Pe
Compiling 5.0-CURRENT on 4.0-STABLE generates problems in getconf:
===> usr.bin/getconf
gperf -t -L ANSI-C -C -k 1,2,7-10,21,'$'
/usr/current/src/usr.bin/getconf/confstr.gperf >confstr.c
/* starting time is 11:48:16 */
gperf: unrecognized option `-L'
usage: gperf
[-acCdDef[num]gGhHijkKlnNoprsStTv
need to do it.
--
Peter.
"Peter Edwards (local)" wrote:
>
> Hi,
> After a (very) quick look at the source it looks like there's a missing
> cdevsw_remove() missing from the MOD_UNLOAD/MOD_SHUTDOWN event handling
> I haven't time to test it, but try this:
Hi,
After a (very) quick look at the source it looks like there's a missing
cdevsw_remove() missing from the MOD_UNLOAD/MOD_SHUTDOWN event handling
I haven't time to test it, but try this:
*** vn.c.oldWed Apr 26 16:23:03 2000
--- vn.cWed Apr 26 16:24:06 2000
***
*** 762,76
Assar Westerlund wrote:
>
> There's a real reason for not writing this in csh. Because the
> built-in function will return results for csh, which might not be the
> right ones for other shells.
>
I got bitten by this by HP-UX 10's csh-based "which". My solaris-hosted
NFS home directory had the d
I just send-pr'ed a patch for this: misc/17143
David Malone wrote:
>
> On Fri, Mar 03, 2000 at 11:23:33AM +0200, Sheldon Hearn wrote:
>
> > Shouldn't I be able to show the current tuneables for a given filesystem?
> >
> > # tunefs -p /usr
> > tunefs: cannot work on read-write mounted file syste
Hi,
fstat(1) should be able to take a set of filenames as arguments to limit the results
of its output to the specified files. However, it doesn't work at the moment, because
of the existance of udev_t. (It compares the st_dev from the stat structure used by
stat(2) with in-kernel dev_t structu
Hi,
(Sorry if this hits the list a couple of times, I had some problems with my mail
system)
I never thought I'd see "clear" break :-) Here's a fix.
It seems to be down to an ncurses change in tgetstr(). The implementation in ncurses
just ignores the "area" parameter, while the one in libtermc
46 matches
Mail list logo
