freebsd-current Digest, Vol 71, Issue 14
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: [PLEASE TEST] Better support for Synaptics Touchpads
(Arne Schwabe)
2. pthread_cond_wait failed (ngl)
3. Re: HEADS UP! boot2 problems (Scott Long)
4. [current tinderbox] failure on i386/pc98 (FreeBSD Tinderbox)
5. Re: Instant Reboots (was: Re: Postgresql locks up server - no
response at all) (Geoff Speicher)
6. Re: kernel build error (Robert Watson)
7. panic: mutex inp not owned at
/usr/src/sys/netinet/tcp_output.c:140 (Jun Kuriyama)
8. Re: So much entropy it's coming out of our ears? (Robert Watson)
9. bootable image problem (Sergey Lyubka)
10. Re: panic: mutex inp not owned at
/usr/src/sys/netinet/tcp_output.c:140 (Robert Watson)
11. Re: pthread_cond_wait failed (Daniel Eischen)
12. Re: No new snapshot of 5-CURRENT anymore? (CHOI Junho)
13. fyi: snap from 080404 will not boot 'no /boot/loader' (Kim Culhan)
14. Re: Unable to build recent kernels (Mark Murray)
15. Re: Unable to build recent kernels (Mark Murray)
16. Re: radeon.ko doesn't load on recent current (Toxa)
17. /dev/vga (Paul Richards)
18. Re: Challenge getting touchpad to work since
src/sys/isa/psm.c 1.71 (Arne Schwabe)
19. Re: kernel build error (Mark Murray)
20. Re: So much entropy it's coming out of our ears? (Mark Murray)
21. gvinum resetconfig (Shaun Courtney)
22. Re: Unable to build recent kernels (Alexandre "Sunny" Kovalenko)
23. Re: Challenge getting touchpad to work since
src/sys/isa/psm.c 1.71 (Alexandre "Sunny" Kovalenko)
24. xmms crashes CURRENT (Gleb Smirnoff)
25. Re: /dev/vga (Robert Watson)
26. [current tinderbox] failure on powerpc/powerpc (FreeBSD Tinderbox)
27. Re: panic: mutex inp not owned at
/usr/src/sys/netinet/tcp_output.c:140 (Jun Kuriyama)
28. Re: [PLEASE TEST] Better support for Synaptics Touchpads
(Alexandre "Sunny" Kovalenko)
29. Re: So much entropy it's coming out of our ears? (Richard Coleman)
30. Re: /dev/vga (Gleb Smirnoff)
31. Re: USB drivers (Chris)
32. Re: panic: mutex inp not owned at
/usr/src/sys/netinet/tcp_output.c:140 (Robert Watson)
33. Re: [PLEASE TEST] Better support for Synaptics Touchpads
(Maxim Maximov)
34. Re: panic: mutex inp not owned at
/usr/src/sys/netinet/tcp_output.c:140 (Jun Kuriyama)
----------------------------------------------------------------------
Message: 1
Date: Thu, 05 Aug 2004 14:38:21 +0200
From: Arne Schwabe <ar...@rfc2549.org>
Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads
To: freebsd...@freebsd.org
Message-ID: <86vffx6...@kamino.rfc1149.org>
Content-Type: text/plain; charset=us-ascii
Philip Paeps <phi...@freebsd.org> writes:
> 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...
Well the programmers of the XFree86 Driver did do that guesswork or
had better documentation.
Arne
--
compiling millions of tiny c-programs...done
checking for a working configure script... not found
------------------------------
Message: 2
Date: Thu, 5 Aug 2004 18:40:13 +0600
From: "ngl" <n...@ur.ru>
Subject: pthread_cond_wait failed
To: <cur...@freebsd.org>
Message-ID: <0d4801c47ae9$5a9a5950$0202000a@spirit>
Content-Type: text/plain; charset="koi8-r"
Hello all
I'm using pcap and c_r libraries under FreeBSD 5.2.1-p9.
I have faced a problem, when one thread call pthread_cond_wait function,
i get 'Segmentation fault (core dumped)' message.
Here is the dump:
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" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
(gdb) core test.core
Core was generated by `test'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.5...done.
Loaded symbols for /lib/libc.so.5
Reading symbols from /usr/lib/libc_r.so.5...done.
Loaded symbols for /usr/lib/libc_r.so.5
Reading symbols from /usr/lib/libpcap.so.2...done.
Loaded symbols for /usr/lib/libpcap.so.2
Reading symbols from /usr/libexec/ld-elf.so.1...done.
Loaded symbols for /usr/libexec/ld-elf.so.1
#0 0x28159ef9 in _atomic_lock () from /usr/lib/libc_r.so.5
(gdb) bt
#0 0x28159ef9 in _atomic_lock () from /usr/lib/libc_r.so.5
#1 0x28159da9 in _spinlock () from /usr/lib/libc_r.so.5
#2 0x2815fbd2 in _mutex_cv_lock () from /usr/lib/libc_r.so.5
#3 0x2815fa79 in _mutex_cv_unlock () from /usr/lib/libc_r.so.5
#4 0x2816488f in _pthread_cond_wait () from /usr/lib/libc_r.so.5
#5 0x281649ee in pthread_cond_wait () from /usr/lib/libc_r.so.5
#6 0x280bcf35 in pthread_cond_wait () from /lib/libc.so.5
#7 0x08049486 in printThread (pv=0x0) at test.c:67
#8 0x2815842e in _thread_start () from /usr/lib/libc_r.so.5
regards,
Nik
------------------------------
Message: 3
Date: Thu, 05 Aug 2004 06:53:02 -0600
From: Scott Long <sco...@samsco.org>
Subject: Re: HEADS UP! boot2 problems
To: Alexander Kabaev <k...@FreeBSD.org>
Cc: FreeBSD Current List <cur...@FreeBSD.org>
Message-ID: <41122DAE...@samsco.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Alexander Kabaev wrote:
> 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.
Thanks!
Scott
------------------------------
Message: 4
Date: Thu, 5 Aug 2004 08:55:34 -0400 (EDT)
From: FreeBSD Tinderbox <tind...@freebsd.org>
Subject: [current tinderbox] failure on i386/pc98
To: FreeBSD Tinderbox <tind...@freebsd.org>, <cur...@freebsd.org>,
<i3...@freebsd.org>
Message-ID: <200408051255...@freebsd-current.sentex.ca>
TB --- 2004-08-05 11:54:25 - tinderbox 2.3 running on freebsd-current.sentex.ca
TB --- 2004-08-05 11:54:25 - starting CURRENT tinderbox run for i386/pc98
TB --- 2004-08-05 11:54:25 - checking out the source tree
TB --- 2004-08-05 11:54:25 - cd /home/tinderbox/sandbox/CURRENT/i386/pc98
TB --- 2004-08-05 11:54:25 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2004-08-05 12:00:12 - building world (CFLAGS=-O -pipe)
TB --- 2004-08-05 12:00:12 - cd /home/tinderbox/sandbox/CURRENT/i386/pc98/src
TB --- 2004-08-05 12:00:12 - /usr/bin/make -B buildworld
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
TB --- 2004-08-05 12:50:05 - building generic kernel (COPTFLAGS=-O -pipe)
TB --- 2004-08-05 12:50:05 - cd /home/tinderbox/sandbox/CURRENT/i386/pc98/src
TB --- 2004-08-05 12:50:05 - /usr/bin/make buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Thu Aug 5 12:50:05 UTC 2004
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
mem.o(.text+0x2ab): In function `memioctl':
/tinderbox/CURRENT/i386/pc98/src/sys/i386/i386/mem.c:188: undefined reference to `mem_range_attr_get'
mem.o(.text+0x2e9):/tinderbox/CURRENT/i386/pc98/src/sys/i386/i386/mem.c:195: undefined reference to `mem_range_softc'
mem.o(.text+0x325):/tinderbox/CURRENT/i386/pc98/src/sys/i386/i386/mem.c:206: undefined reference to `mem_range_attr_set'
mem.o(.text+0x351): In function `dev_mem_md_init':
/tinderbox/CURRENT/i386/pc98/src/sys/i386/i386/mem.c:216: undefined reference to `mem_range_softc'
mem.o(.text+0x359):/tinderbox/CURRENT/i386/pc98/src/sys/i386/i386/mem.c:217: undefined reference to `mem_range_softc'
mem.o(.text+0x35e):/tinderbox/CURRENT/i386/pc98/src/sys/i386/i386/mem.c:217: undefined reference to `mem_range_softc'
*** Error code 1
Stop in /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC.
*** Error code 1
Stop in /tinderbox/CURRENT/i386/pc98/src.
*** Error code 1
Stop in /tinderbox/CURRENT/i386/pc98/src.
TB --- 2004-08-05 12:55:34 - WARNING: /usr/bin/make returned exit code 1
TB --- 2004-08-05 12:55:34 - ERROR: failed to build generic kernel
TB --- 2004-08-05 12:55:34 - tinderbox aborted
------------------------------
Message: 5
Date: Thu, 5 Aug 2004 09:16:28 -0400
From: Geoff Speicher <ge...@speicher.org>
Subject: Re: Instant Reboots (was: Re: Postgresql locks up server - no
response at all)
To: Eric Anholt <e...@lclark.edu>
Cc: Scott Long <sco...@freebsd.org>
Message-ID: <20040805131...@sirius.speicher.org>
Content-Type: text/plain; charset=us-ascii
On Wed, Aug 04, 2004 at 03:26:13PM -0700, Eric Anholt wrote:
> On Wed, 2004-08-04 at 15:07, Geoff Speicher wrote:
> > On Wed, Aug 04, 2004 at 03:34:49PM -0600, Scott Long wrote:
> > > Geoff Speicher wrote:
> > >
> > > >FWIW, in mid-late July, my problems were not PREEMPTION-related. I
> > > >tried everything I could to get usable threaded apps under XFree86, but
> > > >my Athlon XP rebooted every time I tried to run kdm, Firefox, etc.
> > > >
> > > >This included all four combinations of PREEMPTION and ULE/4BSD. Rolling
> > > >back to July 1 was the only thing that worked for me.
> > >
> > > Yeah, the instant reboots have hit me too. Disabling PREEMPTION did
> > > seem to help this for me, but then it might have been a coincidence.
> > > Incidentally, what video drivers are you using?
> >
> > Snippets from /var/log/XFree86.0.log:
> >
> > (II) ATI: ATI driver (version 6.4.18) for chipsets: ati, ativga
> > (--) RADEON(0): Chipset: "ATI Radeon VE/7000 QY (AGP)" (ChipID = 0x5159)
> > (II) Loading /usr/X11R6/lib/modules/drivers/radeon_drv.o
> > (II) Module radeon: vendor="The XFree86 Project"
> > compiled for 4.3.0, module version = 4.0.1
> > Module class: XFree86 Video Driver
> > ABI class: XFree86 Video Driver, version 0.6
> >
> > (II) RADEON(0): [drm] loaded kernel module for "radeon" driver
> > (II) RADEON(0): Direct rendering enabled
>
> Does this happen without using threaded apps? More specifically, does
> it continue if you disable DRI in your X config? If so, please send me
> your dmesg.
Hey, disabling DRI did the trick. Aside from things being remarkably
slow, it's remarkably stable. ;) Threaded X apps or no, I'm running
a July 19 kernel with no instant reboots. PREEMPTION disabled,
WITNESS enabled (I misspoke in another message when I said WITNESS was
disabled---apparently I fiddled more than I had remembered). Toggling
DRI back on and restarting X/kdm reboots immediately.
Geoff
------------------------------
Message: 6
Date: Thu, 5 Aug 2004 09:17:33 -0400 (EDT)
From: Robert Watson <rwa...@FreeBSD.ORG>
Subject: Re: kernel build error
To: Mark Murray <ma...@grondar.org>
Cc: FreeBSD Current <freebsd...@FreeBSD.ORG>
Message-ID:
<Pine.NEB.3.96L.104080...@fledge.watson.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 5 Aug 2004, Mark Murray wrote:
> Robert Watson writes:
> >
> > 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.
> >
> > I've committed this change and things now appear to build. Might take a
> > couple of minutes to propagate to cvsup, etc.
>
> Thanks Robert. Colour me very confused. :-)
>
> I built 4 cases in testing; SMP/UP cross Module/NoModule. All worked.
>
> What did I miss?
I'm not sure what the UP above refers to, but the case I bumped into was
building a GENERIC kernel with "options SMP" and "device apic" removed
from the configuration file. The kernel failed to link due to the missing
softc symbol from mp_machdep.c, which is only compiled into kernels with
"options SMP". I've not yet caught up on e-mail, so I've not yet seen if
you've seen, but I sent a follow-up message in which I observe the same
problem in non-i386 trees, which will also need to be fixed.
For benchmarking purposes, I build UP kernels without "options SMP" or
"device apic" for performance reasons.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
rob...@fledge.watson.org Principal Research Scientist, McAfee Research
------------------------------
Message: 7
Date: Thu, 05 Aug 2004 22:19:44 +0900
From: Jun Kuriyama <kuri...@imgsrc.co.jp>
Subject: panic: mutex inp not owned at
/usr/src/sys/netinet/tcp_output.c:140
To: Current <freebsd...@FreeBSD.org>
Message-ID: <7mvffx...@black.imgsrc.co.jp>
Content-Type: text/plain; charset=US-ASCII
This is "2004-08-05 00:35:00 UTC"'s kernel. (Just before rwatson's
bpf commit)
panic: mutex inp not owned at /usr/src/sys/netinet/tcp_output.c:140
cpuid = 1;
KDB: enter: panic
[thread 100037]
Stopped at kdb_enter+0x2b: nop
db>
trace
kdb_enter(c067821c) at kdb_enter+0x2b
panic(c06776f7,c0686c6a,c06839c5,8c,578) at panic+0x131
_mtx_assert(c3b074c8,1,c06839c5,8c,de94b9e4,c) at _mtx_assert+0x5c
tcp_output(c41fa540) at tcp_output+0x5d
tcp_mtudisc(c3b07438,28) at tcp_mtudisc+0x17f
in6_pcbnotify(c070bfac,de94bbb0,504,de94bbd0,5000) at in6_pcbnotify+0x1d6
tcp6_ctlinput(5,de94bbb0,de94bb80) at tcp6_ctlinput+0xf0
icmp6_notify_error(c3eff500,28,4d8,5) at icmp6_notify_error+0x70e
icmp6_input(de94bcd4,de94bc74,3a,0,3a) at icmp6_input+0xc14
ip6_input(c3eff500) at ip6_input+0xd22
netisr_processqueue(c070af44) at netisr_processqueue+0x6e
swi_net(0) at swi_net+0x88
ithread_loop(c345fc80,de94bd48,c345fc80,c04dcecc,0) at ithread_loop+0x124
fork_exit(c04dcecc,c345fc80,de94bd48) at fork_exit+0xa4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xde94bd7c, ebp = 0 ---
--
Jun Kuriyama <kuri...@imgsrc.co.jp> // IMG SRC, Inc.
<kuri...@FreeBSD.org> // FreeBSD Project
------------------------------
Message: 8
Date: Thu, 5 Aug 2004 09:24:37 -0400 (EDT)
From: Robert Watson <rwa...@FreeBSD.ORG>
Subject: Re: So much entropy it's coming out of our ears?
To: Mark Murray <ma...@grondar.org>
Cc: Sam Leffler <s...@errno.com>
Message-ID:
<Pine.NEB.3.96L.104080...@fledge.watson.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 5 Aug 2004, Mark Murray wrote:
> Sam Leffler writes:
> > 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.
>
> Yarrow is not conducive to "water-mark" type flow-control, but I'm
> looking at replacing Yarrow with Fortuna (code at an advanced stage).
> This should improve things all-round.
Could we do the rate limiting on the sender side, then, by making a
guestimate at a maximum useful entropy rate? I.e., if we think that a
system getting entropy from 20 ethernet packets a second has enough
entropy to operate safely, there's presumably not all that much
incremental benefit to 20,000 ethernet packets a second getting fed to
yarrow (with the corresponding 80,0000 mutex operations in the interrupt
path). If so, we can simply have a counter of some sort that cheaply
tracks how much entropy has been gathered and inhibits gathering once a
threshold is reached, with the counter reset by a callout once in a while?
This would avoid the need to introduce a replacement PRNG implementation,
which is (I assume) unlikely to happen in the next two weeks, but allow us
to avoid the cost today (it's not cheap).
I.e., add a "entropy_gathered" int that uses a unlocked read to test for
non-zero, and is decremented while holding one of the harvesting mutexes
if it's non-zero. Reset it in a callout a few times a second, and set it
to some small value, like 4. This will result in the gathering of some
entropy each second, but not so much that it seriously hits the packet
delivery path in higher workloads.
Similarly, Max makes the suggestion that we can afford weaker
synchronization for gathered entropy. This strikes me as a reasonable
idea, although I haven't given a mechanism much thought as yet.
> > Everything that goes on inside the PRNG is a separate issue.
>
> *nod*
Other than observing the per-packet mutex operations that can be coalesced
when pulling harvested entropy off the harvesting fifos, I haven't made
any attempt to dig into the /dev/random yarrow code yet. So much code, so
little time... :-)
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
rob...@fledge.watson.org Principal Research Scientist, McAfee Research
------------------------------
Message: 9
Date: Thu, 5 Aug 2004 16:39:46 +0300
From: Sergey Lyubka <dev...@uptsoft.com>
Subject: bootable image problem
To: freebsd...@freebsd.org
Message-ID: <2004080516...@oasis.uptsoft.com>
Content-Type: text/plain; charset=us-ascii
I am trying to create an bootable image, this is a script
that does the job:
==== cut here
MD=/dev/md0
dd if=/dev/zero of=img count=8 bs=1m 2>/dev/null
mdconfig -a -t vnode -u 0 -f img
bsdlabel -Bw $MD
bsdlabel $MD | sed -e '/ c:/{p;s/c:/a:/;}' | bsdlabel -R $MD /dev/stdin
newfs -m 0 -o space -f 512 -b 4096 ${MD}a > /dev/null
mkdir dsk
mount ${MD}a `pwd`/dsk
trap "umount ${MD}a ; mdconfig -d -u 0; rm -rf dsk; " EXIT
cp /boot/kernel/kernel dsk/kernel
mkdir dsk/boot
cp /boot/loader* dsk/boot/
===== cut here
Booting this image with qemu, I see this:
FreeBSD/i386 boot
Default: 0:ad(0,a)/boot/loader
boot: No /boot/loader
Trying to boot /kernel, I see this:
boot: error 12 lba 1008
Invalid format
Any hints ?
------------------------------
Message: 10
Date: Thu, 5 Aug 2004 09:43:41 -0400 (EDT)
From: Robert Watson <rwa...@FreeBSD.org>
Subject: Re: panic: mutex inp not owned at
/usr/src/sys/netinet/tcp_output.c:140
To: Jun Kuriyama <kuri...@imgsrc.co.jp>
Cc: Current <freebsd...@FreeBSD.org>
Message-ID:
<Pine.NEB.3.96L.104080...@fledge.watson.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 5 Aug 2004, Jun Kuriyama wrote:
>
> This is "2004-08-05 00:35:00 UTC"'s kernel. (Just before rwatson's
> bpf commit)
>
>
> panic: mutex inp not owned at /usr/src/sys/netinet/tcp_output.c:140
Could you try the attached patch? This modifies the IPv6 code to match
the IPv4 code in passing in the "inpcbinfo" reference for a protocol,
rather than just its inpcb list. This allows in6_pcbnotify() to lock the
structure before walking it. It also acquires the per-pcb locks before
notifying each pcb of an event.
Sorry about the panic!
Index: in6_pcb.c
===================================================================
RCS file: /home/ncvs/src/sys/netinet6/in6_pcb.c,v
retrieving revision 1.57
diff -u -r1.57 in6_pcb.c
--- in6_pcb.c 28 Jul 2004 13:03:07 -0000 1.57
+++ in6_pcb.c 5 Aug 2004 13:42:44 -0000
@@ -610,8 +610,8 @@
* Must be called at splnet.
*/
void
-in6_pcbnotify(head, dst, fport_arg, src, lport_arg, cmd, cmdarg, notify)
- struct inpcbhead *head;
+in6_pcbnotify(pcbinfo, dst, fport_arg, src, lport_arg, cmd, cmdarg, notify)
+ struct inpcbinfo *pcbinfo;
struct sockaddr *dst;
const struct sockaddr *src;
u_int fport_arg, lport_arg;
@@ -619,6 +619,7 @@
void *cmdarg;
struct inpcb *(*notify) __P((struct inpcb *, int));
{
+ struct inpcbhead *head;
struct inpcb *inp, *ninp;
struct sockaddr_in6 sa6_src, *sa6_dst;
u_short fport = fport_arg, lport = lport_arg;
@@ -656,11 +657,16 @@
}
errno = inet6ctlerrmap[cmd];
s = splnet();
+ head = pcbinfo->listhead;
+ INP_INFO_WLOCK(pcbinfo);
for (inp = LIST_FIRST(head); inp != NULL; inp = ninp) {
+ INP_LOCK(inp);
ninp = LIST_NEXT(inp, inp_list);
- if ((inp->inp_vflag & INP_IPV6) == 0)
+ if ((inp->inp_vflag & INP_IPV6) == 0) {
+ INP_UNLOCK(inp);
continue;
+ }
/*
* If the error designates a new path MTU for a destination
@@ -698,13 +704,17 @@
(!IN6_IS_ADDR_UNSPECIFIED(&sa6_src.sin6_addr) &&
!IN6_ARE_ADDR_EQUAL(&inp->in6p_laddr,
&sa6_src.sin6_addr)) ||
- (fport && inp->inp_fport != fport))
+ (fport && inp->inp_fport != fport)) {
+ INP_UNLOCK(inp);
continue;
+ }
do_notify:
if (notify)
(*notify)(inp, errno);
+ INP_UNLOCK(inp);
}
+ INP_INFO_WUNLOCK(pcbinfo);
splx(s);
}
Index: in6_pcb.h
===================================================================
RCS file: /home/ncvs/src/sys/netinet6/in6_pcb.h,v
retrieving revision 1.14
diff -u -r1.14 in6_pcb.h
--- in6_pcb.h 7 Apr 2004 20:46:15 -0000 1.14
+++ in6_pcb.h 5 Aug 2004 13:37:55 -0000
@@ -85,7 +85,7 @@
in6_pcblookup_hash __P((struct inpcbinfo *,
struct in6_addr *, u_int, struct in6_addr *,
u_int, int, struct ifnet *));
-void in6_pcbnotify __P((struct inpcbhead *, struct sockaddr *,
+void in6_pcbnotify __P((struct inpcbinfo *, struct sockaddr *,
u_int, const struct sockaddr *, u_int, int, void *,
struct inpcb *(*)(struct inpcb *, int)));
struct inpcb *
Index: raw_ip6.c
===================================================================
RCS file: /home/ncvs/src/sys/netinet6/raw_ip6.c,v
retrieving revision 1.43
diff -u -r1.43 raw_ip6.c
--- raw_ip6.c 27 Jul 2004 23:45:19 -0000 1.43
+++ raw_ip6.c 5 Aug 2004 13:40:50 -0000
@@ -298,7 +298,8 @@
sa6_src = &sa6_any;
}
- (void) in6_pcbnotify(&ripcb, sa, 0, (const struct sockaddr *)sa6_src,
+ (void) in6_pcbnotify(&ripcbinfo, sa, 0,
+ (const struct sockaddr *)sa6_src,
0, cmd, cmdarg, notify);
}
Index: udp6_usrreq.c
===================================================================
RCS file: /home/ncvs/src/sys/netinet6/udp6_usrreq.c,v
retrieving revision 1.50
diff -u -r1.50 udp6_usrreq.c
--- udp6_usrreq.c 27 Jul 2004 23:45:19 -0000 1.50
+++ udp6_usrreq.c 5 Aug 2004 13:41:22 -0000
@@ -444,11 +444,11 @@
bzero(&uh, sizeof(uh));
m_copydata(m, off, sizeof(*uhp), (caddr_t)&uh);
- (void) in6_pcbnotify(&udb, sa, uh.uh_dport,
+ (void) in6_pcbnotify(&udbinfo, sa, uh.uh_dport,
(struct sockaddr *)ip6cp->ip6c_src,
uh.uh_sport, cmd, cmdarg, notify);
} else
- (void) in6_pcbnotify(&udb, sa, 0,
+ (void) in6_pcbnotify(&udbinfo, sa, 0,
(const struct sockaddr *)sa6_src,
0, cmd, cmdarg, notify);
}
------------------------------
Message: 11
Date: Thu, 5 Aug 2004 09:46:19 -0400 (EDT)
From: Daniel Eischen <eis...@vigrid.com>
Subject: Re: pthread_cond_wait failed
To: ngl <n...@ur.ru>
Cc: cur...@freebsd.org
Message-ID:
<Pine.GSO.4.10.104080...@pcnet5.pcnet.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 5 Aug 2004, ngl wrote:
> Hello all
>
> I'm using pcap and c_r libraries under FreeBSD 5.2.1-p9.
> I have faced a problem, when one thread call pthread_cond_wait function,
> i get 'Segmentation fault (core dumped)' message.
More than likely your program failed, but without a simple test
case we can't tell you where you went wrong ;-)
--
Dan Eischen
------------------------------
Message: 12
Date: Wed, 04 Aug 2004 22:36:37 +0900 (KST)
From: CHOI Junho <c...@kr.FreeBSD.org>
Subject: Re: No new snapshot of 5-CURRENT anymore?
To: rost...@yahoo.com
Cc: freebsd...@freebsd.org
Message-ID: <20040804.22363...@kr.FreeBSD.org>
Content-Type: Text/Plain; charset=us-ascii
From: Rostislav Krasny <rost...@yahoo.com>
Subject: Re: No new snapshot of 5-CURRENT anymore?
Date: Wed, 4 Aug 2004 06:24:04 -0700 (PDT)
> I just tried to install 5.2-CURRENT-20040804-SESNAP snapshot using FTP
> installation with floppies, but I failed. First of all, the sysinstall
> have only one FTP URL of snapshots - the JP one. Secondly, it isn't
> obvious what manual URL should be used. So I've tried following URLs:
>
> ftp://snapshots.se.freebsd.org
> ftp://snapshots.se.freebsd.org/snapshots
> ftp://snapshots.se.freebsd.org/snapshots/i386
> ftp://snapshots.se.freebsd.org/snapshots/i386/5.2-CURRENT-20040804-SESNAP
>
> No one did work and I always got the same error message about that
> sysinstall can't find the '5.2-CURRENT' distribution on the FTP server.
> Should it look for the '5.2-CURRENT-20040804-SESNAP' distribution
> instead? It looks like a build bug. When I looked at a sniffer dump I
> saw that sysinstall tried to find the '5.2-CURRENT' directory, not the
> '5.2-CURRENT-20040804-SESNAP' one. Can you fix it?
Did you try to set 'Options' - 'Release Name' to
'5.2-CURRENT-20040804-SESNAP' in sysinstall menu? sysinstall tries to
find necessary files using it. Maybe default value is '5.2-CURRENT'.
--
CHOI Junho <http://www.kr.FreeBSD.org/~cjh> KFUG <cjh at kr.FreeBSD.org>
FreeBSD Project <cjh at FreeBSD.org> Web Data Bank <cjh at wdb.co.kr>
Key fingerprint = 1369 7374 A45F F41A F3C0 07E3 4A01 C020 E602 60F5
------------------------------
Message: 13
Date: Wed, 4 Aug 2004 07:08:13 -0700 (PDT)
From: Kim Culhan <w8h...@yahoo.com>
Subject: fyi: snap from 080404 will not boot 'no /boot/loader'
To: dwh...@gumbysoft.com
Cc: snap...@snapshots.se.FreeBSD.org
Message-ID: <2004080414081...@web50701.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
--- Doug White <dwh...@gumbysoft.com> wrote:
> On Tue, 3 Aug 2004, Kim Culhan wrote:
>
> >
> > Greetings-
> >
> > Just an fyi here.. The latest snap, 080304, from
> > snapshots.se.FreeBSD.org did not install a bootable system here.
>
> This looks like the boot2 breakage. I think a fix was committed
> not too
> long ago and its possible the snapshot server hadn't picked it up
> in time.
> You might try tomorrow's.
The snap 5.2-CURRENT-20040804-SESNAP.iso does:
F1
[hit enter or wait..]
invalid partition
invalid partition
no /boot/loader
FreeBSD/i386 boot
Default: 0:ad(0,`)/kernel
fyi..
tnx
-kim
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
------------------------------
Message: 14
Date: Wed, 04 Aug 2004 15:38:08 +0100
From: Mark Murray <ma...@grondar.org>
Subject: Re: Unable to build recent kernels
To: Maxim Konovalov <ma...@macomnet.ru>
Cc: "Robin P. Blanchard" <robin.b...@gactr.uga.edu>
Message-ID: <200408041438....@grimreaper.grondar.org>
Maxim Konovalov writes:
> On Wed, 4 Aug 2004, 10:22-0400, Robin P. Blanchard wrote:
>
> >
> > [snip]
> > linking kernel.debug
> > mp_machdep.o(.text+0x705): In function `init_secondary':
> > /usr/src/sys/i386/i386/mp_machdep.c:518: undefined reference to
> > `mem_range_AP_init'
> > *** Error code 1
>
> cat >> your_kernel_config_file <<EOF
> device mem
> device null
> device zero
> EOF
Only the first one. "device mem"
M
--
Mark Murray
iumop ap!sdn w,I idlaH
------------------------------
Message: 15
Date: Wed, 04 Aug 2004 15:40:07 +0100
From: Mark Murray <ma...@grondar.org>
Subject: Re: Unable to build recent kernels
To: Scott Long <sco...@FreeBSD.ORG>
Cc: "Robin P. Blanchard" <robin.b...@gactr.uga.edu>
Message-ID: <200408041440....@grimreaper.grondar.org>
Scott Long writes:
> Robin P. Blanchard wrote:
>
> > [snip]
> > linking kernel.debug
> > mp_machdep.o(.text+0x705): In function `init_secondary':
> > /usr/src/sys/i386/i386/mp_machdep.c:518: undefined reference to
> > `mem_range_AP_init'
> > *** Error code 1
> >
> >
>
> You need to include 'device mem' in your kernel config. Look at
> src/UPDATING and the GENERIC config file for devices that were recently
> added.
And I have a fix to stop the break. I'll commit it in a couple of hours.
The above breakage is my fault - apologies!
M
--
Mark Murray
iumop ap!sdn w,I idlaH
------------------------------
Message: 16
Date: Wed, 4 Aug 2004 23:03:21 +0400
From: Toxa <pos...@senmail.ru>
Subject: Re: radeon.ko doesn't load on recent current
To: Maxime Henrion <m...@freebsd.org>, anh...@FreeBSD.org,
cur...@freebsd.org
Message-ID: <2004080419...@laptoxa.toxa.lan>
Content-Type: text/plain; charset=koi8-r
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 ;-)
--
Anton A. Karpov
#--------------------------------------------------
"Anyone who quotes me in their sig is an idiot."
Rusty Russell.
#--------------------------------------------------
------------------------------
Message: 17
Date: Thu, 5 Aug 2004 00:59:30 +0100
From: Paul Richards <pa...@originative.co.uk>
Subject: /dev/vga
To: cur...@freebsd.org
Message-ID: <2004080423...@myrddin.originative.co.uk>
Content-Type: text/plain; charset=us-ascii
I can't start X anymore it complains about being unable to mmap
/dev/vga.
I can't find anywhere in the code that creates /dev/vga, anyone have
any clues?
------------------------------
Message: 18
Date: Thu, 05 Aug 2004 02:57:09 +0200
From: Arne Schwabe <sch...@uni-paderborn.de>
Subject: Re: Challenge getting touchpad to work since
src/sys/isa/psm.c 1.71
To: David Wolfskill <da...@catwhisker.org>
Cc: n...@freebsd.org
Message-ID: <867jsei...@kamino.rfc1149.org>
Content-Type: text/plain; charset=us-ascii
David Wolfskill <da...@catwhisker.org> writes:
> 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.
>
> I normally run in -STABLE (booted from slice 1), and access the mouse
> via moused; the resulting command line is
>
> /usr/sbin/moused -3 -p /dev/psm0 -t auto
>
> Thus, in -STABLE, tapping the touchpad is equivalent to a press/release
> of the left mouse button (button 1); press/release for the right button
> is button 3, and both the left & right button "chorded" are used to
> simulate the middle button (button 2).
>
> Until the above-cited commit, this was also the case in -CURRENT.
>
> In an attempt to discover a bit more, I fired up moused without the -3
> flag, but with the -f ("foreground") and -d ("debug") flags, so I could
> see what the packets were when each event occurred. I see some
> differences between any two of them, but I'm managing to fail to see how
> those differences map to src/sys/sys/mouse.h's assignments.
>
> Event First generated packet (hex)
> Press/release left button 83 00 00 00 00 00 00 7f
> Press/release right button 86 00 00 00 00 00 00 7f
> Press/release both buttons 82 00 00 00 00 00 00 7f
> Touchpad tap 87 00 00 00 00 00 00 7f
>
> That leftmost byte is to be mapped by src/sys/sys/mouse.h thus:
>
> /* button */
> #define MOUSE_BUTTON1DOWN 0x0001 /* left */
> #define MOUSE_BUTTON2DOWN 0x0002 /* middle */
> #define MOUSE_BUTTON3DOWN 0x0004 /* right */
> #define MOUSE_BUTTON4DOWN 0x0008
> #define MOUSE_BUTTON5DOWN 0x0010
> #define MOUSE_BUTTON6DOWN 0x0020
> #define MOUSE_BUTTON7DOWN 0x0040
> #define MOUSE_BUTTON8DOWN 0x0080
> #define MOUSE_MAXBUTTON 31
> #define MOUSE_STDBUTTONS 0x0007 /* buttons 1-3 */
> #define MOUSE_EXTBUTTONS 0x7ffffff8 /* the others (28 of them!) */
> #define MOUSE_BUTTONS (MOUSE_STDBUTTONS | MOUSE_EXTBUTTONS)
>
>
> which seems a little confusing: moused is apparently reporting the
> touchpad tap as all 3 buttons being down.
>
> Perhaps a bit stranger, the device is now probed as having 3 buttons,
> vs. the 2 that are seen in -STABLE or that were seen in -CURRENT prior
> to the commit.
>
> Here's a cut/paste of the probe messages from recent -CURRENT, with
> PSM_DEBUG=1:
>
> Aug 4 11:22:31 localhost kernel: psm0: unable to allocate IRQ
> Aug 4 11:22:31 localhost kernel: psmcpnp0 irq 12 on acpi0
> Aug 4 11:22:31 localhost kernel: psm0: current command byte:0047
> Aug 4 11:22:31 localhost kernel: Synaptics Touchpad:
> Aug 4 11:22:31 localhost kernel: Version: 4.3
> Aug 4 11:22:31 localhost kernel: Model id: 88 58 a1
> Aug 4 11:22:31 localhost kernel: infoRot180: 1
> Aug 4 11:22:31 localhost kernel: infoPortrait: 0
> Aug 4 11:22:31 localhost kernel: infoSensor: 8
> Aug 4 11:22:31 localhost kernel: infoHardware: 44
> Aug 4 11:22:31 localhost kernel: infoNewAbs: 1
> Aug 4 11:22:31 localhost kernel: capPen: 0
> Aug 4 11:22:31 localhost kernel: infoSimplC: 1
> Aug 4 11:22:31 localhost kernel: infoGeometry: 1
> Aug 4 11:22:31 localhost kernel: Capability Bytes: 55 47 55
> Aug 4 11:22:31 localhost kernel: Mode byte set by BIOS: 41
> Aug 4 11:22:31 localhost kernel: psm0: found Synaptics Touchpad
> Aug 4 11:22:31 localhost kernel: psm0: <PS/2 Mouse> irq 12 on atkbdc0
> Aug 4 11:22:31 localhost kernel: psm0: [GIANT-LOCKED]
> Aug 4 11:22:31 localhost kernel: psm0: model Synaptics Touchpad, device ID 0-00, 3 buttons
> Aug 4 11:22:31 localhost kernel: psm0: config:00000000, flags:00000000, packet size:6
> Aug 4 11:22:31 localhost kernel: psm0: syncmask:c0, syncbits:80
>
>
> Anyone have clues? I'm not married to the idea of using moused. I
> tried running X without moused (telling X to access the mouse directly),
> and I managed to get the same behavior.
>
If you only use X you could use synaptics xfree driver that has its
parsing of the touchpad codes, you have to change in freebsd_mouse.h
the sysctl definition to match /usr/include/sys/mouse.h.
iirc after that:
gmake synaptics_drv.o
cp synaptics_drv.o /usr/X11R6/lib/X11/modules
(I am not sure about the X11 Path)
Otherwise you could simply change the line in /sys/isa/psm.c
/* If it is a Synaptics, byte 2 is 0x47. */
if (status[1] != 0x47)
return (FALSE);
to something like !=0x666;
so that the synaptics touchpad is recognized as a touchpad. (Behavior
like before the patch)
When I have time again I will look over the psm synaptics parsing to
make it better.
Arne
------------------------------
Message: 19
Date: Thu, 05 Aug 2004 08:10:02 +0100
From: Mark Murray <ma...@grondar.org>
Subject: Re: kernel build error
To: Robert Watson <rwa...@FreeBSD.ORG>
Cc: FreeBSD Current <freebsd...@FreeBSD.ORG>
Message-ID: <200408050710....@grimreaper.grondar.org>
Robert Watson writes:
>
> 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.
>
> I've committed this change and things now appear to build. Might take a
> couple of minutes to propagate to cvsup, etc.
Thanks Robert. Colour me very confused. :-)
I built 4 cases in testing; SMP/UP cross Module/NoModule. All worked.
What did I miss?
M
--
Mark Murray
iumop ap!sdn w,I idlaH
------------------------------
Message: 20
Date: Thu, 05 Aug 2004 08:33:44 +0100
From: Mark Murray <ma...@grondar.org>
Subject: Re: So much entropy it's coming out of our ears?
To: Sam Leffler <s...@errno.com>
Cc: ma...@FreeBSD.ORG
Message-ID: <200408050733....@grimreaper.grondar.org>
Sam Leffler writes:
> 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.
Yarrow is not conducive to "water-mark" type flow-control, but I'm looking
at replacing Yarrow with Fortuna (code at an advanced stage). This should
improve things all-round.
> Everything that goes on inside the PRNG is a separate issue.
*nod*
M
--
Mark Murray
iumop ap!sdn w,I idlaH
------------------------------
Message: 21
Date: Thu, 5 Aug 2004 15:25:16 +0200
From: Shaun Courtney <sh...@gvmail.vine.co.za>
Subject: gvinum resetconfig
To: cur...@freebsd.org
Message-ID: <20040805132...@gvmail.vine.co.za>
Content-Type: text/plain; charset=us-ascii
Hi All,
I'm looking for some help with geom_vinum (gvinum) and the resetconf
command. I've moved some disk around but they still keep the old gvinum
configuration. i've tried resetconfig aka vinum but it just returns to
the prompt ;(
Can I dd the disk to wipe out the geom_vinum config information. I've
seup geom_vinum similar to the Robert A. Van Valzah article, except
I'm running 5.2-CURRENT as of yesterday. I have had /dev/gvinum/root;
/dev/gvinum/swap and /dev/gvinum/usr up and running.
I've also tried using vinum to resetconfig and create to try and
clear... not luck...
Thanks.
Shaun Courtney
--
Grapevine Interactive
Research and Development
+27 82 371 2046
+27 21 702 3333
------------------------------
Message: 22
Date: Thu, 05 Aug 2004 09:48:25 -0400
From: "Alexandre \"Sunny\" Kovalenko" <Alex.Ko...@verizon.net>
Subject: Re: Unable to build recent kernels
To: Maxim Konovalov <ma...@macomnet.ru>
Cc: freebsd...@freebsd.org
Message-ID: <1091713704.698.16.camel@RabbitsDen>
Content-Type: text/plain
On Wed, 2004-08-04 at 23:16, Maxim Konovalov wrote:
> On Wed, 4 Aug 2004, 22:18-0400, Alexandre "Sunny" Kovalenko wrote:
>
> > On Wed, 2004-08-04 at 10:28, Maxim Konovalov wrote:
> > > On Wed, 4 Aug 2004, 10:22-0400, Robin P. Blanchard wrote:
> > >
> > > >
> > > > [snip]
> > > > linking kernel.debug
> > > > mp_machdep.o(.text+0x705): In function `init_secondary':
> > > > /usr/src/sys/i386/i386/mp_machdep.c:518: undefined reference to
> > > > `mem_range_AP_init'
> > > > *** Error code 1
> > >
> > > cat >> your_kernel_config_file <<EOF
> > > device mem
> > > device null
> > > device zero
> > > EOF
> > Is this really necessary?
> > System below cvsup'ed and built on Aug 3 22:47 EST
> >
> > RabbitsDen# grep mem /sys/i386/conf/AVERATEC
> > options SYSVSHM #SYSV-style shared memory
> > RabbitsDen# kldstat
> > Id Refs Address Size Name
> > 1 25 0xc0400000 473d7c kernel
> > 2 1 0xc0874000 5e9c snd_via8233.ko
> > 3 9 0xc087a000 2b0c8 usb.ko
> > 4 1 0xc08a6000 3b4c ulpt.ko
> > 5 1 0xc08aa000 40b0 ums.ko
> > 6 1 0xc08b2000 3254 powernow_k7.ko
> > 7 1 0xc08b6000 2f90 uplcom.ko
> > 8 3 0xc08b9000 406c ucom.ko
> > 9 1 0xc08be000 38a8 ubsa.ko
> > 10 1 0xc08c2000 bc6c ng_ubt.ko
> > 11 1 0xc08ce000 2d58 dcons_crom.ko
> > 12 2 0xc08d1000 14d20 firewire.ko
> > 13 2 0xc08e6000 39e8 dcons.ko
> > 14 1 0xc08ea000 1ce4 io.ko
> > 15 1 0xc08ec000 2a8c mem.ko
> > 16 1 0xc1e5e000 a000 ntfs.ko
> > 17 1 0xc1eb1000 6000 linprocfs.ko
> > 18 1 0xc1eb7000 1a000 linux.ko
> > RabbitsDen#
>
> http://freebsd.rambler.ru/bsdmail/cvs-src_curr/msg00134.html
Ah, I see... it is necessary if you are building SMP kernel.
Thanks for the pointer.
---
Alexandre "Sunny" Kovalenko.
------------------------------
Message: 23
Date: Thu, 05 Aug 2004 09:56:27 -0400
From: "Alexandre \"Sunny\" Kovalenko" <Alex.Ko...@verizon.net>
Subject: Re: Challenge getting touchpad to work since
src/sys/isa/psm.c 1.71
To: MikkoTy?l?j?rvi<mb...@pacbell.net>
Cc: freebsd...@freebsd.org
Message-ID: <1091714186.698.20.camel@RabbitsDen>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, 2004-08-05 at 02:10, Mikko Työläjärvi wrote:
> 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;
I was not able to apply this patch to psm.c 1.71. There is another
patch from Philip Paeps, which applied cleanly, and I am going to test
it shortly.
Thank you.
---
Alexandre "Sunny" Kovalenko.
------------------------------
Message: 24
Date: Thu, 5 Aug 2004 18:12:26 +0400
From: Gleb Smirnoff <gle...@freebsd.org>
Subject: xmms crashes CURRENT
To: cur...@freebsd.org
Message-ID: <20040805141...@cell.sick.ru>
Content-Type: text/plain; charset=koi8-r
I've got lots of reboots today, playing Audio CD in
IDE CD-ROM with xmms. My kernel date is 1 Aug.
Hardware is IBM Thinkpad with
acd0: DVDROM <MATSHITADVD-ROM SR-8174> at ata1-master PIO4
Haven't caught backtrace or core yet. But the panic is:
instruction pointer = 0x8:0xc055b780
stack pointer = 0x10:0xc07656bc
frame pointer = 0x10:0xc07656c4
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = IOPL = 0
current process = 612 (xmms)
trap number = 3
panic: breakpoint instruction fault
KDB: enter: panic
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc055b780
stack pointer = 0x10:0xc07655c4
frame pointer = 0x10:0xc07655cc
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = IOPL = 0
current process = 612 (xmms)
trap number = 3
panic: breakpoint instruction fault
KDB: enter: panic
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc055b780
stack pointer = 0x10:0xc07654cc
frame pointer = 0x10:0xc07654d4
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = IOPL = 0
current process = 612 (xmms)
trap number = 3
panic: breakpoint instruction fault
KDB: enter: panic
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc055b780
stack pointer = 0x10:0xc07653d4
frame pointer = 0x10:0xc07653dc
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = IOPL = 0
current process = 612 (xmms)
trap number = 3
panic: breakpoint instruction fault
KDB: enter: panic
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc055b780
stack pointer = 0x10:0xc07652dc
frame pointer = 0x10:0xc07652e4
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = IOPL = 0
current process = 612 (xmms)
trap number = 3
panic: breakpoint instruction fault
KDB: enter: panic
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc055b780
stack pointer = 0x10:0xc07651e4
frame pointer = 0x10:0xc07651ec
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = IOPL = 0
current process = 612 (xmms)
trap number = 3
panic: breakpoint instruction fault
KDB: enter: panic
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc055b780
stack pointer = 0x10:0xc07650ec
frame pointer = 0x10:0xc07650f4
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = IOPL = 0
current process = 612 (xmms)
trap number = 3
panic: breakpoint instruction fault
KDB: enter: panic
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc055b780
stack pointer = 0x10:0xc0764ff4
frame pointer = 0x10:0xc0764ffc
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = IOPL = 0
current process = 612 (xmms)
trap number = 3
panic: breakpoint instruction fault
KDB: enter: panic
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc055b780
stack pointer = 0x10:0xc0764efc
frame pointer = 0x10:0xc0764f04
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = IOPL = 0
current process = 612 (xmms)
trap number = 3
panic: breakpoint instruction fault
KDB: enter: panic
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc055b780
stack pointer = 0x10:0xc0764e04
frame pointer = 0x10:0xc0764e0c
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = IOPL = 0
current process = 612 (xmms)
trap number = 3
panic: breakpoint instruction fault
KDB: enter: panic
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc055b780
stack pointer = 0x10:0xc0764d0c
frame pointer = 0x10:0xc0764d14
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = IOPL = 0
current process = 612 (xmms)
trap number = 3
panic: breakpoint instruction fault
KDB: enter: panic
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc055b780
stack pointer = 0x10:0xc0764c14
frame pointer = 0x10:0xc0764c1c
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = IOPL = 0
current process = 612 (xmms)
trap number = 3
panic: breakpoint instruction fault
KDB: enter: panic
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc055b780
stack pointer = 0x10:0xc0764b1c
frame pointer = 0x10:0xc0764b24
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = IOPL = 0
current process = 612 (xmms)
trap number = 3
panic: breakpoint instruction fault
KDB: enter: panic
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc055b780
stack pointer = 0x10:0xc0764a24
frame pointer = 0x10:0xc0764a2c
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = IOPL = 0
current process = 612 (xmms)
trap number = 3
panic: breakpoint instruction fault
KDB: enter: panic
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc055b780
stack pointer = 0x10:0xc076492c
frame pointer = 0x10:0xc0764934
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = IOPL = 0
current process = 612 (xmms)
trap number = 3
panic: breakpoint instruction fault
KDB: enter: panic
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc055b780
stack pointer = 0x10:0xc0764834
frame pointer = 0x10:0xc076483c
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = IOPL = 0
current process = 612 (xmms)
trap number = 3
panic: breakpoint instruction fault
KDB: enter: panic
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc055b780
stack pointer = 0x10:0xc076473c
frame pointer = 0x10:0xc0764744
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = IOPL = 0
current process = 612 (xmms)
trap number = 3
panic: breakpoint instruction fault
KDB: enter: panic
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
------------------------------
Message: 25
Date: Thu, 5 Aug 2004 10:20:44 -0400 (EDT)
From: Robert Watson <rwa...@freebsd.org>
Subject: Re: /dev/vga
To: Paul Richards <pa...@originative.co.uk>
Cc: cur...@freebsd.org
Message-ID:
<Pine.NEB.3.96L.104080...@fledge.watson.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 5 Aug 2004, Paul Richards wrote:
> I can't start X anymore it complains about being unable to mmap
> /dev/vga.
>
> I can't find anywhere in the code that creates /dev/vga, anyone have any
> clues?
Are you using the XiG X11 server?
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
rob...@fledge.watson.org Principal Research Scientist, McAfee Research
------------------------------
Message: 26
Date: Thu, 5 Aug 2004 10:25:23 -0400 (EDT)
From: FreeBSD Tinderbox <tind...@freebsd.org>
Subject: [current tinderbox] failure on powerpc/powerpc
To: FreeBSD Tinderbox <tind...@freebsd.org>, <cur...@freebsd.org>,
<pow...@freebsd.org>
Message-ID: <200408051425...@freebsd-current.sentex.ca>
TB --- 2004-08-05 14:16:02 - tinderbox 2.3 running on freebsd-current.sentex.ca
TB --- 2004-08-05 14:16:02 - starting CURRENT tinderbox run for powerpc/powerpc
TB --- 2004-08-05 14:16:02 - cleaning the sandbox
TB --- 2004-08-05 14:17:17 - checking out the source tree
TB --- 2004-08-05 14:17:17 - cd /home/tinderbox/sandbox/CURRENT/powerpc/powerpc
TB --- 2004-08-05 14:17:17 - /usr/bin/cvs -f -R -Q -d/home/ncvs checkout -P -A src
TB --- 2004-08-05 14:25:23 - patching the sources
TB --- 2004-08-05 14:25:23 - cd /home/tinderbox/sandbox/CURRENT/powerpc/powerpc/src
TB --- 2004-08-05 14:25:23 - /usr/bin/patch -f -s -i/home/tinderbox/sandbox/powerpc.diff
TB --- 2004-08-05 14:25:23 - WARNING: /usr/bin/patch returned exit code 2
TB --- 2004-08-05 14:25:23 - ERROR: failed to apply patch to source tree
TB --- 2004-08-05 14:25:23 - tinderbox aborted
------------------------------
Message: 27
Date: Thu, 05 Aug 2004 23:28:39 +0900
From: Jun Kuriyama <kuri...@imgsrc.co.jp>
Subject: Re: panic: mutex inp not owned at
/usr/src/sys/netinet/tcp_output.c:140
To: Robert Watson <rwa...@FreeBSD.org>
Cc: Current <freebsd...@FreeBSD.org>
Message-ID: <7mu0vh...@black.imgsrc.co.jp>
Content-Type: text/plain; charset=US-ASCII
At Thu, 5 Aug 2004 09:43:41 -0400 (EDT),
Robert Watson wrote:
> Could you try the attached patch? This modifies the IPv6 code to match
> the IPv4 code in passing in the "inpcbinfo" reference for a protocol,
> rather than just its inpcb list. This allows in6_pcbnotify() to lock the
> structure before walking it. It also acquires the per-pcb locks before
> notifying each pcb of an event.
Can I have more patch?
cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/netinet/tcp_subr.c
/usr/src/sys/netinet/tcp_subr.c: In function `tcp6_ctlinput':
/usr/src/sys/netinet/tcp_subr.c:1241: warning: passing arg 1 of `in6_pcbnotify' from incompatible pointer type
/usr/src/sys/netinet/tcp_subr.c:1251: warning: passing arg 1 of `in6_pcbnotify' from incompatible pointer type
--
Jun Kuriyama <kuri...@imgsrc.co.jp> // IMG SRC, Inc.
<kuri...@FreeBSD.org> // FreeBSD Project
------------------------------
Message: 28
Date: Thu, 05 Aug 2004 10:31:20 -0400
From: "Alexandre \"Sunny\" Kovalenko" <Alex.Ko...@verizon.net>
Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads
To: freebsd...@freebsd.org
Message-ID: <1091716279.698.15.camel@RabbitsDen>
Content-Type: text/plain
On Thu, 2004-08-05 at 03:12, Philip Paeps wrote:
> 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
This patch restored "single tap" = "left button click" functionality on
my AVERATEC 3150H. However, "double tap and drag" = "hold left button
and move the mouse" is still missing. It is working with psm.c 1.70.
Also, I have (possibly subjective) feeling that something happened with
the resolution -- if with psm.c 1.70 I ca successfully tap into "clear
transaction" box in gnucash (relatively small target on the relatively
busy screen) about 9 times out of 10, with 1.71 + your patch it is about
50/50. Please, note I am not proposing to discuss shortcomings of the
user interface in gnucash, but merely use it as my private test of mouse
sensitivity.
I will have to go do some paid work now, but I can test patches or
produce debug output later tonight if necessary.
---
Alexandre "Sunny" Kovalenko.
------------------------------
Message: 29
Date: Thu, 05 Aug 2004 10:33:49 -0400
From: Richard Coleman <rcol...@criticalmagic.com>
Subject: Re: So much entropy it's coming out of our ears?
To: Sam Leffler <s...@errno.com>
Cc: freebsd...@freebsd.org
Message-ID: <4112454D...@criticalmagic.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sam Leffler wrote:
> 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
In general, by using a push model, you open yourself up to the possibility
that the attacker could exhaust the entropy at just the right time so he can
control what entropy is harvested on the next run of the PRNG. But in this
case, we might be able to get away with it, since the PRNG is still
cryptographically strong even when there is no new entropy flowing into the
system (as long at the attacker doesn't know the initial state of the pool).
Rekeying and reseeding the pool are primarily to give you forward security
and to recover if the entropy pool has been compromised.
But a push system is still better if it doesn't impact performance too much.
Richard Coleman
rcol...@criticalmagic.com
------------------------------
Message: 30
Date: Thu, 5 Aug 2004 18:42:06 +0400
From: Gleb Smirnoff <gle...@freebsd.org>
Subject: Re: /dev/vga
To: Paul Richards <pa...@originative.co.uk>
Cc: cur...@freebsd.org
Message-ID: <20040805144...@cell.sick.ru>
Content-Type: text/plain; charset=koi8-r
On Thu, Aug 05, 2004 at 12:59:30AM +0100, Paul Richards wrote:
P> I can't start X anymore it complains about being unable to mmap
P> /dev/vga.
I have /dev/io and /dev/mem disappered in today's CURRENT :)
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
------------------------------
Message: 31
Date: Thu, 05 Aug 2004 11:04:43 -0400
From: Chris <ch...@tellme3times.com>
Subject: Re: USB drivers
To: "M. Warner Losh" <i...@bsdimp.com>
Cc: freebsd...@freebsd.org
Message-ID: <41124C8B...@tellme3times.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
M. Warner Losh wrote:
>
>You misunerstand what's actually happening. There's no case in the
>tree where two drivers are attached, at the same time, to the same
>device node. There's only one set of pointers. However, with USB,
>there can be reasons why multiple things can attach to the same
>driver. The usb code tries to do smart things for devices that have
>multiple configurations.
>
>With USB and multi-function devices, here's the code that we use:
>
> /* First try with device specific drivers. */
> probe and attach driver with a config # of -1 (usegeneric = 0)
> return if successful
> /* Next try with interface drivers. */
> foreach valid configuration
> foreach interface
> probe and attach driver
> /* Finally try the generic driver. */
> probe and attach driver with a config # of -1 (usegeneric = 1)
> return if successful
>
>I'm not familiar with the specific instance of ulpt and unlpt.
>
>
You are right I do not understand. All I know is that when the system
boots, at some point a test is done to see if their are USB devices. If
devices exist then attach drivers.
What I am trying to determine is why my multifunction printer/scanner
receives only one of the two drivers. Is it because the printer does
not respond properly? Is it because the printer is not defined? I have
many questions here.
I looked in the following and just see the code for that specific
device. It does not test for multifunction devices. I do not see any
code that follows the logic above.
src/sys/dev/usb/ulpt.c
src/sys/dev/usb/uscanner.c
src/sys/dev/usb/usbdevs
If you can point me in the right direction, or to some documents on USB
driver writing I will try to figure this out. Any help would be
appreciated. I will get this to work because I need both and the effort
required to switch is just not convenient.
Chris
------------------------------
Message: 32
Date: Thu, 5 Aug 2004 11:00:20 -0400 (EDT)
From: Robert Watson <rwa...@FreeBSD.org>
Subject: Re: panic: mutex inp not owned at
/usr/src/sys/netinet/tcp_output.c:140
To: Jun Kuriyama <kuri...@imgsrc.co.jp>
Cc: Current <freebsd...@FreeBSD.org>
Message-ID:
<Pine.NEB.3.96L.104080...@fledge.watson.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 5 Aug 2004, Jun Kuriyama wrote:
> At Thu, 5 Aug 2004 09:43:41 -0400 (EDT),
> Robert Watson wrote:
> > Could you try the attached patch? This modifies the IPv6 code to match
> > the IPv4 code in passing in the "inpcbinfo" reference for a protocol,
> > rather than just its inpcb list. This allows in6_pcbnotify() to lock the
> > structure before walking it. It also acquires the per-pcb locks before
> > notifying each pcb of an event.
>
> Can I have more patch?
==== //depot/user/rwatson/netperf/sys/netinet/tcp_subr.c#17 - /home/rwatson/p4/rwatson_netperf/sys/netinet/tcp_subr.c ====
@@ -1236,7 +1236,7 @@
bzero(&th, sizeof(th));
m_copydata(m, off, sizeof(*thp), (caddr_t)&th);
- in6_pcbnotify(&tcb, sa, th.th_dport,
+ in6_pcbnotify(&tcbinfo, sa, th.th_dport,
(struct sockaddr *)ip6cp->ip6c_src,
th.th_sport, cmd, NULL, notify);
@@ -1247,7 +1247,7 @@
inc.inc_isipv6 = 1;
syncache_unreach(&inc, &th);
} else
- in6_pcbnotify(&tcb, sa, 0, (const struct sockaddr *)sa6_src,
+ in6_pcbnotify(&tcbinfo, sa, 0, (const struct sockaddr *)sa6_src,
0, cmd, NULL, notify);
}
#endif /* INET6 */
------------------------------
Message: 33
Date: Thu, 05 Aug 2004 19:02:49 +0400
From: Maxim Maximov <mc...@mcsi.pp.ru>
Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads
To: Philip Paeps <phi...@freebsd.org>
Cc: freebsd...@freebsd.org
Message-ID: <41124C19...@mcsi.pp.ru>
Content-Type: text/plain; charset=us-ascii; format=flowed
Philip Paeps wrote:
> 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 :-)
Thanks, Philip!
On ASUS L5 it works perfect! Tapping, double-tapping, scroll-up and
scroll-down buttons now work as expected in X.
--
Maxim Maximov
------------------------------
Message: 34
Date: Fri, 06 Aug 2004 00:37:09 +0900
From: Jun Kuriyama <kuri...@imgsrc.co.jp>
Subject: Re: panic: mutex inp not owned at
/usr/src/sys/netinet/tcp_output.c:140
To: Robert Watson <rwa...@FreeBSD.org>
Cc: Current <freebsd...@FreeBSD.org>
Message-ID: <7msmb1...@black.imgsrc.co.jp>
Content-Type: text/plain; charset=US-ASCII
At Thu, 5 Aug 2004 11:00:20 -0400 (EDT),
Robert Watson wrote:
> ==== //depot/user/rwatson/netperf/sys/netinet/tcp_subr.c#17 - /home/rwatson/p4/rwatson_netperf/sys/netinet/tcp_subr.c ====
Thanks! Previous kernel is paniced several working hours after
booting, so I'm not sure how I can reproduce it.
And unfortunatelly, shutdown -r cannot reboot that box even from
serial console. I'll do hard reset tomorrow morning at office...
--
Jun Kuriyama <kuri...@imgsrc.co.jp> // IMG SRC, Inc.
<kuri...@FreeBSD.org> // FreeBSD Project
------------------------------
_______________________________________________
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 14
***********************************************