freebsd-current Digest, Vol 71, Issue 13
freebsd-cur...@freebsd.org
freebsd...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-current
or, via email, send a message with subject or body 'help' to
freebsd-cur...@freebsd.org
You can reach the person managing the list at
freebsd-cu...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-current digest..."
Today's Topics:
1. Re: So much entropy it's coming out of our ears? (Max Laier)
2. Re: So much entropy it's coming out of our ears? (Sam Leffler)
3. Re: kernel build error (Sean McNeil)
4. Atomic operations on i386/amd64 (Tim Robbins)
5. Re: FreeBSD and wine mmap (John Birrell)
6. Ports broken by compiler upgrade (Pete Carah)
7. Re: Challenge getting touchpad to work since
src/sys/isa/psm.c 1.71 (Mikko Ty?l?j?rvi)
8. Re: Ports broken by compiler upgrade (Alexander Kabaev)
9. Re: HEADS UP! boot2 problems (Alexander Kabaev)
10. Re: Ports broken by compiler upgrade (Kent Stewart)
11. [PLEASE TEST] Better support for Synaptics Touchpads
(Philip Paeps)
12. Dell gx280 problems (Danny Braniss)
13. Re: [PLEASE TEST] Better support for Synaptics Touchpads
(Arne Schwabe)
14. Re: radeon.ko doesn't load on recent current (Maxime Henrion)
15. Re: [PLEASE TEST] Better support for Synaptics Touchpads
(Philip Paeps)
16. Support for pci discover for Acer Aspire 1605 laptop.
(TooManySecrets)
17. ad0 / ad1 wierdness (Ilker OZUPAK)
18. acpi problem (Ilker OZUPAK)
19. Re: Ports broken by compiler upgrade (Michael Nottebrock)
20. Re: Ports broken by compiler upgrade (Poul-Henning Kamp)
21. Re: problems with altq (Divacky Roman)
22. Re: problems with altq (Divacky Roman)
23. Re: problems with altq (Divacky Roman)
24. Re: problems with altq (Divacky Roman)
----------------------------------------------------------------------
Message: 1
Date: Thu, 5 Aug 2004 06:31:51 +0200
From: Max Laier <m...@love2party.net>
Subject: Re: So much entropy it's coming out of our ears?
To: freebsd...@freebsd.org
Cc: ma...@FreeBSD.org
Message-ID: <20040805063...@love2party.net>
Content-Type: text/plain; charset="iso-8859-1"
On Thursday 05 August 2004 05:56, Robert Watson wrote:
> As you know, I'm currently profiling and tracing our inbound and outbound
> network stacks, and I've already bothered you with an e-mail about lock
> coalescing and avoiding lock thrashing in the Yarrow thread. This is more
> of the same sort of thing, and is about per-packet processing costs.
>
> I've observed in tracing that we grab and release two entropy related spin
> mutexes for every ethernet packet processed. We do this in the ithread
> before the netisr runs, and it directly introduces latency (and cost) in
> the network path. Here's a sample trace fragment from receiving an
> ethernet packet:
>
> 12024 0 1280 ithread_schedule: setrunqueue 27
> 12025 0 1480 UNLOCK (spin mutex) sched lock r = 0 at
> ../../../kern/kern_intr.c:414 12026 0 1048 LOCK (spin mutex)
> entropy harvest r = 0 at ../../../dev/random/randomdev_soft.c:300 12027 0
> 788 LOCK (spin mutex) entropy harvest buffers r = 0 at
> ../../../dev/random/randomdev_soft.c:309 12028 0 856 UNLOCK
> (spin mutex) entropy harvest buffers r = 0 at
> ../../../dev/random/randomdev_soft.c:317 12029 0 616 UNLOCK
> (spin mutex) entropy harvest r = 0 at
> ../../../dev/random/randomdev_soft.c:338
>
> On inspecting random_harvest_internal(), it seems to be the case upfront
> that we can do an unlocked read of harvestfifo[origin].count to compare
> with RANDOM_FIFO_MAX and avoid any locks in the event that the event fifo
> is full. Obviously, you'd need to retest after acquiring the locks in the
> event there would appear to be room, but assuming that the fifo will often
> be full under load, this would save a useful amount of cost. I haven't
> attempted to measure how often the fifo fills, however, so can't currently
> reason about whether that will save work in the common case.
>
> Another observation is that we seem to be doing a lot of entropy
> gathering. That is to say -- a lot. On a busy system, I have to wonder
> whether we're not paying a high cost to gather more entropy than we really
> need. I'm not familiar with the Yarrow implementation nor harvesting
> bits, but I'd pose this question to you: right now, we appear to pay four
> mutex operations per packet if the fifo isn't full. Can we rate limit
> entropy gathering in entropy-rich systems to avoid doing so much work? If
> we're processing 25,000 or 100,000 packets a second, that's a lot of goup
> passing through Yarrow. Is it possible to do lockless rate limiting so
> that we gather it only once every few seconds? This might make a big
> aggregate difference when processing ethernet packets at a high rate, such
> as in bridging/forwarding scenarios, etc.
Stupid question: Why do we try to make sure that *entropy* is passed reliable?
i.e. wouldn't it be enough to store it (unlocked) "somewhere" inside a circle
buffer and read from it (unlocked) to turn it into randomness. The potential
race just gives some extra entropy.
But as I started, might be a stupid question.
--
/"\ Best regards, | mla...@freebsd.org
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: signature
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20040805/9260d0cb/attachment-0001.bin
------------------------------
Message: 2
Date: Wed, 4 Aug 2004 21:39:52 -0700
From: Sam Leffler <s...@errno.com>
Subject: Re: So much entropy it's coming out of our ears?
To: freebsd...@freebsd.org
Cc: Robert Watson <rwa...@freebsd.org>
Message-ID: <20040804213...@errno.com>
Content-Type: text/plain; charset="iso-8859-1"
On Wednesday 04 August 2004 08:56 pm, Robert Watson wrote:
> Another observation is that we seem to be doing a lot of entropy
> gathering. That is to say -- a lot. On a busy system, I have to wonder
> whether we're not paying a high cost to gather more entropy than we really
> need. I'm not familiar with the Yarrow implementation nor harvesting
> bits, but I'd pose this question to you: right now, we appear to pay four
> mutex operations per packet if the fifo isn't full. Can we rate limit
> entropy gathering in entropy-rich systems to avoid doing so much work? If
> we're processing 25,000 or 100,000 packets a second, that's a lot of goup
> passing through Yarrow. Is it possible to do lockless rate limiting so
> that we gather it only once every few seconds? This might make a big
> aggregate difference when processing ethernet packets at a high rate, such
> as in bridging/forwarding scenarios, etc.
Virtually all performance-sensitive installations will disable entropy
gathering through fast paths. I've suggested for a long time that this sort
of collection should be enabled only under dire circumstances and never by
default. Regardless the last time I looked at the entropy harvesting it used
a model where entropy was unilateraly sent for harvest and discarded when too
plentiful. I term this the "push model". I've advocated a "pull model"
where the PRNG requests entropy when a low water mark is hit and/or a hybrid
scheme where producers have some sort of flow control or feedback mechanism.
Everything that goes on inside the PRNG is a separate issue.
Sam
------------------------------
Message: 3
Date: Wed, 04 Aug 2004 21:43:52 -0700
From: Sean McNeil <se...@mcneil.com>
Subject: Re: kernel build error
To: FreeBSD Current <freebsd...@freebsd.org>
Message-ID: <1091681032.5...@server.mcneil.com>
Content-Type: text/plain
On Wed, 4 Aug 2004, Robert Watson wrote:
> The problem appears to be that 'mem_range_softc' is defined in
> mp_machdep.c, which means you can't build a non-SMP i386 kernel
because
> the symbol is undefined. We probably need to move the declaration to
> machdep.c or the like.
Can someone please also fix the other architectures besides i386? I
have the same issue with amd64 and it doesn't appear anyone has fixed it
yet.
Thanks,
Sean
------------------------------
Message: 4
Date: Thu, 5 Aug 2004 15:04:22 +1000
From: Tim Robbins <t...@freebsd.org>
Subject: Atomic operations on i386/amd64
To: freebsd...@freebsd.org
Message-ID: <20040805050...@cat.robbins.dropbear.id.au>
Content-Type: text/plain; charset=us-ascii
Is there any particular reason why atomic_load_acq_*() and
atomic_store_rel_*() are implemented with CMPXCHG and XCHG instead of
MOV on i386/amd64 UP?
Also, could we use MFENCE/LFENCE/SFENCE in combination with MOV on
SMP systems instead of LOCK CMPXCHG / (implied LOCK) XCHG?
Tim
------------------------------
Message: 5
Date: Thu, 5 Aug 2004 15:07:25 +1000
From: John Birrell <j...@cimlogic.com.au>
Subject: Re: FreeBSD and wine mmap
To: Julian Elischer <jul...@elischer.org>
Cc: freebsd...@freebsd.org
Message-ID: <20040805050...@freebsd3.cimlogic.com.au>
Content-Type: text/plain; charset=us-ascii
On Wed, Aug 04, 2004 at 03:46:42PM -0700, Julian Elischer wrote:
> /proc/curproc/map
> can give you a quick temporary solution..
> julian@ref3:cat /proc/curproc/map
I can't see how that gives a quick temporary solution. The mmaps we are
talking about are the ones done by rtld. Wine libraries are standard
Unix shared libraries that are dlopen'ed. The fact that the load fails
is due to the upper process memory being deliberately consumed before
the libraries are loaded. Screwing up rtld seems like a poor idea to
me.
The Wine people say that Linux now loads shared libraries at random
addresses to make buffer overruns less predictable. That's why they
gobble upper memory as soon as they can (albeit after libc has been
loaded because that's linked to the Wine program). Presumably FreeBSD
may one day consider doing the same thing for the same reason.
--
John Birrell
------------------------------
Message: 6
Date: Wed, 4 Aug 2004 22:56:30 -0700
From: Pete Carah <pe...@altadena.net>
Subject: Ports broken by compiler upgrade
To: cur...@freebsd.org
Message-ID: <20040805055...@users.altadena.net>
Content-Type: text/plain; charset=us-ascii
Many ports that compile in C++ are broken by the recent
compiler upgrade; the packages distribution hasn't caught
up *at all* either. I know part of the reason is that some
of the affected ports don't compile at all with the new
compiler (by trying). I presume that the converse probably
holds too; once the ports are fixed then the resulting
packages probably won't work on a current dated before
last week. It might be a good idea to keep an older
package directory around for a while for those not-quite-
so-adventurous types...
Two examples, artsd and aspell both abort instantly with
undefined symbols; either the name-mangling has changed
or one or another library has changed, or both. Aspell
is needed for pan2 to work and artsd is obvious to those
who like sound in kde. Neither compiles completely as-is
(artsd itself actually does but several needed "extension"
modules don't, leaving things less than useful).
This may be old news but... It is not quite enough to
make sure that the main tree compiles with a newly-committed
compiler - some of the ports are so widely used (e.g. XFree86)
that they could be considered to be fairly essential.
I don't need any replies to this; it is just a note to
whomever it may concern (lots of port-maintainers, and
the compiler folk(s))...
It does leave my laptop less than useful; I can back up
to last week easily enough but that is lots of trouble
(and don't say to use 4.x in the laptop since it (like many
modern laptops) depends on several drivers that are only in
current, like cardbus.)
-- Pete
------------------------------
Message: 7
Date: Wed, 4 Aug 2004 23:10:01 -0700 (PDT)
From: Mikko Ty?l?j?rvi<mb...@pacbell.net>
Subject: Re: Challenge getting touchpad to work since
src/sys/isa/psm.c 1.71
To: "Alexandre \"Sunny\" Kovalenko" <Alex.Ko...@verizon.net>
Cc: freebsd...@freebsd.org
Message-ID: <200408042...@sotec.home>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Wed, 4 Aug 2004, Alexandre "Sunny" Kovalenko wrote:
> On Wed, 2004-08-04 at 17:00, David Wolfskill wrote:
>> Sorry about the delay; right around the time of the commit, I was having
>> some thermal issues with my laptop (a Dell Inspiron 5000e). I believe
>> those are fixed now -- it's gone through 5 days, each of which has
>> involved a "buildworld cycle" for each of -STABLE & -CURRENT, without
>> incident.
>>
>> But I'm now having trouble getting a "touchpad tap" to be recognized as
>> a press/release of a mouse button in -CURRENT; I believe that the recent
>> commit to src/sys/isa/psm.c 1.71 is involved.
> Rolling psm.c back to 1.70 restores tapping behavior of the touchpad on
> my AVERATEC 3150H. Unfortunately with 200+ lines of diff, I could not
> come up with the better idea at the moment.
>
> I can test patches or try out settings if necessary.
Here is what I'm using:
$.02,
/Mikko
--- psm.c.orig Wed Aug 4 22:34:32 2004
+++ psm.c Wed Aug 4 22:34:38 2004
@@ -103,6 +103,13 @@
#define PSM_INPUT_TIMEOUT 2000000 /* 2 sec */
#endif
+#ifndef PSM_TAP_TIMEOUT
+#define PSM_TAP_TIMEOUT 125000
+#endif
+#ifndef PSM_TAP_THRESHOLD
+#define PSM_TAP_THRESHOLD 25
+#endif
+
/* end of driver specific options */
#define PSM_DRIVER_NAME "psm"
@@ -181,6 +188,8 @@
struct cdev *bdev;
int lasterr;
int cmdcount;
+ struct timeval taptimeout; /* (Synaptics) width of a "tap" pulse */
+ int zmax; /* (Synaptics) pressure measured during tap */
};
static devclass_t psm_devclass;
#define PSM_SOFTC(unit) ((struct psm_softc*)devclass_get_softc(psm_devclass, unit))
@@ -2531,11 +2540,20 @@
} else {
sc->flags |= PSM_FLAGS_FINGERDOWN;
}
-
+ sc->zmax = imax(z, sc->zmax);
sc->xold = x0;
sc->yold = y0;
} else {
sc->flags &= ~PSM_FLAGS_FINGERDOWN;
+ sc->flags &= ~PSM_FLAGS_FINGERDOWN;
+ if (sc->zmax > PSM_TAP_THRESHOLD
+ && timevalcmp(&sc->lastsoftintr, &sc->taptimeout, <=)) {
+ ms.button |= MOUSE_BUTTON1DOWN;
+ }
+ sc->zmax = 0;
+ sc->taptimeout.tv_sec = PSM_TAP_TIMEOUT / 1000000;
+ sc->taptimeout.tv_usec = PSM_TAP_TIMEOUT % 1000000;
+ timevaladd(&sc->taptimeout, &sc->lastsoftintr);
}
z = 0;
break;
------------------------------
Message: 8
Date: Thu, 5 Aug 2004 06:19:58 +0000
From: Alexander Kabaev <k...@freebsd.org>
Subject: Re: Ports broken by compiler upgrade
To: Pete Carah <pe...@altadena.net>
Cc: cur...@freebsd.org
Message-ID: <20040805061...@freefall.freebsd.org>
Content-Type: text/plain; charset=us-ascii
On Wed, Aug 04, 2004 at 10:56:30PM -0700, Pete Carah wrote:
> Many ports that compile in C++ are broken by the recent
> compiler upgrade; the packages distribution hasn't caught
> up *at all* either. I know part of the reason is that some
> of the affected ports don't compile at all with the new
> compiler (by trying). I presume that the converse probably
> holds too; once the ports are fixed then the resulting
> packages probably won't work on a current dated before
> last week. It might be a good idea to keep an older
> package directory around for a while for those not-quite-
> so-adventurous types...
>
> Two examples, artsd and aspell both abort instantly with
> undefined symbols; either the name-mangling has changed
> or one or another library has changed, or both. Aspell
> is needed for pan2 to work and artsd is obvious to those
> who like sound in kde. Neither compiles completely as-is
> (artsd itself actually does but several needed "extension"
> modules don't, leaving things less than useful).
>
> This may be old news but... It is not quite enough to
> make sure that the main tree compiles with a newly-committed
> compiler - some of the ports are so widely used (e.g. XFree86)
> that they could be considered to be fairly essential.
GCC snapshots were available for ports people to test their ports
quite some time in advance. Expecting gcc maintainers to fix all
major ports to work with each new GCC version directy contradicts the
goal of having in-tree compiler updated more often than once every
100 years.
I would gladly respond to any bug report, indicating the trouble
with compiler itself, though.
--
Alexander Kabaev
------------------------------
Message: 9
Date: Thu, 5 Aug 2004 06:27:28 +0000
From: Alexander Kabaev <k...@freebsd.org>
Subject: Re: HEADS UP! boot2 problems
To: Scott Long <sco...@samsco.org>
Cc: FreeBSD Current List <cur...@freebsd.org>
Message-ID: <20040805062...@freefall.freebsd.org>
Content-Type: text/plain; charset=us-ascii
On Fri, Jul 30, 2004 at 03:21:19PM +0000, Alexander Kabaev wrote:
> On Thu, Jul 29, 2004 at 08:39:43PM -0600, Scott Long wrote:
> > All,
> >
> > The GCC 3.4 import seems to have broken the boot2 loader on at least
> > i386. This doesn't affect normal world and kernel builds and installs,
> > but does affect writing new bootblocks via the disklabel program. You
> > should refrain from doing this until it gets fixed. It's being looked
> > into right now.
> >
> > Scott
>
> Commit below made boot2 usable again.
As suggested by Matt Dillon, the problems were caused by imcompletely
zeroed out BSS. I merged approproate fixes from DragonflyBSD in commit
below. Success/failure reports from people affected are appreciated.
kann 2004-08-05 06:00:05 UTC
FreeBSD src repository
Modified files:
sys/boot/i386/boot2 boot1.S
sys/boot/i386/btx/lib btxcsu.s
Log:
Move boot2 BSS zeroing into btx startup code out of boot1. boot1 does not
have clear idea on boot2 BSS size and leaves portion of it not zeroed out.
btxcsu.s is in much better position for this job.
Obtained from: DragonflyBSD (with minor adjustments)
Revision Changes Path
1.29 +0 -4 src/sys/boot/i386/boot2/boot1.S
1.4 +9 -1 src/sys/boot/i386/btx/lib/btxcsu.s
------------------------------
Message: 10
Date: Thu, 5 Aug 2004 00:01:41 -0700
From: Kent Stewart <kste...@owt.com>
Subject: Re: Ports broken by compiler upgrade
To: freebsd...@freebsd.org
Cc: Alexander Kabaev <k...@freebsd.org>
Message-ID: <200408050001....@owt.com>
Content-Type: text/plain; charset="iso-8859-1"
On Wednesday 04 August 2004 11:19 pm, Alexander Kabaev wrote:
> On Wed, Aug 04, 2004 at 10:56:30PM -0700, Pete Carah wrote:
> > Many ports that compile in C++ are broken by the recent
> > compiler upgrade; the packages distribution hasn't caught
> > up *at all* either. I know part of the reason is that some
> > of the affected ports don't compile at all with the new
> > compiler (by trying). I presume that the converse probably
> > holds too; once the ports are fixed then the resulting
> > packages probably won't work on a current dated before
> > last week. It might be a good idea to keep an older
> > package directory around for a while for those not-quite-
> > so-adventurous types...
> >
> > Two examples, artsd and aspell both abort instantly with
> > undefined symbols; either the name-mangling has changed
> > or one or another library has changed, or both. Aspell
> > is needed for pan2 to work and artsd is obvious to those
> > who like sound in kde. Neither compiles completely as-is
> > (artsd itself actually does but several needed "extension"
> > modules don't, leaving things less than useful).
> >
> > This may be old news but... It is not quite enough to
> > make sure that the main tree compiles with a newly-committed
> > compiler - some of the ports are so widely used (e.g. XFree86)
> > that they could be considered to be fairly essential.
>
> GCC snapshots were available for ports people to test their ports
> quite some time in advance. Expecting gcc maintainers to fix all
> major ports to work with each new GCC version directy contradicts the
> goal of having in-tree compiler updated more often than once every
> 100 years.
>
> I would gladly respond to any bug report, indicating the trouble
> with compiler itself, though.
>
I consider changing compilers like this to be the equivalent of the
libintl.so.* changes. You have to think that the interfaces in the
headers have changed and everything needs to be rebuilt using the new
compiler. Since I updated XFree86 to xorg, I couldn't do a
portupgrade -pufa easily. The upgrade had to be done more piece meal.
What I have found, with one exception (libxine), is that a -Rf
portupgrade did wonders on making individual ports compile again. FWIW,
I am not having any problem building artsd or aspell.
Kent
--
Kent Stewart
Richland, WA
http://users.owt.com/kstewart/index.html
------------------------------
Message: 11
Date: Thu, 5 Aug 2004 09:12:36 +0200
From: Philip Paeps <phi...@freebsd.org>
Subject: [PLEASE TEST] Better support for Synaptics Touchpads
To: freebsd...@freebsd.org
Message-ID: <2004080507...@loge.nixsys.be>
Content-Type: text/plain; charset=us-ascii
Hi gang :-)
Since the original synaptics support was added to psm, there have been some
reports of malfunctions and missing magic. I've tried to fix all that, but
it's still work in progress.
If you happen to own a laptop with a synaptics touchpad, please help test:
<http://people.freebsd.org/~philip/psm.diff>
So far, I've had one report of a panic, possibly related to an extra gadget
chained through the the touchpad. If you're extra masochistic, and your
laptop has one of these extra gadgets, you might like to remove the #if 0
around line 2537 and the #endif around line 2568 of your sys/isa/psm.c.
Please report successes and failures :-)
- Philip
--
Philip Paeps Please don't Cc me, I am
phi...@freebsd.org subscribed to the list.
Teamwork is essential. It allows you to blame someone else.
------------------------------
Message: 12
Date: Thu, 05 Aug 2004 10:33:20 +0300
From: Danny Braniss <da...@cs.huji.ac.il>
Subject: Dell gx280 problems
To: Freebsd...@freebsd.org
Message-ID: <200408050733...@mx1.FreeBSD.org>
Content-Type: text/plain; charset=us-ascii
hi,
This is a new box on evaluation, and so far i can't boot it.
Every system has a different problem.
With current/acpi:
FreeBSD 5.2-CURRENT #0: Wed Aug 4 18:21:27 IDT 2004
danny@new-dev:/r+d/obj/new-dev/r+d/5.2/src/sys/HUJI
WARNING: Kernel preemption is disabled, expect reduced performance.
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a3b000.
Preloaded elf module "/boot/modules/if_nv.ko" at 0xc0a3b2bc.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a3b368.
Table 'FACP' at 0xfcc3d
Table 'SSDT' at 0xfffd1fe6
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x1c
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc075b71e
stack pointer = 0x10:0xc0c21bd4
frame pointer = 0x10:0xc0c21cac
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 0 ()
[thread 0]
Stopped at vm_fault+0x1b2: lock cmpxchgl %ecx,0x1c(%ebx)
db> trace
vm_fault(c103a000,c1004000,1,0,c08dfa60) at vm_fault+0x1b2
trap_pfault(c0c21d14,0,c1004c29) at trap_pfault+0x184
trap(fffd0018,c1000010,c0c20010,c1004bfd,7) at trap+0x2f5
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc0a1d9f0, esp = 0xc0c21d54, ebp = 0xc0c21d74 ---
madt_probe(c22274a8,c08b7890,c0c21d98,c05e620a,0) at madt_probe+0x174
apic_init(0,c1ec00,c1e000,0,c0440c65) at apic_init+0x47
mi_startup() at mi_startup+0x96
begin() at begin+0x2c
disabling apic i get much further but then broadcom is not
found.
danny
------------------------------
Message: 13
Date: Thu, 05 Aug 2004 10:34:28 +0200
From: Arne Schwabe <ar...@rfc2549.org>
Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads
To: freebsd...@freebsd.org
Message-ID: <86ekmmh...@kamino.rfc1149.org>
Content-Type: text/plain; charset=us-ascii
Philip Paeps <phi...@freebsd.org> writes:
> Hi gang :-)
>
> Since the original synaptics support was added to psm, there have been some
> reports of malfunctions and missing magic. I've tried to fix all that, but
> it's still work in progress.
z>
> If you happen to own a laptop with a synaptics touchpad, please help test:
>
> <http://people.freebsd.org/~philip/psm.diff>
>
> So far, I've had one report of a panic, possibly related to an extra gadget
> chained through the the touchpad. If you're extra masochistic, and your
> laptop has one of these extra gadgets, you might like to remove the #if 0
> around line 2537 and the #endif around line 2568 of your sys/isa/psm.c.
>
+ * XXX: This is largely guesswork. The documentation from
+ * Synaptics doesn't mention guest devices, but it appears
+ * that packets from a stick are simple ps/2 packets...
They are ps/2 packets but if you are crazy you can send
the guest ps/2 device some ps/2 commands to put it into a special
mode where can get features like pressure but well I don't know if
that is really needed. ;)
Arne
--
compiling millions of tiny c-programs...done
checking for a working configure script... not found
------------------------------
Message: 14
Date: Thu, 5 Aug 2004 10:38:53 +0200
From: Maxime Henrion <m...@freebsd.org>
Subject: Re: radeon.ko doesn't load on recent current
To: anh...@FreeBSD.org, cur...@freebsd.org
Message-ID: <20040805083...@elvis.mu.org>
Content-Type: text/plain; charset=us-ascii
Toxa wrote:
> On Wed, Aug 04, 2004 at 06:13:55PM +0200, Franz Klammer wrote:
> >
> > the patch works!
> >
> > i removed the devices mem and mgadrm vom kernel config and build the
> > new kernel with -DNOCLEAN. hopefully this was correct enough for testing.
> >
> > franz.
>
> the same with radeon.ko. "suddenly everything works" :-)
> we're waiting for commit ;-)
Done! Thanks for testing the patch.
Cheers,
Maxime
------------------------------
Message: 15
Date: Thu, 5 Aug 2004 10:58:07 +0200
From: Philip Paeps <phi...@freebsd.org>
Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads
To: freebsd...@freebsd.org
Message-ID: <2004080508...@loge.nixsys.be>
Content-Type: text/plain; charset=us-ascii
On 2004-08-05 10:34:28 (+0200), Arne Schwabe <ar...@rfc2549.org> wrote:
> Philip Paeps <phi...@freebsd.org> writes:
> > If you happen to own a laptop with a synaptics touchpad, please help test:
> >
> > <http://people.freebsd.org/~philip/psm.diff>
>
> + * XXX: This is largely guesswork. The documentation from
> + * Synaptics doesn't mention guest devices, but it appears
> + * that packets from a stick are simple ps/2 packets...
>
> They are ps/2 packets but if you are crazy you can send the guest ps/2
> device some ps/2 commands to put it into a special mode where can get
> features like pressure but well I don't know if that is really needed. ;)
It might be fun to do :-) Given enough physical and virtual buttons, we
should be able to emulate a full-scale piano over ps/2. *grin*
Do you know of any documentation more recent than the ACF126.pdf from the
Synaptics site? Guessing is a bit tedious...
- Philip
--
Philip Paeps Please don't Cc me, I am
phi...@freebsd.org subscribed to the list.
A budget is buying a dress two sizes too small because
it was marked down.
------------------------------
Message: 16
Date: Thu, 05 Aug 2004 11:09:31 +0200
From: TooManySecrets <too...@toomany.net>
Subject: Support for pci discover for Acer Aspire 1605 laptop.
To: current <freebsd...@freebsd.org>
Message-ID: <1091696970.5...@manu.datagrama.net>
Content-Type: text/plain; charset=iso-8859-15
Hi.
Sorry for my bad english...
Three or four month's ago I was write about a recognition problem with a
Acer Aspire 1605 laptop; it doesn't "see" the realtek ethernet. Today I
download the 5.2-CURRENT-20040804-SESNAP.iso and try, with and without
ACPI, and seem it's continue in the same way; don't work.
M. Warner Losh <i...@bsdimp.com> was contacted with me, but I don't know
if this problem have a solution, if the solution was applied (I think
not), or anything about.
This is the last e-mail I recieved from him:
==================================================================
In message: <1083945436.7...@toomany.toomany.net>
TooManySecrets <too...@toomany.net> writes:
: El vie, 07-05-2004 a las 16:59, M. Warner Losh escribió:
: > In message: <1083941740.7...@toomany.toomany.net>
: > TooManySecrets <too...@toomany.net> writes:
: > : El vie, 07-05-2004 a las 16:16, M. Warner Losh escribió:
: > : > What does pciconf -r pci0:7:0 0:0xff tell you?
: > :
: > : ffffffff ffffffff ffffffff ffffffff
: > : ffffffff ffffffff ffffffff ffffffff
: > : ffffffff ffffffff ffffffff ffffffff
: > : ffffffff ffffffff ffffffff ffffffff
: > : ffffffff ffffffff ffffffff ffffffff
: > : ffffffff ffffffff ffffffff ffffffff
: > : ffffffff ffffffff ffffffff ffffffff
: > : ffffffff ffffffff ffffffff ffffffff
: > : ffffffff ffffffff ffffffff ffffffff
: > : ffffffff ffffffff ffffffff ffffffff
: > : ffffffff ffffffff ffffffff ffffffff
: > : ffffffff ffffffff ffffffff ffffffff
: > : ffffffff ffffffff ffffffff ffffffff
: > : ffffffff ffffffff ffffffff ffffffff
: > : ffffffff ffffffff ffffffff ffffffff
: > : ffffffff ffffffff ffffffff ffffffff
: >
: > OK. So FreeBSD is definitely not seeing this device at all. Yet
the
: > listing from Linux clearly shows that the device is there.
:
: Aham... And now? Can I help you? Sorry for the "printf" suggestion,
but
: my C level is so poor... :-/
OK. I've taken a look. I'm thinking that there may be an issue with
the i386 config register reading. src/sys/i386/pci/pci_cfgreg.c, look
at pcireg_cfg{read,write} may be in error. you might try switching
the inb/inw/outb/outw to inl/outl with masking. It likely won't
matter, but it is worth a shot.
===================================================================
Because my programming skills are very very poor, I'm only capable to
help testing and reporting, but I would like to deinstall the Linux from
laptop and install a FreeBSD.
Thank you very much!!
--
\|/ ____ \|/
Have a nice day ;-) "@'/ ,. \'@"
TooManySecrets /_| \__/ |_\
\__U_/
BSD is what you get when a bunch of Unix hackers sit down to try to port
a Unix system to the PC. Linux is what you get when a bunch of PC
hackers sit down and try to write a Unix system for the PC
------------------------------
Message: 17
Date: Thu, 5 Aug 2004 12:51:19 +0300
From: Ilker OZUPAK <ilker....@emu.edu.tr>
Subject: ad0 / ad1 wierdness
To: freebsd...@freebsd.org
Message-ID: <200408051251.35...@emu.edu.tr>
Content-Type: Text/Plain; charset="us-ascii"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello list,
I am fallowing -current through CTM (current at 6439).
I recently tried installing a ide disk for short time to take
backups on it. and to do so i unplugged my ide cdrom
connected to primary ide as slave and plugged in the hd
as primary slave (keeping hd's config) even bios detected hd
it did not get recognized by the system.
when I changed it to master it got detected.
Is there a must to have a pri. master? OR
shouldn't stand alone pri. slave got detected?
my system is installed on scsi...
- --
IO
pgp key @ http://www.emu.edu.tr/ilker/ilker.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFBEgMgvxSBSqT0G9ARAu6NAKCjDDOUVYFlyc0SOn6J9RY1CBPuogCgxAwV
3EgCxw1HtlCw1+jIGhC1ALg=
=udX0
-----END PGP SIGNATURE-----
------------------------------
Message: 18
Date: Thu, 5 Aug 2004 13:13:31 +0300
From: Ilker OZUPAK <ilker....@emu.edu.tr>
Subject: acpi problem
To: freebsd...@freebsd.org
Message-ID: <200408051313.53...@emu.edu.tr>
Content-Type: Text/Plain; charset="us-ascii"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hello list,
i am fallowing current through ctm.
After last update (to src-cur 6439)to my system it started giving an error
for acpi .
dmesg output and kernel config is attached.
modules loaded -- sound, acpi, linux, snd_es137x
- --
IO
gpg key @ http://www.emu.edu.tr/ilker/ilker.asc
- -- dmesg output --
Copyright (c) 1992-2004 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.2-CURRENT #0: Mon Aug 2 18:27:21 EEST 2004
ro...@eniac.emu.edu.tr:/usr/obj/usr/src/sys/eniac4
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Pentium II/Pentium II Xeon/Celeron (350.80-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x652 Stepping = 2
Features=0x183f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR>
real memory = 268369920 (255 MB)
avail memory = 257126400 (245 MB)
npx0: [FAST]
npx0: <math processor> on motherboard
npx0: INT 16 interface
acpi0: <QDIQDI AWRDACPI> on motherboard
ACPI-0290: *** Error: Return object type is incorrect
[\\_SB_.PCI0.ISA_.UAR1._PRW] (Node 0xc11a46a0)
, AE_TYPE
acpi0: [GIANT-LOCKED]
acpi0: Power Button (fixed)
can't fetch resources for \\_SB_.PCI0.ISA_.PS2M - AE_BAD_DATA
Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0
cpu0: <ACPI CPU (3 Cx states)> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0x5000-0x500f,0x4000-0x4041,0xcf8-0xcff on
acpi0
pci0: <ACPI PCI bus> on pcib0
agp0: <Intel 82443BX (440 BX) host to PCI bridge> mem 0xea000000-0xeaffffff at
device 0.0 on pci0
pcib1: <PCI-PCI bridge> at device 1.0 on pci0
...
- -- dmesg output ends --
- -- kern config - comments cleared --
machine i386
cpu I686_CPU
ident eniac4
options SCHED_ULE
options INET
options FFS
options SOFTUPDATES
options UFS_ACL
options UFS_DIRHASH
options MD_ROOT
options NFSCLIENT
options NFSSERVER
options NFS_ROOT
options MSDOSFS
options CD9660
options PROCFS
options PSEUDOFS
options GEOM_GPT
options COMPAT_43
options COMPAT_FREEBSD4
options SCSI_DELAY=15000
options KTRACE
options SYSVSHM
options SYSVMSG
options SYSVSEM
options _KPOSIX_PRIORITY_SCHEDULING
options KBD_INSTALL_CDEV
options AHC_REG_PRETTY_PRINT
options AHD_REG_PRETTY_PRINT
options PFIL_HOOKS
options IBCS2
options COMPAT_LINUX
options COMPAT_AOUT
options LINPROCFS
device isa
device eisa
device pci
device fdc
device ata
device atadisk
device atapicd
device atapifd
device atapist
options ATA_STATIC_ID
device ahc
device ahd
# SCSI peripherals
device scbus
device ch
device da
device sa
device cd
device pass
device ses
# atkbdc0 controls both the keyboard and the PS/2 mouse
device atkbdc
device atkbd
device psm
device vga
device splash
# syscons is the default console driver, resembling an SCO console
device sc
# Enable this for the pcvt (VT220 compatible) console driver
#device vt
#options XSERVER # support for X server on a vt console
#options FAT_CURSOR # start with block cursor
device agp # support several AGP chipsets
# Floating point support - do not disable.
device npx
device apm
device pmtimer
device cbb
device pccard
device cardbus
device sio
device ppc
device ppbus
device lpt
device ppi
device miibus
device ed
device random
device loop
device ether
device tun
device pty
device md
device bpf
# USB support
device uhci
device ohci
device usb
#device udbp
device ugen
device uhid
device ukbd
device ulpt
device umass
device ums
device uscanner
- -- kern conf. ends --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFBEghUvxSBSqT0G9ARAjaPAJsFOBtfUXrjNgmdX8RcAjhH2t/zmwCgnwu6
NnmxyxsqLa4T3rlC4ZRqv94=
=3pLV
-----END PGP SIGNATURE-----
------------------------------
Message: 19
Date: Thu, 5 Aug 2004 12:24:26 +0200
From: Michael Nottebrock <michaeln...@gmx.net>
Subject: Re: Ports broken by compiler upgrade
To: freebsd...@FreeBSD.org
Cc: Pete Carah <pe...@altadena.net>
Message-ID: <200408051224.30230...@gmx.net>
Content-Type: text/plain; charset="iso-8859-1"
On Thursday 05 August 2004 07:56, Pete Carah wrote:
> Many ports that compile in C++ are broken by the recent
> compiler upgrade; the packages distribution hasn't caught
> up *at all* either.
Yes, as usual the packages on the mirrors are lagging behind (and additionally
our guy who uploads them is on holiday :-)).
> Two examples, artsd and aspell both abort instantly with
> undefined symbols; either the name-mangling has changed
Yes. Symbol name-mangling has definitely changed, you're in for a complete
recompile of all things C++ - or wait for updated packages to become
available.
However, since the libxine fix has been committed yesterday, KDE's dependency
path is now completely clear again - all of KDE builds fine, except KOffice
(which will be updated to 1.3.2 tomorrow, which builds fine). Also
kdemultimedia has been reported to not build with optimization higher than
-O, I'm currently testing a fix. I'm planning to do a real big commit to many
KDE ports tomorrow, accompanied by new packages on fruitsalad - stay tuned.
--
,_, | Michael Nottebrock | lo...@freebsd.org
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: signature
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20040805/631291bd/attachment-0001.bin
------------------------------
Message: 20
Date: Thu, 05 Aug 2004 12:34:11 +0200
From: "Poul-Henning Kamp" <p...@phk.freebsd.dk>
Subject: Re: Ports broken by compiler upgrade
To: Michael Nottebrock <michaeln...@gmx.net>
Cc: freebsd...@freebsd.org
Message-ID: <74452.10...@critter.freebsd.dk>
There is a new 1.0d coming of mail/annoyance-filter, I just reported
successful compilation to the author.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
------------------------------
Message: 21
Date: Thu, 5 Aug 2004 12:39:56 +0200
From: Divacky Roman <xdiv...@stud.fit.vutbr.cz>
Subject: Re: problems with altq
To: freebsd...@freebsd.org
Message-ID: <20040805103...@stud.fit.vutbr.cz>
Content-Type: text/plain; charset=us-ascii
On Wed, Aug 04, 2004 at 04:15:55PM +0300, Dan Cojocar wrote:
> On Wed, 4 Aug 2004 14:56:40 +0200, Divacky Roman
> <xdiv...@stud.fit.vutbr.cz> wrote:
> > I am getting this
> > pfctl: DIOCADDALTQ: Cannot allocate memory
> > if I try to enable altq on pf configured as
> >
> > altq on $ext_if bandwidth 256Kb cbq queue { ssh_i web other}
> > queue ssh_i bandwidth 25% cbq(borrow red)
> > queue web bandwidth 25% cbq(borrow red)
> > queue other bandwidth 50% cbq(borrow default red)
> >
> > without that "red" it works ok...
> Hi,
> I'm using red too, and i don't have that problem.
> I tested your config and it's working here:
> 5.2-CURRENT FreeBSD 5.2-CURRENT #4: Tue Aug 3 12:16:27 EEST 2004
> What driver are you using?
vr
------------------------------
Message: 22
Date: Thu, 5 Aug 2004 12:50:48 +0200
From: Divacky Roman <xdiv...@stud.fit.vutbr.cz>
Subject: Re: problems with altq
To: Max Laier <m...@love2party.net>
Cc: freebsd...@freebsd.org
Message-ID: <20040805105...@stud.fit.vutbr.cz>
Content-Type: text/plain; charset=us-ascii
On Wed, Aug 04, 2004 at 08:03:00PM +0200, Max Laier wrote:
> On Wednesday 04 August 2004 15:05, Divacky Roman wrote:
> > struct pf_altq *altq, *a;
> >
> > if (pa->ticket != ticket_altqs_inactive) {
> > error = EBUSY;
> > break;
> > }
> > altq = pool_get(&pf_altq_pl, PR_NOWAIT);
> > ^^^^^^^^^^
> > shouldnt this be initalized to NULL? at least its not nice to have it
> > uninitalized...
>
> hum?
> $ cd /usr/src/sys/contrib/pf/net && grep pf_altq_pl *
> <...>
> pf_ioctl.c: pf_state_pl = pf_altq_pl = pf_pooladdr_pl = NULL;
> pf_ioctl.c: UMA_DESTROY(pf_altq_pl);
> pf_ioctl.c: UMA_CREATE(pf_altq_pl, struct pf_altq, "pfaltqpl");
> <...>
>
> Or what are you thinking about?
pf/net/pf_ioctl.c:2032 and below
hm... I got it wrong. I looked at it again and I changed type with variable
name ;(
hysteria.sk/~neologism/NEOLOGISM is my kernel config
hysteria.sk/~neologism/pf.conf is my whole pf config
I am compiling kernel with -Os (I know its not supported) I'll try with plain
-O
btw: why does the malloc has to be NOWAIT?
> Just like Dan Cojocar said in his reply, I can't reproduce your problem
> here :-\
I can provide you any information you'll ask for
> > On Wed, Aug 04, 2004 at 02:56:40PM +0200, Divacky Roman wrote:
> > > I am getting this
> > > pfctl: DIOCADDALTQ: Cannot allocate memory
> > > if I try to enable altq on pf configured as
> > >
> > > altq on $ext_if bandwidth 256Kb cbq queue { ssh_i web other}
> > > queue ssh_i bandwidth 25% cbq(borrow red)
> > > queue web bandwidth 25% cbq(borrow red)
> > > queue other bandwidth 50% cbq(borrow default red)
> > >
> > >
> > > without that "red" it works ok...
>
> Now that is strange as it makes no difference in the DIOCADDALTQ call path
> whether you use RED or not. Might it be possible that you really are short on
> (kernel) memory?
vm.kvm_free: 562032640
vm.kvm_size: 1073737728
witten ~# vmstat
procs memory page disks faults cpu
r b w avm fre flt re pi po fr sr ad0 ad1 in sy cs us sy id
1 1 0 124936 189072 10 0 0 0 8 0 0 0 903 1010 1733 2 2
96
witten ~# /etc/rc.d/pf restart
Disabling pf.
pf disabled
Enabling pf.
pfctl: DIOCADDALTQ: Cannot allocate memory
pf enabled
witten ~#
if this is what I think it is I should have enough kernel memory, shouldnt I?
roman
------------------------------
Message: 23
Date: Thu, 5 Aug 2004 13:16:37 +0200
From: Divacky Roman <xdiv...@stud.fit.vutbr.cz>
Subject: Re: problems with altq
To: Max Laier <m...@love2party.net>
Cc: freebsd...@freebsd.org
Message-ID: <20040805111...@stud.fit.vutbr.cz>
Content-Type: text/plain; charset=us-ascii
On Thu, Aug 05, 2004 at 12:50:48PM +0200, Divacky Roman wrote:
> On Wed, Aug 04, 2004 at 08:03:00PM +0200, Max Laier wrote:
> > On Wednesday 04 August 2004 15:05, Divacky Roman wrote:
> > > struct pf_altq *altq, *a;
> > >
> > > if (pa->ticket != ticket_altqs_inactive) {
> > > error = EBUSY;
> > > break;
> > > }
> > > altq = pool_get(&pf_altq_pl, PR_NOWAIT);
> > > ^^^^^^^^^^
> > > shouldnt this be initalized to NULL? at least its not nice to have it
> > > uninitalized...
> >
> > hum?
> > $ cd /usr/src/sys/contrib/pf/net && grep pf_altq_pl *
> > <...>
> > pf_ioctl.c: pf_state_pl = pf_altq_pl = pf_pooladdr_pl = NULL;
> > pf_ioctl.c: UMA_DESTROY(pf_altq_pl);
> > pf_ioctl.c: UMA_CREATE(pf_altq_pl, struct pf_altq, "pfaltqpl");
> > <...>
> >
> > Or what are you thinking about?
>
> pf/net/pf_ioctl.c:2032 and below
>
> hm... I got it wrong. I looked at it again and I changed type with variable
> name ;(
>
> hysteria.sk/~neologism/NEOLOGISM is my kernel config
> hysteria.sk/~neologism/pf.conf is my whole pf config
>
> I am compiling kernel with -Os (I know its not supported) I'll try with plain
> -O
>
> btw: why does the malloc has to be NOWAIT?
kernel compiled with -O and M_WAITOK doesnt help either
------------------------------
Message: 24
Date: Thu, 5 Aug 2004 13:50:01 +0200
From: Divacky Roman <xdiv...@stud.fit.vutbr.cz>
Subject: Re: problems with altq
To: Max Laier <m...@love2party.net>
Cc: freebsd...@freebsd.org
Message-ID: <20040805115...@stud.fit.vutbr.cz>
Content-Type: text/plain; charset=us-ascii
On Thu, Aug 05, 2004 at 01:16:37PM +0200, Divacky Roman wrote:
> On Thu, Aug 05, 2004 at 12:50:48PM +0200, Divacky Roman wrote:
> > On Wed, Aug 04, 2004 at 08:03:00PM +0200, Max Laier wrote:
> > > On Wednesday 04 August 2004 15:05, Divacky Roman wrote:
> > > > struct pf_altq *altq, *a;
> > > >
> > > > if (pa->ticket != ticket_altqs_inactive) {
> > > > error = EBUSY;
> > > > break;
> > > > }
> > > > altq = pool_get(&pf_altq_pl, PR_NOWAIT);
> > > > ^^^^^^^^^^
> > > > shouldnt this be initalized to NULL? at least its not nice to have it
> > > > uninitalized...
> > >
> > > hum?
> > > $ cd /usr/src/sys/contrib/pf/net && grep pf_altq_pl *
> > > <...>
> > > pf_ioctl.c: pf_state_pl = pf_altq_pl = pf_pooladdr_pl = NULL;
> > > pf_ioctl.c: UMA_DESTROY(pf_altq_pl);
> > > pf_ioctl.c: UMA_CREATE(pf_altq_pl, struct pf_altq, "pfaltqpl");
> > > <...>
> > >
> > > Or what are you thinking about?
> >
> > pf/net/pf_ioctl.c:2032 and below
> >
> > hm... I got it wrong. I looked at it again and I changed type with variable
> > name ;(
> >
> > hysteria.sk/~neologism/NEOLOGISM is my kernel config
> > hysteria.sk/~neologism/pf.conf is my whole pf config
> >
> > I am compiling kernel with -Os (I know its not supported) I'll try with plain
> > -O
> >
> > btw: why does the malloc has to be NOWAIT?
>
> kernel compiled with -O and M_WAITOK doesnt help either
the problem is that I didnt have
ALTQ_RED in my kernel config (thnx Pyun YongHyeon)
should it be announced a more friendly way?
roman
------------------------------
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
End of freebsd-current Digest, Vol 71, Issue 13
***********************************************