On Fri, 30 May 2008 16:37:00 +0200 (CEST), Oliver Fromme wrote:
Dinesh Nair wrote:
for those of us who're booting off a stripped down freebsd and are not
using the 4th routines, are the above to be set before 'load /kernel'
or after 'load /kernel' ?
It doesn't matter. The tunables
On Thu, 22 May 2008 06:38:19 -0700, Jeremy Chadwick wrote:
You need to modify some kernel settings via /boot/loader.conf and
reboot. Here's what we use on our production RELENG_6 and RELENG_7
boxes:
# Increase maximum allocatable memory on a process to 2GB.
# (We don't choose 3GB (our max
On Thu, 8 Nov 2007 16:52:38 -0600, Dan Nelson wrote:
In the last episode (Nov 08), Randall Hyde said:
It appears that character-at-a-time file I/O is *exceptionally* slow.
Yes, I realize that when processing large files I really ought to be
doing block/buffered I/O to get the best
On Fri, 06 Apr 2007 14:13:59 +0200, Volker wrote:
You need to patch your kernel sources a bit (all info in the PR) and
your silo overflows will be gone. I've done that to get a Merlin
i was about to comment on that, given that i extensively use a Huawei
3G/UMTS card without experiencing any of
On 08/16/06 20:37 Pyun YongHyeon said the following:
If the media is set to 'none' you couldn't send anything from re(4) as
recent changes checks whether the link is present(Receiver should work).
ifconfig re0 media 10baset or 100baset always returns error, so there
doesn't seem to be
i've got a single board computer with VIA C3 Samuel 2, 256MB RAM and 4
onboard Realtek 8139C+ NICs. I'm attempting to get FreeBSD 6.1-STABLE
working on them, but the realtek NICs just don't seem to want to work.
booting up led to a kernel trap with the following,
rlphy0: RealTek internal
On 08/14/06 17:22 Dinesh Nair said the following:
i've got a single board computer with VIA C3 Samuel 2, 256MB RAM and 4
onboard Realtek 8139C+ NICs. I'm attempting to get FreeBSD 6.1-STABLE
working on them, but the realtek NICs just don't seem to want to work.
booting up led to a kernel
On 08/14/06 18:39 Pyun YongHyeon said the following:
Recent changes from wpaul disabled re_diag() routine by default so it
i disabled re_diag() in /usr/src/sys/dev/if_re.c, and that caused the
kernel trap to go away, as per my original email. also, see my followup
email (to myself) in which
On 08/14/06 19:09 Pyun YongHyeon said the following:
really sucks and need much more CPU power to saturate the link.
So I don't think it's good idea to make rl(4) serve 8139C+.
perhaps, but re(4) doesn't work at the moment on this chipset, and i'd
rather have something which works, albeit a
On 11/12/05 21:02 Dinesh Nair said the following:
how does one specify a read/write mount of mfsroot in 6.0 in the
bootloader ?
apparently, the behaviour of vfs_mountroot_try() has changed in 6.0.
previously, if the root filesystem was mounted from a memory disk, as would
be the case
On 10/28/05 10:52 M. Warner Losh said the following:
libc_r will block all other threads in the application while an ioctl
executes. libpthread and libthr won't. I've had several bugs at work
so if the userland thread does an ioctl, and the the driver goes to
tsleep() when the ioctl is
On 11/03/05 03:12 Warner Losh said the following:
Yes. if you tsleep with signals enabled, the periodic timer will go
off, and you'll return early. This typically isn't what you want
either.
looks like i've got a lot of work to do, poring thru all the ioctls for the
device and trying to
On 11/03/05 04:27 M. Warner Losh said the following:
that this is the case: sleep in an ioctl, and the entire process hangs
until the ioctl returns.
which is probably what's happening in my case. i've got 4 threads spun off,
and one thread reads what the other writes and vice versa. after
On 11/03/05 05:17 M. Warner Losh said the following:
this is to create a helper program that gets the ioctl request over a
pipe or socket, does the call to the kernel and then returns the
results. Not idea, I'll grant, but it is an alternative worth
no, that wont work. the userland app is
On 11/03/05 05:15 Scott Long said the following:
before the ioctl call runs. But it does work. Look at the aac(4)
driver for my example of this.
i will, it sounds like a good solution.
The other option is to use rfork, aka 'linuxthreads' to similate threads
i could try with
On 10/28/05 16:40 Dinesh Nair said the following:
On 10/28/05 10:52 M. Warner Losh said the following:
libc_r will block all other threads in the application while an ioctl
executes. libpthread and libthr won't. I've had several bugs at work
which is a Good Thing(tm) indeed for me
On 11/02/05 00:03 Scott Long said the following:
I think this thread has gone too far into hyperbole and conjecture. What
is your code trying to do, and what problems are you seeing?
apologies, scott. i'm actually trying to get a driver written for freebsd
5.x backported to 4.x. the driver
On 11/02/05 03:02 Julian Elischer said the following:
drops to splzero or similar,..
woken process called,
starts manipulating another buffer
collides with next interrupt.
that makes a lot of sense, i'll try with using splxxx() in the pseudo
driver, to block out the real driver. it's
On 11/02/05 03:51 Scott Long said the following:
INTR_TYPE_TTY and spltty
[..snipped..]
You'll also want to use an spl in the top half of the pseudo driver to
cover where the pointers are read and changed.
thanx a bunch. i'll rewrite the portions affected based on yours and
julian's
On 11/02/05 06:12 Julian Elischer said the following:
depends on what they are using it for..
if it's a WAN interface, then splimp. (INTR_TYPE_NET)
if ppp or several other moduels are loaded, teh tty and net masks are
combined anyhow..
it's a quad-span E1/T1 line card which would be
On 11/02/05 06:16 Julian Elischer said the following:
also, why do you need a pseudo device AND a device? The device driver
can do all the things you have
suggested on its own.
this is so userland apps wont need to change when different devices are
used. the pseudo device is the front for
On 10/27/05 22:00 Scott Long said the following:
If you need to protect your pseudodriver from being interrupted by the
real driver then you'll need to use the same spl() as the driver. Note
that you shouldn't be using splhigh() unless you really know what you
the driver currently is set to
On 10/28/05 10:52 M. Warner Losh said the following:
libc_r will block all other threads in the application while an ioctl
executes. libpthread and libthr won't. I've had several bugs at work
which is a Good Thing(tm) indeed for me on 4.x.
--
Regards, /\_/\ All
carrying on this discussion, what would be a good locking mechanism to use
to protect tsleep() and other sensitive areas in a driver in freebsd 4.x ?
the current code for the driver in 5.x uses mtx_lock and mtx_unlock with
some parts even being protected by mtx_lock(Giant).
would the use
On 10/27/05 22:00 Scott Long said the following:
are doing. Other than that, there likely isn't anything that you need
to do for 'locking' in 4.x. The kernel is non-reentrant there, so you
don't need to worry about synchronizing multiple threads.
thanx a bunch, scott. it's been a nightmare
On 10/26/05 04:10 John Baldwin said the following:
Yes, and on some archs the sync() operations do have memory barriers in place,
but there isn't any bounce buffering with bus_dmamem_alloc() memory.
and in _bus_dmamap_load() in /usr/src/sys/i386/i386/busdma_machdep.c,
apparently if the
On 10/26/05 10:39 Scott Long said the following:
Apparently the original poster sent his question to me in private, then
sent it again to the mailing list right as I was responding in private.
apologies on that, scott. an initial search only turned up your message in
the archives, but
On 10/26/05 23:54 Scott Long said the following:
The value of the map is an implementation detail, which is why it's an
opaque typedef. Portable code should always assume that the map has
valid data. Now, specifically for i386, if you have a device with a
right, so for portability's sake,
On 10/27/05 01:20 John Baldwin said the following:
On i386, yes. It won't on sparc64 when using an IOMMU for example. The whole
point of using bus_dma is to not use vtophys() since by doing that you are
righto, so for platform portability, we'd still need to use it there though.
Yes,
On 10/27/05 04:16 Scott Long said the following:
an example would be using (BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE)
which
would be 0x03 in freebsd 4.x and 0x06 in freebsd 5.x. the gotcha is that
0x03 in freebsd 4.x is BUS_DMASYNC_POSTWRITE. so therefore,
i came across this message
http://lists.freebsd.org/pipermail/freebsd-current/2004-December/044395.html
and while it explains the use of bus_dmamap_sync, i'm still a little
confused on it's usage. i'm trying to port over a driver from freebsd 5.x
to freebsd 4.x, and it uses dma mapped
On 10/25/05 21:15 Dinesh Nair said the following:
the pseudo code for the read and write, called during an interrupt
cycle, are:
rx_func()
{
POSITION A
while(there_is_some_data) {
memcpy(somebuf, readbuf)
}
POSITION B
}
tx_func()
{
POSITION C
while
On 10/26/05 01:27 John Baldwin said the following:
On Tuesday 25 October 2005 09:15 am, Dinesh Nair wrote:
(must i malloc space for them before passing them into those functions, or
will the call to bus_dmamem_alloc do it for me ?)
bus_dmamem_alloc() will do it for you.
thanx.
Probably
On 10/26/05 01:02 Singh, Vijay said the following:
man bus_dma(9)
thanx, but that doesn't exist on freebsd 4.x. though
http://www.freebsd.org/cgi/man.cgi?query=bus_dmamap_syncapropos=0sektion=0manpath=FreeBSD+5.4-stableformat=html
has it, it still applies only to 5.x.
--
Regards,
On 04/02/05 14:05 Nate Lawson said the following:
Dinesh Nair wrote:
On 03/31/05 20:51 John Baldwin said the following:
The problem is that the taskqueue_swi in 4.x doesn't have a thread
context that can be slept on via tsleep(). The fix would be to
create a kthread in which to run the ACPI
On 03/31/05 20:51 John Baldwin said the following:
The problem is that the taskqueue_swi in 4.x doesn't have a thread
context that can be slept on via tsleep(). The fix would be to create a
kthread in which to run the ACPI tasks. 4.x already has one such
kthread for the taskqueue_thread
acpi related, but on freebsd 4.11 (cvsupped and built on 24 march).
i've compiled with device acpica in the kernel, but i get sporadic page
faults as attached.
i do know that acpica is experimental and that LINT does warn of kernel
panics and machine hangs. however i was wondering if anyone has
On Mon, 19 Jan 2004, Anton Alin-Adrian wrote:
Regarding latest qmail vulnerability, I coded this quickly patch.
Please double-check me if I am wrong here. Forward this to
freebsd-security please.
320c320
++pos;
---
if (pos9) ++pos;
, AUE_GPIO1, 0x34);
/* Grrr. LinkSys has to be different from everyone else. */
if (sc-aue_info-aue_flags LSYS) {
---CUT HERE ---
On Wed, 7 Jan 2004, Dinesh Nair wrote:
hey,
i have one of the above. it's a usb device which connects to a HomePNA
network, with a 10
use the following patch instead of earlier one. earlier patch hardcoded
use of HomePNA PHY and disabled Ethernet PHY. this patch corrects this
behaviour and allows switching between either PHY thru use of the ifconfig
command. this means that the USB dongle can either be used as an Ethernet
+* and only activates the 1Mbps HomePNA PHY
+*
+* Modified by Dinesh Nair [EMAIL PROTECTED]
+* Wed Jan 7 20:36:34 MYT 2004
+*
+*/
+ if (sc-aue_info-aue_vid == USB_VENDOR_ADMTEK
+ sc-aue_info-aue_did == USB_PRODUCT_ADMTEK_PEGASUSII
On Tue, 5 Nov 2002, Richard Sharpe wrote:
Well, we have 4GB in a 4.6.2 system, and I think that we ran 4.3 on those
systems for a while.
However, you lose anywhere between 128M and 512M because of the PCI
address space.
what PCI address space ? could someone explain about this loss ?
On Fri, 7 Jun 2002, Frank Mayhar wrote:
I see very common short-term hangs, a few seconds to less than a minute.
The mouse and keyboard stop responding, X stops updating and everything
just pauses, the whole system (including the network). It then starts
i've seen this happen on an Asus
On Fri, 10 May 2002, Doug White wrote:
usually have onboard everything, including dual fxp's nowadays. But they
have the ServerWorks curse.
. Tyan makes some interesting stuff, but as with all ServerWorks based
stuff, stay far, far away from the base ATA33 controller. Even the cheap
what
On Mon, 4 Mar 2002, Garrett Rooney wrote:
one comment from the quick look at the screenshots. why bother having
the 's around the strings? it would make more sense to me to just
perhaps the quotes would show up otherwise hidden spaces ?
Regards, /\_/\ All dogs
45 matches
Mail list logo
