freebsd-hackers-digest V5 #753
owner-freebsd-...@freebsd.org
freebsd-hackers-digest Monday, March 24 2003 Volume 05 : Number 753
In this issue:
Accessibility software
KVM mice issues
Re: bug in subr_bus.c?
超值好禮任您挑選!!歡迎來電看貨現場看貨比較選購
Re: Lots of kernel core dumps
shared mem and panics when out of PV Entries
Re: KVM mice issues
Re: KVM mice issues
Re: shared mem and panics when out of PV Entries
Re: misc/41772: can't disable keybell [PATCH]
----------------------------------------------------------------------
Date: Sat, 22 Mar 2003 10:07:00 -0800
From: "Richard Norris" <ric...@voicewebsolutions.biz>
Subject: Accessibility software
Hi,
My name is Richard. I saw your interest in Section 508 and
Accessiblity and I just wanted to let you know that there
is a new product for webmasters that uses speech recognition
to make the Web sites more accessible. The Voice Web Studio
software enables you to add speech as another mode of
interaction with any web page using Macromedia Dreamweaver MX.
You can access these speech-enabled pages from your computer
or handheld wireless device with just a microphone. This new
web authoring tool is available now as a free download. If
you are interested, I can e-mail you a brief brochure that
will show you the easiest way to start using the software.
I am looking forward to hearing from you soon.
Best Regards,
Richard Norris
Business Development
Voice Web Solutions
Phone: (206) 338-6632
------------------------------
Date: Sun, 23 Mar 2003 09:57:36 -0600
From: Chip Norkus <w...@arpa.com>
Subject: KVM mice issues
Greetings hackers,
I have a KVM switch and a fairly new (Logitech MouseMan+ cordless) mouse,
and I've found that while FreeBSD properly detects the mouse and all its
functionality (buttons, scrollwheel, etc) upon boot if I switch to
another port on the KVM and then switch back my mouse "loses" its
functionality.
After spending a while trying to figure out this problem (and reading PRs
on the issue (esp. i386/25463)) I found that a solution was not
immediately available, but might be somewhat easy to achieve. In
particular, for my mouse, the mouse driver can and does detect invalid
packets, and invalid packets are always received after a return to my
FreeBSD system via the KVM. I found that doing a reinitialization of the
device would fix the mouse, but that doing it from the interrupt handler
(in sys/isa/psm.c around line 2170) caused some intermediate problems.
Normally the mouse would just bounce around and generate click events for
a while and then settle down, but occasionally the driver (or maybe
mouse?) would lock solid and I'd have to reboot the system.
Anyways, I'd like to work further on this problem and hopefully find a
solution, but I'm having some trouble understanding where and what I
should do. I'm not a novice C hacker, but I *am* a very novice kernel
hacker and would appreciate help from anyone with knowledge of the psm
(and atkbdc) code. I've considered maybe adding an ioctl to reset the
mouse and adding a signal handler to moused to force a reset, but that
seems kind of silly when the kernel driver can detect the problem itself
and resolve it. On the other hand, maybe that's the right way to go?
Advice would be greatly appreciated.
- -chip
- --
chip norkus; renaissance hacker; w...@arpa.com
"question = (to) ? be : !be;" --Shakespeare http://telekinesis.org/
------------------------------
Date: Sun, 23 Mar 2003 09:23:05 -0700 (MST)
From: "M. Warner Losh" <i...@bsdimp.com>
Subject: Re: bug in subr_bus.c?
In message: <20030323174445...@resnet.uoregon.edu>
John-Mark Gurney <gurn...@resnet.uoregon.edu> writes:
: The bus code could use some locking in it... like you can't delete_child
: from child_detache... and/or better docs on how to handle children... I'm
: not even sure how I was doing things wrong, but I think it might of been
: problems with my code not calling bus_generic_detach before calling
: device_child_delete...
I'm doing the locking, but you can do a bus_delete_child in a child's
detach routine. Cardbus does this right now and it works when you
unload the cardbus bridge...
Warner
------------------------------
Date: Mon, 24 Mar 2003 00:44:51 +0800
From: 4200tttttfh...@ms67.hinet.net
Subject: 超值好禮任您挑選!!歡迎來電看貨現場看貨比較選購
超值好禮任您挑選!!歡迎來電看貨現場看貨比較選購
http://www.vovo2.com/~nono/new_page_tt.htm
新貨已上架，趕快進去挑選！！！！
http://vivi.liful.com/
手機每分鐘費率3.5元
市面上唯一用手機及市話，打國內和國際電話都能節費的系統
http://203.70.228.20/tel/index.asp
19歲能月入十萬...原來他是做這ㄚ
http://www.mymorningmusume.com/hope/new.htm
=======================================================
SUPER e-Mail專業電子郵件行銷~郵件代客群發 / 購買名單 /
=======================================================
http://210.62.128.25/~cai/good/fate/index.htm
*******************************************************
*******************************************************
------------------------------
Date: Sun, 23 Mar 2003 11:20:15 -0800
From: Wes Peters <w...@softweyr.com>
Subject: Re: Lots of kernel core dumps
On Saturday 22 March 2003 15:10, Daniela wrote:
> > I know, but 5.0-RELEASE was
> >
> > a) A work-in-progress, not a perfect, bug-free release
> >
> > b) A snapshot of 5.0-CURRENT
> >
> > You read the 5.0 Early Adopter's Guide, right? Bugs like this are
> > expected at this stage in the development process, and if you
> > encounter them then you need to either give up on 5.x and go back to
> > 4.x-STABLE, or upgrade to 5.0-CURRENT if they are already fixed
> > there.
> >
> > Kris
>
> Yes, I read the Early Adopter's Guide.
> Is there any way to solve this without upgrading to -current?
> I want a stable server, of course, but I still want to help the FreeBSD
> folks to make 5.0 the best release ever. This requires testing to be
> done.
Yes it does, but not on a "production" machine. We admire your courage
and willingness to help, but it's not helping as much as you think. ;^)
The reason for creating the 5.0 release is to make it easy for more
developers and testers to jump onto the 5.x bandwagon by giving them a
known (relatively) good starting point. Quite a number of problems have
been fixed since 5.0-RELEASE; CURRENT is now generally much more stable,
and nobody is going to spend time updating 5.0 which is essentially an
"early access" release.
You have to decide for yourself if this machine is too critical to run
CURRENT, in which case it's probably best off running STABLE or the
latest 4.x release branch, or if you want to update it to CURRENT, follow
the CURRENT mailing list, and update again at known stable development
points. It looks like right now is pretty good if you want to jump.
At any rate, thanks for your tenacity. We really do appreciate the
contributions of everyone.
- --
Where am I, and what am I doing in this handbasket?
Wes Peters w...@softweyr.com
------------------------------
Date: Mon, 24 Mar 2003 01:57:32 -0800
From: "Andrew Kinney" <andyk...@advantagecom.net>
Subject: shared mem and panics when out of PV Entries
Hello,
(very long message with background information on the issue
follows)
The machine discussed in this email is tracking RELENG_4_7.
The machine is a well loaded web/mail/ftp server with dual Athlon
MP 2000+ CPUs, 4GB of RAM, and 8GB of available swap space.
The most it has ever swapped was 292KB (yes, KB not MB) and
the CPUs are about 60% idle most of the time. I don't believe we're
pushing the hardware all that hard given the specifications of the
system.
We're getting panics ("page fault" panic traced back to
pmap_insert_entry) because we're running out of PV Entries. I've
bumped up PMAP_SHPGPERPROC to 400, then 800, and then
1500 over the last several months in an attempt to solve this
problem by increasing the PV Entries limit (per the warning in
pmap_collect). Each time, we still bumped the limit and got
panics due to running out of PV Entries. I've verified that maxed
PV Entries are indeed the cause of the panics by logging sysctl
vm.zone. Our PV Entry limit is now 11113502 (from sysctl
vm.zone) and we're still running into this limit.
With 1GB KVA space, I really shouldn't take
PMAP_SHPGPERPROC much higher since each PV Entry takes
28 bytes of KVA space and with 11113502 PV Entries, that is
nearly 300MB of KVA space used just for PV Entries. Also, from
past experience, if you set PMAP_SHPGPERPROC too high, the
system will not boot. I'm not 100% sure, but I believe that would
happen right around PMAP_SHPGPERPROC=1600 from my
calculations.
Now, I could increase KVA space by way of increasing
KVA_PAGES and presumably continue increasing
PMAP_SHPGPERPROC until the problem goes away, but per a
previous discussion, there are problems (related to pthreads) with
increasing KVA_PAGES in FreeBSD 4.7. This has apparently
been fixed in FreeBSD 4.8.
Since moving to FreeBSD 4.8 isn't an option I can exercise in the
near term, I'd like to approach this problem from a different angle
and possibly solve it without needing to increase KVA_PAGES. In
my opinion, increasing KVA_PAGES would only be a short term
bandaid for the PV Entries issue. I'll eventually need to increase
KVA_PAGES for a different reason, though, because sysctl
vm.kvm_free does hit "0" sometimes after the system has been
running for awhile, but I'll tackle that issue if/when it becomes a
stability issue.
The source of the PV Entry usage is shared memory in Apache
(PHP and/or mod_perl). We know it's Apache memory sharing
that causes the problem because nearly all PV Entries are freed
when Apache is stopped and the problem is worst right after
Apache starts when you have a lot of "clean" memory segments
getting shared (10 to 11 million PV Entries used). After Apache
has run for awhile and the shared memory segments become
unshared due to them being "dirtied", the number of PV Entries
used declines and settles in at a much lower number (3 to 5 million
PV Entries used most days). Apache on this machine likes to
hover right around 256 children processes, so you could see how
requiring duplicate PV Entries per shared memory segment per
Apache process could add up quite quickly.
Under ideal circumstances, we'd correct our PHP/PERL code to
avoid running into the issue at all, but this is customer code that
we don't have much control over since we allow users to select and
run their own CGI scripts without our intervention. So, for this
instance, we have to solve it at the system level by bullet-proofing
our system as much as possible.
I've read that setting sysctl kern.ipc.shm_use_phys to "1" will
cause shared memory segments not to use PV Entries at all.
(See
http://www.geocrawler.com/archives/3/159/2002/6/50/9031353/ )
However, in the real world with FreeBSD 4.7, setting
kern.ipc.shm_use_phys to "1" seems to have no visible effect on
the number of PV Entries consumed by Apache memory sharing.
We're currently running sysctl kern.ipc.shm_use_phys=1 and are
still seeing the heavy PV Entry usage after rebooting (sysctl set on
boot) with no apparent difference in usage.
My thoughts at this point are leaning towards setting some limits
on shared memory (kern.ipc.shmmax, kern.ipc.shmseg,
kern.ipc.shmall, and kern.ipc.shmmax sysctl's) to limit the number
of PV Entries that Apache can consume by way of shared
memory. Is that a viable approach to this problem? What kind of
gotchas and caveats should I watch out for in taking this approach?
Any recommendations on which one to tweak first?
If I'm headed in completely the wrong direction to solve this PV
Entries limit issue, I'd appreciate any alternative approaches to
solving the problem that anyone is willing to offer.
If you need any further information about our settings or usage,
please let me know. I've been as thorough as possible in this
email without getting overly verbose, but in complex issues like this
I recognize that I may not have included all the information needed
for the experts to make a fair assessment of the issue and suggest
work arounds. Also, though I believe that the highly technical
nature of this message made it suitable for posting to freebsd-
hackers, if it would be better suited to a different list, please point
me in the right direction.
Thanks in advance for any advice or assistance you can offer.
Sincerely,
Andrew Kinney
President and
Chief Technology Officer
Advantagecom Networks, Inc.
http://www.advantagecom.net
------------------------------
Date: Mon, 24 Mar 2003 12:50:24 +0200
From: Ruslan Ermilov <r...@FreeBSD.org>
Subject: Re: KVM mice issues
- --3XA6nns4nE4KvaS/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
I think Alexey was having similar issues, and may have some
non-production quality patches for you to try.
On Sun, Mar 23, 2003 at 09:57:36AM -0600, Chip Norkus wrote:
>=20
> Greetings hackers,
>=20
> I have a KVM switch and a fairly new (Logitech MouseMan+ cordless) mouse,=
=20
> and I've found that while FreeBSD properly detects the mouse and all its=
=20
> functionality (buttons, scrollwheel, etc) upon boot if I switch to=20
> another port on the KVM and then switch back my mouse "loses" its=20
> functionality.
>=20
> After spending a while trying to figure out this problem (and reading PRs=
=20
> on the issue (esp. i386/25463)) I found that a solution was not=20
> immediately available, but might be somewhat easy to achieve. In=20
> particular, for my mouse, the mouse driver can and does detect invalid=20
> packets, and invalid packets are always received after a return to my=20
> FreeBSD system via the KVM. I found that doing a reinitialization of the=
=20
> device would fix the mouse, but that doing it from the interrupt handler=
=20
> (in sys/isa/psm.c around line 2170) caused some intermediate problems. =
=20
> Normally the mouse would just bounce around and generate click events for=
=20
> a while and then settle down, but occasionally the driver (or maybe=20
> mouse?) would lock solid and I'd have to reboot the system.
>=20
> Anyways, I'd like to work further on this problem and hopefully find a=20
> solution, but I'm having some trouble understanding where and what I=20
> should do. I'm not a novice C hacker, but I *am* a very novice kernel=20
> hacker and would appreciate help from anyone with knowledge of the psm=20
> (and atkbdc) code. I've considered maybe adding an ioctl to reset the=20
> mouse and adding a signal handler to moused to force a reset, but that=20
> seems kind of silly when the kernel driver can detect the problem itself=
=20
> and resolve it. On the other hand, maybe that's the right way to go? =20
> Advice would be greatly appreciated.
>=20
> -chip
> --=20
> chip norkus; renaissance hacker; w...@arpa.com
> "question =3D (to) ? be : !be;" --Shakespeare http://telekinesis.org/
>=20
>=20
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
- --=20
Ruslan Ermilov Sysadmin and DBA,
r...@sunbay.com Sunbay Software AG,
r...@FreeBSD.org FreeBSD committer,
+380.652.512.251 Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
- --3XA6nns4nE4KvaS/
Content-Type: application/pgp-signature
Content-Disposition: inline
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+fuLvUkv4P6juNwoRAuT8AJ9L6zyNwZoGIkyz7miz4O/ZDaUjQgCfSlKO
yPTtxXHtMvrslFUWHozQ7Eg=
=mI63
- -----END PGP SIGNATURE-----
- --3XA6nns4nE4KvaS/--
------------------------------
Date: Mon, 24 Mar 2003 14:33:55 +0200
From: Alexey Zelkin <pha...@FreeBSD.org.ua>
Subject: Re: KVM mice issues
hi,
Yep. In order to avoid moused(8) getting something crazy (after
console switch) I just forced psm reset after synchronization error
detection. It can be achieved by changing changing of
PSM_SYNCERR_THRESHOLD1 define from 20 to 0 (in file sys/isa/psm.c).
Please try to do it and let me know result, if you're also happy
with solution -- I'll cleanup and commit my patch which forces such
behaviour using sysctl(8).
On Mon, Mar 24, 2003 at 12:50:24PM +0200, Ruslan Ermilov wrote:
> I think Alexey was having similar issues, and may have some
> non-production quality patches for you to try.
>
> On Sun, Mar 23, 2003 at 09:57:36AM -0600, Chip Norkus wrote:
> >
> > Greetings hackers,
> >
> > I have a KVM switch and a fairly new (Logitech MouseMan+ cordless) mouse,
> > and I've found that while FreeBSD properly detects the mouse and all its
> > functionality (buttons, scrollwheel, etc) upon boot if I switch to
> > another port on the KVM and then switch back my mouse "loses" its
> > functionality.
> >
> > After spending a while trying to figure out this problem (and reading PRs
> > on the issue (esp. i386/25463)) I found that a solution was not
> > immediately available, but might be somewhat easy to achieve. In
> > particular, for my mouse, the mouse driver can and does detect invalid
> > packets, and invalid packets are always received after a return to my
> > FreeBSD system via the KVM. I found that doing a reinitialization of the
> > device would fix the mouse, but that doing it from the interrupt handler
> > (in sys/isa/psm.c around line 2170) caused some intermediate problems.
> > Normally the mouse would just bounce around and generate click events for
> > a while and then settle down, but occasionally the driver (or maybe
> > mouse?) would lock solid and I'd have to reboot the system.
> >
> > Anyways, I'd like to work further on this problem and hopefully find a
> > solution, but I'm having some trouble understanding where and what I
> > should do. I'm not a novice C hacker, but I *am* a very novice kernel
> > hacker and would appreciate help from anyone with knowledge of the psm
> > (and atkbdc) code. I've considered maybe adding an ioctl to reset the
> > mouse and adding a signal handler to moused to force a reset, but that
> > seems kind of silly when the kernel driver can detect the problem itself
> > and resolve it. On the other hand, maybe that's the right way to go?
> > Advice would be greatly appreciated.
> >
> > -chip
> > --
> > chip norkus; renaissance hacker; w...@arpa.com
> > "question = (to) ? be : !be;" --Shakespeare http://telekinesis.org/
> >
> >
> > To Unsubscribe: send mail to majo...@FreeBSD.org
> > with "unsubscribe freebsd-hackers" in the body of the message
>
> --
> Ruslan Ermilov Sysadmin and DBA,
> r...@sunbay.com Sunbay Software AG,
> r...@FreeBSD.org FreeBSD committer,
> +380.652.512.251 Simferopol, Ukraine
>
> http://www.FreeBSD.org The Power To Serve
> http://www.oracle.com Enabling The Information Age
------------------------------
Date: Mon, 24 Mar 2003 16:02:19 +0300 (MSK)
From: Igor Sysoev <i...@rambler-co.ru>
Subject: Re: shared mem and panics when out of PV Entries
On Mon, 24 Mar 2003, Andrew Kinney wrote:
> The source of the PV Entry usage is shared memory in Apache
> (PHP and/or mod_perl). We know it's Apache memory sharing
> that causes the problem because nearly all PV Entries are freed
> when Apache is stopped and the problem is worst right after
> Apache starts when you have a lot of "clean" memory segments
> getting shared (10 to 11 million PV Entries used). After Apache
> has run for awhile and the shared memory segments become
> unshared due to them being "dirtied", the number of PV Entries
> used declines and settles in at a much lower number (3 to 5 million
> PV Entries used most days). Apache on this machine likes to
> hover right around 256 children processes, so you could see how
> requiring duplicate PV Entries per shared memory segment per
> Apache process could add up quite quickly.
>
> Under ideal circumstances, we'd correct our PHP/PERL code to
> avoid running into the issue at all, but this is customer code that
> we don't have much control over since we allow users to select and
> run their own CGI scripts without our intervention. So, for this
> instance, we have to solve it at the system level by bullet-proofing
> our system as much as possible.
How many Apache processes do you have and what's their size ?
> I've read that setting sysctl kern.ipc.shm_use_phys to "1" will
> cause shared memory segments not to use PV Entries at all.
> (See
> http://www.geocrawler.com/archives/3/159/2002/6/50/9031353/ )
> However, in the real world with FreeBSD 4.7, setting
> kern.ipc.shm_use_phys to "1" seems to have no visible effect on
> the number of PV Entries consumed by Apache memory sharing.
> We're currently running sysctl kern.ipc.shm_use_phys=1 and are
> still seeing the heavy PV Entry usage after rebooting (sysctl set on
> boot) with no apparent difference in usage.
>
> My thoughts at this point are leaning towards setting some limits
> on shared memory (kern.ipc.shmmax, kern.ipc.shmseg,
> kern.ipc.shmall, and kern.ipc.shmmax sysctl's) to limit the number
> of PV Entries that Apache can consume by way of shared
> memory. Is that a viable approach to this problem? What kind of
> gotchas and caveats should I watch out for in taking this approach?
> Any recommendations on which one to tweak first?
kern.ipc.shm_use_phys, kern.ipc.shmmax, etc are for System V shared memory.
They have no relation to the memory that shared between processes via fork().
Igor Sysoev
http://sysoev.ru/en/
------------------------------
Date: Mon, 24 Mar 2003 10:42:01 -0500 (EST)
From: John Baldwin <j...@FreeBSD.org>
Subject: Re: misc/41772: can't disable keybell [PATCH]
On 23-Mar-2003 sor...@cydem.org.ua wrote:
>
>> Using kbdcontrol -b off on my laptop running current does
>> turn off the sound already.
>
> I tested `kbdcontrol -b off` on FreeBSD 5.0-RELEASE, and it
> still did not turn off the beeper. I have also checked
> 'syscons.c', v. 1.399 ([0]), and foud only one change
> concerning keybell:
> 'if (cold || shutdown_in_progress || !enable_bell)' -
> ('enable_bell' added, which must be "hw.syscons.bell"
> sysctl var), that enables to turn the keybell off globally,
> but not for separate vtys.
>
>> Incidentally, using quiet.off doesn't
>> shut it up either which is very confusing since quiet sets
>> SC_QUIET_BELL.
>
> I tested this again, and it works fine:
>
> `kbdcontrol -b quiet.normal`
> `(sleep 2;echo -e "\x07";sleep 2)&`
> When, after executing this command, i quickly switch to
> another vty, I hear no bell; when I stay on the same vty,
> I can hear the bell.
>
>> PCI ID's for the ICH4 controllere were committed prior to 4.7.
>
> good, found my controller's ID in the latest CVSweb ATA-PCI tree
>
>> This patch would inadvertently turn off visual bell's if you
>> set the duration or pitch to zero manually. A better patch
>> might be:
>>
>> Index: syscons.c
>> ===================================================================
>> RCS file: /usr/cvs/src/sys/dev/syscons/syscons.c,v
>> retrieving revision 1.399
>> diff -u -r1.399 syscons.c
>> --- syscons.c 3 Mar 2003 16:24:44 -0000 1.399
>> +++ syscons.c 22 Mar 2003 14:38:58 -0000
>> @@ -3547,7 +3547,7 @@
>> if (scp != scp->sc->cur_scp)
>> scp->sc->blink_in_progress += 2;
>> blink_screen(scp->sc->cur_scp);
>> - } else {
>> + } else if (duration != 0 && pitch != 0) {
>> if (scp != scp->sc->cur_scp)
>> pitch *= 2;
>> sysbeep(pitch, duration);
>>
>> Can you verify that this fix works for you?
>
> yes, it does
> but, I think, this may produce faster code:
> + } else if (duration && pitch) {
Nope, optimizing like that is the compiler's job, not the authors.
Making readable code that follows style conventions leads to code
that is easier to maintain. :)
> I also found couple more problems:
>
> 00.
> `kbdcontrol -b 128.800`
> `(sleep 2;echo -e "\x07";sleep 2)&`
> If I stay on the same vty, I hear 800Hz bell, if I switch
> to another vty, I hear ~400Hz bell.
>
> `kbdcontrol -b normal`
> `(sleep 2;echo -e "\x07";sleep 2)&`
> If I stay on the same vty, I hear normal bell, if I switch
> to another vty, I hear a bell with pitch twice as _high_.
>
> 01.
> `kbdcontrol quiet.115.400` - won't set SC_QUIET_BELL flag
I have no idea about these other bugs.
- --
John Baldwin <j...@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
------------------------------
End of freebsd-hackers-digest V5 #753
*************************************
To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-hackers-digest in the body of the message