13.0-RELEASE iichid.ko breaks suspend/resume

[J.R. Oldroyd]

Asus S510UQ laptop

acpiconf -s 3 susp/resume works perfectly on 11.[12], 12.[012]

On 12.2 susp/resume worked with iichid.ko loaded from port
sysutils/iichid 0.0.6.

On 13.0-RELEASE susp/resume works when kernel iichid.ko is not loaded
but resume breaks if iichid.ko is loaded.

When loading modules in this order:
iicbus.ko   susp/resume works
ig4.ko  susp/resume works
hidbus.ko   susp/resume works
iichid.ko   susp/resume breaks
hidmap.ko
hms.ko
hidconf.ko
hmt.ko

When it breaks, system still suspends, but it does not resume.
Screen stays off, network is not pingable.  Hard power reset is needed.

Let me know if I can help debug.

-jr


pgpme8ZE7RO_s.pgp
Description: OpenPGP digital signature

Path error, failure in "make installworld" 10.2p20 -> 10.3p7

[J.R. Oldroyd]

Recently did a full source upgrade following the standard make
buildworld/buildkernel/installkernel/installworld sequence.  Went
from running 10.2p20 to latest 10.3p7.  Using source from svn
releng/10.3 revision r304958.

buildworld, buildkernel and installkernel all completed just fine.

The "make installworld" bombed out like this:

===> kerberos5/lib/libasn1 (install)  
install -C -o root -g wheel -m 444   libasn1.a /usr/lib
install -C -o root -g wheel -m 444   libasn1_p.a /usr/lib
install -s -o root -g wheel -m 444 libasn1.so.11 /usr/lib
install -l s libasn1.so.11 /usr/lib/libasn1.so
cmp -s pkinit_asn1.hx pkinit_asn1.h 2> /dev/null || cp pkinit_asn1.hx 
pkinit_asn1.h
cp: not found
*** Error code 127

The same error occurred in these three dirs:
kerberos5/lib/libasn1   
kerberos5/lib/libhdb
kerberos5/lib/libhx509

Looks like this was previously reported in 2014 and prior to that
in 2011.  See here:

http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2014-04/msg00194.html

The patch below fixed it for me.  I just added the "/bin/" path
to the two calls of cp(1).  That worked and the rest of the install
finished successfully.  Perhaps I should have used ${CP}, though,
but I didn't test that.  Similar patch in all three affected dirs.

-jr



# svn diff Makefile
Index: Makefile
===
--- Makefile(revision 304958)
+++ Makefile(working copy)
@@ -112,10 +112,10 @@
 .SUFFIXES: .h .c .x .hx
 
 .x.c:
-   cmp -s ${.IMPSRC} ${.TARGET} 2> /dev/null || cp ${.IMPSRC} ${.TARGET}
+   cmp -s ${.IMPSRC} ${.TARGET} 2> /dev/null || /bin/cp ${.IMPSRC} 
${.TARGET}
 
 .hx.h:
-   cmp -s ${.IMPSRC} ${.TARGET} 2> /dev/null || cp ${.IMPSRC} ${.TARGET}
+   cmp -s ${.IMPSRC} ${.TARGET} 2> /dev/null || /bin/cp ${.IMPSRC} 
${.TARGET}
 
 .include 
 
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: /etc/rc.d/ip6addrctl

[J.R. Oldroyd]

On Tue, 8 Jan 2013 16:02:43 -0500 "J.R. Oldroyd"  wrote:

> Seems to me that the ip6addrctl script should also prefer IPv6 if any
> interface has IPv6 enabled using one of the ifconfig_(interface)_ipv6
> variables.
> 
>   -jr
> 

A simple change along the lines of the attached patch, which also
prefers IPv6 if any i/f uses IPv6 autoconfig, will accomplish this.

-jr
--- ip6addrctl.orig	2013-01-04 00:07:03.0 -0500
+++ ip6addrctl	2013-01-08 16:28:53.0 -0500
@@ -62,7 +62,8 @@
 			ip6addrctl install "${config_file}"
 			checkyesno ip6addrctl_verbose && ip6addrctl
 		else
-			if checkyesno ipv6_activate_all_interfaces; then
+			ipv6auto=`list_net_interfaces autoconf`
+			if [ -n "$ipv6auto" ] || checkyesno ipv6_activate_all_interfaces; then
 ip6addrctl_prefer_ipv6
 			else
 ip6addrctl_prefer_ipv4
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

/etc/rc.d/ip6addrctl

[J.R. Oldroyd]

On Tue, 8 Jan 2013 19:46:09 +0100 Ulrich Spörlein 
wrote:

> Turns out it was the missing setting of
> ip6addrctl_policy="ipv6_prefer" in rc.conf that also bit me in
> strange and mysterious ways on another machine where I did the
> upgrade. It's very unfortunate that this will runtime-break sendmail
> and I honestly don't know why we make ipv4 the default in this day
> and age.
> 
> Can some IPv6 guru chime in here? This is all thoroughly confusing.
> 
> Thanks!
> Uli
> 

This bit me too, although with something other than sendmail.

It's /etc/rc.d/ip6addrctl that sets the preference for IPv6 or IPv4.  I
think the logic is a bit confusing here, or at least isn't consistent
with what the documentation for these settings (in rc.conf(5)) suggests.

In the startup script, IPv6 is preferred if:
either: ip6addrctl_policy is set to "ipv6_prefer"
or: ip6addrctl_policy is set to "auto", you've not
specified your own policy config file and
ipv6_activate_all_interfaces is set to true

In the documentation, it implies that using ipv6_activate_all_interfaces
is probably not needed for most users:
Note that it is not always necessary to set this variable to
“YES” to use IPv6 functionality on FreeBSD.  In most cases,
just configuring ifconfig_⟨interface⟩_ipv6 variables works.

Seems to me that the ip6addrctl script should also prefer IPv6 if any
interface has IPv6 enabled using one of the ifconfig_(interface)_ipv6
variables.

-jr
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FBSD 8.2R does not probe sound card

[J.R. Oldroyd]

Hi,

The info you attached below shows your problem.

First, read the association list at the bottom.  You have two associations,
0 for output and 1 for input.  Look at the output association 0.  It shows
the output is mapped to nid 20 seq 0 and then nid 27 seq 15.  The "seq"
tells you what it will use.  It will start at seq=0 then seq=1 then seq=2
etc, but seq=15 is special which means to use that if there's something
connected to the jack.  So yours will use nid 20 normally or nid 27 if
there's something connected to the jack.

Now look at the nids in the main list, AFTER where it says "Patched".
You see nid 20 is Line-out and nid 27 is Headphones.

So, nid 27 is OK (you want it to use the headphones if they are connected
to the jack), but nid 20 is not - nid 20 is your Line-out and you want
to use Speakers.  But all the Speaker nids are [DISABLED].

So you need to reprogram your HDAC.  You have four speaker possibilities,
nids 21, 22, 28 and 30.  I can't tell which one is the one you want, so
you'll need to try all four until you find it.  Use config in your
/boot/loader.conf.local like this:

hint.hdac.0.cad0.nid21.config="as=0 seq=0"
hint.hdac.0.cad0.nid27.config="as=0 seq=15"

Reboot and see if that works.  If not, replace the "21" with each
of 22, 28 and 30 and try again.  If you use verbose boot again, you
will see the Patched nid list and you can verify that the speaker
nid is not [DISABLED].

One thing puzzles me about your list.  All your speakers have a location
of "None".  Normally, you'd expect one to have location of "Fixed" and
that would be the built-in speaker.  Since you can't tell here which is
your built-in speaker, try all four and hope you find it.  If none of
the four work, you could try again explicitly setting the location:

hint.hdac.0.cad0.nid21.config="as=0 seq=0 device=Speaker conn=Fixed"

to see if that helps.

Note that if there is already configuration in either loader.conf.local
or loader.conf for "hint.hdac" you should comment that out first.

Also, be sure to run mixer each time to make sure that both the vol
and the pcm are turned up when you test.  Otherwise you won't hear
anything.

Your input side, association 1, is set to nid 24, 25 or 26 which are all
Mic and Line-in, so probably OK.  But if the mic doesn't work as expected,
you can try changing these around, too.

-jr


On Sat, 19 Mar 2011 21:41:53 +0700, Gua Chung Lim  
wrote:
>
> hdac0: Processing audio FG cad=0 nid=1...
> hdac0: GPIO: 0x4002 NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1
> hdac0:  nid 20 0x01014010 as  1 seq  0  Line-out  Jack jack  1 loc  1 
> color   Green misc 0
> hdac0:  nid 21 0x41f0 as 15 seq  0   Speaker  None jack  1 loc  1 
> color   Black misc 1
> hdac0:  nid 22 0x41f0 as 15 seq  0   Speaker  None jack  1 loc  1 
> color   Black misc 1
> hdac0:  nid 24 0x01a19830 as  3 seq  0   Mic  Jack jack  1 loc  1 
> colorPink misc 8
> hdac0:  nid 25 0x02a19831 as  3 seq  1   Mic  Jack jack  1 loc  2 
> colorPink misc 8
> hdac0:  nid 26 0x0181303f as  3 seq 15   Line-in  Jack jack  1 loc  1 
> colorBlue misc 0
> hdac0:  nid 27 0x0221401f as  1 seq 15Headphones  Jack jack  1 loc  2 
> color   Green misc 0
> hdac0:  nid 28 0x41f0 as 15 seq  0   Speaker  None jack  1 loc  1 
> color   Black misc 1
> hdac0:  nid 29 0x4004c601 as  0 seq  1  Line-out  None jack  4 loc  0 
> color   Res.C misc 6
> hdac0:  nid 30 0x41f0 as 15 seq  0   Speaker  None jack  1 loc  1 
> color   Black misc 1
> hdac0: Patched pins configuration:
> hdac0:  nid 20 0x01014010 as  1 seq  0  Line-out  Jack jack  1 loc  1 
> color   Green misc 0
> hdac0:  nid 21 0x41f0 as 15 seq  0   Speaker  None jack  1 loc  1 
> color   Black misc 1 [DISABLED]
> hdac0:  nid 22 0x41f0 as 15 seq  0   Speaker  None jack  1 loc  1 
> color   Black misc 1 [DISABLED]
> hdac0:  nid 24 0x01a19830 as  3 seq  0   Mic  Jack jack  1 loc  1 
> colorPink misc 8
> hdac0:  nid 25 0x02a19831 as  3 seq  1   Mic  Jack jack  1 loc  2 
> colorPink misc 8
> hdac0:  nid 26 0x0181303f as  3 seq 15   Line-in  Jack jack  1 loc  1 
> colorBlue misc 0
> hdac0:  nid 27 0x0221401f as  1 seq 15Headphones  Jack jack  1 loc  2 
> color   Green misc 0
> hdac0:  nid 28 0x41f0 as 15 seq  0   Speaker  None jack  1 loc  1 
> color   Black misc 1 [DISABLED]
> hdac0:  nid 29 0x4004c601 as  0 seq  1  Line-out  None jack  4 loc  0 
> color   Res.C misc 6 [DISABLED]
> hdac0:  nid 30 0x41f0 as 15 seq  0   Speaker  None jack  1 loc  1 
> color   Black misc 1 [DISABLED]
> hdac0: 2 associations found:
> hdac0: Association 0 (1) out:
> hdac0:  Pin nid=20 seq=0
> hdac0:  Pin nid=27 seq=15
> hdac0: Association 1 (3) in:
> hdac0:  Pin nid=24 seq=0
> hdac0:  Pin nid=25 seq=1
> hdac0:  Pin nid=26 seq=15


signature.asc
Description: PGP signature

Re: /usr/src fails to compile on 7.x after csup to RELENG_8

[J.R. Oldroyd]

[Slightly modified subject from the original posting back in June.]

William D. Colburn (Schlake)  wrote:
> 
> I can make the kernel just fine, but if I try to make the world I get this:
> 
> cc -O2 -pipe  -I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/compat 
> opensolaris
> -I/usr/src/cddl/usr.bin/zinject/../../compat/opensolaris/include
> -I/usr/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem
> -I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common
> -I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common
> -I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair
> -I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs
> -I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys
> -I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common
> -I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head
> -I/usr/src/cddl/usr.bin/zinject/../../lib/libumem
> -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector
> -Wno-unknown-pragmas  -o zinject zinject.o translate.o -lavl -lgeom
> -lm -lnvpair -lumem -luutil -lzfs -lzpool
> /lib/libthr.so.3: undefined reference to `__pselect at FBSDprivate_1.0'
> *** Error code 1
> 
> I searched, but I couldn't find anything on this problem.
> 

I just ran into this problem, too.  It turns out that it was due to
LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib being set which is causing
the loader to pick up the wrong library.

Clearing the problem and resuming the build ends up being simple:
# unset LD_LIBRARY_PATH
# make -DNO_CLEAN buildworld

(Csh users will need unsetenv).

-jr
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Freebsd 8.1 + xorg + radeonhd hang

[J.R. Oldroyd]

On Thu, 16 Sep 2010 18:20:35 +0200 (CEST), Eivind E  
wrote:
> 
> I'll try another card (not radeon) this evening, and if that works,
> I won't bother with the radeon anymore. This is my primary working
> machine and I need to be able to use it again. I do however
> wish to thank everybody for their hints and suggestions.
> 
> 

I've had a similar (but not the same problem).

My card is an RS880 [Radeon HD 4200] on an Asus M4A785-M
motherboard.  Problem here was that with either the radeonhd or
the ati driver and the radeon.ko module loaded, performance was
very slow indeed.  One could see the windows being repainted,
and xterm scroll was like a 1970's 1200 baud terminal!

I found that renaming the radeon.ko module so that it would
not be found when X.org goes to auto-load it, then unloading it
and restarting X gave me normal performance.  However, that came
without the benefit of xvideo support.

Finally I tried the radeonhd driver from the experimental port
in x11-drivers/xf86-video-radeonhd-devel.  This works perfectly
for me: good performance AND xvideo support.

Maybe this will help you too...

-jr
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Status of Flash 9 on stable

[J.R. Oldroyd]

On Fri, 17 Oct 2008 13:37:56 +0200, Tijl Coosemans <[EMAIL PROTECTED]> wrote:
>
> No audio often means libflashsupport can't find all lib dependencies.

I had noticed that a couple of dependencies were, in fact, missing.
Your email was very timely - I was just going to figure out how to
get them.  Deinstalling fc8 and installing the up-to-date version
in the ports solved the problem.

Flash9 with audio now OK here on 7-stable.

Great stuff, Tijl, and everyone else who worked on this.  Very much
appreciated.

-jr


signature.asc
Description: PGP signature

Re: Status of Flash 9 on stable

[J.R. Oldroyd]

On Thu, 16 Oct 2008 14:25:37 -0500, Mark Kane <[EMAIL PROTECTED]> wrote:
>
> I'm using RELENG_7 as of yesterday which appears to have the linprocfs
> fixes from CURRENT, and I also updated linux-flashplayer9 with the
> patch from the above PR.
> 
> When trying to use Flash 9 in linux-opera a few Flash items work (such
> as Adobe's test page which confirms it is using version 9 and sound
> does work on the rollovers there), but most things including YouTube
> videos or videos from other sites either do not play at all and lock up
> immediately or play for a few seconds and then lock up:
> 
> 
> opera: Plug-in 90514 is not responding. It will be closed.
> opera: Define environment variable OPERA_KEEP_BLOCKED_PLUGIN to keep
> blocked plug-ins.
> 
> 
> Trying with linux-firefox and linux-firefox-devel gives similar
> results except Firefox crashes entirely on most Flash sites.
> 
> I was using linux_base-fc4 and 2.4.2 however I updated to linux_base-f8
> and 2.6.16 since I saw others in the above emulation@ thread having
> success with f8. There doesn't seem to be any change with f8.
> 
> Is this still the expected behavior? I'm not sure if these fixes were
> supposed to fix everything related to Flash 9 or if there are still
> things to be done, so I'm just giving it a try and posting the results.
> I am running amd64 by the way.
> 
> Thanks very much in advance,
> 
> -Mark
> FreeBSD 7.1-PRERELEASE #14: Thu Oct 16 00:12:09 CDT 2008 amd64
> 

It works here, although my 7-stable is a few days old and I applied
the linprocfs.c patch by hand.

I also used the pre-compiled libflashsupport.so binary referred to in
the thread.

Then used nspluginwrapper to add links for native apps.

Linux support is fc8.

It works in native firefox3, albeit without audio.  Firefox does not
crash.  Flash apps quietly run to completion.  Youtube works.

It does not work in native opera.

-jr


signature.asc
Description: PGP signature

ACPI blacklist regression on 7.1 on old VAIO

[J.R. Oldroyd]

Just upgraded the system on my old VAIO laptop from 7-stable of mid-Aug
to 7-stable now and this, of course, got me 7.1-PREREL.

At boot time, my ACPI is now disabled due to blacklist.  It has never been
blacklisted before.  If I set hint.acpi.0.disabled=0, everything still
works fine.

What info is needed to un-blacklist this system?

-jr


signature.asc
Description: PGP signature

Low CPU Freq responsible for xterm pixel corruption on RELENG_7

[J.R. Oldroyd]

Some weeks ago, I posted on the x11@ list of a problem of pixel corruption
I am seeing in xterm windows.  An example of the problem can still be
seen here:
http://opal.com/jr/xterm-corruption.gif

Quick summary: Wide xterm windows (wider than 158 columns, 1440 pixels)
have the problem shown, but only when at least that many columns are on
the screen.  That is, moving a wide window so that it is partially off
the screen causes the corruption to cease when less than 158 columns
are displayed.

Further investigation has unearthed that this problem happens only when
the CPU frequency is set to low levels, which was happening because of
powerd.  When the CPU frequency is set low, these pixel corruptions happen.
When the CPU freq is raised they do not: everything is normal.

Disabling powerd and manually adjusting the CPU frequency gives these results:

# sysctl dev.cpu.0.freq_levels
dev.cpu.0.freq_levels: 3176/-1 2779/-1 2382/-1 1985/-1 1588/-1 1191/-1 794/-1 
397/-1

CPU freq from 3176 to 1191 causes no problems.
CPU freq at 794 or 397 causes pixel corruptions.

This problem did not happen on RELENG_6.

-jr


signature.asc
Description: PGP signature

Re: 7.0-PRERELEASE desktop system periodically freezes momentarily

[J.R. Oldroyd]

On Wed, 23 Jan 2008 08:27:58 -0700, Joe Peterson <[EMAIL PROTECTED]> wrote:
> 
> Also, it seems that intermittent mouse freezes happen more often when
> I've been away from the machine for a while and return to start using
> the mouse again, but that's not always the case.  A few short
> freezes/stutters happen a second or so after mouse movement resumes.
> 
>   -Joe

Joe,

I don't see any postings from you showing any ktr dumps.  Do you have
any?  Your symptoms (that it seems to happen after you've been away
for a while and then return and move the mouse) sound a lot like mine.

I posted some ktr dumps and have since chatted off-list with Kris and
Sam about what may be up.  My dumps show the shared irq ath/pcm and
the ath taskq are hogging the cpu for ages without the clock swi getting
to run at all.  Sam has suggested experimenting with the ath taskq
priority and also with disabling ath bg scans which I will do, but
right now I am back to looking at powerd again as the possible cause.

I ran without powerd for a while when originally suggested by David
Lawrence on Jan 12th.  I believe I did still see freezes then, but I
re-enabled powerd when I was ready to do LOCK_PROFILING and then ktr
monitoring; I re-enabled it so I could be sure I had the same test
conditions.  At this point, I am no longer sure what happened when
powerd was disabled.  My recollection is that there were freezes while
powerd was off, but the only email in which I appear to have posted
about that says "no freezes so far".  So I'm running without powerd again,
and at this point, several hours at the computer over two days, I have
not seen further freezes.  Does anyone else who sees these freezes also
have powerd enabled and can try without powerd for a while?

Since these freezes are proving so hard to pinpoint, it may be worth
comparing notes to try to find things in common between the systems
or eliminate other things.  But first, it seems like we may be chasing
three separate causes:

1. the softupdate freeze
after removing a very large file (e.g., >1Gb) there is a
noticeable freeze while the softupdate runs 

2. the busy freeze
folk complain of short freezes and mouse jerkiness while
the system is busy, e.g., glxgears or compilations

3. the idle freeze
short and longer freezes (some going into minutes) apparently
when resuming work after having left the system mostly idle
for a while

Now, I also had the "busy freeze" when I first tested 7.0.  At that time
(several weeks back now) someone suggested switching to the ULE scheduler,
which I did, and the symptoms I had were dramatically improved.  Since
then I've had occasions to run several compilations at once and had no
mouse jerkiness.  But for folk who still have it: what scheduler do you
have and what processes are running when it happens?

At the moment, I'm chasing an "idle freeze".  In other emails, I've
posted details of what processes are typically running and several ktr
dumps of such events.  As noted, I'm looking again into powerd right
now, and if that isn't it, I'll go to the ath taskq prio and scan stuff
that Sam suggested.  Anyone else with an idle freeze care to post
details of what scheduler and processes are in use?

-jr


signature.asc
Description: PGP signature

Re: RELENG_7 2008/01/10 desktop system also periodically freezes

[J.R. Oldroyd]

Here is another ktr dump.  This freeze was a longer one, getting on for
two minutes:
http://opal.com/jr/freebsd/releng_7-freeze/200801141259-ktr.out

This one again shows some post-freeze activity, and yet again the only
activity during the freeze is that shared ath0/pcm irq and the ath0 taskq.

-jr


signature.asc
Description: PGP signature

Re: RELENG_7 2008/01/10 desktop system also periodically freezes

[J.R. Oldroyd]

Yet another:
 http://opal.com/jr/freebsd/releng_7-freeze/200801132359-ktr.out

Shows just the same as the first, just:
CPU 0
irq 17: pcm0 ath0
ath0 taskq

-jr



signature.asc
Description: PGP signature

Re: RELENG_7 2008/01/10 desktop system also periodically freezes

[J.R. Oldroyd]

Well, after running the ktr_sched-enabled kernel for about 4h50 now, I
did just see a short freeze.  Abt 2-3 seconds.  And I got a ktr dump
right after it came back.  It can be downloaded here (I guess rt-click
and save the link):
http://opal.com/jr/freebsd/releng_7-freeze/200801132250-ktr.out

When I run schedgraph, all it shows for the whole period is just:
CPU 0
irq 17: pcm0 ath0
ath0 taskq
that's it.  I have a shared irq between ath and the sound.  Funnily
enough, within a few mins before the freeze, I was just listening
to a voicemail (i.e., I ran mplayer on a .wav file), but that was done
easily a minute or more before the freeze.  I tried repeating that,
listening to the file and waiting a bit, but no more freezes.  So not
sure if this is a possible indication of the cause, or not.  It's
annoying not to be able to find a way of triggering this problem on
demand, though.

Anyway, I looked at the other system where I've had long freezes.
It has a shared [irq9: pcm0 cbb0++*] and on cbb0 I have an ath card!
So there, too, is an irq shared between pcm and ath.  On this system,
if I find I'm in a long freeze and don't want to be, I've found that
pulling the ath card causes an immediate un-freeze.

Admittedly, based on the recent days' discussion in this thread, I
was more expecting to see moused or powerd or an xorg problem.

Oh! Another freeze, right then!  This dump shows pcm0/ath0 too, but
also a bit more activity just after the return.
http://opal.com/jr/freebsd/releng_7-freeze/200801132337-ktr.out
This time I was not listening to sound.  I was typing this email.

Wasn't there a thread about shared irqs here (or maybe on current)
recently?

-jr


signature.asc
Description: PGP signature

Re: RELENG_7 2008/01/10 desktop system also periodically freezes

[J.R. Oldroyd]

On Sun, 13 Jan 2008 22:29:34 +0100, "Ronald Klop" <[EMAIL PROTECTED]> wrote:
>
> What version of xf86-video-intel? I'm having trouble since I upgraded  
> xf86-video-i810, which is an older version of the intel driver, from 1.6.x  
> to 1.7.x and a colleague had trouble with the 2.x version of the  
> xf86-video-intel driver.

xf86-video-intel-2.1.1

> My trouble is a hanging system (I never waited for it to come back) and  
> then ctrl-alt-F1 (to console) gives a panic a lot of times. I just  
> prepared my machinde for a crash dump. So maybe next panic I have one.
> 

I have not seen any panics switching between vtys.  Your "hang" might
be the same as my long freeze.  Next time it happens, try waiting for
a while.  I've had some freezes many minutes long.  A 9 min one yesterday,
and I've had a 12 min one before.  Just move the mouse and then sit back
until the cursor actually moves!

> Maybe downgrading to 1.6.x helps me again. After the next panic I'll try  
> that. But maybe it helps you also.
>
When I started my 7.0BETA testing the installation process gave me
xf86-video-i810 and I had several other problems which resolved on
switching to the xf86-video-intel driver.  I'd be hesitant to go
back.
 
> I upgrade my RELENG_7 about every week, so it's fairly recent.
> 
> Ronald.
> 

Mine is now also up-to-date RELENG_7.

David's suggestion re powerd may be relevant.  I'd noticed that the
problem seems to happen when the system is idle.  I posted earlier that
it seems like I can do all sorts of work without a problem then I stop for
a phone call and when I resume it hangs.  I tend to notice a lot of hangs
when typing an email.  I have disabled powerd for now; don't really need
it anyway, that was a left-over from something quite some time back.  No
freezes yet, but it'll take several more hours to know if this might be
relevant.

-jr


signature.asc
Description: PGP signature

Re: RELENG_7 2008/01/10 desktop system also periodically freezes

[J.R. Oldroyd]

On Sat, 12 Jan 2008 13:40:34 -0500, I wrote:
>
> Ah!  Just experienced a short freeze ...

And another!  This one about 3 or 4 seconds.

The profile from the last minute is here:
http://opal.com/jr/freebsd/releng_7-freeze/200801121342-unknown.txt

This one shows a long hold_avg (I meant hold_avg in the previous
message, too) for:
/usr/src/sys/kern/vfs_vnops.c:515 (lockmgr:ufs)

-jr


signature.asc
Description: PGP signature

Re: RELENG_7 2008/01/10 desktop system also periodically freezes

[J.R. Oldroyd]

On Sat, 12 Jan 2008 12:30:53 -0500, I wrote:
>
> On Fri, 11 Jan 2008 12:49:29 -0500, I wrote:
> >
> > I have yet to experience a "random" freeze not directly attributable
> 
> It is looking more likely to me that enabling lock profiling does mask
> ...
> 
> At the time of that long freeze, all I was doing was typing an email
> message.  The load average was almost 0.  Mail client is claws-email.
> Also running but idle were firefox, ical, several xterms, fvwm & its
> children (Fvwm{Buttons,Event,Pager,IconMan}), xload and xclock.  And
> xorg which uses the xf86-video-intel driver.  Daemons running were
> wpa_supplicant, dhclient, devd, syslogd, cupsd, ntpd, powerd, sshd,
> sendmail, cron, moused and xdm.  That is all.
> 
> I had only one browser window open, the last page I'd viewed there
> was one containing some flash, I have linux-flash7 installed and
> nspluginwrapper to make that work in the native browser.
> 

Ah!  Just experienced a short freeze (it seemed like about 5 secs) while
lock profiling was enabled.

The profile from the last minute is here:
http://opal.com/jr/freebsd/releng_7-freeze/200801121331-unknown.txt

There's an almost 4 second wait_avg for:
/usr/src/sys/sys/buf.h:280 (lockmgr:bufwait)

I had exactly the same mix of programs open as shown above.

-jr


signature.asc
Description: PGP signature

Re: RELENG_7 2008/01/10 desktop system also periodically freezes

[J.R. Oldroyd]

On Fri, 11 Jan 2008 12:49:29 -0500, I wrote:
>
> I have yet to experience a "random" freeze not directly attributable
> to a softupdate while running the lock profiling.  I am running with
> lock profiling on, and resetting the profiling counters once a minute.
> Yesterday and this morning, I've run for quite a while now with lock
> profiling on but without a "random" freeze.  I'll wait some more, but
> I'm hoping that enabling the lock profiling hasn't masked the freeze.
> I'll post again when I see one..
> 

It is looking more likely to me that enabling lock profiling does mask
the freeze.  I ran for more than 10 hours yesterday with lock profiling
enabled and did not observe a single freeze.  After about 7 hours, I
stopped the lock profiling and within 20 mins or so, I experienced a
NINE MINUTE freeze!!  On re-enabling the lock profiling, I ran for about
3 more hours with no further freezes.

At the time of that long freeze, all I was doing was typing an email
message.  The load average was almost 0.  Mail client is claws-email.
Also running but idle were firefox, ical, several xterms, fvwm & its
children (Fvwm{Buttons,Event,Pager,IconMan}), xload and xclock.  And
xorg which uses the xf86-video-intel driver.  Daemons running were
wpa_supplicant, dhclient, devd, syslogd, cupsd, ntpd, powerd, sshd,
sendmail, cron, moused and xdm.  That is all.

I had only one browser window open, the last page I'd viewed there
was one containing some flash, I have linux-flash7 installed and
nspluginwrapper to make that work in the native browser.

All code (kernel, world and ports) have been compiled locally - there
are no packages installed.  Kernel is RELENG_7 from two days ago,
world and ports are about one month old.

If I get time today I may have a go at getting schedgraph info
instead of continuing with lock profiling.

-jr


signature.asc
Description: PGP signature

Re: RELENG_7 2008/01/10 desktop system also periodically freezes

[J.R. Oldroyd]

On Thu, 10 Jan 2008 08:32:12 +0100, Kris Kennaway <[EMAIL PROTECTED]> wrote:
>
> J.R. Oldroyd wrote:
> > On Wed, 09 Jan 2008 20:38:29 +0100, Kris Kennaway <[EMAIL PROTECTED]> wrote:
> >>
> >> OK, same requests as to the others then.
> >>
> > 
> > I presume you mean hwpmc...
> 
> LOCK_PROFILING, sched_graph, hwpmc.
> 

Quick update on this so that folk know what's going on.

Firstly, I've updated the code here to RELENG_7 csup'd yesterday and
if I run a "normal" kernel, without debugging, I do see the same freezes
with that, too.

Secondly, I am unable to process hwpcm dumps using pmcstat because it
core dumps when using the "-R" option to decode a dump.  I will talk to
jkoshy@ about that.

I am now running a kernel with LOCK_PROFILING.  I am able to create a
freeze due to the softupdate activity by removing a large file; a lock
profile captured surrounding such a freeze can be seen here:
http://opal.com/jr/freebsd/releng_7-freeze/20080135-softupdate.txt
This is easily repeatable.  The sequence is:
create 1.5GB file
sysctl debug.lock.prof.enable=1
rm file
... wait, moving mouse until it freezes then unfreezes ...
sysctl debug.lock.prof.enable=0
sysctl debug.lock.prof.stats
Kostik, is this of any help to you?

I have yet to experience a "random" freeze not directly attributable
to a softupdate while running the lock profiling.  I am running with
lock profiling on, and resetting the profiling counters once a minute.
Yesterday and this morning, I've run for quite a while now with lock
profiling on but without a "random" freeze.  I'll wait some more, but
I'm hoping that enabling the lock profiling hasn't masked the freeze.
I'll post again when I see one..

-jr


signature.asc
Description: PGP signature

Re: 7.0BETA4 desktop system also periodically freezes

[J.R. Oldroyd]

On Thu, 10 Jan 2008 07:33:03 +0200, Kostik Belousov <[EMAIL PROTECTED]> wrote:
>
> 
> For the SU-imposed jerkiness, try the patch below. Progress on developing
> the change stalled somehow, and I would like to process with it.
> 
> diff --git a/sys/kern/vfs_mount.c b/sys/kern/vfs_mount.c
> index 248ce22..005f915 100644
> --- a/sys/kern/vfs_mount.c
> +++ b/sys/kern/vfs_mount.c
> @@ -2001,6 +2001,12 @@ __mnt_vnode_next(struct vnode **mvp, struct mount *mp)
>   mtx_assert(MNT_MTX(mp), MA_OWNED);
>  
>   KASSERT((*mvp)->v_mount == mp, ("marker vnode mount list mismatch"));
> + if ((*mvp)->v_yield++ == 500) {
> + MNT_IUNLOCK(mp);
> + (*mvp)->v_yield = 0;
> + uio_yield();
> + MNT_ILOCK(mp);
> + }
>   vp = TAILQ_NEXT(*mvp, v_nmntvnodes);
>   while (vp != NULL && vp->v_type == VMARKER)
>   vp = TAILQ_NEXT(vp, v_nmntvnodes);
> diff --git a/sys/sys/vnode.h b/sys/sys/vnode.h
> index 0525a43..1ac289a 100644
> --- a/sys/sys/vnode.h
> +++ b/sys/sys/vnode.h
> @@ -131,6 +131,7 @@ struct vnode {
>   struct socket   *vu_socket; /* v unix domain net (VSOCK) */
>   struct cdev *vu_cdev;   /* v device (VCHR, VBLK) */
>   struct fifoinfo *vu_fifoinfo;   /* v fifo (VFIFO) */
> + int vu_yield;   /*   yield count (VMARKER) */
>   } v_un;
>  
>   /*
> @@ -185,6 +186,7 @@ struct vnode {
>  #define  v_socketv_un.vu_socket
>  #define  v_rdev  v_un.vu_cdev
>  #define  v_fifoinfo  v_un.vu_fifoinfo
> +#define  v_yield v_un.vu_yield
>  
>  /* XXX: These are temporary to avoid a source sweep at this time */
>  #define v_object v_bufobj.bo_object
> diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c
> index a221b66..02cf45b 100644
> --- a/sys/ufs/ffs/ffs_softdep.c
> +++ b/sys/ufs/ffs/ffs_softdep.c
> @@ -864,6 +864,7 @@ softdep_process_worklist(mp, full)
>*/
>   if (loopcount++ % 128 == 0) {
>   FREE_LOCK(&lk);
> + uio_yield();
>   bwillwrite();
>   ACQUIRE_LOCK(&lk);
>   }


Applied this patch.  No change when deleting 1Gb files - the system
still freezes briefly during the deallocation.

-jr


signature.asc
Description: PGP signature

Re: 7.0BETA4 desktop system also periodically freezes

[J.R. Oldroyd]

On Wed, 09 Jan 2008 20:38:29 +0100, Kris Kennaway <[EMAIL PROTECTED]> wrote:
>
> 
> OK, same requests as to the others then.
> 

I presume you mean hwpmc...

In setting that up, I may have stumbled upon a possible cause.
I ran pmcstat for a while and ended up with a very large output
file.  Having not noticed any freezes during that time, I decided
to start over with the output to a different filesystem with more
free space.  When I removed that first output file, the resulting
disk i/o for the block deallocation caused a very similar freeze
for a few seconds.  And when it came back, the load average graph
peaked up, just as before.

This appears to be repeatable:

1. create a very large file, say 1Gb or so
2. remove it
3. observe freeze during file dealloc i/o activity

This on an ata drive, ufs filesystem with softupdates.

Folk complaining of jerky mouse syndrome (e.g., during compilations)
may be seeing the same - the compiler creates and removes lots of
files.

I'm not sure how this would explain those longer freezes (30s or
several minutes) though.
 
-jr


signature.asc
Description: PGP signature

Re: 7.0BETA4 desktop system also periodically freezes

[J.R. Oldroyd]

I believe this same problem may also be present on 7.0, at least on
the BETA releases; BETA4 is the latest I have here.

I have the same problem on two systems here: periodically the systems
will stop dead (no mouse action, no ping responses from other systems,
processes with windows on the screen also freeze); the hangs can be
anything from a few seconds to several MINUTES; then it all comes back
"as if nothing happened" except that keyboard input during the freeze
is lost.  Most of my freezes are a few seconds long, some are in the
15-60 second range, but (fortunately, rarely) I have seen some that
lasted 10-15 MINUTES!

The only obvious indication after the return is that the system load
average monitor peaks up, typically from the 0-0.5 range before the
hang to 1.5-2 after the hang, then immediately decays back down.  Just
as if some real-time prio process had grabbed the processor exclusively
for a while.  Except I have no rtprio processes that I know of.

It is not swap related.  One of the systems here has 4GB ram and is
not swapping, even after one of these freezes.  It doesn't even swap
while running X, with the mailer open, several xterms and firefox and
a make running.

I had not reported this because I figured this was yet another problem
with xorg-7.3.  I am unable to make it happen on demand.  As yet it
seems random.  I am able to do CPU-intensive stuff (e.g., port builds)
without problems: it doesn't trigger the freeze and I don't even see
the jerky mouse problem that folk also talk of.  I am running a make
right now in fact, just to see if it'll do it.  Of course, it's fine.

But the phone might ring, so I'll stop doing things, the system will
become pretty-much idle, then I'll go to move the mouse and it might be
frozen.  When it comes back, the small load peak shows, but top and ps
show nothing unusual.

As I said, I have two systems here which exhibit this.  Both systems
here are 7.0BETA4.  Different i386 hardware; both are UP systems; one is
a fast 3200Ghz processor with 4GB ram, the other is a very slow
processor with not much ram at all; the scheduler is SCHED_ULE on both;
and the app mix includes basic servers:
/usr/sbin/wpa_supplicant
dhclient
/sbin/devd
/usr/sbin/syslogd
/usr/local/sbin/cupsd
/usr/sbin/ntpd
/usr/sbin/powerd
/usr/sbin/sshd
sendmail
/usr/sbin/cron
/usr/sbin/moused
/usr/local/bin/xdm (on the fast system only)
/usr/local/bin/X
and various end-user clients such as a WM and its children (including
load graph and a clock), firefox, xterms, ical, nvi, etc.

Because it is unpredictable, I don't have any profiling of this for
you.  But I wanted to throw this out there since I am not sure the
problem is 6.x-related.

Oh, both systems ran 6.2-stable with xorg-6.9 and didn't have this
problem.  Also, there doesn't seem to be any indication of hardware
issues on either.

-jr



signature.asc
Description: PGP signature

Re: psm GlidePoint problems on 7.0b3

[J.R. Oldroyd]

On Mon, 19 Nov 2007 16:29:38 -0500, "J.R. Oldroyd" <[EMAIL PROTECTED]> wrote:
>
> [7.0b3 on a Sony VAIO laptop with an ALPS GlidePoint touchpad.
>  System ran 6.2 and earlier FreeBSD versions without problems.]
> 
> 3. occasionally when moving the cursor using the touchpad, the coordinates
>suddenly jump unexpectedly to a new place on the screen, as in several
>hundred pixels away.  These jumps seem to be of varying x and y offsets
>and direction.  I am also seeing occasional menu pop-ups as if left-clicks
>or keyboard input (such as Alt-F) has been done - but all I am doing is
>moving the mouse using the touchpad!
>
This problem appears to be related to mouse acceleration settings.

I discovered that, for years, I have used "xset m 3/1" in my X startup.
Removing it eliminates this problem.  But, the mouse is then too slow.

I've looked at the -a and -A options on moused, instead.  The problem
returns, albeit to a lesser extent.

What I'd previously described as large jumps and occasional keyboard
input might more likely be sudden sequences of unexpected jump-tap
events, some of which cause menu or popup openings, text selection or
window focus changes, depending on where the cursor went.  This when all
I am doing is moving the cursor using the touchpad.  This suggests a
touchpad calibration problem.

Since there doesn't seem to be any other outcry about GlidePoint problems
on 7.0 and since this worked fine for me under 6.2-stable, perhaps I just
need to find better settings for use with 7.0.  Anyone else using a GlidePoint
touchpad care to suggest moused and/or X mouse settings?

  
> 2. after every [ACPI] resume it's as if a middle-click has been done: the last
>selected text is pasted back again.  This could have possibly serious
>consequences depending on what text is present and what application
>the mouse is over when the unwanted paste occurs.
> 
I'm no closer to solving this one.  It is easily repeatable for me:
- in X, use left-click to select some text (in any application)
- give the focus to an xterm window (e.g., move cursor to an
xterm window, or click on one)
- suspend the system (mine suspends to S5)
- resume the system
- observe that previously selected text is now pasted in the
  xterm window

Any thoughts?

-jr



signature.asc
Description: PGP signature

psm GlidePoint problems on 7.0b3

[J.R. Oldroyd]

Just installed 7.0b3 on a Sony VAIO laptop which has an ALPS GlidePoint
touchpad.  System ran 6.2 and earlier FreeBSD versions without problems.

On 7.0b3, there are several touchpad problems.  Things work fine after
the initial boot, both on the console and in xorg.

I am running moused:
/usr/sbin/moused -3 -m 1=4 -p /dev/psm0 -t auto

and have the following in xorg.conf:
Section "InputDevice"
Identifier  "Mouse0"
Driver  "mouse"
Option  "Protocol" "auto"
Option  "Device" "/dev/sysmouse"
EndSection

Those settings have been there for years, over several earlier FreeBSD
versions, without problems.

But now, on 7.0b3, after an APCI suspend and resume:

1. the touchpad's tap feature no longer works
=> adding hint.psm.0.flags="0x6000" to set HOOKRESUME and
   INITAFTERSUSPEND seems to cure this, despite this not being
   needed under previous FreeBSD versions.

2. after every resume it's as if a middle-click has been done: the last
   selected text is pasted back again.  This could have possibly serious
   consequences depending on what text is present and what application
   the mouse is over when the unwanted paste occurs.

3. occasionally when moving the cursor using the touchpad, the coordinates
   suddenly jump unexpectedly to a new place on the screen, as in several
   hundred pixels away.  These jumps seem to be of varying x and y offsets
   and direction.  I am also seeing occasional menu pop-ups as if left-clicks
   or keyboard input (such as Alt-F) has been done - but all I am doing is
   moving the mouse using the touchpad!

dmesg is:
atkbdc0:  port 0x60,0x64 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0:  flags 0x6000 irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model GlidePoint, device ID 0

Other than the 0x6000 flags hint, I have not changed any of the mouse
settings during the freebsd-7.0 upgrade.  Are some other changes needed?
Or is this indicative of a possible bug in the mouse driver?

Thanks,
-jr


signature.asc
Description: PGP signature

[SOLVED] Re: freebsd-7.0b1 xorg-7.3_1 runs only once

[J.R. Oldroyd]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 02 Nov 2007 13:24:04 -0700, Mark Atkinson <[EMAIL PROTECTED]> wrote:
>
> 
> J.R. Oldroyd wrote:
> >> xorg-7.3_1 runs fine, but just once.
> >> 
> >> Subsequent attempts to start xorg result in:
> >> (EE) I810(0): V_BIOS address 0x0 out of range
> >> (EE) I810(0): VBE initialization failed.
> >> (EE) Screen(s) found, but none have a usable configuration.
> >> 
> I also have this problem on with the i915 module.  There are some
> differences in agp between -current/7.0 and -stable, but i915 and drm have
> been MFC'd between stable and current, so I'm not sure what's up.
> 

The problem goes away if you deinstall x11-drivers/xf86-video-i810 and
use in its place x11-drivers/xf86-video-intel.

There's further discussion about this over on the x11@ list.

-jr
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQFHLjiils33urr0k4kRAstkAJ4oak02MEwL3As1EqEx4CWGpFwiAACfb2oF
4OJkloq7/t7hhep5c6DSTGI=
=m4jU
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: freebsd-7.0b1 xorg-7.3_1 runs only once

[J.R. Oldroyd]

Adding some additional information...

On Wed, 31 Oct 2007 18:34:51 -0400, "J.R. Oldroyd" <[EMAIL PROTECTED]> wrote:
>
> xorg-7.3_1 runs fine, but just once.
> 
> Subsequent attempts to start xorg result in:
> (EE) I810(0): V_BIOS address 0x0 out of range
> (EE) I810(0): VBE initialization failed.
> (EE) Screen(s) found, but none have a usable configuration.
> 

Noticed that running xorg the first time loads drm and i915.  I also see
that i915.ko and drm.ko are modules.  On unloading them, I see this:

drm0: detached
Warning: memory type drm leaked memory on destroy (4 allocations, 128 bytes 
leaked).

Reloading them and running xorg again doesn't fix the V_BIOS out of
range problem; xorg still doesn't start more than once.

Since my last posting I have recompiled the kernel and all the xorg
ports just to make sure I didn't mess something up the first time.  No
change.

I'd appreciate thoughts from someone who's into stuff like V_BIOS and
drm and i915 and xorg.

-jr
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

freebsd-7.0b1 xorg-7.3_1 runs only once

[J.R. Oldroyd]

Just upgraded a desktop machine from 6.2-stable to 7.0beta1.  Csup'd the
kernel source and portsnap'd the latest ports on Oct 29th.  Compiled
everything locally.  Removed all old files, libs, etc.  Everything looks
good, except...


xorg-7.3_1 runs fine, but just once.

Subsequent attempts to start xorg result in:
(EE) I810(0): V_BIOS address 0x0 out of range
(EE) I810(0): VBE initialization failed.
(EE) Screen(s) found, but none have a usable configuration.

Xorg.0.log then ends in:
(II) Module vgahw: vendor="X.Org Foundation"
compiled for 1.4.0, module version = 0.1.0
ABI class: X.Org Video Driver, version 2.0
(==) I810(0): Depth 24, (==) framebuffer bpp 32
(==) I810(0): RGB weight 888
(==) I810(0): Default visual is TrueColor
(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Reloading /usr/local/lib/xorg/modules//libint10.so
(II) I810(0): initializing int10
(==) I810(0): Write-combining range (0xa,0x2) was already clear
(==) I810(0): Write-combining range (0xc,0x4) was already clear
(EE) I810(0): V_BIOS address 0x0 out of range
(EE) I810(0): VBE initialization failed.
(II) UnloadModule: "i810"
(II) UnloadModule: "int10"
(II) UnloadModule: "vgahw"
(II) Unloading /usr/local/lib/xorg/modules//libvgahw.so
(II) UnloadModule: "vbe"
(II) Unloading /usr/local/lib/xorg/modules//libvbe.so
(II) UnloadModule: "int10"
(II) Unloading /usr/local/lib/xorg/modules//libint10.so
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found

On the good starts, Xorg.0.log contains:
(II) Module vgahw: vendor="X.Org Foundation"
compiled for 1.4.0, module version = 0.1.0
ABI class: X.Org Video Driver, version 2.0
(==) I810(0): Depth 24, (==) framebuffer bpp 32
(==) I810(0): RGB weight 888
(==) I810(0): Default visual is TrueColor
(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Reloading /usr/local/lib/xorg/modules//libint10.so
(II) I810(0): initializing int10
(==) I810(0): Write-combining range (0xa,0x2) was already clear
(==) I810(0): Write-combining range (0xc,0x4) was already clear
(II) I810(0): Primary V_BIOS segment is: 0xc000
(==) I810(0): Write-combining range (0x0,0x1000) was already clear
(II) I810(0): VESA BIOS detected
(II) I810(0): VESA VBE Version 3.0
(II) I810(0): VESA VBE Total Mem: 8000 kB
(II) I810(0): VESA VBE OEM: Intel(r)865G Graphics Chip Accelerated VGA BIOS
(II) I810(0): VESA VBE OEM Software Rev: 1.0
(II) I810(0): VESA VBE OEM Vendor: Intel Corporation
(II) I810(0): VESA VBE OEM Product: Intel(r)865G Graphics Controller
(II) I810(0): VESA VBE OEM Product Rev: Hardware Version 0.0
(II) I810(0): Integrated Graphics Chipset: Intel(R) 865G
(--) I810(0): Chipset: "865G"
(--) I810(0): Linear framebuffer at 0xF000
(--) I810(0): IO registers at addr 0xFE78
(==) I810(0): Write-combining range (0xfe78,0x8) was already clear
(II) I810(0): 1 display pipe available.
(II) I810(0): detected 8060 kB stolen memory.
(II) I810(0): Kernel reported 491520 total, 0 used
(II) I810(0): I830CheckAvailableMemory: 1966080 kB available
(II) I810(0): Will attempt to tell the BIOS that there is 12288 kB VideoRAM
(WW) I810(0): Extended BIOS function 0x5f11 not supported.
(==) I810(0): Write-combining range (0x0,0x1000) was already clear
...


On 6.2-stable, xorg worked repeatedly.

On 7.0b1, need to reboot system before xorg will run once again
(pun intended).

-jr
--- Begin Message ---
Just upgraded a desktop machine from 6.2-stable to 7.0beta1.  Csup'd the
kernel source and portsnap'd the latest ports on Oct 29th.  Compiled
everything locally.  Removed all old files, libs, etc.  Everything looks
good, except...


xorg-7.3_1 runs fine, but just once.

Subsequent attempts to start xorg result in:
(EE) I810(0): V_BIOS address 0x0 out of range
(EE) I810(0): VBE initialization failed.
(EE) Screen(s) found, but none have a usable configuration.

Xorg.0.log then ends in:
(II) Module vgahw: vendor="X.Org Foundation"
compiled for 1.4.0, module version = 0.1.0
ABI class: X.Org Video Driver, version 2.0
(==) I810(0): Depth 24, (==) framebuffer bpp 32
(==) I810(0): RGB weight 888
(==) I810(0): Default visual is TrueColor
(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Reloading /usr/local/lib/xorg/modules//libint10.so
(II) I810(0): initializing int10
(==) I810(0): Write-combining range (0xa,0x2) was already clear
(==) I810(0): Write-combining range (0xc,0x4) was already clear
(EE) I810(0): V_BIOS address 0x0 out of range
(EE) I810(0): VBE initialization failed.
(II) UnloadModule: "i810"
(II) UnloadModule: "int10"
(II) UnloadModule: "vgahw"
(II) Unloading /usr/local/lib/xorg/modules//libvgahw.so
(II) UnloadModule: "vbe"
(II) Unloading /usr/local/lib/xorg/modules//libvbe.so
(II) UnloadModule: "int10"
(II) Unloading /usr/local/lib/xorg/modules//libint10.so
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
n

vge0: watchdog timeout

[J.R. Oldroyd]

I am seeing this:

kernel: vge0: watchdog timeout
kernel: vge0: link state changed to DOWN
kernel: vge0: link state changed to UP

periodically on 6.2-stable on a system running on a VIA EN15000
motherboard.  The interface does work, however.

I recall much discussion in the fall last year of a similar problem
for the bge driver, which I believe resulted in patches for that
driver.

Is there a general solution for this, or will work be needed for
this driver, too?

-jr
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

bogus dhclient EXPIRE when using wi0

[J.R. Oldroyd]

Using 6.1-STABLE cvsup'd on 5/9, I am noticing that on insertion
of a wi0 card, dhclient is invoking its dhclient-script several
times, as follows, from instrumentation added to the script:

Sun May 14 18:34:20 EDT 2006 dhclient reason=PREINIT
Sun May 14 18:34:20 EDT 2006 dhclient reason=REBOOT
Sun May 14 18:34:21 EDT 2006 dhclient reason=EXPIRE

The third invocation, the EXPIRE, is wrong.  This EXPIRE has the
effect of causing the just-acquired IP address to be deleted, so
the i/f appears to have no IP address.

Interestingly, if dhclient is run manually, immediately following
this, as in:
# killall dhclient
# dhclient wi0
the dhclient-script invocations then do not include the EXPIRE, as
one would expect:

Sun May 14 18:36:49 EDT 2006 dhclient reason=PREINIT
Sun May 14 18:36:50 EDT 2006 dhclient reason=REBOOT

Further instrumentation of the dhclient-script shows that the
EXPIRE does seem to be premature, in that the value of $old_expiry
does appear to be (well) beyond the current time.

Anyone have thoughts on why this is happening?

Tcpdumping the DHCP dialog on shows a perfectly normal exchange
with the server, by the way.

-jr
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Regression: apm no longer works between 6.1-RC1 and 6.1-STABLE 2006/05/09

[J.R. Oldroyd]

On May 11, 09:41, David Malone wrote:
> On Wed, May 10, 2006 at 06:31:20PM -0400, J.R. Oldroyd wrote:
> > apm: Other PM system enabled.
> 
> Could you edit /usr/src/sys/i386/bios/apm.c and a go to line
> which says:
> 
>   printf("apm: Other PM system enabled.\n");
> 
> and replace it with:
> 
>   printf("apm: Other (%d) PM system enabled.\n", 
> (int)power_pm_get_type());
> 
> and recompile and install your kernels and modules? I suspect that
> it will show 1 for the type, which means that acpi has somehow
> claimed the power management even though it is supposed to be turned
> off.
> 
>   David.

Well, I added this instrumentation, but at the same time I also
removed "device apm" from the kernel config and added "apm_load="YES""
to loader.conf.local so that I could play with it more easily.
Rebuilt... rebooted...  needless to say, it works now!

apm0:  on motherboard
apm0: found APM BIOS v1.2, connected at v1.2

Does loading it as a module change the order in which apm and acpi
are probed?

It looks like I had not edited this kernel config since late 2004,
and had used it, i.e., with "device apm" included, for builds of
several 6.0 and early 6.1 kernels with apm being fine.

In the cvsup I did between 6.1-RC1 and the recent 6.1-STABLE, the
following 149 files had been updated.  Maybe this will help pinpoint
where something was changed...

sys/amd64/amd64/busdma_machdep.c
sys/amd64/amd64/fpu.c
sys/amd64/amd64/identcpu.c
sys/amd64/amd64/initcpu.c
sys/amd64/amd64/mp_machdep.c
sys/amd64/amd64/pmap.c
sys/amd64/conf/GENERIC
sys/amd64/conf/NOTES
sys/amd64/include/md_var.h
sys/amd64/include/specialreg.h
sys/boot/forth/beastie.4th
sys/boot/i386/cdboot/cdboot.s
sys/boot/i386/pxeldr/pxeldr.S
sys/cam/scsi/scsi_cd.c
sys/conf/NOTES
sys/conf/files
sys/conf/files.alpha
sys/conf/files.amd64
sys/conf/files.i386
sys/conf/files.ia64
sys/conf/files.pc98
sys/conf/files.powerpc
sys/conf/files.sparc64
sys/conf/newvers.sh
sys/conf/options
sys/contrib/pf/net/pf_norm.c
sys/dev/acpica/Osd/OsdSchedule.c
sys/dev/ata/ata-all.c
sys/dev/ata/ata-all.h
sys/dev/ata/ata-disk.c
sys/dev/ata/ata-queue.c
sys/dev/ata/ata-raid.c
sys/dev/ata/atapi-cam.c
sys/dev/ata/atapi-cd.c
sys/dev/ata/atapi-fd.c
sys/dev/ath/if_ath.c
sys/dev/bfe/if_bfe.c
sys/dev/fxp/if_fxp.c
sys/dev/hme/if_hme.c
sys/dev/mii/brgphy.c
sys/dev/mii/miidevs
sys/dev/sound/isa/ad1816.c
sys/dev/sound/isa/mss.c
sys/dev/sound/pci/csapcm.c
sys/dev/sound/pci/ich.c
sys/dev/sound/pci/via8233.c
sys/dev/sound/pci/atiixp.c
sys/dev/sound/pcm/channel.c
sys/dev/sound/pcm/dsp.c
sys/dev/sound/pcm/mixer.c
sys/dev/sound/pcm/sound.c
sys/dev/sound/pcm/sound.h
sys/dev/sound/pcm/vchan.c
sys/dev/sound/usb/uaudio.c
sys/dev/usb/hid.c
sys/dev/usb/umass.c
sys/dev/usb/if_ural.c
sys/dev/atkbdc/psm.c
sys/dev/le/am7990.c
sys/dev/le/am79900.c
sys/dev/ipw/if_ipw.c
sys/dev/ipw/if_ipwvar.h
sys/fs/fifofs/fifo_vnops.c
sys/geom/gate/g_gate.c
sys/geom/gate/g_gate.h
sys/geom/mirror/g_mirror.c
sys/geom/geom_bsd.c
sys/geom/nop/g_nop.c
sys/geom/raid3/g_raid3.c
sys/geom/stripe/g_stripe.c
sys/geom/stripe/g_stripe.h
sys/geom/shsec/g_shsec.c
sys/geom/shsec/g_shsec.h
sys/geom/eli/g_eli.c
sys/geom/zero/g_zero.c
sys/gnu/fs/ext2fs/ext2_bitops.h
sys/i386/conf/GENERIC
sys/i386/conf/NOTES
sys/i386/i386/busdma_machdep.c
sys/i386/i386/identcpu.c
sys/i386/i386/initcpu.c
sys/i386/i386/machdep.c
sys/i386/i386/mem.c
sys/i386/i386/mp_machdep.c
sys/i386/include/md_var.h
sys/i386/include/specialreg.h
sys/i386/isa/npx.c
sys/ia64/ia64/nexus.c
sys/kern/kern_event.c
sys/kern/kern_intr.c
sys/kern/kern_synch.c
sys/kern/kern_thread.c
sys/kern/md5c.c
sys/kern/subr_sleepqueue.c
sys/kern/subr_taskqueue.c
sys/kern/subr_turnstile.c
sys/kern/subr_witness.c
sys/kern/tty_pty.c
sys/kern/uipc_mbuf.c
sys/kern/vfs_lookup.c
sys/kern/vfs_subr.c
sys/modules/Makefile
sys/modules/ath/Makefile
sys/modules/smbfs/Makefile
sys/net/if_bridge.c
sys/net/if_media.h
sys/net/if_ppp.c
sys/net/route.h
sys/net/rtsock.c
sys/net80211/ieee80211_ioctl.c
sys/net80211/ieee80211_output.c
sys/netgraph/netflow/netflow.c
sys/netgraph/netflow/netflow.h
sys/netinet6/ip6_mroute.c
sys/netinet6/ipsec.c
sys/netinet6/nd6.c
sys/netipsec/ipsec.h
sys/netipsec/ipsec_mbuf.c
sys/netipsec/xform.h
sys/netipsec/xform_ah.c
sys/netipsec/xform_esp.c
sys/netipsec/xform_ipcomp.c
sys/netipsec/xform_ipip.c
sys/netipx/ipx_ip.c
sys/netsmb/smb_crypt.c
sys/netsmb/smb_smb.c
sys/nfsclient/nfs_bio.c
sys/nfsclient/nfs_socket.c
sys/nfsclient/nfs_vnops.c
sys/nfsserver/nfs_srvsubs.c
sys/nfsserver/nfsrvcache.h
sys/sparc64/include/asi.h
sys/sparc64/sparc64/eeprom.c
sys/sparc64/sparc64/exception.S
sys/sparc64/sparc64/interrupt.S
sys/sparc64/sparc64/machdep.c
sys/sparc64/sparc64/mp_machdep.c
sys/sparc64/sparc64/tick.c
sys/sys/ata.h
sys/sys/interrupt.h
sys/sys/mbuf.h
sys/sys/md5.h
sys/sys/param.h
sys/sys/systm.h
sys/sys/taskqueue.h
sys/ufs/ffs/ffs_softdep.c
sys/ufs/ufs/ufs_quota.c
sys/ufs/ufs/uf

Regression: apm no longer works between 6.1-RC1 and 6.1-STABLE 2006/05/09

[J.R. Oldroyd]

I have just taken the system on a Sony Vaio PCG-Z505SX laptop from
6.1-RC1 (2006/03/23) to 6.1-STABLE (2006/05/09) using a cvsup update
and full buildworld/buildkernel rebuild, while keeping the same
kernel config.

On booting the new system, apm no longer works.  Now, acpi never
work on this hardware anyway, but apm always worked fine.  On the
6.1-STABLE kernel, it doesn't probe or load properly at boot time.
For reasons I no longer recall, "device apm" is configured in this
kernel, rather than loading it as a module, and this has been fine
for years, in fact, since back in the 5.x days and for several 6.0
kernels as well as 6.1-RC1.

Here's the pertinent boot info:


FreeBSD 6.1-RC1 (2006/03/23):

real memory  = 134152192 (127 MB)
avail memory = 121733120 (116 MB)
ACPI disabled by blacklist.  Contact your BIOS vendor.
npx0: [FAST]
npx0:  on motherboard
npx0: INT 16 interface
cpu0 on motherboard
apm0:  on motherboard
apm0: found APM BIOS v1.2, connected at v1.2
pcib0:  pcibus 0 on motherboard
pir0:  on motherboard


FreeBSD 6.1-STABLE (2006/05/09):

real memory  = 134152192 (127 MB)
avail memory = 121733120 (116 MB)
ACPI disabled by blacklist.  Contact your BIOS vendor.
cpu0 on motherboard
apm: Other PM system enabled.
pcib0:  pcibus 0 on motherboard
pir0:  on motherboard


On 6.1-STABLE, the /dev/apm device is not created and so none of
the apm tools work.

I don't see any changes to any of the apm code (in the last year
or so, actually), so this is presumably due to a change at a lower
level?

Any thoughts?
-jr
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"