Re: Another KSE problem?
On Thu, Jul 11, 2002 at 10:58:56PM -0700, Julian Elischer wrote: it may be in NEW state if it has just been forked. if so then the NEW state is hanging around too long. it should be fixed tomorrow after testing. What do you mean by just forked ? This is a running process that's block on a kernel of some sort within libc_r. If my reading of the problem is correct, then there might be a problem with signal delivery and things like select/poll. I don't know until I do some investigation. bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Another KSE problem?
On Thu, 11 Jul 2002, Bill Huey wrote: On Thu, Jul 11, 2002 at 10:58:56PM -0700, Julian Elischer wrote: it may be in NEW state if it has just been forked. if so then the NEW state is hanging around too long. it should be fixed tomorrow after testing. What do you mean by just forked ? I was asking if it was a newly forked process... This is a running process that's block on a kernel of some sort within libc_r. If my reading of the problem is correct, then there might be a problem with signal delivery and things like select/poll. let me know.. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Another KSE problem?
On Thu, Jul 11, 2002 at 11:42:56PM -0700, Julian Elischer wrote: I was asking if it was a newly forked process... No, its not. It's something that's been running for at least a few seconds. Sorry to be unclear about that. bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
USB ScrollMouse , XFree86 and -current
Hi Folks, I just got an USB ScrollMouse and am trying to get the Scrollmouse to work in X. It does not seem to work. It only scrolls down and does not scroll up. Is it a known problem ? Or Is this cause moused is supposedly broken ? I have this in my /etc/rc.conf moused_flags=-t intellimouse -z 4 and my XF86Config has this. Section InputDevice Identifier Mouse0 Driver mouse Option Protocol Auto Option ZAxisMapping 4 5 Option Device /dev/sysmouse Option Emulate3Buttons no EndSection Any Misconfiguraiton ? Mine is a HP scrollmouse with 2 Buttons and a Scroll, which also acts as the middle button. I have checked the archives, but to no avail. Thanks in Advance Regards Sid -- I've known him as a man, as an adolescent and as a child -- sometimes on the same day. Sid Carter FreeBSD oder Debian GNU/Linux. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: openoffice is compiling again!...but won't run.
hi, there! On Fri, Jul 12, 2002 at 01:30:47AM +0200, Martin Blapp wrote: Make sure you use the ports gcc31 for compiling. The c++ from CURRENT has broken exception handling. In the next few days a patch will be committed to address this. btw does it still use -fsjlj method for exception handling? /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: openoffice is compiling again!...but won't run.
Hi, btw does it still use -fsjlj method for exception handling? sjlj and dwarf2 work. But the problem with CURRENT is that this patch seems to be needed. (Patch from Alexander Kabaev) Index: config/i386/freebsd.h === RCS file: /usr/ncvs/src/contrib/gcc/config/i386/freebsd.h,v retrieving revision 1.56 diff -u -r1.56 freebsd.h --- config/i386/freebsd.h 21 Jun 2002 22:53:03 - 1.56 +++ config/i386/freebsd.h 26 Jun 2002 20:55:44 - @@ -385,11 +385,9 @@ #define DBX_CHECK_FUNCTION_FIRST TARGET_ELF #undef DBX_REGISTER_NUMBER -#define DBX_REGISTER_NUMBER(n) (TARGET_64BIT ? dbx64_register_map[n] \ - : (write_symbols == DWARF2_DEBUG\ - || write_symbols == DWARF_DEBUG) \ - ? svr4_dbx_register_map[(n)] \ - : dbx_register_map[(n)]) + +#define DBX_REGISTER_NUMBER(n) \ + (TARGET_64BIT ? dbx64_register_map[n] :svr4_dbx_register_map[(n)]) /* tag end of file in elf mode */ #undef DBX_OUTPUT_MAIN_SOURCE_FILE_END Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Update to the DRM
On Thu, Jul 11, 2002 at 12:25:08PM -0600, Eric Anholt wrote: On Thu, 2002-07-11 at 03:19, Stanislav Grozev wrote: i wanted to try the pci rage 128, as i have a sony vaio with it (i think) :-) so, the patch applied cleanly, but then, make buildkernel complains about missing ati_pcigart.h. i did a find /usr/src/sys -follow -name ati_pcigart.h and nothing showed up. any ideas? Missed the N on my cvs diff -uN. New patch is uploaded, including not stripping FreeBSD ID tags. http://people.freebsd.org/~anholt/dri/files/currentdrm-20020711.diff thanks, i'll try it now -tacho -- [i am the mask you wear] | [http://daemonz.org/ || [EMAIL PROTECTED]] 0x44fc3339 || [02b5 798b 4bd1 97fb f8db 72e4 dca4 be03 44fc 3339] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Update to the DRM
On Fri, Jul 12, 2002 at 09:56:50AM +0200, Stanislav Grozev wrote:
snip/
Missed the N on my cvs diff -uN. New patch is uploaded, including not
stripping FreeBSD ID tags.
http://people.freebsd.org/~anholt/dri/files/currentdrm-20020711.diff
thanks, i'll try it now
ok, it compiles and runs fine...
but my card isn't recognized. here's what pciconf -l -v shows:
none6@pci0:13:0:class=0x03 card=0x80af104d chip=0x4c521002 rev=0x64
hdr=0x00
vendor = 'ATI Technologies'
device = 'Rage P/M Mobility PCI'
class= display
subclass = VGA
so I just added the chipid to r128_drv.c (hoping that it will work;-):
{0x1002, 0x4c52, __REALLY_HAVE_SG, ATI Rage 12m Mobility P/M (PCI)},
and the driver now detects it:
drm0: ATI Rage 12m Mobility P/M (PCI) port 0x1400-0x14ff mem
0xfc00c000-0xfc00cfff,0xfd00-0xfdff irq 9 at device 13.0 on pci0
[drm:r128_init]
[drm:r128_agp_init] agp_available = 0
[drm:r128_ctxbitmap_next] drm_ctxbitmap_next bit : 0
[drm:r128_ctxbitmap_init] drm_ctxbitmap_init : 0
info: [drm] Initialized r128 2.2.0 20010917 on minor 0
but, glxinfo still says 'Direct rendering: no' (i have load dri in my
x config, do i need something else?).
so any ideas would be appreciated.
-tacho
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
HEADS UP, beware of pmap changes.
This is mostly a FYI because I do not expect major problems this time.
I have been extensively testing it in a handful of configurations.
I expect this to have bigger positive effects than are apparent from
the stats I quoted in the commit message from 'make world' for SMP systems,
especially for pentium/pentiumpro/2/3 systems. Pentium4 Xeon I am not sure
about.. it has a fast APIC subsystem, but the penalties for taking traps
etc are quite different.
There are a few more changes that I want to do over the next few days that
build on top of this - I backed a couple of things out of this change
that I thought were working but I didn't want to risk them yet.
If I've broken something new, please yell. I must confess that I have not
tried to use vm86 doscmd or anything perverse like that.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
--- Forwarded Message
Date:Fri, 12 Jul 2002 00:56:11 -0700
From:Peter Wemm [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: cvs commit: src/sys/conf options.i386 options.pc98 src/sys/i386/i386 b
ios.c db_interface.c locore.s mp_machdep.c mpapic.c pmap.c support.s
vm86.c src/sys/i386/include cpufunc.h pmap.h smp.h src/sys/i386/isa a
pic_vector.s intr_machdep.h ...
peter 2002/07/12 00:56:11 PDT
Modified files:
sys/conf options.i386 options.pc98
sys/i386/i386bios.c db_interface.c locore.s
mp_machdep.c mpapic.c pmap.c support.s
vm86.c
sys/i386/include cpufunc.h pmap.h smp.h
sys/i386/isa apic_vector.s intr_machdep.h
sys/kern subr_witness.c
Log:
Revive backed out pmap related changes from Feb 2002. The highlights are:
- It actually works this time, honest!
- Fine grained TLB shootdowns for SMP on i386. IPI's are very expensive,
so try and optimize things where possible.
- Introduce ranged shootdowns that can be done as a single IPI.
- PG_G support for i386
- Specific-cpu targeted shootdowns. For example, there is no sense in
globally purging the TLB cache for where we are stealing a page from
the local unshared process on the local cpu. Use pm_active to track
this.
- Add some instrumentation for the tlb shootdown code.
- Rip out SMP code from machine/cpufunc.h
- Try and fix some very bogus PG_G and PG_PS interactions that were bad
enough to cause vm86 bios calls to break. vm86 depended on our existing
bugs and this was the cause of the VESA panics last time.
- Fix the silly one-line error that caused the 'panic: bad pte' last time.
- Fix a couple of other silly one-line errors that should have caused more
pain than they did.
Some more work is needed:
- pmap_{zero,copy}_page[_idle]. These can be done without IPI's if we
have a hook in cpu_switch.
- The IPI handlers need some cleanup. I have a bogus %ds load that can
be avoided.
- APTD handling is rather bogus and appears to be a large source of
global TLB IPI shootdowns for no really good reason.
I see speedups of between 1.5% and ~4% on buildworlds in a while 1 loop.
I expect to see a bigger difference when there is significant pageout
activity or the system otherwise has memory shortages.
I have backed out a few optimizations that I had been using over the last
few days in order to be a little more conservative. I'll revisit these
again over the next few days as the dust settles.
New option: DISABLE_PG_G - In case I missed something.
Revision ChangesPath
1.172 +2 -1 src/sys/conf/options.i386
1.147 +2 -1 src/sys/conf/options.pc98
1.54 +8 -7 src/sys/i386/i386/bios.c
1.66 +2 -2 src/sys/i386/i386/db_interface.c
1.158 +3 -21 src/sys/i386/i386/locore.s
1.188 +231 -23 src/sys/i386/i386/mp_machdep.c
1.59 +0 -3 src/sys/i386/i386/mpapic.c
1.337 +261 -249 src/sys/i386/i386/pmap.c
1.91 +0 -36 src/sys/i386/i386/support.s
1.47 +2 -0 src/sys/i386/i386/vm86.c
1.126 +93 -75src/sys/i386/include/cpufunc.h
1.80 +5 -4 src/sys/i386/include/pmap.h
1.71 +9 -1 src/sys/i386/include/smp.h
1.84 +82 -5 src/sys/i386/isa/apic_vector.s
1.42 +13 -7 src/sys/i386/isa/intr_machdep.h
1.121 +3 -0 src/sys/kern/subr_witness.c
--- End of Forwarded Message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
CURRENT+PHP+Sablotron+__gxx_personality_v0
Is there some strange things with Sablotron port or gcc? I built apache and php with Sablotron(FreeBSD - CURRENT): vaio@root[/1ports]# apachectl start Syntax error on line 38 of /usr/local/etc/apache/httpd.conf: Cannot load /usr/local/libexec/apache/libphp4.so into server: /usr/local/lib/lib sablot.so.68: Undefined symbol __gxx_personality_v0 /usr/local/sbin/apachectl start: httpd could not be started grepar said that __gxx_personality_v0 have to be near static only libsupc++. so, what may be wrong? does anybody have problem like this? -- bye Juriy Goloveshkin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Update to the DRM
Stanislav Grozev wrote:
On Fri, Jul 12, 2002 at 09:56:50AM +0200, Stanislav Grozev wrote:
snip/
Missed the N on my cvs diff -uN. New patch is uploaded, including not
stripping FreeBSD ID tags.
http://people.freebsd.org/~anholt/dri/files/currentdrm-20020711.diff
thanks, i'll try it now
ok, it compiles and runs fine...
but my card isn't recognized. here's what pciconf -l -v shows:
none6@pci0:13:0:class=0x03 card=0x80af104d chip=0x4c521002 rev=0x64
hdr=0x00
vendor = 'ATI Technologies'
device = 'Rage P/M Mobility PCI'
class= display
subclass = VGA
so I just added the chipid to r128_drv.c (hoping that it will work;-):
{0x1002, 0x4c52, __REALLY_HAVE_SG, ATI Rage 12m Mobility P/M (PCI)},
and the driver now detects it:
drm0: ATI Rage 12m Mobility P/M (PCI) port 0x1400-0x14ff mem
0xfc00c000-0xfc00cfff,0xfd00-0xfdff irq 9 at device 13.0 on pci0
[drm:r128_init]
[drm:r128_agp_init] agp_available = 0
[drm:r128_ctxbitmap_next] drm_ctxbitmap_next bit : 0
[drm:r128_ctxbitmap_init] drm_ctxbitmap_init : 0
info: [drm] Initialized r128 2.2.0 20010917 on minor 0
but, glxinfo still says 'Direct rendering: no' (i have load dri in my
x config, do i need something else?).
Load glx
and something like
Section DRI
Mode 0666
EndSection
See http://www.xfree86.org/current/DRI6.html#10 for details.
Regards,
--
Michael Nottebrock
The circumstance ends uglily in the cruel result. - Babelfish
msg40941/pgp0.pgp
Description: PGP signature
Re: USB ScrollMouse , XFree86 and -current
On 12 Jul, Sid Carter wrote: I just got an USB ScrollMouse and am trying to get the Scrollmouse to work in X. It does not seem to work. It only scrolls down and does not scroll up. Is it a known problem ? Or Is this cause moused is supposedly broken ? I have this in my /etc/rc.conf moused_flags=-t intellimouse -z 4 You have to change it in /etc/usbd.conf directly. Bye, Alexander. -- Weird enough for government work. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Updating from 4.6 to Current
Hi, I updated my system from 4.6 to 5.0-current (11.07.2002). 1st: during make installworld i ran into this error: /usr/bin/cu - /usr/bin/tip ln /usr/bin/cu Operation not permitted. After manualy doing chflags noschg /usr/bin/cu the installworld worked 2nd: I tried to build a custom kernel, but make depend returns: don't know how to make ../../sys/inttypes.h bye, -- -- Michael Bretterklieber LCP JAWA Management Software GmbH Liebenauer Hauptstr. 200 A-8041 GRAZ Tel: ++43-(0)316-403274-12 Fax: ++43-(0)316-403274-10 GSM: ++43-(0)676-93 96 698 [EMAIL PROTECTED] homepage: http://www.jawa.at - privat --- E-mail: [EMAIL PROTECTED] homepage: http://www.inode.at/mbretter -- ...the number of UNIX installations has grown to 10, with more expected... - Dennis Ritchie and Ken Thompson, June 1972 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB ScrollMouse , XFree86 and -current
On Fri, 12 Jul 2002 13:05:03 +0530 Sid Carter wrote: I just got an USB ScrollMouse and am trying to get the Scrollmouse to work in X. It does not seem to work. It only scrolls down and does not scroll up. Is it a known problem ? Or Is this cause moused is supposedly broken ? no, it's XF86 mouse_drv.o I have checked the archives, but to no avail. then you didn't check enough ;] in [EMAIL PROTECTED] Ted Lindgreen described a patch which worked for him. didn't work for me tho because my wheel doesn't do a thing under X (but it does on /dev/sysmouse and moused) cheers simon -- /\ http://corecode.ath.cx/#donate \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News msg40944/pgp0.pgp Description: PGP signature
Re: Updating from 4.6 to Current
On 2002-07-12 14:40 +, Michael Bretterklieber wrote: 2nd: I tried to build a custom kernel, but make depend returns: don't know how to make ../../sys/inttypes.h Are you using 'make depend clean all' to build the kernel? Try using cd /usr/src ; make buildkernel instead. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updating from 4.6 to Current
Hi, Giorgos Keramidas schrieb: On 2002-07-12 14:40 +, Michael Bretterklieber wrote: 2nd: I tried to build a custom kernel, but make depend returns: don't know how to make ../../sys/inttypes.h Are you using 'make depend clean all' to build the kernel? clean all not because it was a completely new kernel-config, Try using cd /usr/src ; make buildkernel instead. for sure, this works. bye, -- -- Michael Bretterklieber LCP JAWA Management Software GmbH Liebenauer Hauptstr. 200 A-8041 GRAZ Tel: ++43-(0)316-403274-12 Fax: ++43-(0)316-403274-10 GSM: ++43-(0)676-93 96 698 [EMAIL PROTECTED] homepage: http://www.jawa.at - privat --- E-mail: [EMAIL PROTECTED] homepage: http://www.inode.at/mbretter -- ...the number of UNIX installations has grown to 10, with more expected... - Dennis Ritchie and Ken Thompson, June 1972 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updating from 4.6 to Current
On Fri, Jul 12, 2002 at 02:40:00PM +0200, Michael Bretterklieber wrote: Hi, I updated my system from 4.6 to 5.0-current (11.07.2002). 1st: during make installworld i ran into this error: /usr/bin/cu - /usr/bin/tip ln /usr/bin/cu Operation not permitted. After manualy doing chflags noschg /usr/bin/cu the installworld worked I've just fixed this in src/usr.bin/tip/tip/Makefile,v 1.18. Thanks for spotting! 2nd: I tried to build a custom kernel, but make depend returns: don't know how to make ../../sys/inttypes.h Please do not diverge from the procedure described in UPDATING. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg40948/pgp0.pgp Description: PGP signature
Re: Updating from 4.6 to Current
Hi, thx. Please do not diverge from the procedure described in UPDATING. sorry my first current. bye, Ruslan Ermilov schrieb: On Fri, Jul 12, 2002 at 02:40:00PM +0200, Michael Bretterklieber wrote: Hi, I updated my system from 4.6 to 5.0-current (11.07.2002). 1st: during make installworld i ran into this error: /usr/bin/cu - /usr/bin/tip ln /usr/bin/cu Operation not permitted. After manualy doing chflags noschg /usr/bin/cu the installworld worked I've just fixed this in src/usr.bin/tip/tip/Makefile,v 1.18. Thanks for spotting! 2nd: I tried to build a custom kernel, but make depend returns: don't know how to make ../../sys/inttypes.h Please do not diverge from the procedure described in UPDATING. Cheers, -- -- Michael Bretterklieber LCP JAWA Management Software GmbH Liebenauer Hauptstr. 200 A-8041 GRAZ Tel: ++43-(0)316-403274-12 Fax: ++43-(0)316-403274-10 GSM: ++43-(0)676-93 96 698 [EMAIL PROTECTED] homepage: http://www.jawa.at - privat --- E-mail: [EMAIL PROTECTED] homepage: http://www.inode.at/mbretter -- ...the number of UNIX installations has grown to 10, with more expected... - Dennis Ritchie and Ken Thompson, June 1972 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc-3.1 Mozilla Build Fails
÷ Thu, 11.07.2002, × 19:52, Joe Marcus Clarke ÎÁÐÉÓÁÌ: On Thu, 2002-07-11 at 03:13, Sheldon Hearn wrote: On (2002/07/10 19:15), Dirk Engling wrote: Maybe this would be more interesting to the mozilla guys but mozilla compiles on 2.95.3, so I think, the problem is related to gcc-3.1 As far as I know, ports/lang/gcc31 is still required to build mozilla. That, or stick the attached patch in mozilla/files. I'm still analyzing options to get Mozilla to build on alpha, though. After patch mozilla successfully builds and run on -CURRENT, but it don't want work with my jdk: LoadPlugin: failed to initialize shared library /usr/local/jdk1.3.1/jre/plugin/i386/ns600/libjavaplugin_oji.so [/usr/local/jdk1.3.1/jre/plugin/i386/ns600/libjavaplugin_oji.so: Undefined symbol _vt$17nsGetServiceByCID] Any ideas ? rebuild jdk from scratch ? Joe --- xpcom/reflect/xptcall/src/md/unix/xptc_platforms_unixish_x86.h.orig Fri Jun 21 01:12:40 2002 +++ xpcom/reflect/xptcall/src/md/unix/xptc_platforms_unixish_x86.hFri Jun 21 01:41:51 2002 @@ -94,8 +94,16 @@ * gcc is that the system gcc defines __FreeBSD_cc_version. This variable * can also identify the period of time that 4.0-CURRENT used thunks. */ -#if defined(__FreeBSD_cc_version) \ -(__FreeBSD_cc_version 42 || __FreeBSD_cc_version 43) + +/* It seems we need to use thunks in FreeBSD -CURRENT after gcc-3.1 was merged. + * This solves a problem wherein regxpcom and/or regchrome would seg fault + * after running for a while. This problem has also exhibited itself on + * the alpha platform. Therefore, use thunks on all non-i386 versions of + * -stable and _all_ versions of -CURRENT that are using gcc-3.1. + */ +#if defined(__FreeBSD_cc_version) defined(__i386__) \ +(__FreeBSD_cc_version 42 || __FreeBSD_cc_version 43) \ +(__FreeBSD_cc_version 53) #define CFRONT_STYLE_THIS_ADJUST #else #define THUNK_BASED_THIS_ADJUST -- Vladimir B. Grebenschikov [EMAIL PROTECTED], SWsoft, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On Wed, Jul 10, 2002 at 01:36:46PM -0700, Don Lewis wrote: It'll drop into ddb every time you get a witness error and you'll have to tell ddb to continue. This could be a might annoying if you are getting errors ever ten seconds ... I'm seeing this: ../../../vm/uma_core.c:1332: could sleep with kernel linker locked from ../../../kern/kern_linker.c:1797 very early on (before rc.sysctl is read -- okay I'm still using the old rc scripts). Is there any way to set debug.witness_ddb=1 from the loader? This is entirely repeatable (just boot up the machine), also seems to happen a few times at random while the system is running. I figure if I could get it to panic in the repeatable case... - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On Fri, Jul 12, 2002 at 08:33:39 -0700, Alex Zepeda wrote: On Wed, Jul 10, 2002 at 01:36:46PM -0700, Don Lewis wrote: It'll drop into ddb every time you get a witness error and you'll have to tell ddb to continue. This could be a might annoying if you are getting errors ever ten seconds ... I'm seeing this: ../../../vm/uma_core.c:1332: could sleep with kernel linker locked from ../../../kern/kern_linker.c:1797 very early on (before rc.sysctl is read -- okay I'm still using the old rc scripts). Is there any way to set debug.witness_ddb=1 from the loader? This is entirely repeatable (just boot up the machine), also seems to happen a few times at random while the system is running. I figure if I could get it to panic in the repeatable case... You can set debug.witness_ddb from the loader. It'll get propagated to the sysctl once you boot. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On 12 Jul, Alex Zepeda wrote: On Wed, Jul 10, 2002 at 01:36:46PM -0700, Don Lewis wrote: It'll drop into ddb every time you get a witness error and you'll have to tell ddb to continue. This could be a might annoying if you are getting errors ever ten seconds ... I'm seeing this: ../../../vm/uma_core.c:1332: could sleep with kernel linker locked from ../../../kern/kern_linker.c:1797 very early on (before rc.sysctl is read -- okay I'm still using the old rc scripts). I see that one also and I know what the problem is. Unfortunately I don't know of a good way of fixing it. The problem is that SYSCTL_OUT() is being called while a lock is held, and SYSCTL_OUT() can potentially block. I've posted a lot more information about this error in another thread. Check the archives for the subject '/usr/src/sys/vm/uma_core.c:1332: could sleep with kernel li', I guess my original subject got truncated. Is there any way to set debug.witness_ddb=1 from the loader? Dunno, but you could tweak the source to change the default value and recompile, or you could binary patch the kernel. It's not worth doing it in this case though. This is entirely repeatable (just boot up the machine), also seems to happen a few times at random while the system is running. I figure if I could get it to panic in the repeatable case... You can also reproduce it by running sysctl -a, but I'll save you the trouble. Here's the stack trace: witness_sleep() uma_zalloc_arg() vm_map_entry_create() vm_map_clip_start() vm_map_wire() vslock() sysctl_old_user() sysctl_kern_function_list_iterate() link_elf_each_function_name() sysctl_kern_function_list() ... There were some other similar cases in the kernel that I've already fixed because they were easy, but I don't know of a good fix for the general case. I'm planning to solicit ideas from the freebsd-arch list. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT trashes disk label
In message: [EMAIL PROTECTED] Ian Dowse [EMAIL PROTECTED] writes: : In message [EMAIL PROTECTED], David Schultz writes: : I just made world on -CURRENT (cvsup a few hours ago), booted : using a new GENERIC kernel and ran mergemaster. Before I : installed world, I mounted the root partition for my more stable : development environment (4.6-RELEASE) to copy my firewall rules : over. In summary: : : # fsck /dev/ad1s1a : ** /dev/ad1s1a : BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE : /dev/ad1s1a: INCOMPLETE LABEL: type 4.2BSD fsize 0, frag 0, cpg 0, size 524288 : : You just need to fsck -b16 /dev/ad1s1a, or alternatively upgrade : to the latest -STABLE fsck, which fixes this issue. There are a few : new superblock fields in use in -CURRENT that trigger some unnecessary : fsck sanity checks. : : The other thing that causes scary-looking errors when moving disks : back and forth between -CURRENT and -STABLE is when the snapshot : used by -CURRENT's fsck gets left behind if you reboot during the : background fsck and then boot -STABLE. Damn. I forgot to include Kirk's UPDATING entry that he sent me on this topic. Sorry about that. I'll deal later today. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NEWCARD
In message: [EMAIL PROTECTED] Kurt Erik Lindqvist [EMAIL PROTECTED] writes: : : : --On Tuesday, July 09, 2002 23:47:09 -0700 Julian Elischer : [EMAIL PROTECTED] wrote: : : the new code has been tweeked for gcc 3.1 : : in 3.1 you need foo[] : in 2.95 you needed foo[0] : : you can follow the instructions in /usr/src/Makefile : specifically the make buildkernel bit : to make both the new compiler and build the kernel with it. : : : Thanks! : : Now I ofcourse have two additional questions : : 1) When trying to insert a Cisco Aironet 340 adapter, I get thrown to the : db prompt after it has found the card (which it seems to do nicely). If I : boot with it inserted, I only get to the detection, then the boot stops. At : boot up dmesg says the following on the bridge : : : cardbus0: CardBus bus on pccbb0 : pccard0: 16-bit PCCard bus on pccbb0 : pccbb1: TI1450 PCI-CardBus Bridge mem 0x4118-0x41180fff irq 11 at : device 4 : .1 on pci0 : cardbus1: CardBus bus on pccbb1 : pccard1: 16-bit PCCard bus on pccbb1 Traceback for the panic? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ACPI Sony FX601
Hi,
I installed FreeBSD 5.0-current on my notebook, because in FreeBSD4.6
the sounddriver let the kernel hang on boot.
I know, that acpi is under developement, but here are my results testing
acpi on this hardware.
acpiconf -s 3:
works, but the machine doesen't completely wake up, the display still
stays dark
acpiconf -s 4:
the system hangs uo.
Here's my acpidump
/*
RSD PTR: Checksum=17, OEMID=PTLTD, RsdtAddress=0x0fef9a90
*/
/*
RSDT: Length=48, Revision=1, Checksum=247,
OEMID=SONY, OEM Table ID=K5, OEM Revision=0x604,
Creator ID= LTP, Creator Revision=0x0
*/
/*
Entries={ 0x0fefee4c, 0x0fefeec0, 0x0fefeee8 }
*/
/*
DSDT=0xfef9ac0
INT_MODEL=PIC
SCI_INT=9
SMI_CMD=0x802f, ACPI_ENABLE=0xf0, ACPI_DISABLE=0xf1, S4BIOS_REQ=0xf2
PM1a_EVT_BLK=0x8000-0x8003
PM1a_CNT_BLK=0x8004-0x8005
PM2_TMR_BLK=0x8008-0x800b
PM2_GPE0_BLK=0x8020-0x8023
P_LVL2_LAT=90ms, P_LVL3_LAT=1100ms
FLUSH_SIZE=0, FLUSH_STRIDE=0
DUTY_OFFSET=0, DUTY_WIDTH=4
DAY_ALRM=125, MON_ALRM=126, CENTURY=50
Flags={WBINVD,PROC_C1,SLP_BUTTON,RTC_S4,TMR_VAL_EXT}
*/
and here's my dmesg output:
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #1: Fri Jul 12 11:53:31 CEST 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
Preloaded elf kernel /boot/kernel/kernel at 0xc05d.
Preloaded elf module /boot/kernel/acpi.ko at 0xc05d00a8.
Timecounter i8254 frequency 1193182 Hz
Timecounter TSC frequency 1100048152 Hz
CPU: mobile AMD Duron(tm) (1100.05-MHz 686-class CPU)
Origin = AuthenticAMD Id = 0x662 Stepping = 2
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
AMD Features=0xc040AMIE,DSP,3DNow!
real memory = 268435456 (262144K bytes)
avail memory = 254119936 (248164K bytes)
Pentium Pro MTRR support enabled
Using $PIR table, 6 entries at 0xc00fdf60
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: SONY K5 on motherboard
acpi0: power button is handled as a fixed feature programming model.
Timecounter ACPI-safe frequency 3579545 Hz
acpi_timer0: 32-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0
acpi_cpu0: CPU on acpi0
acpi_tz0: thermal zone on acpi0
acpi_button0: Sleep Button on acpi0
acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: PCI bus on acpi_pcib0
pcib1: PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pci1: display, VGA at device 0.0 (no driver attached)
isab0: PCI-ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
atapci0: VIA 82C686 ATA100 controller port 0x1c40-0x1c4f at device 7.1
on pci0
atapci0: Correcting VIA config for southbridge data corruption bug
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0: VIA 83C572 USB controller port 0x1c00-0x1c1f irq 9 at device
7.2 on pci0
usb0: VIA 83C572 USB controller on uhci0
usb0: USB revision 1.0
uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhub0: port error, restarting port 1
uhub0: port error, giving up port 1
uhub0: port error, restarting port 2
uhub0: port error, giving up port 2
ums0: Logitech USB Mouse, rev 1.10/6.10, addr 2, iclass 3/1
ums0: 3 buttons and Z dir.
uhci1: VIA 83C572 USB controller port 0x1c20-0x1c3f irq 9 at device
7.3 on pci0
usb1: VIA 83C572 USB controller on uhci1
usb1: USB revision 1.0
uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhub1: port error, restarting port 1
uhub1: port error, giving up port 1
uhub1: port error, restarting port 2
uhub1: port error, giving up port 2
isab1: PCI-ISA bridge at device 7.4 on pci0
pci0: multimedia, audio at device 7.5 (no driver attached)
pci0: simple comms at device 7.6 (no driver attached)
pccbb0: TI1420 PCI-CardBus Bridge irq 9 at device 10.0 on pci0
cardbus0: CardBus bus on pccbb0
pccard0: 16-bit PCCard bus on pccbb0
pccbb1: TI1420 PCI-CardBus Bridge irq 10 at device 10.1 on pci0
cardbus1: CardBus bus on pccbb1
pccard1: 16-bit PCCard bus on pccbb1
pci0: serial bus, FireWire at device 14.0 (no driver attached)
rl0: RealTek 8139 10/100BaseTX port 0x1800-0x18ff mem
0xe8004800-0xe80048ff irq 10 at device 16.0 on pci0
rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect
mode
/usr/src/sys/vm/uma_core.c:1332: could sleep with rl0 locked from
/usr/src/sys/pci/if_rl.c:855
rl0: Ethernet address: 08:00:46:5a:c4:4b
miibus0: MII bus on rl0
rlphy0: RealTek internal media interface on miibus0
rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
/usr/src/sys/vm/uma_core.c:1332: could sleep with rl0 locked from
/usr/src/sys/pci/if_rl.c:587
acpi_acad0: AC adapter on acpi0
acpi_cmbat0: Control method Battery on acpi0
acpi_cmbat1: Control method Battery on
Re: thread_sanity_check()
On 11-Jul-2002 Julian Elischer wrote: all gone now.. Ok, I didn't mind it being there, just maybe under INVARIANTS instead is all. On Thu, 11 Jul 2002, John Baldwin wrote: Considering the incredible amount of complaining over having a cred_free_thread() function conditionally compiled into the kernel that only did a mutex lock, decrement, and mutex unlock in the common case, why isn't thread_sanity_check() (or it's body) conditionally compiled? It's a lot more expensive than cred_free_thread() and isn't even under INVARIANTS. Pardon me if I find this a bit hypocritical. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Thread state
On 11-Jul-2002 Julian Elischer wrote: It has been tested on sparc64, alpha, and i386 all with SMP. I would like to commit it soonish. Comments? put me down as having approved/agreed/applauded/whatever! (but check the idle thread setup first) Cool, ok. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
bdwrite: buffer is not busy
I see this panic constantly during last month or two, UP machine, no softupdates. Anybody else saw it too? Any ideas? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Here's a new(er) one
* $FreeBSD: src/sys/kern/vfs_bio.c,v 1.319 2002/07/10 17:02:28 dillon Exp $
* $FreeBSD: src/sys/kern/vfs_syscalls.c,v 1.267 2002/07/02 17:09:22 mux Exp $
GNU gdb 5.2 (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-portbld-freebsd5.0...
IdlePTD at phsyical address 0x00566000
initial pcb at physical address 0x0044ee80
panicstr: bremfree: bp 0xc422f8e8 not locked
panic messages:
---
panic: Most recently used by temp
cpuid = 0; lapic.id =
boot() called on cpu#0
syncing disks... panic: bremfree: bp 0xc422f8e8 not locked
cpuid = 0; lapic.id =
boot() called on cpu#0
Uptime: 2h21m27s
Dumping 127 MB
ata0: resetting devices .. done
16 32 48 64 80 96 112
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) t bt
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc021e885 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc021ea8a in poweroff_wait (junk=0xc03a9665, howto=-1004341016)
at ../../../kern/kern_shutdown.c:491
#3 0xc025107b in bremfree (bp=0xc03a9665) at ../../../kern/vfs_bio.c:633
#4 0xc025274e in vfs_bio_awrite (bp=0xc422f8e8)
at ../../../kern/vfs_bio.c:1626
#5 0xc01f9226 in spec_fsync (ap=0xc9b07678)
at ../../../fs/specfs/spec_vnops.c:403
#6 0xc01f8e1b in spec_vnoperate (ap=0x0)
at ../../../fs/specfs/spec_vnops.c:121
#7 0xc02fa484 in ffs_sync (mp=0xc1b15800, waitfor=2, cred=0xc0bace80,
td=0xc04079e0) at vnode_if.h:463
#8 0xc025f636 in sync (td=0xc04079e0, uap=0x0)
at ../../../kern/vfs_syscalls.c:127
#9 0xc021e4f4 in boot (howto=256) at ../../../kern/kern_shutdown.c:254
#10 0xc021ea8a in poweroff_wait (junk=0xc03c6448, howto=-1069940211)
at ../../../kern/kern_shutdown.c:491
#11 0xc031993a in mtrash_ctor (mem=0x100, size=0, arg=0x0)
at ../../../vm/uma_dbg.c:135
#12 0xc03188d8 in uma_zalloc_arg (zone=0xc0b85200, udata=0x0, flags=0)
at ../../../vm/uma_core.c:1358
#13 0xc0215c58 in malloc (size=6, type=0xc0411c80, flags=0)
at ../../../kern/kern_malloc.c:171
#14 0xc0253764 in allocbuf (bp=0xc4202f98, size=1024)
at ../../../kern/vfs_bio.c:2584
#15 0xc025353f in getblk (vp=0xc1f3c420, blkno=0, size=1024, slpflag=0,
slptimeo=0) at ../../../kern/vfs_bio.c:2476
#16 0xc025115b in breadn (vp=0xc1f3c420, blkno=0, size=1024, rablkno=0x0,
rabsize=0x0, cnt=0, cred=0x0, bpp=0x0) at ../../../kern/vfs_bio.c:691
#17 0xc025112a in bread (vp=0xc1f3c420, blkno=0, size=1024, cred=0x0,
bpp=0xc9b078d8) at ../../../kern/vfs_bio.c:673
#18 0xc02f7f86 in ffs_blkatoff (vp=0xc1f3c420, offset=0, res=0x0,
bpp=0xc9b0794c) at ../../../ufs/ffs/ffs_subr.c:91
#19 0xc0300569 in ufs_lookup (ap=0xc9b07a74)
at ../../../ufs/ufs/ufs_lookup.c:266
#20 0xc030695d in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2724
#21 0xc0255545 in vfs_cache_lookup (ap=0x0) at vnode_if.h:73
#22 0xc030695d in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2724
#23 0xc0258d68 in lookup (ndp=0xc9b07c40) at vnode_if.h:48
#24 0xc025881e in namei (ndp=0xc9b07c40) at ../../../kern/vfs_lookup.c:175
#25 0xc0262de8 in rename (td=0xc1d6b180, uap=0xc9b07d14)
at ../../../kern/vfs_syscalls.c:2497
#26 0xc0350ddc in syscall (frame=
{tf_fs = 134676527, tf_es = 134610991, tf_ds = -1078001617, tf_edi = 134647304,
tf_esi = 134652936, tf_ebp = -1077938248, tf_isp = -911180428, tf_ebx = 134653064,
tf_edx = 134652957, tf_ecx = 9, tf_eax = 128, tf_trapno = 47, tf_err = 2, tf_eip =
671960931, tf_cs = 31, tf_eflags = 646, tf_esp = -1077938404, tf_ss = 47}) at
../../../i386/i386/trap.c:1045
#27 0xc033d95d in syscall_with_err_pushed () at /var/tmp//ccPk7eLY.s:129
#28 0x0804f51e in ?? ()
#29 0x0804a129 in ?? ()
#30 0x08049cc1 in ?? ()
#31 0x0804d7aa in ?? ()
#32 0x08049eb9 in ?? ()
#33 0x08049a75 in ?? ()
(kgdb)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Update to the DRM
On Fri, 2002-07-12 at 03:07, Stanislav Grozev wrote:
ok, it compiles and runs fine...
but my card isn't recognized. here's what pciconf -l -v shows:
none6@pci0:13:0:class=0x03 card=0x80af104d chip=0x4c521002 rev=0x64
hdr=0x00
vendor = 'ATI Technologies'
device = 'Rage P/M Mobility PCI'
class= display
subclass = VGA
so I just added the chipid to r128_drv.c (hoping that it will work;-):
{0x1002, 0x4c52, __REALLY_HAVE_SG, ATI Rage 12m Mobility P/M (PCI)},
That's a Mach64-based chip, so the r128 driver won't work with it.
Luckily for you, support for mach64s (Rage Pros specifically, which I
think your chip is) is being worked on in DRI CVS, so it should be
available soon. What's needed at this point is for someone to port the
Mach64 DRM from Linux to the Linux/BSD framework we've got in DRI CVS
now. It's a pretty straightforward process now for most chipsets, but
does take some time.
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/dri/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: bdwrite: buffer is not busy
On Fri, Jul 12, 2002 at 10:25:35PM +0400, Andrey A. Chernov wrote: I see this panic constantly during last month or two, UP machine, no softupdates. Anybody else saw it too? Any ideas? I've been seeing it, when I'm lucky :) I get weird issues when mplayer is doing its thing with the sdl backend, usually it follows an error like this: TPTE at 0xbfc20340 IS ZERO @ VA 0x000d panic: bad pte haven't dug in on it yet, I don't have another machine handy to ssh or serial tty in on, and it doesn't release video when the locks happen usually, so I'm not sure if that's the persistant problem :) I'll look into it more when I get time. (btw, UP, softupdates on /usr and /var, not /, cvsup'd at 2002-07-11 09:28 CST (GMT-6) -current) -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- -Erik [EMAIL PROTECTED] [http://math.smsu.edu/~erik] The opinions expressed by me are not necessarily opinions. In all probability, they are random rambling, and to be ignored. Failure to ignore may result in severe boredom or confusion. Shake well before opening. Keep Refrigerated. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Update to the DRM
On Fri, Jul 12, 2002 at 01:06:31PM -0600, Eric Anholt wrote: That's a Mach64-based chip, so the r128 driver won't work with it. i see... Luckily for you, support for mach64s (Rage Pros specifically, which I think your chip is) is being worked on in DRI CVS, so it should be available soon. What's needed at this point is for someone to port the Mach64 DRM from Linux to the Linux/BSD framework we've got in DRI CVS now. It's a pretty straightforward process now for most chipsets, but does take some time. well if you give me details, i could try -tacho To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bdwrite: buffer is not busy
In message [EMAIL PROTECTED], Andrey A. Chernov writes:
I see this panic constantly during last month or two, UP machine, no
softupdates. Anybody else saw it too? Any ideas?
The buffer is not busy panic is usually a secondary panic that
occurs while trying to sync the disks after a different panic. If
possible, try to get the first panic message, or ideally a stack
trace.
I think (but I've never checked for sure) that the buffer is not
busy panics occur because of the following code in lockmgr(),
combined with later sanity checks:
if (panicstr != NULL) {
mtx_unlock(lkp-lk_interlock);
return (0);
}
This basically causes all lockmgr locks to be unconditionally and
immediately granted after a panic without actually marking the lock
as locked. Not surprisingly, this causes any lock state sanity
checks later to fail. The original intention was probably to avoid
deadlocking while syncing the disks, but a virtually guaranteed
secondary panic isn't helpful either. It might be worth checking
if a return (EBUSY); or a lkp-lk_flags |= LK_HAVE_EXCL;
lkp-lk_lockholder = pid; in here would do better. The alternative
is to make kern.sync_on_panic=0 the default.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: bdwrite: buffer is not busy
Ian Dowse writes: In message [EMAIL PROTECTED], Andrey A. Chernov writes: I see this panic constantly during last month or two, UP machine, no softupdates. Anybody else saw it too? Any ideas? The buffer is not busy panic is usually a secondary panic that occurs while trying to sync the disks after a different panic. If possible, try to get the first panic message, or ideally a stack trace. Why do we dump after sync'ing fs's? It seems like we should dump first, then sync later. Also, with interrupt threads in -current, panic's are totally bizzare. Alphas can't dump because they get into a situation where some system thread wakes up and can never go to sleep again (like bufdaemon). I think the whole set of panicstr hacks need to be re-thought.. I'd like to do something that (as Julian says) puts a big stick in the works just after we panic which allows only interrupt threads and the panic'ing thread to run. What's the best way to do this? Should I add to the panicstr hacks, or is there a more elegent way to achieve this? Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB ScrollMouse , XFree86 and -current
Sid Carter wrote: I just got an USB ScrollMouse and am trying to get the Scrollmouse to work in X. It does not seem to work. It only scrolls down and does not scroll up. Is it a known problem ? Or Is this cause moused is supposedly broken ? I have this in my /etc/rc.conf moused_flags=-t intellimouse -z 4 Have you tried explicitly mapping the buttons? E.g. -z 4 5 instead of just -z? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Update to the DRM
On Fri, 2002-07-12 at 13:49, Stanislav Grozev wrote:
On Fri, Jul 12, 2002 at 01:06:31PM -0600, Eric Anholt wrote:
Luckily for you, support for mach64s (Rage Pros specifically, which I
think your chip is) is being worked on in DRI CVS, so it should be
available soon. What's needed at this point is for someone to port the
Mach64 DRM from Linux to the Linux/BSD framework we've got in DRI CVS
now. It's a pretty straightforward process now for most chipsets, but
does take some time.
well if you give me details, i could try
cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri login
cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri -z3 co -P xc
That's trunk, which includes the Radeon TCL (transform+lighting) 3d
driver and the os-independent framework for the DRM. The DRM is in
xc/programs/Xserver/hw/xfree86/os-support/${OS}/drm/kernel. To get the
branch with mach64 work add -rmach64-0-0-5-branch to the checkout.
You would probably want to check out a trunk and a mach64-0-0-5-branch.
Install World with the mach64 branch, then copy the mach64* files from
the mach64-branch drm into the trunk's drm and port the DRM from there.
cvs logs of os-support/shared/drm/kernel/* along with looking at
os-support/linux/drm/kernel/drm_os_linux.h and
os-support/linux/drm/kernel/drm_os_freebsd.h should give an example of
most of the changes to be done in porting a driver.
I've taken a quick look at the mach64 code, and I have the following
concerns on porting it:
- we don't have any os-independent macros for linked lists yet.
- needs allocation of 16kb, 16kb-aligned memory (do we have a clean
method of doing this?) which is consistent for DMA. For x86 it looks
like we can ignore the consistent stuff.
They still have interrupt code enabled, but it should probably be #if
MACH64_INTERRUPTS (currently 0). We don't have any DRMs on FreeBSD
using interrupts, so I don't know how well it would work if that got
turned back on.
The goal for porting drivers to *BSD for the DRI project is to have no
os-specific #ifdefs in the driver code itself. They might be a little
more flexible allowing that now, but if we can avoid ifdefs it'll help
get the code merged faster.
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/dri/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: bdwrite: buffer is not busy
Andrey A. Chernov wrote: I see this panic constantly during last month or two, UP machine, no softupdates. Anybody else saw it too? Any ideas? Lazy #$@*% buffer! -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bdwrite: buffer is not busy
On Fri, Jul 12, 2002 at 22:18:35 +0100, Ian Dowse wrote: In message [EMAIL PROTECTED], Andrey A. Chernov writes: I see this panic constantly during last month or two, UP machine, no softupdates. Anybody else saw it too? Any ideas? The buffer is not busy panic is usually a secondary panic that occurs while trying to sync the disks after a different panic. If possible, try to get the first panic message, or ideally a stack trace. This is remote machine, all I can see is savecore info in /var/crash. BTW, can we fix it in simple way, i.e. always disallow second panic dump just checking panic flag? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Noisy ACPI, please help
Hello, I think that I need your help. I'm not well versed in the ways of ACPI. On my -current testbox, the ACPI module produces a seemingly infinate number of error messages on console like the following: ACPI-1046: *** Error: AcpiEvGpeDispatch: No handler or method for GPE[3a], disabling event Actually, I think it happens each time I get an interrupt on my ethernet device. At least 'ifconfig fxp0 up' starts the messages, and 'ifconfig fxp0 down' stops them. This is an SMP SuperMicro 370DLE (Serverworks) based machine. If an acpidump would help to debug this, I'd be happy to provide one. Thank you very much for your help, Drew OK boot -s -\|/-\|Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Fri Jul 12 20:14:49 EDT 2002 gallatin@big:/usr/src/sys/i386/compile/SMP Preloaded elf kernel /boot/kernel/kernel at 0xc04a1000. Preloaded elf module /boot/kernel/acpi.bak.ko at 0xc04a10b4. Timecounter i8254 frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (999.53-MHz 686-class CPU) Origin = GenuineIntel Id = 0x68a Stepping = 10 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 536805376 (524224K bytes) avail memory = 515915776 (503824K bytes) Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 Programming 16 pins in IOAPIC #1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 4, version: 0x000f0011, at 0xfec0 io1 (APIC): apic id: 5, version: 0x000f0011, at 0xfec01000 Pentium Pro MTRR support enabled Using $PIR table, 9 entries at 0xc00f5260 npx0: math processor on motherboard npx0: INT 16 interface acpi0: RCCRCCNILE on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz can't fetch resources for \_SB_.LN02 - AE_BAD_DATA can't fetch resources for \_SB_.LN06 - AE_BAD_DATA can't fetch resources for \_SB_.LN08 - AE_BAD_DATA can't fetch resources for \_SB_.LN15 - AE_BAD_DATA can't fetch resources for \_SB_.LNUS - AE_BAD_DATA acpi_timer0: 32-bit timer at 3.579545MHz port 0x508-0x50b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Sleep Button on acpi0 acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0 IOAPIC #1 intpin 2 - irq 2 IOAPIC #1 intpin 6 - irq 5 IOAPIC #1 intpin 15 - irq 9 pci0: PCI bus on acpi_pcib0 atapci0: Promise ATA66 controller port 0xdf00-0xdf3f,0xdfe0-0xdfe3,0xdfa8-0xdfaf,0xdfe4-0xdfe7,0xdff0-0xdff7 mem 0xfe9a-0xfe9b irq 2 at device 2.0 on pci0 ata2: at 0xdff0 on atapci0 ata3: at 0xdfa8 on atapci0 pci0: display, VGA at device 4.0 (no driver attached) fxp0: Intel Pro 10/100B/100+ Ethernet port 0xd400-0xd43f mem 0xfc90-0xfc9f,0xfcafe000-0xfcafefff irq 9 at device 6.0 on pci0 fxp0: Ethernet address 00:30:48:21:d3:0b inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: PCI-ISA bridge port 0x580-0x58f at device 15.0 on pci0 isa0: ISA bus on isab0 atapci1: ServerWorks ROSB4 ATA33 controller port 0xffa0-0xffaf at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci1 ata1: at 0x170 irq 15 on atapci1 ohci0: OHCI (generic) USB controller mem 0xfcaff000-0xfcaf irq 10 at device 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: (unknown) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered acpi_pcib1: Host-PCI bridge on acpi0 acpi_pcib1: we have duplicate bus number 0 - not probing bus atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 fdc0: cmd 3 failed at out byte 1 of 3 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 fdc0: cmd 3 failed at out byte 1 of 3 pcib1: ServerWorks NB6635 3.0LE host to PCI bridge at pcibus 1 on motherboard IOAPIC #1 intpin 8 - irq 11 pci1: PCI bus on pcib1 pci1: old, non-VGA display device at device 1.0 (no driver attached) orm0: Option ROMs at iomem 0xc9800-0xca7ff,0xc8000-0xc97ff,0xc-0xc7fff on isa0 fdc0: enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles,
Re: i386 trap code
--- John Baldwin [EMAIL PROTECTED] wrote: On 07-Jul-2002 Jonathan Lemon wrote: On Sat, Jul 06, 2002 at 11:59:50PM -0700, David Xu wrote: Jonthan, I just use DOS program as an example, for any program, if it wants to go into VM86 mode, it is very easy, just calls i386_vm86() to initailize its VM86 pcb extension, setups some memory area, then call sigreturn() to turn into VM86 mode. I think global in_vm86call flags is a bug under SMP, it creates a race condition. suppose this scenario: CPU A is running a simple VM86 code program. CPU B is running vm86_intcall() by some kernel driver (vesa module ?) CPU B set in_vm86call = 1 CPU A gets a fault trap. CPU A runs trap(), and find that in_vm86call is set and handles the trap as it is running vm86_intcall(), but it is not true and make a mess. Yes, as I mentioned earlier, the way the original vm86 bioscall worked was to prevent an AST until the BIOS was done. This relied on the giant lock for correctness, since we only allowed one CPU into the kernel at once. There probably needs to be some work done for -current in this area. Since vm86_lock is a spin lock, you could possibly make in_vm86call per-cpu or you could just check the lock instead of the variable to fix this. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ when did the vm86_lock become spin lock ? I havn't seen changes in cvs, it is still a MTX_DEF. I had tried changing it to spin lock and got a panic. :( David Xu __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/lib/libc/gen statvfs.c
On Thu, Jul 11, 2002 at 06:59:28PM -0400, Garrett Wollman wrote: On Thu, 11 Jul 2002 15:54:12 -0700 (PDT), Garrett Wollman [EMAIL PROTECTED] said: wollman 2002/07/11 15:54:12 PDT Added files: lib/libc/gen statvfs.c Log: A simple implementation of statvfs(3) (one step above the trivial one). Not yet connected to the build (awaiting documentation). Would the people complaining about ports with broken configure scripts not compiling please add this into your libc and report on your success (and in particular whether it gives the results your programs expect)? archivers/rpm was one of the ports that had problems with statvfs in its script. I just built/installed libc with statvfs.c and rpm no longer has a problem (with at least building). Thanks. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
mergemaster failure
I first saw this a while ago (10 days?) but thought I'd screwed
something up myself. Didn't get a chance to clean the box up fully and
try again until this morning. After a successfull buildworld, trying to
do a mergemaster, this happens:
# mergemaster -i
mergemaster: not found
# /usr/sbin/mergemaster -i
*** The directory specified for the temporary root environment,
/var/tmp/temproot, exists. This can be a security risk if untrusted
users have access to the system.
Use 'd' to delete the old /var/tmp/temproot and continue
Use 't' to select a new temporary root directory
Use 'e' to exit mergemaster
Default is to use /var/tmp/temproot as is
How should I deal with this? [Use the existing /var/tmp/temproot]
*** Leaving /var/tmp/temproot intact
*** Creating the temporary root environment in /var/tmp/temproot
*** /var/tmp/temproot ready for use
*** Creating and populating directory structure in /var/tmp/temproot
set - `grep ^[a-zA-Z] /usr/src/etc/locale.deprecated`; while [ $# -gt 0 ] ; do
for dir in /usr/share/locale /usr/share/nls /usr/local/share/nls; do test -d
/var/tmp/temproot/${dir} cd /var/tmp/temproot/${dir}; test -L $2 rm -rf $2;
test \! -L $1 test -d $1 mv $1 $2; done; shift; shift; done
mtree -deU -f /usr/src/etc/mtree/BSD.root.dist -p /var/tmp/temproot/
mtree:No such file or directory
*** Error code 1
Stop in /usr/src/etc.
*** FATAL ERROR: Cannot 'cd' to /usr/src/etc and install files to
the temproot environment
/usr/src/etc exists, so does the temproot. I've tried nuking the
temproot too, nothing helps. Did I miss out on something or are other
people seeing this?
If it at all matters (can't see why), UP Thunderbird 1200.
uname -a:
FreeBSD CPE0030ab0ef2bb.cpe.net.cable.rogers.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0:
Fri Jul 12 16:38:29 EDT 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARCADIA i386
Any insights would be appreciated.
--
Munish Chopra The FreeBSD NVIDIA Driver Initiative
http://nvidia.netexplorer.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: HEADS UP, beware of pmap changes.
Peter Wemm wrote: This is mostly a FYI because I do not expect major problems this time. I have been extensively testing it in a handful of configurations. As murphy would dictate, something fishy is going on. In the last 12 hours or so (I had a long sleep), I've started getting apparent memory corruption - although it only seems visible to userland. The usual symptom is that gas gets blocks of memory clobbered with 0xd0d0d0d0 (yes, the same fill pattern used in phkmalloc). This is highly suspicious. I'll keep everybody informed once I've narrowed down when it started breaking. My test machines had one last cvs update/merge conflicts/compile/reboot before commit. I hope I didn't fat-finger merging the conflicts or something silly right before commit. I have only seen it happen occasionally on one SMP box, the others appear OK. I have not seen problems show up on UP at all. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
New ipfw isn't 64-bit clean
In struct ip_fw, the member timespace becomes padded with 32-bits because a pointer follows it. This causes the RULESIZE() macro to miscalculate the size of the rule by 4 bytes. Resulting in EINVAL and kernel warnings: %%% bowie# ipfw add allow all from me to 192.168.3.1 0 allow ip from me to 192.168.3.1 ipfw: size mismatch (have 64 want 68) ipfw: getsockopt(IP_FW_ADD): Invalid argument %%% (Shouldn't 0 be 00100?) I worked around the breakage by moving next_rule to the second position in the struct. I imagine the real solution involves not jamming kernel pointers into public interfaces. Also, ipfw(8) has lots of warnings as a result of printf()s with deprecated quad_t's. This should be easily fixed by using intmax_t's. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
