In message [EMAIL PROTECTED], Matthew Dillon w
rites:
I'm trying to figure out how the acpi_sleep_machdep() code works and
there are a couple of lines I just don't understand:
pm = vmspace_pmap(p-p_vmspace);
cr3 = rcr3();
#ifdef PAE
load_cr3(vtophys(pm-pm_pdpt));
In message [EMAIL PROTECTED], Hans Petter Selasky writes:
But there is one problem, that has been overlooked, and that is High speed
isochronous transfers, which are not supported by the existing USB system. I
don't think that the EHCI specification was designed for scatter and gather,
when you
In message [EMAIL PROTECTED], Hans Petter Selasky writes:
On Sunday 02 July 2006 14:05, Ian Dowse wrote:
This data structure requires the associated data buffer to be
contiguous (relative to virtual memory), but allows the physical
memory pages to be non-contiguous. Seven page pointers
In message [EMAIL PROTECTED], Ian Dowse writes:
The trick is that if the 0x6000 bytes are contiguous in virtual
memory then they never span more than 6 pages so one iTD is enough.
Sorry, I meant of course 6 page boundaries, which means no more
than 7 pages. This is why the 7 physical address
In message [EMAIL PROTECTED], Hans Petter Selasky writes:
Ok. So the solution to my problem is to use scatter and gather. I will see
about updating my USB system to do it like that.
But there is one thing I do not understand yet. When you load a page that
physically resides above 4GB, because a
In message [EMAIL PROTECTED], Nate Nielsen writes:
Thanks, that helps. It works nicely with a uhci USB controller.
However when the ohci driver is in use, we crash somewhere in
usb_transfer_complete. I'll look into this further.
You could try updating to the latest 6-stable usb code, which might
In message [EMAIL PROTECTED], Scott Long writes:
You're correct that dumping is meant to be done with interrupts and task
switching disabled. The first thing that the umass driver is missing is
a working CAM poll handler. Without this, there is no way for command
completions to be seen when
: freebsd-stable@freebsd.org
From:Ian Dowse [EMAIL PROTECTED]
Subject: Re: EHCI: mtools stuck in state 'physrd' or panic
OpenBSD have a workaround for problems with VIA EHCI controllers
that can cause the hanging symptoms you describe. Below is a patch
that implements their change
In message [EMAIL PROTECTED], Hans Petter Selasky writes:
Yes, you are right, but the problem is, that for most callback systems in the
kernel, there is no mechanism that will pre-lock some custom mutex before
calling the callback.
I am not speaking about adding lines to existing code, but to
In message [EMAIL PROTECTED], Kris Kennaway writes:
Yes, that's because (as discussed in the archives) the kernel treats
it like an extra, completely decoupled physical CPU and schedules
processes on it without further consideration. This is presumably the
cause of the slowdown, because it's only
In message [EMAIL PROTECTED], Rober
t Watson writes:
BTW, if this bug exists in 5.0 for the same reasons (or even different
ones), we should try to generate a fix ASAP and get it committed.
I'll check later today if 5.0 is affected. It is probably easy to
trigger by arranging for a bridged
In message [EMAIL PROTECTED]
, Patrick Soltani writes:
In the last couple of months, upgraded to 4.6 and 4.7 using RELENG_4 =
with again no errors, however, now under a light smurf attack, I get:
panic: icmp_error: bad length
Hardware: Dell PowerEdge 350, 2 built-in Intel nic cards, 256 meg of
In message [EMAIL PROTECTED], Alexander Langer
writes:
Yeah, same situation here. 4.6 used to work w/o problem, 4.7 doesn't.
Great, thanks for the debugging info. The bug seems to be that
icmp_error() requires that the IP header fields are in host order,
but when it is called on a briged packet
In message [EMAIL PROTECTED], Luigi Rizzo writes:
the diagnosis looks reasonable, though i do not remember changing
anything related to this between 4.6 and 4.7 so i wonder why the
error did not appear in earlier versions of the code.
Yes strange - actually, it looks like the THERE IS NO
In message [EMAIL PROTECTED], Josh Brooks
writes:
I run netstat -i fxp0 while _innside_ a jail:
and then, I transfer a large file from the jail to some external host.
The file I transferred out was 4.3 megabytes. Opkts only increased by
1733 ... which means 2481 bytes per packet ... but
In message [EMAIL PROTECTED], Al-Afu writes:
Yes. I am using the fxp driver. Any other possiblities? Or should I take
it easy (and stick to 4.6.2-RELEASE) until such time a fix for the fxp
driver on 4.7-RELEASE is done?
I've checked into -stable the fxp driver change that fixes some
random
In message [EMAIL PROTECTED], Andrew Gallatin
writes:
gdbmods does an ugly thing which is incredibly useful. It assumes
that the modules you want to debug are sitting in your kernel build
pool. So what it does is extract the build directory from the kernel
(using strings), and runs a find
In message p05111710b9c1484025de@[128.113.24.47], Garance A Drosihn writes:
I also have a partition with freebsd-current from two or three days
ago, and all the latest versions of the ports. Every time I try to
start vmware2 on the newer system, the hardware dies. Sometimes it
automatically
In message [EMAIL PROTECTED], Mark Santcroos writes:
On Thu, Oct 03, 2002 at 09:04:04AM +0100, Ian Dowse wrote:
There may still be further issues, but it allowed me to use vmware2
on a current from a week or two ago.
That's only for virtual disks, and that is not where the problem
In message [EMAIL PROTECTED], Soeren Schmidt writes:
It should be possible to hide the USB stuff under the ATA_* macroes
or even just under bus_space_*.
I need a bit more concrete details on how to call into the USB
code, then it should be pretty easy to add...
This would be hard to do right, as
In message 20020826225851.GA93947@gallium, Dominic Marks writes:
+static int kq = -1;
+int kq, rv, idx;
kevent(0x3,0xbfbfedbc,0x1,0x0,0x0,0x0) = 0 (0x0)
kevent(0x809abc0,0x0,0x0,0xbfbfede0,0x8,0x0) ERR#9 'Bad file descriptor'
Look at the above 4 lines, and it is pretty clear
In message [EMAIL PROTECTED], Bernd Walter writes:
I never saw any negative block numbers in on-disc structures.
Now I wonder if it was just hidden behind macros.
What is the reason to handle it that way?
Do you have some code reference for homework?
These logical block numbers are not stored on
In message [EMAIL PROTECTED], jogegabsd wr
ites:
I just upgrade to 4.6-RELEASE.
...
# mount_cd9660 /dev/acd0c /cdrom
/dev/acd0c: Device not configured
What way did you upgrade? The device minor number for acdXc changed
between 4.5 and 4.6, so you need to ensure that you have an up-to-date
In message [EMAIL PROTECTED], Marc Olzheim writes:,
Marco van de Voort writes:
While working on tha FreePascal FreeBSD port, we found a bug in the
kernel source, that has been fixed in -CURRENT...
Any reason why pathes 1.137 and 1.148 of kern_sig.c have not yet been
committed to RELENG_4 ?
Are
In message [EMAIL PROTECTED], Jason
Borkowsky writes:
1. How is it my load average is over 1, but my single CPU is 85% idle?
This is quite possible due to process synchronisation, since there
is no direct relationship between the load average and the percentage
of time that the CPU is idle. The
In message [EMAIL PROTECTED], Robe
rt Watson writes:
Sigh. Remote gdb, not ddb. I tried the usual tricks (updating $sp in
gdb, etc) but gdb persisted in using the old frame. Nevermind. It seemed
In gdb, the proc command switches processes, so this should work:
proc pid
bt
In message Pine.GSO.4.10.10203191303250.3121-10@orbit, Kip Macy writes:
Looking at the source for efence this happens when mmap fails (in this case wi
th
ENOMEM). Looking at the man page the two possibilities are: the system has
reached the per-process mmap limit specified in the
In message [EMAIL PROTECTED], Daniel O'Connor writ
es:
I end up with EFBIG when trying to read the .katie-server-info file, but
if I create a file inside the view (eg echo abc foo) then it can be
read with no problem, _but_ the dump of NFS traffic doesn't show a read
for that file.
At a guess,
In message [EMAIL PROTECTED], Matthew Dillon wri
tes:
NFS fix). I think Ian's mknod tests are a no-brainer. They should
just go in, as should my mknod fix.
I agree here - Matt's mknod fix and the S_IFMT mode bits corruption
bug that I fixed are simple fixes and they are both
In message [EMAIL PROTECTED], Matthew Dillon wri
tes:
Patch section 1
Here we were previously vput()ing nd.ni_vp only if error == 0.
If error is returned non-zero from namei() this would normally be
correct. However, we force error on a number of occassions after
In message [EMAIL PROTECTED], Ian Dowse writes:
I don't think this is necessary, because the cleanup code at the
end of nfsrv_mknod() catches any cases where nd.ni_vp was not
released earlier. It would be harmless to add it though.
Oops, I missed a 'return (0);' when reading the code. You're
In message [EMAIL PROTECTED], Matthew Dillon wri
tes:
Ok, cool. I'll get the commit gears started for the
first part of the patch.
FYI, I was able to reproduce this and confirm that the first part
of your patch fixes it. All that it takes is for the mknod to fail
because the name
In message [EMAIL PROTECTED], John Baldwin writes:
The short form is htat you need to hack the cpu_halt to call a function that
puts a stub down in low memory, and calls it. This code needs to be mapped 1:1
so that the logical address == physical address. The first thing you will
Yeah, I
In message [EMAIL PROTECTED], Bernd Walter writes:
Is there any reason we don't want to truncate the file? Does O_TRUNC
not work well of the file is a tape device or something?
I don't expect O_TRUNK to work on devices such tapes and disks.
Well, it won't achieve anything on tapes or disk
In message [EMAIL PROTECTED], Matthew Dillon wri
tes:
Woa! That sounds like a bad idea to me. If you want to do it right
then open(), fstat(), and only if the stat says it is a regular file
do you then ftruncate(). Passing O_TRUNC to a tape device may be ignored
by us, but it's
In message [EMAIL PROTECTED], Makoto Matsushita writes:
I really know I'm doing a stupid thing, but here is benchmark results
of both plain and patched 5-current (as of Nov/26/2001). Patched
FreeBSD is about 10% faster than before.
... but only if you spend most of your time running CPU
In message [EMAIL PROTECTED], W.Scholten writes:
I submitted a bugreport patch for 3.3 /4.1 a year ago, but on
installing 4.4 a while back, I found it had not been incorporated.
It's in -current and -stable now. Sorry for the delay.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
In message [EMAIL PROTECTED], Srinivas Dharmasanam writ
es:
Hi,
I'm using the generic usb device drive ugen for controlling a USB device.
The problem is I'm having to reboot the computer each time I
disconnect/connect the device in order for FreeBSD to see the USB device.
Are you running usbd
In message [EMAIL PROTECTED], Matt Dillon writes:
:This seems rather large compared to Ian Dowse's version.. Are you sure that
:you're doing this the right way? Adding a whole new locking mechanism
:when the simple VRENAME flag to be enough seems like a bit of overkill..
Matt addresses the
In message [EMAIL PROTECTED], Matt Dillon writes:
What I've done is add a SOFTLOCKLEAF capability to namei(). If set, and
the file/directory exists, namei() will generate an extra VREF() on
the vnode and set the VSOFTLOCK flag in vp-v_flag. If the vnode already
has VSOFTLOCK
The pointers in the last few entries of the vm_page_buckets array got
corrupted when an agument to a function that manipulated whatever was next
in ram was 0, and it turned out that it was 0 because
of some PTE flushing thing (you are the one that found it... remember?)
I think I've also seen
In message [EMAIL PROTECTED], Matt Dillon writes:
Hmm. Do we have a guard page at the base of the per process kernel
stack?
As I understand it, no. In RELENG_4 there are UPAGES (== 2 on i386)
pages of per-process kernel state at p-p_addr. The stack grows
down from the top, and struct
In message [EMAIL PROTECTED], Warner Losh writes:
I think that might be due to a bug in the shared interrupt code that
Ian Dowse sent me about earlier today.
Just to add a few details - there is a bug in the update_masks()
function in i386/isa/intr_machdep.c that can cause some interrupts
In message 003401c1244d$1fa6ee80$[EMAIL PROTECTED], Sansonetti Laurent w
rites:
A another stupid question, how can I do to stop the loading process in
MOD_LOAD event handler (in my case, if the cfg file doesn't exist, it should
be better to interrupt..) ?
Someone else might a have better idea of
In message 003101c12411$294adaa0$[EMAIL PROTECTED], Sansonetti Laurent w
rites:
Hello hackers,
I'm currently working on a kld syscall module which needs to read a config
file at startup (MOD_LOAD).
Following the advice of Eugene L. Vorokov, I tried to allocate some userland
space with mmap() to
In message [EMAIL PROTECTED], David Malone writes:
When you do a mount it automatically HUP's mountd which then
re-exports NFS filesystems. I suspect what is happening is that
the the filesystem mountlist is being cleared for a moment and that
is upsetting the cp.
Yes, the mountd-kernel
In message [EMAIL PROTECTED], Tabor Kelly writes:
Now that that is taken care of, would somebody mind explaining to me
what n_value represents? Is it an offset in kernel memory to retrieve
the actual data?
It is the kernel virtual address of the symbol that you specified
in n_name, which will be
For about a year, fdisk(8) has had code that automatically adjusts
partitions to begin on a head boundary and end on a cylinder
boundary. This is fine in most situations, but the way it is
implemented makes it awkward to override, and more importantly it
is way too easy to mess up an existing
In message [EMAIL PROTECTED], Brian Dean writes:
On Sat, Jul 21, 2001 at 02:47:29PM +0100, Ian Dowse wrote:
Below is a patch that makes fdisk request user confirmation before
making any changes to the start and end of partitions.
Please allow this behaviour to be overridden by a flag that can
In message [EMAIL PROTECTED], Terry Lambert writes:
FWIW, I vote that we rever to the traditional default and require
-R1 or -b to avoid boot time hangs. The standard behaviour for most
NFS implementations that I'm aware of would do this.
I agree; people at work have bitched about this. We
Shortly after the TI-RPC changes in -current, the default retry
behaviour for mount_nfs was changed. Previously, mount_nfs would
keep retrying for a long time (~1 week) if the server didn't respond,
but since revision 1.40 of mount_nfs.c, it gives up on non-background
mounts after one attempt.
In message [EMAIL PROTECTED], David Gilbert write
s:
Is it not possible (or has nobody done it) to swap with the current
diskless boot?
I do remember some problem with PXE and swap, but I forget the
details or if it was resolved. The diskless setup that we have
locally uses an MFS root image in
In message [EMAIL PROTECTED], Warner Losh writ
es:
I do have the options of connection the hardware up to the floppy
controller in my desktop too :-). I have both the RX-50 drives, as
well as a pair of TEAC FD55 drives (that do the same data rate as the
RX-50's, with the same heads, but with
In message [EMAIL PROTECTED], Warner Losh writ
es:
That's OK. The Rainbow disks have sectors numbered 1 through 10, for
both CP/M disks and MS-DOS disks. This makes things easier to cope
with.
Great, then no driver changes are required. I've just tried it; I
found a normal PC 5.25 drive, and
In message [EMAIL PROTECTED], Terry Lambert writes:
Use a chain allocator. I would suggest using the zone
allocator, but it has some fundamental problems that I
don't think are really resolvable without a rewrite.
Heh, maybe, but I'm not sure I want to write a new allocator for
this :-) Based
In message [EMAIL PROTECTED], Graham Barr writes:
Also why does this happen only every few hours ? There is a lot of
data going through these connections maybe the timer for SO_RCVTIMEO
is not being reset.
But then we have another server, with a similar number of clients and
data through put,
In message [EMAIL PROTECTED], Matt Dillon writes:
I would further recommend a (dynamic) array of pointers at the first
level as part of the summary structure. Any given array entry would
either point to the second level array (the 512 byte allocations),
be NULL (no second level
In message [EMAIL PROTECTED], Matt Dillon writes:
What are your commit plans? It looks extremely well contained,
it could be committed to -current and then -stable a few days later
without any destabilizing impact at all for when the option isn't
specified.
...
The only
Prompted by the recent discussion about performance with large
directories, I had a go at writing some code to improve the situation
without requiring any filesystem changes. Large directories can
usually be avoided by design, but the performance hit is very
annoying when it occurs. The namei
In message [EMAIL PROTECTED], Andrea writes:
MY FreeBSD 4.2 system has begun to crash some time ago..
fault virtual address = 0x9ec03e00
This virtual address suggests that these crashes are caused by a
bug that was fixed around two months ago. See
In message [EMAIL PROTECTED], Oliver Cook writes:
After about a week there are hundreds of stuck
httpd processes in exactly this state. It is not
possible to attach to them, but information can
be gleaned from a kernel backtrace:
Could you post the full output of ps axl on one of these machines?
In message [EMAIL PROTECTED], Oliver Cook writes:
There are three processes stuck in vmopar. I include the backtrace
of one of these below.
Thanks. That particular process is hanging because nfs_loadattrcache()
has noticed that the file shrunk, but it is not safe in this context
(from vm_fault)
In message [EMAIL PROTECTED], Oliver Cook writes:
However, the more noticeable problem was the processes stuck in
nfsvin because of the broken directory entry. Have you any ideas
as to what would be causing that particular problem which is
plaguing our servers more than the vmopar problem?
The
In message [EMAIL PROTECTED], "Daniel C. Sobral" writes:
and you must make sure your kernel is compiled with
options CD9660
Err... no. The kld gets autoloaded if the kernel doesn't have cd9660
compiled-in.
The error message that is printed is misleading though, and gives the
impression that
In message [EMAIL PROTECTED], Jaye Mathisen writes:
I have a 930GB vinum volume
However, I can't fsck it, I have to always use the alternate block.
newsfeed-inn2# fsck /dev/vinum/v-spool
** /dev/vinum/v-spool
BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE
[moved to -fs]
In message [EMAIL PROTECTED], Ian Dowse writes:
Jaye sent me a ktrace.out for the fsck that was failing. It appears
that the kernel had overshot the end of the superblock fs_csp[] array
in ffs_mountfs(), since the list of pointers there extended through
fs_maxcluster, fs_cpc
It appears that the pointer to the root vnode, 'rootvnode' does
not hold a corresponding vnode reference. Here's a fragment of code
from start_init():
/* Get the vnode for '/'. Set p-p_fd-fd_cdir to reference it. */
if (VFS_ROOT(TAILQ_FIRST(mountlist), rootvnode))
In message [EMAIL PROTECTED], Len Conrad
writes:
# vmstat -z
...
socket 607 1050 113/196K
...
kern.ipc.maxsockets: 1064
doesn't look like it to me.
I think a few slots are reserved, so you can consider 1050 as being
equal to 1064. Try putting
set
In message [EMAIL PROTECTED], Doug Ambrisko writes:
| to the kernel's output. I had a look at the pxe code in
| /sys/boot/i386/libi386/pxe.c where pxeboot is built from and in
| /sys/i386/i386/autoconf.c which is the kernel side and it looks like
| they don't do anything about swap. There is a /*
In message [EMAIL PROTECTED], Vadim Belman writes:
wmesg=0xc0233171 "vmopar", timo=0) at ../../kern/kern_synch.c:467
...
#8 0xc01dd606 in vm_fault (map=0xdc3e7e80, vaddr=712876032,
fault_type=1 '\001', fault_flags=0) at ../../vm/vm_pager.h:130
If anyone is interested, here are a few
In message [EMAIL PROTECTED], [EMAIL PROTECTED] wri
tes:
[EMAIL PROTECTED]
it hard to compile it under FreeBSD (however I can
compile it under Linux).I get "Buss error" and coredump
It's a simple programming error - you're not initialising the pointer
'q' in main(), so your code is overwriting
In message [EMAIL PROTECTED], "David E. Cross" writes:
though. Especially confusing is the following sequence of events:
41096 ypserv CALL select(0x10,0x8051040,0,0,0xbfbff518)
41096 ypserv PSIG SIGCHLD caught handler=0x804c75c mask=0x0 code=0x0
...
41096 ypserv RET sigreturn
In message [EMAIL PROTECTED], Chet Ramey writes:
for f in $$empty_list ${SUBDIRS}; do ...
Not bad, but will break if the shell is run with the `-u' option on
for some reason.
Ok, how about:
for f in $$IFS ${SUBDIRS}; do ...
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
In message [EMAIL PROTECTED], Warner Losh writes:
: to
:
: sh_subdirs=${SUBDIRS}; for f in $$sh_subdirs ; do ...
there's lots of other workarounds, from seeing if SUBDIRS is defined,
to using make's .foreach.
Another option is:
for f in $$empty_list ${SUBDIRS}; do ...
In message [EMAIL PROTECTED]
de, Jan Conrad writes:
When I cloned a new machine, I usually booted with the floppies, set up
DOS partitions and disk label and then pulled everyting over by tar and
rsh, thereby overwriting fstab etc. with prepared files. Worked pretty
fast...
What would you
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes:
I'm trying to use a Sun ELC (sun4c) as an Xterminal on my FreeBSD
system using Xkernel 2.0. I've used the old howto's from 1996
(Philippe Regnauld) as well as NetBSD diskless howto's to set this up.
So, does anyone have a fix for this?
In message [EMAIL PROTECTED], Dan Busa
row writes:
Earlier than that. 2.2.5? It prevents the machine from being used
as part of a smurf amplifier. If you want to change the behaviour
see
icmp_bmcastecho="NO"# respond to broadcast ping packets
This is different; the change I was
In message pine.bsf.4.10.9907151329040.9501-100...@merlin.th.physik.uni-bonn.d
e, Jan Conrad writes:
after wondering for two years why FreeBSD (2.2.x ... 3.2) might lock up
when an NFS server is down, I think I have found one reason for that (see
kern/12609 - I now know it doesn't belong to kern -
In message [EMAIL PROTECTED], "Bria
n F. Feldman" writes:
On 13 Jul 1999, Ville-Pertti Keinonen wrote:
[EMAIL PROTECTED] (Brian F. Feldman) writes:
It's "out with the bad, in with the good." Pidentd code is pretty terrible
.
The only security concerns with my code were wrt FAKEID, and
In message pine.bsf.4.10.9907130946220.76301-100...@janus.syracuse.net, Bria
n F. Feldman writes:
On 13 Jul 1999, Ville-Pertti Keinonen wrote:
gr...@freebsd.org (Brian F. Feldman) writes:
It's out with the bad, in with the good. Pidentd code is pretty terrible
.
The only security
80 matches
Mail list logo
