At Mon, 3 Dec 2001 17:33:13 -0800 (PST),
Dag-Erling Smorgrav wrote:
> Modified files:
> sys/fs/procfsprocfs.h procfs_ctl.c procfs_dbregs.c
> procfs_fpregs.c procfs_map.c procfs_mem.c
> procfs_note.c procfs_regs.c
>
Hi,
We're seeing strange behavior of mpd (netgraph-ified ppp daemon)
under -current that doesn't occur under -stable.
The problem is that when mpd tries to do a connect(2) on a
(PF_INET, SOCK_RAW, IPPROTO_GRE), the kernel returns EINPROGRESS
instead of succeeding immediately (note: this is a dat
:> :sits on irq 14 & 15 making them the lowest priority devices in the system,
:> :and that could cause the interrupt latency I'm seeing which then again
:> :causes the bad transfer rates on transfers that need to transfer more
:> :that one transaction full of data (ie max 128k).
:> :
:> :-Søren
On Mon, 3 Dec 2001, Julian Elischer wrote:
> do these patches include the proc->thread changes needed?
According to cvs logs - yes.
--
Boris Popov
http://rbp.euro.ru
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
It seems Matthew Dillon wrote:
> :Hmm, I've just played around a bit, it seems we are hit by interrupt
> :latency or something, if you limit the transfer to 128k, which allows
> :the ATA controller to fetch it in one go, you will see the expected
> :transfer rates. Now I dont see this on PCI based
On 4 Dec 2001, Dag-Erling Smorgrav wrote:
> I'm about to commit patches to procfs(5) that will (unfortunately)
> temporarily disable truss(1), until I finish extending ptrace(2) and
> rewriting truss(1) to use that instead of procfs(5) (or find a quiet
> moment to figure out why my legacy support
I'm about to commit patches to procfs(5) that will (unfortunately)
temporarily disable truss(1), until I finish extending ptrace(2) and
rewriting truss(1) to use that instead of procfs(5) (or find a quiet
moment to figure out why my legacy support code doesn't work). Until
then, use ktrace(1) (or
On Mon, 3 Dec 2001 17:29:32 -0600
Alfred Perlstein <[EMAIL PROTECTED]> wrote:
> * David Hill <[EMAIL PROTECTED]> [011203 16:50] wrote:
> > This patch was done on -CURRENT.
> >
> > It is both pasted and attached to this message.
>
> Which write.c is this to be applied to?
>
>
> To Unsubscribe:
* David Hill <[EMAIL PROTECTED]> [011203 16:50] wrote:
> This patch was done on -CURRENT.
>
> It is both pasted and attached to this message.
Which write.c is this to be applied to?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
This patch was done on -CURRENT.
It is both pasted and attached to this message.
Thanks
David
--- write.c.origMon Dec 3 17:42:45 2001
+++ write.c Mon Dec 3 17:45:22 2001
@@ -190,8 +190,7 @@
while (read(ufd, (char *) &u, sizeof(u)) == sizeof(u))
if (strncmp
:Hmm, I've just played around a bit, it seems we are hit by interrupt
:latency or something, if you limit the transfer to 128k, which allows
:the ATA controller to fetch it in one go, you will see the expected
:transfer rates. Now I dont see this on PCI based controllers, and that
:hints that the
Galen Sampson <[EMAIL PROTECTED]> wrote:
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x1
> fault code= supervisor read, page not present
> instruction pointer = 0x8:0xc02b5baf
> stack pointer = 0x10:0xcadc3d48
> frame pointer = 0x10:0xb
>
> On Wed, 28 Nov 2001, Sheldon Hearn wrote:
>
> > | I have some untested patches in my tree and I will contact bp this
> > | week about them (I wanted to import smbfs userland to the tree and
> > | already got ok from bp but could not test it because kernel-side smbfs
> > | is not compilable yet
I think it is necessary to add the notice to UPDATING because it's been
half an year since the incident day. If it were like within last few
days, I definitely would've gotten some hints about the fix by scanning
-current (which I did). But I had to scratch my heads helplessly until
I asked the
Hello all,
Today I cannot boot into my machine with either kernel or kernel.old. Both
panic after trying to mount the filesystems. "kernel.old" is a generic kernel,
but "kernel" is a generic kernel from 11/12 source. Neither kernel is a debug
kernel. This panic does not seem to relate to the
On Mon, Dec 03, 2001 at 09:12:29AM -0800, Glenn Gombert wrote:
>
> I can't really see how it would be, everything updates alright until
> it starts working on the 'src/contrib/cpio' directory and then it stops
> with the error shown below, I can try something else if you had an suggestion
> on e
I can't really see how it would be, everything updates alright until
it starts working on the 'src/contrib/cpio' directory and then it stops
with the error shown below, I can try something else if you had an suggestion
on exactly what, any help would be greatly appreciated...
Glenn G.
Be
On Mon, Dec 03, 2001 at 02:55:37AM +0100, Emiel Kollof wrote:
> On Monday 03 December 2001 02:28, David Xu wrote:
> > This is strange, the problem would happen in heavy forked system which
> > have lots of pages
> > are shared between lots of process and most are commited to these
> > processes,
On Mon, Dec 03, 2001 at 03:35:13AM -0800, Glenn Gombert wrote:
>
> I keep getting the following error below when I try to make a complete
> copy of the 'src' directory:
>
> cvs server: Updating src/contrib/cpio
> cvs checkout: in directory src/contrib/cvs:
> cvs checkout: cannot open CVS/En
I was surprised by a compile time error with one of my programms on
FreeBSD-alpha.
HP-UX, Solaris and NetBSD expect the data argument as beeing
u_longlong_t which sounds logical given the function name.
On FreeBSD (verified on -current) it is defined to be u_quad_t which
resolves to unsigned long
On 4 Dez, nuzrin yaapar wrote:
> I'm also getting around 20MB/sec.
>
>
> dmesg:
> atapci0: port 0xd000-0xd00f at device 7.1
> on pci0
> ad0: 12416MB [25228/16/63] at ata0-master UDMA66
atapci0: port 0xd000-0xd00f at device 7.1 on pci0
atapci0: VIA '686b southbridge fix applied
ata0: at 0x
Glenn Gombert <[EMAIL PROTECTED]> wrote:
> Are there any FreeBSD 'Anonymous' FreeBSD Servers avaiable besides:
> ":pserver:[EMAIL PROTECTED]:/home/ncvs" ,
anoncvs.de.openbsd.org
--
Christian "naddy" Weisgerber [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PR
Below is the result of your feedback form. It was submitted by
([EMAIL PROTECTED]) on Monday, December 3, 2001 at 04:36:36
---
Dear Sir or Madam: Its finally here, the product we've all been waiting for... PORN
NAPSTER.
Do
I keep getting the following error below when I try to make a complete
copy of the 'src' directory:
cvs server: Updating src/contrib/cpio
cvs checkout: in directory src/contrib/cvs:
cvs checkout: cannot open CVS/Entries for reading: No such file or
directory
cvs [checkout aborted]: cannot
It seems nuzrin yaapar wrote:
> > Hmm, yes that looks somewhat on the low side...
> > Well, two things, the older VIA chips are not the best performers, but
> > I still think it should be better than that, I'll run some tests here,
> > I might have messed up something...
> > Are we talking -curren
Søren Schmidt wrote:
> It seems Miklos Niedermayer wrote:
>
>>I think they are idle (looking at vmstat -i), but i can't be sure.
>>However i have 2 machines here with VIA 82C596 chipset...
>>
>>atapci0: port 0xd800-0xd80f at device 4.1 on pci0
>>ata0: at 0x1f0 irq 14 on atapci0
>>ad0: 28629MB
It seems Miklos Niedermayer wrote:
> I think they are idle (looking at vmstat -i), but i can't be sure.
> However i have 2 machines here with VIA 82C596 chipset...
>
> atapci0: port 0xd800-0xd80f at device 4.1 on pci0
> ata0: at 0x1f0 irq 14 on atapci0
> ad0: 28629MB [58168/16/63] at ata0-maste
Hi,
On Mon, Dec 03, 2001 at 10:50:02AM +0100, Sřren Schmidt wrote:
> 1+0 records in
> 1+0 records out
> 524288 bytes transferred in 0.006204 secs (84507936 bytes/sec)
>
> But the disk needs to be idle or you risk getting another
> request inbetween ruining the cached data, or if you disk has
>
It seems Miklos Niedermayer wrote:
> On Mon, Dec 03, 2001 at 09:28:26AM +0100, S_ren Schmidt wrote:
>
> > > > No, I mean it exactly as written (X is the number of the disk to test).
> > >
> > > Ah, you mean just do it 5 times?
> >
> > Yeps, the idea here is that I want the drive to cache the da
Hi,
On Mon, Dec 03, 2001 at 09:28:26AM +0100, Sřren Schmidt wrote:
> > > No, I mean it exactly as written (X is the number of the disk to test).
> >
> > Ah, you mean just do it 5 times?
>
> Yeps, the idea here is that I want the drive to cache the data, so that
> I can get the raw interface sp
On Sun, 02 Dec 2001 15:20:36 +0600, Boris Popov wrote:
| > Presumably, if bp doesn't respond by the end of the year, you'll go
| > ahead regardless? :-)
|
| Actually, bp responded much faster than you expected :)
Yes. Sorry for spreading second-hand information as to your
availability.
It seems Greg Lehey wrote:
> On Monday, 3 December 2001 at 9:08:59 +0100, Søren Schmidt wrote:
> > It seems Greg Lehey wrote:
> >>>
> >>> for n in 1 2 3 4 5
> >>> do
> >>> dd if=/dev/adX of=/dev/null bs=512K count=1
> >>
> >> Don't you mean
> >>
> >> dd if=/dev/ad$n of=/dev/null bs=512
On Monday, 3 December 2001 at 9:08:59 +0100, Søren Schmidt wrote:
> It seems Greg Lehey wrote:
>>>
>>> for n in 1 2 3 4 5
>>> do
>>> dd if=/dev/adX of=/dev/null bs=512K count=1
>>
>> Don't you mean
>>
>> dd if=/dev/ad$n of=/dev/null bs=512K count=1
>>
>> ?
>
> No, I mean it exactly as
It seems Greg Lehey wrote:
> >
> > for n in 1 2 3 4 5
> > do
> > dd if=/dev/adX of=/dev/null bs=512K count=1
>
> Don't you mean
>
> dd if=/dev/ad$n of=/dev/null bs=512K count=1
>
> ?
No, I mean it exactly as written (X is the number of the disk to test).
-Søren
To Unsubscribe: send
34 matches
Mail list logo
