Re: vinum error: statfs related?

[Eric Anholt]

On Sun, 2003-11-16 at 20:14, Daryl Chance wrote:
> I am currently not able to load my vinum array
> (haven't tried to revert back to pre-statfs source)
> after I built a new kernel and world.  I upgraded the
> recommended way (installkernel, reboot, single user
> mode, installworld, etc) and when my box boots I get
> "vinum loaded, no drives found".  When I go to
> kldunload vinum, it unloads but I get the error:
> 
> vinum: exiting with malloc table inconsistency at
> 0xc2f49400 from vinumio.c:755
> vinum: unloaded
> 
> I checked the pr's, but haven't seen anything yet
> listed in there.  Should I do a sendpr?  I'm basically
> using the generic conf, with the exception that I've
> removed 486 and 586 and changed the ident.
> 
> I don't have a lint config, so i don't know how to
> compile vinum into the kernel to test if that fixes
> it.  If theres anymore info needed, I'd be glad to
> give access to the box or email a dmesg.

I'm getting the same (no drives/subdisks/plexes/volumes found) trying to
upgrade from a Nov 11 kernel/userland to Nov 16th kernel.  I tried
seeing if using a Nov 16th vinum binary would load them, but after doing
a stop/start, the system paniced, and it seems my swap is too small to
dump on.  Kernel was built using configure MYKERNEL; cd
../compile/MYKERNEL; make depend all install instead of buildkernel. 
DDB enabled but no invariants/witness, not sure what else from my config
might be applicable.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

Re: driver problem without lock held

[Eric Anholt]

On Mon, 2003-11-10 at 21:10, Jason wrote:
> Here is the error:
> 
> drm0:  port 0xa000-0xa0ff mem 
> 0xec02-0xec02,0xe000-0xe7ff irq 10 at device 0.0 on pci2
> info: [drm] Initialized radeon 1.9.0 20020828 on minor 0
> error: [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
> error: [drm:radeon_unlock] *ERROR* Process 512 using kernel context 0
> 
> Now are there any suggestions on what is causing this or how to fix 
> this?  I have a nforce2 epox 8rda, freebsd 5.1, and cvsuped and did a 
> buildworld today.
> Thanks,
> Jason

This error has been reported by both FreeBSD and Linux users for several
months.  Does it prevent the DRI from initializing?   Looks like it
should.  Under what circumstances do you get this error?

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

Re: -CURRENT and -STABLE fails on IBM R30 in agp_ali.c

[Eric Anholt]

On Mon, 2003-11-10 at 13:50, Bjoern Fischer wrote:
> Hello,
> 
> there is a problem in ali_agp.c (both, -CURRENT and -STABLE): If I
> boot the generic kernel, it panics in agp_ali.c, when it tries to
> allocate memory for the gatt. Some simlpe tests showed, that the
> initial aperture size is reported as zero by the device:
> 
>   static int
>   agp_ali_attach(device_t dev)
>   {
> struct agp_ali_softc *sc = device_get_softc(dev);
> struct agp_gatt *gatt;
> int error;
>   
> error = agp_generic_attach(dev);
> if (error)
> return error;
>   
> sc->initial_aperture = AGP_GET_APERTURE(dev);
> 
> This is zero-^^
>   
> for (;;) {
> gatt = agp_alloc_gatt(dev);
> if (gatt)
> break;
>   
> /*
>  * Probably contigmalloc failure. Try reducing the
>  * aperture so that the gatt size reduces.
>  */
> if (AGP_SET_APERTURE(dev, AGP_GET_APERTURE(dev) / 2)) {
> agp_generic_detach(dev);
> return ENOMEM;
> }
> }
> sc->gatt = gatt;
>   
> /* Install the gatt. */
> 
> Since I don't have a machine ready running -CURRENT, I can't really
> debug this. How can I disable agp0 on boot time?

Would this be appropriate to commit to AGP, to disable the ali agp in
case it reports 0 size (perhaps something in the BIOS has disabled it?)
and to have agp_alloc_gatt() just fail instead of panicing in
contigmalloc if the aperture size is 0?

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]

Index: agp.c
===
RCS file: /home/ncvs/src/sys/pci/agp.c,v
retrieving revision 1.33
diff -u -r1.33 agp.c
--- agp.c	23 Oct 2003 18:08:56 -	1.33
+++ agp.c	11 Nov 2003 20:21:08 -
@@ -175,6 +175,11 @@
 			  "allocating GATT for aperture of size %dM\n",
 			  apsize / (1024*1024));
 
+	if (entries == 0) {
+		device_printf(dev, "bad aperture size\n");
+		return NULL;
+	}
+
 	gatt = malloc(sizeof(struct agp_gatt), M_AGP, M_NOWAIT);
 	if (!gatt)
 		return 0;
Index: agp_ali.c
===
RCS file: /home/ncvs/src/sys/pci/agp_ali.c,v
retrieving revision 1.8
diff -u -r1.8 agp_ali.c
--- agp_ali.c	22 Aug 2003 07:13:20 -	1.8
+++ agp_ali.c	11 Nov 2003 20:21:10 -
@@ -102,6 +102,10 @@
 		return error;
 
 	sc->initial_aperture = AGP_GET_APERTURE(dev);
+	if (sc->initial_aperture == 0) {
+		device_printf(dev, "bad initial aperture size, disabling\n");
+		return ENXIO;
+	}
 
 	for (;;) {
 		gatt = agp_alloc_gatt(dev);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Radeon DRM-Problem

[Eric Anholt]

On Fri, 2003-11-07 at 13:23, Ralf Folkerts wrote:
> Hi,
> 
> I have a Problem with DRM (Radeon) on my "Current"-Box.
> 
> I cvsuped and made my last buildworld/-kernel/installkernel/-world last week
> (Oct 31).
> 
> FreeBSD penguin.home.folkerts-net.de 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Fri
> Oct 31 20:04:27 CET 2003
> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PENGUINKERNEL  i386
> 
> >From this List I think this Problem should have been fixed a while ago?!
> 
> When starting X I get
> 
> agp0: binding memory at bad offset 0
> error: [drm:pid704:radeon_cp_init] *ERROR* radeon_cp_init called without
> lock held
> error: [drm:pid704:radeon_unlock] *ERROR* Process 704 using kernel context 0
> 
> on the Console. When I then shutdown X and start it up again I don't get any
> display any
> longer (however, the machine still works and i.e. can be shutdown -r now,
> but w/o seing
> anything until the reboot).
> 
> Pls note: Except for these Problems (Lock when restarting X and no DRM) X
> runs nice and w/o
> any other Problems!
> 
> Does anyone have a hint? Did I shred my Config(s)? Or is this a real
> Problem?

Linux users have also been experiencing those *ERROR* messages.  I'm not
sure what's going on here.  I don't think the hangs are related to the
error, since Linux people haven't been complaining about hangs.  The agp
message, however, is something I haven't seen or heard about before. 
What does dmesg| grep agp say?

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

Re: drm, irqs, etc.

[Eric Anholt]

On Wed, 2003-11-05 at 21:24, Mike Hoskins wrote:
> first, i apologize...  i didn't think i'd get real answers on -questions
> so i'm posting this here.  i realize 5.x isn't really "stable" yet, but i
> hope it's close enough to be relevant.  ;)
> 
> i've got XFree86 4.3.0 installed, from the "X-4" meta port.  that went
> smoothly.  using the mga driver with a matrox g450 (dual head).  no dri on
> head 2 as expected, but again no obvious problems.
> 
> what i've noticed (this is 5.1-p8) is that after X has been running for
> awhile, trying to exit X causes a hang.  at first i thought it was some
> program under X not exiting properly (that's what it looks like), but i've
> reproduced the same behavior with nothing but X running.  if i start X and
> then exit immediately, everything is fine.  this seems to only happen
> after X runs for a week or more.
> 
> the one thing i noticed, was some "interesting" behavior wrt drm and it's
> claimed IRQ.  before starting X (after a reboot), `ps ax|grep irq` shows:
> 
>19  ??  WL 0:00.00  (irq9: pcm0 acpi0)
>20  ??  WL 0:00.10  (irq14: ata0)
>21  ??  WL 0:00.00  (irq15: ata1)
>22  ??  WL 0:00.00  (irq10: fxp0)
>23  ??  WL 0:00.00  (irq6: fdc0)
>24  ??  WL 0:00.01  (irq1: atkbd0)
> 
> the same from within X shows,
> 
>19  ??  WL 0:00.00  (irq9: pcm0 acpi0)
>20  ??  WL 0:01.05  (irq14: ata0)
>21  ??  WL 0:00.00  (irq15: ata1)
>22  ??  WL 0:00.02  (irq10: fxp0)
>23  ??  WL 0:00.00  (irq6: fdc0)
>24  ??  WL 0:00.08  (irq1: atkbd0)
>25  ??  WL 0:00.09  (irq12: psm0)
>   690  ??  WL 0:00.12  (irq11: drm0)
> 
> and once exiting X (immediately, when it exits without hanging),
> 
>19  ??  WL 0:00.00  (irq9: pcm0 acpi0)
>20  ??  WL 0:01.04  (irq14: ata0)
>21  ??  WL 0:00.00  (irq15: ata1)
>22  ??  WL 0:00.02  (irq10: fxp0)
>23  ??  WL 0:00.00  (irq6: fdc0)
>24  ??  WL 0:00.07  (irq1: atkbd0)
>25  ??  WL 0:00.06  (irq12: psm0)
>   690  ??  WL 0:00.08  (irq11:)
> 
> is irq11 not being freed?  or is that normal behavior?  i've double
> checked by X config, but i may have something wrong.  i've read various
> web pages and XFree's suggestions about configuring the g450...  but,
> again, i may have overlooked something.
> 
> this is a hard hang...  ctrl-alt-bkspc, ctrl-alt-del, etc. have no effect.
> i've since enabled "NoTrapSignals" in my X config hoping to get a core
> dump the next time it happens.  if i can manage that, i'll include it in a
> future report.  (or any other info you think is relevant.)
> 
> please CC me directly with any replies, i am not currently subscribed to
> -stable.

5.1 is -current, not -stable, so you should be mailing the -current
list.  I've reset the cc: appropriately.

If you're not using up to date -current, please upgrade to -current past
October 24th, which included some DRM IRQ fixes.  If the problem
persists, could you check that it doesn't happen with the DRI disabled
in your XF86Config?

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

Re: DRM error messages - easy way to turn them off?

[Eric Anholt]

On Mon, 2003-11-03 at 12:31, Michael L. Squires wrote:
>  > > On Sat, 25 Oct 2003 04:50:30 +0900, Shin-ichi Yoshimoto wrote:
>  > > > I'm using a radeon DRM module.
>  > > 
>  > > Now DRM work fine. But some kernel messages found my log like this.
>  > > 
>  > > kernel: error: [drm:pid38523:radeon_ioctl] *ERROR* can't find 
>  > > authenticator
>  > > 
>  > > Is this OK ?
>  > 
>  
> Is there any simple way to turn this error off?  These are appearing 
> frequently enough to fill /var/log/messages several times a day, although
> I haven't seen any other side effects.

I've gone ahead and made it a debug message again in -current.  It's
still an issue that really needs to get fixed I think (I think it's
related to the failure to init DRI after a KDE session), but I don't
have the time for it myself.  One thing that's been suggested by linux
folks for other purposes is getting things fixed so that only KDE things
that need libGL to link to libGL.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

Re: Radeon 7500 w/ DRI locking on restart of X

[Eric Anholt]

On Fri, 2003-10-24 at 11:06, Sean Welch wrote:
> Eric, I updated my 5.1-RELEASE system to CURRENT dated today at
> approx. 9:10 CDT to give your changes a try.  I had a bit of a fright at
> first with kernel panics right at the end of the boot sequence but it turned
> out I had forgotten to disable the ltmdm code -- the kernel module
> compiled under -RELEASE wasn't friendly to -CURRENT.
> 
> I've got just a basic install with my custom kernel.  I'm using the packages
> for X from the 5.1-RELEASE cd running twm.  Hangs on restart are gone!
> I restarted about 10 times in a row and ran glxinfo and glxgears each time
> to verify DRI was still activated and working -- no issues.  VT switches are
> fine (even while running glxgears).  The one thing that does not work is 
> resume from acpiconf -s 4 (disk) -- there is a failure to refresh in X and no
> ability *apparently* to switch to a VT; the keystrokes just generate beeps.
> Interestingly, the cursor still changed between the different modes when 
> mousing over the xterm and onto the background.  Also, Alt-Cntl-Del did
> work just fine.

Suspend/resume is doesn't work well.  You might get lucky with the
-current DRM with XFree86-4-Server-snap.

> The only other thing I noticed is that there seems to be a syslog entry for
> every instance of running glxgears that reads:
> 
> [MP SAFE] drm0
> 
> Is this expected behavior?  I noticed that same message (in brackets) in
> front of each of my disks as they were probed during boot.

That printout happens whenever an mpsafe interrupt handler is
installed.  It gets installed upon initializing the DRI in the server. 
I don't think any drivers do it more often.  It may happen frequently if
glxgears is your only app running, in which case you'll get a server
regenerate on exit of glxgears.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

Re: DRM related error

[Eric Anholt]

On Sat, 2003-10-25 at 10:21, Shin-ichi Yoshimoto wrote:
> Subject: Re: fresh -current trap,
> On Sat, 25 Oct 2003 04:50:30 +0900, Shin-ichi Yoshimoto wrote:
> > I'm using a radeon DRM module.
> 
> Now DRM work fine. But some kernel messages found my log like this.
> 
> kernel: error: [drm:pid38523:radeon_ioctl] *ERROR* can't find 
> authenticator
> 
> Is this OK ?

Sort of.  This is an error that has actually been happening for a long
time, and I'm guessing is the reason for the issues with KDE and the
DRI, but it's been a debug message instead of an error.  It's something
that needs to get fixed, but doesn't mean things have gotten worse since
the previous import.  It's the highest thing on my list of FreeBSD DRM
issues to fix.

I wasn't expecting the error to be as common as it is.  I admit that I
didn't really start KDE up fully, because it's a read-only netboot
system, which KDE didn't like very much.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

Re: fresh -current trap

[Eric Anholt]

On Fri, 2003-10-24 at 05:39, Sergey A. Osokin wrote:
> Hello,
> 
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x60
> fault core= supervisor read, page not present
> instruction pointer   = 0x8:0xc04d6d42
> stack pointer = 0x10:0xde5b7624
> frame pointer = 0x10:0xde5b764c
> code segment  = base 0x0, limit 0xf, type 0x1b
>   = DPL 0, pres 1, def32 1, gran 1
> processor eflags  = interrupt enabled, resume, IOPL = 0
> current process   = 87 (sysctl)
> kernel: trap 12 trap, code=0
> Stopped at_mtx_lock_sleep+0x1b2:  movl0x68(%ecx),%edx
> db> where
> _mtx_lock_sleep(c2978c18,0,c07a85f4,e5,c12bfa80) at _mtx_lock_sleep+0x1b2
> _mtx_lock_flags(c2978c18,0,c07a85f4,e5,0) at _mtx_lock_flags+0x40
> radeon_bufs_info(c2973920,c2978c00,0,de5b7bf8,de5b7bf8) at radeon_bufs_info+0x6f
> sysctl_root(0,de5b7c98,4,de5b7bf8,c29b85f0) at sysctl_root+0x14b
> useland_sysctl(c29b85f0,de5b7c98,4,0,bfbff40c) at useland_sysctl+0x14d
> __sysctl(c29b85f0,de5b7d10,18,c0509436,6) at __sysctl+0xd4
> syscall(2f,2f,2f,0,bfbff40c) at syscall+0x310
> Xint0x80_syscall() at Xint0x80_syscall+0x1d
> --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x280bed2f, esp = 0xbfbff38c, ebp 
> = 0xbfbff3b8 ---
> 
> Any idea?

I just committed a fix for this to CVS.  Sorry for the trouble.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

Re: fresh -current trap

[Eric Anholt]

On Fri, 2003-10-24 at 13:40, Arjan van Leeuwen wrote:
> On Friday 24 October 2003 19:30, Kris Kennaway wrote:
> > On Fri, Oct 24, 2003 at 10:13:34AM -0700, Janet Sullivan wrote:
> > > Kris Kennaway wrote:
> > > >On Fri, Oct 24, 2003 at 04:39:14PM +0400, Sergey A. Osokin wrote:
> > > >>Fatal trap 12: page fault while in kernel mode
> > > >
> > > >Looks like it might be related to the DRM import from yesterday.
> > > >You're not using any modules, are you?
> > >
> > > Since the DRM commit I received similar traps.  I had to rebuild a
> > > kernel without "options radeondrm" just to be able to boot.  I'm not
> > > using any modules.
> >
> > Don't drop the mailing list from the CC list when reporting bugs ;-)
> >
> > Kris
> 
> Same here, using an Ati Radeon R100. I see functions that have 'radeon' in the 
> name in the trace. Is there any more information I can provide?

Not sure what went wrong here.  I'm cvsupping to do a fresh build (going
really slow, our internet connection is terrible).  Sorry for the
trouble everyone.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

Re: FreeBSD-Current and XFree86

[Eric Anholt]

On Fri, 2003-10-24 at 00:13, Thomas Schwarzkopf wrote:
> On Friday 24 October 2003 02:00, James Tanis wrote:
> 
> >  From the log file:
> > (II) Primary Device is: 
> > (--) Assigning device section with no busID to primary device
> > (WW) RADEON: No matching Device section for instance (BusID
> > PCI:1:0:1) found (EE) No devices detected.
> >
> >  I did not attempt any different settings from the norm at
> > this time since, if my memory serves me right this is the same exact
> > error I was getting before and nothing I tried seemed to fix it. Here
> > is the device section as it is now for my radeon 9800, these are the
> > same settings that I used to use and worked perfectly fine with my
> > radeon 7000, although I have tried a config without the extra options
> > it did not seems to help nor is their any reason that I can think of
> > that these options would not work with the 9800.
> >
> > Section "Device"
> >  Identifier  "Radeon 9800"
> >  Driver  "radeon"
> >  #VideoRam131072
> >  # Insert Clocks lines here if appropriate
> >  Option  "AGPMode"   "4"
> >  Option  "AGPFastWrite"  "1"
> >  Option  "EnablePageFlip""1"
> > EndSection
> 
> Have you tried adding a line like this
> 
> BusID"PCI 01:00:0"
> 
> to Section "Device"? Maybe also try "PCI 1:0:1"
> I had the same error with a different card and this helped.

Actually, the problem here (as I just replied in a private email) was
that that card is newer than 4.2.99.12's radeon support, so it didn't
probe the radeon.  Solution I suggested was to try chipid 0x4e48 because
his is 0x4e49, which is the same generation of chip.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

Re: Radeon 7500 w/ DRI locking on restart of X

[Eric Anholt]

On Tue, 2003-08-26 at 20:37, Glenn Johnson wrote:
> On Tue, Aug 26, 2003 at 01:27:11PM -0700, Eric Anholt wrote:
> 
> > On Tue, 2003-08-26 at 18:05, Vulpes Velox wrote:
> >
> > > I had similar problem with a 7200 and OGL. I solved the problem by
> > > turning off some of the options in the X config.
> > >
> > > On Tue, 26 Aug 2003 12:21:56 -0500 (GMT) Sean Welch
> > > <[EMAIL PROTECTED]> wrote:
> > >
> > > > Is anyone else seeing this issue?  I'm running into it on desktop
> > > > boxes and a laptop running 4.8-RELEASE with up to date ports
> > > > collections and various versions of DRI installed over a ports
> > > > version of X.  I'm also seeing this under 5.1-RELEASE on the
> > > > laptop.
> > > >
> > > > Everything works perfectly unless/until I restart the X server.
> > > > This appears to be initiated automatically when running GDM -- ie,
> > > > GDM starts, you log in using that X session, you log out and the
> > > > session stops, GDM starts X again and displays the login screen.
> >
> > Everyone that's experiencing this and is using the DRI, what version
> > of the radeon DRM is loaded? (dmesg | grep drm) Is anyone experiencing
> > this without the DRI loaded?  The ForcePCIMode workaround is
> > interesting, I'll take a look at what could be going on there.
> 
> I did some googling tonight and found out this problem is supposedly
> fixed in XFree86-4.3.99 although I do not see any specific mention of
> this problem in the Changelog.  See:
> 
> http://www.knoppix.net/forum/viewtopic.php?t=2504&highlight=

That patch has been in our XFree86 for quite a while.  For those of you
using -current, could you try with the latest DRM which I committed to
FreeBSD CVS a few minutes ago?

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

Re: FreeBSD-Current and XFree86

[Eric Anholt]

On Thu, 2003-10-23 at 13:59, James Tanis wrote:
>  I'm having problems with XFree86 that result from the fact that 
> the ATI Radeon 9800 is not supported by the current 4.3.0 radeon driver. I 
> would like to upgrade to current/cvs version of XFree86, 4.3.99 since the 
> next release isn't going to be for around another 2 months. My question is, 
> what is the most flawless way to do this? Is there a FreeBSD concentric 
> repository, or should I just get the sources from the standard XFree86 cvs 
> repository? Is there a place where I can instead get frequently updated 
> ports of the repository? Building from source is there any configure 
> switches that I need to successfully build? Last but not least is it 
> possible to build only the radeon drivers and use those in 4.3.0.. if so, 
> how do I go about doing that? I had some problems when I only downloaded 
> the graphics drivers module.
> Thanks for any 

Please use XFree86-4-Server-snap if you are looking for CVS X Server. 
The snap is slightly out of date due to problems getting 4.2.99.14
building (the monolithic nature of XFree86 is a major issue for
maintaining these ports), but it should include radeon 9800 support.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

Re: PCI domains?

[Eric Anholt]

On Tue, 2003-10-21 at 15:42, Scott Long wrote:
> Eric Anholt wrote:
> > Is there any concept of PCI domains in the kernel?
> > 
> > This is for the DRM, while dealing with a complaint from Linus recently:
> > 
> > 
> >>Please fix the fact that modern PCI is _not_ enumerated with just "bus,
> >>slot, function". A lot of machines are starting to have a "domain number", 
> >>which allows fro multiple independent PCI subsystems in the same machine.
> >>
> >>On linux, you can use "pci_name(pdev)" to get a truly unique descriptor of
> >>the device (within the PCI subsystem). It will look something like
> >>
> >>:00:02.0
> >>
> >>for "domain 0, bus 0, device 2, function 0".
> > 
> > 
> > 
> 
> We don't have much of a concept of this (except possibly Alpha like John
> mentioned, but I really cannot comment on that).  Supporting it
> wouldn't be terribly magical on our end until we fix busdma to support
> device-device transfers.  Since I don't know much context on the DRM
> side, what exactly is Linus asking to change, and do we need to worry
> about it?

The DRM historically doesn't attach to specific devices itself.  The X
Server opens a /dev/dri/cardX, sees if it fits its criteria (driver name
matches, no unique value currently set), then sets the "unique."  The
unique is a Bus ID in the form PCI:x:y:z.  This unique is passed through
the XF86DRI protocol to the clients, who iterate over the /dev/dri/cardX
looking for one with that unique when they want to open it.

Because of this whole system, the DRM also doesn't associate with
framebuffer, mmio registers, or other device-specific things by itself
-- it's all done by the X Server through things like the addmap ioctl. 
This makes using bus_space difficult.

I'm working on a change so that the DRM attaches to a specific device,
and thus has the unique set before the X Server gets to it (well, it's
not that way due to backwards compatibility gymnastics, but that's the
goal).  It was prompted by another developer who's working on standalone
DRI, which doesn't use the X Server at all.  When the issue of the
unique came up, Linus said the quote above.

It looks like the "hose" on alpha is equivalent to a domain, from the
linux code.  For now I'm just using a domain of 0 on FreeBSD, but if the
hoses have numbers that match XFree86's scheme, whatever that is, I'll
use that.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

PCI domains?

[Eric Anholt]

Is there any concept of PCI domains in the kernel?

This is for the DRM, while dealing with a complaint from Linus recently:

> Please fix the fact that modern PCI is _not_ enumerated with just "bus,
> slot, function". A lot of machines are starting to have a "domain number", 
> which allows fro multiple independent PCI subsystems in the same machine.
> 
> On linux, you can use "pci_name(pdev)" to get a truly unique descriptor of
> the device (within the PCI subsystem). It will look something like
> 
>   :00:02.0
> 
> for "domain 0, bus 0, device 2, function 0".


-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

Re: DRM SMPng locking for review

[Eric Anholt]

On Thu, 2003-10-16 at 23:03, Eric Anholt wrote:
> I've been working on locking of the DRM, based off of the work that was
> already done for linux and ported to BSD.  I think the current locking
> was wrong, including that it used lockmgr and simplelocks on -stable
> when as far as I know it was unnecessary.  Also, I had marked the IRQ
> handlers MPSAFE without understanding the issue really, so IRQs could
> get missed.  Here's a patch, which I hope someone can review because I
> don't trust myself at all.
> http://people.freebsd.org/~anholt/dri/files/drm-locking-2.diff
> 
> It's against DRI CVS, as I haven't merged to FreeBSD in a while.  You
> can get it using the instructions at:
> http://dri.sourceforge.net/cgi-bin/moin.cgi/CVS
> If you don't want to build the whole tree, you can just:
> 
> cd xc
> patch -p0 < ~/drm-locking-2.diff
> cd programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel
> ln -s ../../../shared/drm/kernel/*.[ch] ./
> 
> Quick question: If open returns an error, close doesn't get called, does
> it?

Well, I went ahead and made a bunch of fixes and committed it.  Should
anyone want to review the code, the same steps with the patch step
removed should do it.  I'll probably bring it over to -current some time
soon.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

DRM SMPng locking for review

[Eric Anholt]

I've been working on locking of the DRM, based off of the work that was
already done for linux and ported to BSD.  I think the current locking
was wrong, including that it used lockmgr and simplelocks on -stable
when as far as I know it was unnecessary.  Also, I had marked the IRQ
handlers MPSAFE without understanding the issue really, so IRQs could
get missed.  Here's a patch, which I hope someone can review because I
don't trust myself at all.
http://people.freebsd.org/~anholt/dri/files/drm-locking-2.diff

It's against DRI CVS, as I haven't merged to FreeBSD in a while.  You
can get it using the instructions at:
http://dri.sourceforge.net/cgi-bin/moin.cgi/CVS
If you don't want to build the whole tree, you can just:

cd xc
patch -p0 < ~/drm-locking-2.diff
cd programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel
ln -s ../../../shared/drm/kernel/*.[ch] ./

Quick question: If open returns an error, close doesn't get called, does
it?

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

Re: Problems with XFree86-4

[Eric Anholt]

On Tue, 2003-10-14 at 17:21, Rossam Souza Silva wrote:
> Hi, I'm running 5.1-CURRENT (sources/ports from Oct/13) and
> the X package isn't compiling:
> 
> FeaNoR# make package
> ===>  Installing for XFree86-4.3.0,1
> ===>   XFree86-4.3.0,1 depends on executable: xvinfo - not found
> ===>Verifying package for xvinfo in /usr/ports/x11/XFree86-4-clients
> ===>  Building for XFree86-clients-4.3.0_3
> making all in lib/lbxutil/lbx_zlib...
> making all in lib/lbxutil/delta...
> making all in lib/lbxutil/image...
> making all in programs/appres...
> making all in programs/bdftopcf...
> make: don't know how to make
> /home/FreeBSD/ports/x11/XFree86-4-clients/work/xc/exports/lib/libfntstubs.a.
> Stop
> *** Error code 2
> 
> Stop in /home/FreeBSD/ports/x11/XFree86-4-clients/work/xc/programs.
> *** Error code 1
> 
> Stop in /home/FreeBSD/ports/x11/XFree86-4-clients.
> *** Error code 1
> 
> Stop in /home/FreeBSD/ports/x11/XFree86-4.
> 
> I had this same error a week ago, someone have a clue?

Fixed yesterday.  cvsup and try again.

(The fix is in XFree86-4-libraries/files/ and XFree86-4-clients/scripts
-- you need to cvs update both before rebuilding -clients)

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

Re: XFree86-4-clients port broken.

[Eric Anholt]

On Mon, 2003-10-13 at 14:54, David Gilbert wrote:
> I don't really have a clue where to look for this fix as there seems
> to be a serious amount of magic going into the divided XFree86-4 port
> builds, but my XFree86-4-clients port fails saying:
> 
> make: don't know how to make 
> /usr/ports/x11/XFree86-4-clients/work/xc/exports/lib/libfntstubs.a. Stop
> 
> Dave.

It should be fixed now.  Please cvsup (in ~1hour) and try again.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

Re: XFree86-4-clients port broken.

[Eric Anholt]

On Mon, 2003-10-13 at 16:05, Peter Wemm wrote:
> Eric Anholt wrote:
> > On Mon, 2003-10-13 at 15:51, Peter Wemm wrote:
> > > David Gilbert wrote:
> > > > I don't really have a clue where to look for this fix as there seems
> > > > to be a serious amount of magic going into the divided XFree86-4 port
> > > > builds, but my XFree86-4-clients port fails saying:
> > > > 
> > > > make: don't know how to make /usr/ports/x11/XFree86-4-clients/work/xc/exp
> orts
> > > /lib/libfntstubs.a. Stop
> > > 
> > > I ran into this on my amd64 box too.  Is yours an i386?
> > 
> > This is a problem on ref5, too.  I am testing a fix right now.  The
> > confusing part is I can't find any change I (or anyone else) has made
> > that would have caused this.
> 
> Does the port have any exposure to make(1) at all?  Its been futzed with
> fairly recently.  I know it's supposed to use gmake, but perhaps there are
> still some "make" references?

No, actually it uses the system (bsd) make.  It generally is pretty
resistant to differences with different types of make, though.

Testing a new idea for a fix that will cut the build time/space
required, too.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

Re: XFree86-4-clients port broken.

[Eric Anholt]

On Mon, 2003-10-13 at 15:51, Peter Wemm wrote:
> David Gilbert wrote:
> > I don't really have a clue where to look for this fix as there seems
> > to be a serious amount of magic going into the divided XFree86-4 port
> > builds, but my XFree86-4-clients port fails saying:
> > 
> > make: don't know how to make /usr/ports/x11/XFree86-4-clients/work/xc/exports
> /lib/libfntstubs.a. Stop
> 
> I ran into this on my amd64 box too.  Is yours an i386?

This is a problem on ref5, too.  I am testing a fix right now.  The
confusing part is I can't find any change I (or anyone else) has made
that would have caused this.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

Re: i865 Video Memory

[Eric Anholt]

On Wed, 2003-10-08 at 10:10, David Malone wrote:
> It seems some recent Dell machines have the amount of video memory
> available set to 1MB by default. The desktop machines allow you to
> set this in the BIOS, but the laptops don't seem to allow you to
> adjust this. Christian Zietz has a hack for Linux that convinces
> the BIOS to let you use more memory, and I've just ported his hack
> to FreeBSD.
> 
> Christian's code is at:
> 
>   http://www.chzsoft.com.ar/855patch.html
> 
> and my patch to his code, and a binary compiled for 4.9 are at:
> 
>   http://www.cnri.dit.ie/~dwmalone/855patch/
> 
> You can just run "855patch 8192" before starting X, and suddenly
> you can do a resolution higher than 640x480 in 8 bit mode ;-)

I'm pretty sure code got included in XFree86 a week or so ago to
accomplish this.  I'll be updating XFree86-4-Server-snap when I can so
people can try this out.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

Re: i386_set_ldt messages with today's world

[Eric Anholt]

On Sun, 2003-09-07 at 14:13, Daniel Eischen wrote:
> On Sun, 7 Sep 2003, Harald Schmalzbauer wrote:
> 
> > Hi all,
> > 
> > I have no idea what it means, but since today's world I get the following 
> > messages after starting x:
> > 
> > Warning: pid 541 used static ldt allocation.
> > See the i386_set_ldt man page for more info
> > Warning: pid 547 used static ldt allocation.
> > See the i386_set_ldt man page for more info
> > Warning: pid 548 used static ldt allocation.
> > See the i386_set_ldt man page for more info
> > Warning: pid 567 used static ldt allocation.
> > See the i386_set_ldt man page for more info
> > Warning: pid 568 used static ldt allocation.
> > See the i386_set_ldt man page for more info
> > Warning: pid 569 used static ldt allocation.
> > See the i386_set_ldt man page for more info
> > Warning: pid 570 used static ldt allocation.
> > See the i386_set_ldt man page for more info
> > Warning: pid 573 used static ldt allocation.
> > See the i386_set_ldt man page for more info
> > Warning: pid 572 used static ldt allocation.
> > See the i386_set_ldt man page for more info
> > Warning: pid 577 used static ldt allocation.
> > See the i386_set_ldt man page for more info
> 
> Something is using i386_set_ldt() static ldt allocations.  We
> added the warning message to detect usage of these allocations
> so they could be changed to dynamic allocations.
> 
> Our threads libraries make use of LDTs on i386, so having
> other code also use (possibly) the same LDT would break
> things.
> 
> > Only ode still exists which is:
> > 541  ??  S  0:15,50 /usr/X11R6/bin/XFree86 -auth /var/run/xauth/A:0-2CitM
> 
> What is ode?  Typo?  pid?
> 
> I don't see how XFree86 can use i386_set_ldt().  It doesn't
> reference it on my box:
> 
>   $ nm /usr/X11R6/bin/XFree86 | grep ldt
>   $

XFree86 loads various modules from /usr/X11R6/lib/modules.  That said, I
could find nothing about ldts being used anywhere in the source
(grepping for LDT, sldt, and set_ldt).

Perhaps the nvidia driver is being used?  That's the only thing I could
think of.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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

Re: Radeon 7500 w/ DRI locking on restart of X

[Eric Anholt]

On Tue, 2003-08-26 at 18:05, Vulpes Velox wrote:
> I had similar problem with a 7200 and OGL. I solved the problem by turning off
> some of the options in the X config.
> 
> On Tue, 26 Aug 2003 12:21:56 -0500 (GMT)
> Sean Welch <[EMAIL PROTECTED]> wrote:
> 
> > Is anyone else seeing this issue?  I'm running into it
> > on desktop boxes and a laptop running 4.8-RELEASE with
> > up to date ports collections and various versions of
> > DRI installed over a ports version of X.  I'm also seeing
> > this under 5.1-RELEASE on the laptop.
> > 
> > Everything works perfectly unless/until I restart the X
> > server.  This appears to be initiated automatically when
> > running GDM -- ie, GDM starts, you log in using that X
> > session, you log out and the session stops, GDM starts X
> > again and displays the login screen.
> > 
> > This seems to happen a bit more than 1/3 of the times I
> > try it (intentionally or not).  It isn't much of a problem
> > on the laptop as I'm the only user and tend to turn the
> > machine off when I log out but it is causing all sorts of
> > issues on the desktops because they are intended to be
> > used as multi-user (serially and also simultaneously)
> > systems.
> > 
> > Any ideas?  The instability goes away completely with DRI
> > disabled, but part of the use of these desktops is in the
> > accelerated OpenGL rendering...
> > 
> >   Sean

(CC'ed to -current since it's not -stable specific)

This is an example of why people need to send PRs and not just emails. 
I realize now I've seen emails on this before, but I had forgotten about
them because they seemed isolated and I didn't have them piling up in my
assigned prs list (things pile up in my mailboxes easily, and I don't go
back and check very often).

I've tried to reproduce this with a radeon, by doing startx, C-A-B to
kill the server, then startx again.  The second time, the screen
displays for a brief moment then goes black.  The system isn't hung, and
I can exit using C-A-B again.  Is this what everyone else sees?

Everyone that's experiencing this and is using the DRI, what version of
the radeon DRM is loaded?  (dmesg | grep drm)  Is anyone experiencing
this without the DRI loaded?  The ForcePCIMode workaround is
interesting, I'll take a look at what could be going on there.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]

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

Anyone had hangs with Radeon, XF86 4.3.0, and DRI on logout?

[Eric Anholt]

As the subject says, I'm wondering if anyone out there has experienced
hangs on logging out from xdm (or perhaps switching VTs) with Radeon or
matrox (perhaps r128, too) cards using the updated DRM in -current and
XFree86 4.3.0.  If so, I may have a fix, but I'm wondering if this
affects FreeBSD.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]

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

Re: buildkernel error on latest cvs src's

[Eric Anholt]

On Thu, 2003-02-13 at 18:25, Giorgos Keramidas wrote:
> On 2003-02-13 18:31, Matt <[EMAIL PROTECTED]> wrote:
> > Trying a buildworld/buildkernel of today's latest cvs code and the 
> > buildworld has compiled fine but the kernel is giving the error below.
> [...]
> > cc -O -pipe -mcpu=pentiumpro  -D_KERNEL -Wall -Wredundant-decls -Wnested-
> > externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -
> > Wcast-qual  -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I-   -I. -I@ -
> > I@/dev -I@/../include -fno-common  -mno-align-long-strings -mpreferred-stack-
> > boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-
> > prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -
> > fformat-extensions -ansi -c /usr/src/sys/pci/agp_i810.c
> > /usr/src/sys/pci/agp_i810.c: In function `agp_i810_match':
> > /usr/src/sys/pci/agp_i810.c:112: `AGP_I85X_CAPID' undeclared (first use in this 
>function)
> 
> Revert sys/pci/agp_i810.c to revision 1.16 and it will all build fine.

Or cvsup as of 7 hours ago.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: alpha tinderbox failure

[Eric Anholt]

On Thu, 2003-02-13 at 03:28, Dag-Erling Smorgrav wrote:
> ===> agp
> /h/des/src/sys/pci/agp_i810.c: In function `agp_i810_match':
> /h/des/src/sys/pci/agp_i810.c:112: `AGP_I85X_CAPID' undeclared (first use in this 
>function)
> /h/des/src/sys/pci/agp_i810.c:112: (Each undeclared identifier is reported only once
> /h/des/src/sys/pci/agp_i810.c:112: for each function it appears in.)
> /h/des/src/sys/pci/agp_i810.c:113: `AGP_I855_GME' undeclared (first use in this 
>function)
> /h/des/src/sys/pci/agp_i810.c:116: `AGP_I855_GM' undeclared (first use in this 
>function)
> /h/des/src/sys/pci/agp_i810.c:119: `AGP_I852_GME' undeclared (first use in this 
>function)
> /h/des/src/sys/pci/agp_i810.c:122: `AGP_I852_GM' undeclared (first use in this 
>function)
> /h/des/src/sys/pci/agp_i810.c: In function `agp_i810_attach':
> /h/des/src/sys/pci/agp_i810.c:342: `AGP_I855_GCC1' undeclared (first use in this 
>function)
> /h/des/src/sys/pci/agp_i810.c:343: `AGP_I855_GCC1_GMS' undeclared (first use in this 
>function)
> /h/des/src/sys/pci/agp_i810.c:344: `AGP_I855_GCC1_GMS_STOLEN_1M' undeclared (first 
>use in this function)
> /h/des/src/sys/pci/agp_i810.c:347: `AGP_I855_GCC1_GMS_STOLEN_4M' undeclared (first 
>use in this function)
> /h/des/src/sys/pci/agp_i810.c:350: `AGP_I855_GCC1_GMS_STOLEN_8M' undeclared (first 
>use in this function)
> /h/des/src/sys/pci/agp_i810.c:353: `AGP_I855_GCC1_GMS_STOLEN_16M' undeclared (first 
>use in this function)
> /h/des/src/sys/pci/agp_i810.c:356: `AGP_I855_GCC1_GMS_STOLEN_32M' undeclared (first 
>use in this function)
> *** Error code 1

I'm very sorry about this, I committed only one of the two files.  It
should be fixed now.  

As a side note, do any of these AGP chipsets apply to sparc64, alpha,
ia64?

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: kld problem ? (was: Re: MSDOSFS wastes 256k when nothing ismounted!)

[Eric Anholt]

On Sun, 2003-02-09 at 12:16, Alexey Zelkin wrote:
> hi,
> 
> On Sun, Feb 09, 2003 at 08:39:59PM +0100, Poul-Henning Kamp wrote:
> 
> > /*ARGSUSED*/
> > int
> > msdosfs_init(vfsp)
> > struct vfsconf *vfsp;
> > {
> > dehashtbl = hashinit(desiredvnodes/2, M_MSDOSFSMNT, &dehash);
> > mtx_init(&dehash_mtx, "msdosfs dehash", NULL, MTX_DEF);
> > return (0);
> > }
> 
> BTW, it reminds me a problem I found last month.  If you've MSDOSFS
> compiled in kernel and try to load msdosfs.ko with loader -- then
> you're 100% will hit into 'mutex already initialized' (or something
> like that) panic later in boot process. (i.e. msdosfs_init() is called
> twice for some reason)
> 
> I not sure if it's applicable to KLDs at all or to msdosfs only.

http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/34030
seems to be a similar problem.

We've seen this with the agp module when it's in the kernel and in
loader.conf.  In the agp case, it appears to initialize, but then
doesn't function when other devices (DRM) try to use it.  I would guess
it's being initialized twice, too.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: X compilation problems

[Eric Anholt]

On Thu, 2003-02-06 at 02:53, Fred Souza wrote:
>   Since the last port update for XFree86-libraries, I've been unable to
>   get that port (x11/XFree86-4-libraries) compiled. I insistently get this
>   error:
> 
> cc -c -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith  -I../include 
>-I/usr/ports/x11/XFree86-4-libraries/work/xc/include 
>-I/usr/ports/x11/XFree86-4-libraries/work/xc/include/GL  
>-I/usr/ports/x11/XFree86-4-libraries/work/xc 
>-I/usr/ports/x11/XFree86-4-libraries/work/xc/exports/include   -DCSRG_BASED  
>-DFUNCPROTO=15 -DNARROWPROTO   -DNDEBUG  -O2 -pipe -march=k6-2   mipmap.c -o 
>unshared/mipmap.o
> {standard input}: Assembler messages:
> {standard input}:7683: Error: value of -129 too large for field of 1 bytes at 20035
> *** Error code 1
> 
>   I'm running 5.0-CURRENT built yesterday (02/06), but I have seen this
>   happening since the update from revision 5 to 6 of the port (I'm not
>   sure about the exact date, but I think it happened about a week or so
>   ago.) Has anyone seen this? How do I fix it?

Please remove your nonstandard CFLAGS and try again.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: problem with X

[Eric Anholt]

On Wed, 2003-01-29 at 19:18, Kirk R. Wythers wrote:
> Eric,
> 
> I'll grep that for you as soon as I get to my office tomorrow. Should I
> try the add -fno-merge-constants to CFLAGS?

Sure.  What you add to CFLAGS in the environment won't show up in that
grep, so I'll still be able to get the information from it.  (The
question is whether imake is detecting whether that flag is available in
gcc or not).


-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: problem with X

[Eric Anholt]

On Wed, 2003-01-29 at 15:17, Eric Anholt wrote:
> On Wed, 2003-01-29 at 11:29, Charlie ROOT wrote:
> > On Tue, 28 Jan 2003, joseph wrote:
> > 
> > > Try a make build world and see if that version of libc_r works.
> > > It should fix the problem. joseph
> > 
> > I tried that... now the error is:
> > Symbol  from module /usr/X11R6/lib/modules/fonts/libbitmap.a is
> > unresolved!
> 
> I'm sorry this error was still around.  Apparently I had looked at a CVS
> version of X when trying to figure out why it was happening, and CVS X
> has it fixed.  Until I commit a fix, you can add -fno-merge-constants to
> your CFLAGS.

I'm more confused now.  Could someone who is seeing this problem, after
building XFree86-4-Server, do this:

grep MODULE XFree86-4-Server/work/xc/lib/font/bitmap/module/Makefile | grep FLAG

and tell me the output?

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: problem with X

[Eric Anholt]

On Wed, 2003-01-29 at 11:29, Charlie ROOT wrote:
> On Tue, 28 Jan 2003, joseph wrote:
> 
> > Try a make build world and see if that version of libc_r works.
> > It should fix the problem. joseph
> 
> I tried that... now the error is:
> Symbol  from module /usr/X11R6/lib/modules/fonts/libbitmap.a is
> unresolved!

I'm sorry this error was still around.  Apparently I had looked at a CVS
version of X when trying to figure out why it was happening, and CVS X
has it fixed.  Until I commit a fix, you can add -fno-merge-constants to
your CFLAGS.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: font failure in X

[Eric Anholt]

On Tue, 2003-01-07 at 13:25, Alexander Leidinger wrote:
> On Tue, 7 Jan 2003 02:46:49 +0100 (MET)
> Roine Thunberg <[EMAIL PROTECTED]> wrote:
> 
> > I recently installed 5.0-RC2 and X from ports and some programs too.
> > 
> > Now I have trouble with huge font sizes. Mainly in webbrowsers. But it's
> > only some kind of fonts. I just can't find the options and I can't see any
> > logs telling me what's wrong. Seems like the fonts use the size 100
> > instead of 10 or 12 that they normally do... suggestions ?
> 
> Sometimes I get this too. I restart X or have to reboot then and
> everything goes back to normal operation.
> 
> Bye,
> Alexander.

One thing good might be to check your DisplaySize (grep Display
/var/log/XFree86.0.log), since your DPI is calculated from that and
things are using the DPI to calculate font sizes more and more.  For
some reason it's probed wrong on my system (2500mm x 2500mm or some
such).  Adding the following line to my XF86Config's Monitor section
fixed it.
DisplaySize 310 270

If this is the problem, could you tell me what card you're using?

-- 

Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/dri/ [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: 5.0-RC2 informal PR: X hangups using radeon driver

[Eric Anholt]

On Wed, 2003-01-01 at 12:14, Gary W. Swearingen wrote:
> I downloaded a 5.0-RC2 ISO, checked the MD5 against a different mirror's
> MD5, burned a CD, diff'ed the CD against the ISO, and installed the OS.
> My first try using the full-GUI X installer failed gracefully (I forget
> the details).  The other two X installers didn't offer to support my
> video card, so I tried the full-GUI one again.  It offered something
> called "ati".  I'm not sure why it said "ati" rather than what my old
> XF86Config used "radeon", but it seemed close enough.  IIRC, it wasn't

The 'ati' driver detects what type of ATI card you have and loads the
appropriate driver (radeon, r128, atimisc).

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/dri/ [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: DRM_LINUX, potential draw backs?

[Eric Anholt]

On Mon, 2002-11-11 at 20:39, Lucky Green wrote:
> Are there any potential draw backs to enabling DRM_LINUX? Or should
> DRM_LINUX be enabled whenever one enables COMPAT_LINUX?
> 
> This has not been clear to me from reading NOTES.

It is an option that applies to the drm to allow linux binaries to use
the DRI.

-- 
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: XFree

[Eric Anholt]

On Thu, 2002-11-07 at 16:56, Horen wrote:
> 
> 
> 
> On 7 Nov 2002, Eric Anholt wrote:
> 
> > On Thu, 2002-11-07 at 04:40, Horen wrote:
> > >
> > >
> > > On 6 Nov 2002, Eric Anholt wrote:
> > >
> > > > On Wed, 2002-11-06 at 18:34, Horen wrote:
> > > > >
> > > > > Posted a week ago the question, didn't get any reaction.
> > > > >
> > > > > Everything with current from last night works fine but killing
> > > > > X or logging out ends in a black screen. No way to activate the
> > > > > display without reboot. Remote login is fine. Typing blind works
> > > > > too.
> > > >
> > > > How long has this been going on?  Did it start at any particular point
> > > > (a specific kernel or XFree86 upgrade)?  What video card do you use?
> > > > Does starting X again not work?
> > > >
> > >
> > > It started sometimes in Oct, switched back to 4.7 stable. Did yesterday
> > > an installation from scratch and built XFree86-Server after buildworld.
> >
> > I was asking if X has ever exited cleanly to console for you after
> > logging out, and if it has, what you changed (particularly in your
> > XFree86-Server version) between when it was working and when it wasn't.
> > This is most likely just a failure of the driver to properly reset
> > things for your card.  Does disabling DRI in XF86Config help it exit
> > cleanly?
> >
> 
> X has exited cleanly only on 4.6 or 4.7 , never on 5.0 in the
> last 4-5 weeks. Didn't change anything. I disabled DRI but, didn't
> help. Work normally with res 1600x1200 , tried 1024x768 to 1920x1440.
> Nothing changed.

Exact same version of the X Server (pkg_info | grep XFree86-Server)?

-- 
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: XFree

[Eric Anholt]

On Thu, 2002-11-07 at 04:40, Horen wrote:
> 
> 
> On 6 Nov 2002, Eric Anholt wrote:
> 
> > On Wed, 2002-11-06 at 18:34, Horen wrote:
> > >
> > > Posted a week ago the question, didn't get any reaction.
> > >
> > > Everything with current from last night works fine but killing
> > > X or logging out ends in a black screen. No way to activate the
> > > display without reboot. Remote login is fine. Typing blind works
> > > too.
> >
> > How long has this been going on?  Did it start at any particular point
> > (a specific kernel or XFree86 upgrade)?  What video card do you use?
> > Does starting X again not work?
> >
> 
> It started sometimes in Oct, switched back to 4.7 stable. Did yesterday
> an installation from scratch and built XFree86-Server after buildworld.

I was asking if X has ever exited cleanly to console for you after
logging out, and if it has, what you changed (particularly in your
XFree86-Server version) between when it was working and when it wasn't. 
This is most likely just a failure of the driver to properly reset
things for your card.  Does disabling DRI in XF86Config help it exit
cleanly?

-- 
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: XFree

[Eric Anholt]

On Wed, 2002-11-06 at 18:34, Horen wrote:
> 
> Posted a week ago the question, didn't get any reaction.
> 
> Everything with current from last night works fine but killing
> X or logging out ends in a black screen. No way to activate the
> display without reboot. Remote login is fine. Typing blind works
> too.

How long has this been going on?  Did it start at any particular point
(a specific kernel or XFree86 upgrade)?  What video card do you use? 
Does starting X again not work?

-- 
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

Panic in swapon on 10/24

[Eric Anholt]

) {
2162v_incr_usecount(vp, -1);
2163/*
2164 * We must call VOP_INACTIVE with the node locked.
2165 * If we are doing a vput, the node is already locked,
2166 * but, in the case of vrele, we must explicitly lock

-- 
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: sorry state of Xserver in 5.0

[Eric Anholt]

On Mon, 2002-10-07 at 11:13, Andrew Gallatin wrote:
> 
> Every so often, my X server locks up.  It seems to be in a tight
> loop, 95% user time, and making only these ktrace'able calls:
> 
>  27069 XFree86  0.019988 PSIG  SIGALRM caught handler=0x80d219c mask=0x0 code=0x0
>  27069 XFree86  0.39 CALL  sigreturn(0xbd9e7b0c)
>  27069 XFree86  0.04 RET   sigreturn JUSTRETURN
>  27069 XFree86  0.019951 PSIG  SIGALRM caught handler=0x80d219c mask=0x0 code=0x0
>  27069 XFree86  0.15 CALL  sigreturn(0xbd9e6e0c)
>  27069 XFree86  0.04 RET   sigreturn JUSTRETURN
>  27069 XFree86  0.019980 PSIG  SIGALRM caught handler=0x80d219c mask=0x0 code=0x0
> 
> Anybody have a workaround for this?
> 
> The whole system (2.53 Ghz P4) was compiled from sources late last
> week...
> 
> Between this, and the Type1 bezier font abort, the state of 5.0 on a
> desktop is very sorry indeed.  My old alpha running -stable is far
> more stable.

Basically what this ktrace output means, from my reading, is that the
server is stuck processing some client request and never gets back to it
main scheduling loop / goes idle and turns off the alarm.  Finding where
the server is sitting would be valuable.

If you have a hardware cursor and smooth mouse on (it's default) you'll
still be able to move the mouse because the mouse response is done in a
signal handler, so a busy server doesn't make your mouse stop working.

Still wishing I could get a working gdb on an X.

-- 
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: X problems & 5.0... -RELEASE?

[Eric Anholt]

On Sun, 2002-10-13 at 23:00, Eric Anholt wrote:
> On Sun, 2002-10-13 at 21:14, Kris Kennaway wrote:
> > On Sun, Oct 13, 2002 at 11:28:51PM -0400, Wesley Morgan wrote:
> > 
> > > I know there is some work being done on the recent signal changes to fix
> > > some things, but are we sure this is the problem? I would hate to see
> > > release schedules pushed back because these problems are lost in the
> > > noise, and I can't see a release being made that has a known unstable X.
> > 
> > I thought this was believed to be a bug in X that was exposed by
> > kernel changes.
> > 
> > Kris

> Could anyone who is having stability issues with X please email me
> privately if they are using either -current before September or 
> -stable?  If not, without some sort of hints of where an issue really
> is, I'm going to chalk this up to kernel bugs.

Just to let people know what's going on with this on my end: I've got my
laptop up to a fresh kernel, world, and X as of 10/17 or so.  I've got a
reproducible X server crash with XFree86 + glxgears alone  (DRI
disabled).  I'm working on getting backtraces to see if anything useful
can be produced.  However, gdb521 is crashing if I start XFree86 from it
(gdbing that gdb produced only silliness -- gbs exiting semicleanly or
senseless backtraces).  gdb521 can attach to a running XFree86 fine
apparently, but then it doesn't get the module info.

On my -stable box, gdb521 appears to start XFree86 fine, but on stable
(and current iirc) ^Cing in gdb results in nothing happening and needing
to kill the gdb or the XFree86 because they go unresponsive.

If I can get gdb52 to be useful, I'll add a patch to XFree86-4-Server
(and dri-devel maybe?) to compile debuggable X Server/modules and
install them properly.

>From the reports:

Both stable and current users get the "self-healing" hang, where the X
server responds to nothing but the mouse moves, and at some minutes
later time it continues and responds to those actions.  One person said
they'd had this since at least current in July.

Folks with kernels later than a couple weeks ago get X crashes all the
time.  Updated world wasn't necessary to get it (in my case), updated
world+kernel didn't help (others), and updated world+kernel+X didn't
help (my case, too).  

Note that just about any X crash will result in a signal six reported by
the kernel, because one X crash causes another while it tries to recover
(reset to the console, etc), and on the second crash that gets caught it
aborts.  To see what started the mess, look at the console output from
startx if you used startx.  You're looking for the first "Fatal error"
-- later stuff is trying to recover from that crash that got caught.  If
you use xdm, it's in your /var/log/xdm-errors iirc.

If you blame this on type1/bezier, make sure you actually have an error
message about bezier or something else in your log before the abort. 
All of the type1 module's aborts have a reason printed before the abort.

-- 
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: X problems & 5.0... -RELEASE?

[Eric Anholt]

On Sun, 2002-10-13 at 21:14, Kris Kennaway wrote:
> On Sun, Oct 13, 2002 at 11:28:51PM -0400, Wesley Morgan wrote:
> 
> > I know there is some work being done on the recent signal changes to fix
> > some things, but are we sure this is the problem? I would hate to see
> > release schedules pushed back because these problems are lost in the
> > noise, and I can't see a release being made that has a known unstable X.
> 
> I thought this was believed to be a bug in X that was exposed by
> kernel changes.
> 
> Kris

I've heard some people saying that it's the bezier bug.  When I had
moved to late September/early October kernels, I saw sig11s and the
hangs (some temporary, some resulting in reset switch before they could
be temporary), but never that message people have mentioned about the
Beziers.  I couldn't see *any* pattern to my crashes.  It often happened
while I was reading email, but then I spend a decent amount of time
reading mail.

The [EMAIL PROTECTED] archived message mentioned previously about Type 1
issues listed two bugs.  One was an abort on an error, which we aren't
experiencing as far as I've heard.  The other was not failing requests
for very large fonts, which shouldn't be happening too often and
shouldn't have anything to do with the kernel version.

Could anyone who is having stability issues with X please email me
privately if they are using either -current before September or 
-stable?  If not, without some sort of hints of where an issue really
is, I'm going to chalk this up to kernel bugs.

-- 
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: XFree86 crash, Bezier thing (was Re: Is phk rewriting thekernel over the weekend?)

[Eric Anholt]

On Sun, 2002-09-29 at 10:25, Wesley Morgan wrote:
> Does this bug effect -stable? It only showed up in -current recently.
> Isn't it a bigger chance that something on the FreeBSD side made this bug
> much more visible?
> 
> On Sun, 29 Sep 2002, Maxim Sobolev wrote:
> 
> > I think it should be fixed in FreeBSD ports before 4.7, because it
> > is really annoying when server crashes without any particular
> > reason.
> >
> > Eric, what do you think about it?
> >
> > -Maxim

>From what I had heard on the lists it was only a thing that happened
when people upgraded kernels, and that it had stopped after some date of
kernel.  I hadn't experienced it, so I ignored it.  I don't know about
that link posted, I thought that was a mozilla bug that was supposed to
be fixed.

-- 
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: groff and X11 broken (before gcc3.2)

[Eric Anholt]

On Mon, 2002-09-02 at 05:35, Christian Weisgerber wrote:
> I just finished updating my alpha box to shortly before the gcc3.2
> import and now I'm seeing some weird breakage:

> $ startx
> [...]
> xinit:  No such file or directory (errno 2):  unable to connect to X server
> xinit:  No such process (errno 3):  Server error.
> 
> (Hmm, actually that may be due to the XFree86-Server-4.2.0_5 to _6
> update.  I think I haven't restarted the X11 server since.)

You need to either reinstall Xwrapper port, or setuid root your XFree86
and accept the possible security holes.

I wish we could accept having some sort of suid Xwrapper installed with
XFree86-4-Server, but that would probably be shot down for security
concerns by those who don't use startx.

-- 
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: Still no XFree86-4

[Eric Anholt]

On Sat, 2002-07-20 at 03:14, John Angelmo wrote:
> Well here's my latest XFree86-4 build errors, I made a clean build 
> uninstalled XFree-4, perl and so on but still I get these errors
> 
[...]

> ===>  Extracting for XFree86-4.2.0_1,1
> >> No MD5 checksum file.
> ===>   XFree86-4.2.0_1,1 depends on shared library: Xft.1 - found
> ===>  Patching for XFree86-4.2.0_1,1
> ===>  Configuring for XFree86-4.2.0_1,1
> ===>  Installing for XFree86-4.2.0_1,1
> ===>   XFree86-4.2.0_1,1 depends on executable: xvinfo - found
> ===>   XFree86-4.2.0_1,1 depends on file: /usr/X11R6/lib/X11/doc/ddx.TXT - found

You don't have XFree86-4 uninstalled, or don't have it uninstalled
successfully.  Just removing the XFree86-4 metaport doesn't remove the
miniports that contain the actual files.  If you are going to build
without using portupgrade, you should start from scratch wrt XFree86
(all XFree86-4 ports uninstalled along with imake-4).

> ===>   XFree86-4.2.0_1,1 depends on file: 
>/usr/X11R6/lib/X11/fonts/100dpi/UTBI__10-ISO8859-1.pcf.gz - not found
> ===>Verifying reinstall for 
>/usr/X11R6/lib/X11/fonts/100dpi/UTBI__10-ISO8859-1.pcf.gz in 
>/usr/ports/x11-fonts/XFree86-4-font100dpi
> ===>  Extracting for XFree86-font100dpi-4.2.0
> >> Checksum OK for xc/X420src-2.tgz.
> ===>   XFree86-font100dpi-4.2.0 depends on executable: mkfontdir - found
> ===>   XFree86-font100dpi-4.2.0 depends on executable: imake - found
> ===>   XFree86-font100dpi-4.2.0 depends on shared library: X11.6 - found
> ===>  Patching for XFree86-font100dpi-4.2.0
> ===>  Configuring for XFree86-font100dpi-4.2.0
> (cd /usr/ports/x11-fonts/XFree86-4-font100dpi/work/xc/fonts/encodings &&  imake 
>-DUseInstalled -DProjectRoot=/usr/X11R6 -I/usr/X11R6/lib/X11/config  
>-DTOPDIR=../../.. -DCURDIR=.;  make Makefiles ;  make includes ;  make depend)
> making Makefiles in large...
> including in ./large...
> depending in ./large...
> (cd /usr/ports/x11-fonts/XFree86-4-font100dpi/work/xc/fonts/bdf/100dpi &&  imake 
>-DUseInstalled -DProjectRoot=/usr/X11R6 -I/usr/X11R6/lib/X11/config  
>-DTOPDIR=../../.. -DCURDIR=.;  make Makefiles ;  make includes ;  make depend)
> make: don't know how to make /usr/X11R6/bin/ucs2any.pl. Stop

I'm aware of this one.  Currently the solution is "use portupgrade -RiN
XFree86-4".  I hope to get these dependencies fixed so it's not
necessary to do this, but I haven't made it around to that yet.

Also, for anyone reading this, one thing that'll help figure out build
errors (particularly relating to dependencies like this) will be to
include an ls -l /var/db/pkg/XFree86* /var/db/pkg/imake* with bug
reports

-- 
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: Problem with agpgart on current, XFree86-4, Matrox G400 video

[Eric Anholt]

On Wed, 2002-07-17 at 20:59, Peter Wemm wrote:
> Eric Anholt wrote:
> 
> > This looks like the classic error of the agp module having been loaded
> > by the drm because it's required, but agp doesn't probe/attach because
> > a generic bridge driver has already claimed the agp device.
> 
> I doubt that would be a problem as long as it came with a patch to the
> release scripts so that the agp device was filtered out of the BOOTMFS
> kernel image.  (A quick grep -r for BOOTMFS should show up the sed scripts
> that turn GENERIC into BOOTMFS in src/release).
> 
> The 'agp' device isn't likely to hurt anything, is it?

There's one thing in i810 I might want to check again before making it
default, but other than that I think agp is pretty stable these days.  I
haven't heard of problems with specific AGP chipsets since the AMD fixes
(MTRR + agp_amd.c) we had.

The one interesting interaction I've heard of recently is that when a
person had device agp in the kernel and agp_enable="YES" in loader.conf
the agp device malfunctioned (probed fine according to dmesg, but the
DRM couldn't find it with agp_find_device()).  I could see this biting
people if we didn't have an entry in UPDATING, because a lot of people
have gone the loader.conf way.

-- 
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: Problem with agpgart on current, XFree86-4, Matrox G400 video

[Eric Anholt]

On Wed, 2002-07-17 at 18:40, Garance A Drosihn wrote:

> I have a Matrox G400 Dual Head 32mb AGP card running on a dual
> Pentium III system, and I have been using XFree86-4 on my system for
> testing -current.  This worked fine for months, and I still have a
> snapshot of -current from about April 23 where it works fine.
> Sometime after that (probably mid-May), I did a buildworld and I
> started to consistently get the following errors when XDM starts:
> 
> Timecounter "PIIX"  frequency 3579545 Hz
> Timecounter "PIIX"  frequency 3579545 Hz
> Timecounter "PIIX"  frequency 3579545 Hz
> Timecounter "PIIX"  frequency 3579545 Hz
> Timecounter "PIIX"  frequency 3579545 Hz
> Timecounter "PIIX"  frequency 3579545 Hz
> Timecounter "PIIX"  frequency 3579545 Hz
> drm0:  mem 
> 0xe080-0xe0ff,0xe100-0xe1003fff,0
> xe200-0xe3ff irq 10 at device 0.0 on pci1
> error: [drm:mga_init] *ERROR* Cannot initialize the agpgart module.
> device_probe_and_attach: drm0 attach returned 12

This looks like the classic error of the agp module having been loaded by the drm 
because it's required, but agp doesn't probe/attach because a generic bridge driver 
has already claimed the agp device.

What would it take to get AGP into GENERIC?  It's useless as a module
the way most people expect it to use it, and not having it makes a
reboot required to configure X for i8x0, along with configuring the DRI.

> XDM generally did still seem to come up okay, although occasionally
> the system would panic right at that initial XDM startup.  While I
> tried a few things to fix this (including various buildworlds over
> time), I didn't really worry about it too much because I could always
> fall back to my April 23rd snapshot of -current.

April 27th was when the DRM went into -current.  Did you ever get a
dump/backtrace of the panic?  Did you have drm-kmod installed?

> I added that line, rebooted, and now XFree86-4 has no problem
> initializing agpgart when XDM starts up.  I do not know why I
> started to need that line in /boot/loader.conf, when I had never
> actually needed it before (and I've never had 'device agp' in my
> kernel).  But, I'm happy enough to have finally tracked down what
> the issue was.
Can you still make it panic after adding agp?

-- 
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: Still no XFree86-4?

[Eric Anholt]

On Tue, 2002-07-16 at 19:38, Garance A Drosihn wrote:
> At 7:27 PM -0600 7/16/02, Eric Anholt wrote:
> >It notably doesn't include md5summing of Wraphelp.c.  If I can
> >find what's the 'best' Wraphelp.c (and most legal?  What's the
> >status of wraphelp importing/exporting?), I'll switch it.  Is
> >there any circumstance when someone wouldn't have access to
> >Wraphelp.c?
> 
> I thought the whole point of Wraphelp.c was that the person who
> runs the machine (whatever machine X is being installed on) has
> to obtain that file, so they would have to explicitly verify that
> they -- personally -- have the right to use it.
> 
> Mind you, I did that once about seven years ago, and I just keep
> copying that Wraphelp.c around to wherever I need it.  I have no
> idea what the current requirement is...   :-)

It used to be that way.  Then within the last year (iirc) our ports
changed to auto-downloading Wraphelp.c and defaulting to HasXdmAuth
YES.  I don't know what exactly changed legally.  I noted that at least
NetBSD has a Wraphelp.c in their CVS repos of X-3 and X-4.

My changes do make the file required by all of the miniports that could
use it, though it only gets used if HasXdmAuth is set to YES by imake-4
(it's default).

-- 
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: Still no XFree86-4?

[Eric Anholt]

On Tue, 2002-07-16 at 17:25, Eric Anholt wrote:
> As far as the Wraphelp.c issues, I'm working on cleaning that mess up
> right now (testing the patch on a full XFree86-4 build on clean
> -current).

I've put the patch up at
http://people.freebsd.org/~anholt/files/x420diff2-1
It does the following:
- Make me maintainer of imake-4 port.  It's very much a part of the X-4
build, and was supposed to be in the take-over-maintainership commit.
- Make the X-4 miniports use imake-4's HasXdmAuth setting (the
use-Wraphelp.c option) and copy Wraphelp.c (unconditionally).
- Adds USE_PERL5 to imake-4 because perl's required for the install of
it.  This will also cover perl dependencies for the rest of the X-4.
- Rewords some of the comments in XFree86-4-*/scripts/configure.

It notably doesn't include md5summing of Wraphelp.c.  If I can find
what's the 'best' Wraphelp.c (and most legal?  What's the status of
wraphelp importing/exporting?), I'll switch it.  Is there any
circumstance when someone wouldn't have access to Wraphelp.c?

If this works for other people, I'll work on getting it committed.

-- 
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: Still no XFree86-4?

[Eric Anholt]

On Tue, 2002-07-16 at 04:04, John Angelmo wrote:
> Hello
> 
> I erased my /usr/ports just to be sure that all the diffrent patches 
> out, then cvsuped to get the latest version, to my disepointment 
> XFree86-4 Still dosn't build under Current, I still got the same perl 
> error in fonts, the perl port is installed.
> 
> Does anyone have a working patch?

http://people.freebsd.org/~anholt/files/imake4diff

Could you apply this patch and rebuild imake-4 and see if it picks up
the perl dependency?   If it doesn't pick it up, does adding:
http://people.freebsd.org/~anholt/files/bsdportmk.diff
make perl get picked up?

If you've already installed perl, ignore this.

As far as the Wraphelp.c issues, I'm working on cleaning that mess up
right now (testing the patch on a full XFree86-4 build on clean
-current).

> 
> /John
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
-- 
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: Update to the DRM

[Eric Anholt]

On Sat, 2002-07-13 at 11:23, Michael Nottebrock wrote:
> Eric Anholt wrote:

> I have just compiled a world with the 20020711.diff. It sure runs fast, 
> but the quality isn't very good. I tested with glxgears and gltron and 
> in both there is a lot of flashing and lighting errors.
> 
> Do you have any recommendations what other tests I could run?
> 
> Hardware:
> 
> drm0@pci1:0:0:  class=0x03 card=0x008a1002 chip=0x51441002 rev=0x00 
> hdr=0x00
>  vendor   = 'ATI Technologies'
>  device   = 'Radeon 7200 / Radeon'
>  class= display
>  subclass = VGA

Okay, I'm seeing that with 4.2.0+Radeon on the new DRM.  I'll build a
4.2.0 for linux and see if that shows it too, to figure out if it's a
BSD-specific issue.

-- 
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: Update to the DRM

[Eric Anholt]

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: Update to the DRM

[Eric Anholt]

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: don't know how to make /usr/X11R6/bin/ucs2any.pl. on v.recen t-CURRENT when trying to build ports/x11/XFree86-4

[Eric Anholt]

On Wed, 2002-07-10 at 11:34, Shizuka Kudo wrote:
> --- "Thyer, Matthew" <[EMAIL PROTECTED]> wrote:
> > make: don't know how to make /usr/X11R6/bin/ucs2any.pl. Stop
> > *** Error code 2
> > 
> > --
> 
> Try:
> 
>   build ports/lang/perl and set env PERL to /usr/local/bin/perl

The X ports are failing for a lot of people on -current because of a
lack of perl.  Most of the ports use perl in building as part of their
imake use.  I've added USE_PERL5 to imake-4's makefile locally, but it
seems to incorrectly detect the /usr/bin/perl wrapper as a functioning
perl installation.  Shouldn't USE_PERL5 depend on ${LOCALBASE}/bin/perl
on -current rather than just the existence of a binary called "perl" in
the path?

Before the patch:
%ls /usr/local/bin/
%/usr/bin/perl -pi -e "s|asd|sdf|g" test
perl: Perl is not installed, try 'pkg_add -r perl'
%make
===>  Extracting for XFree86-4.2.0_1,1
>> No MD5 checksum file.
===>   XFree86-4.2.0_1,1 depends on shared library: Xft.1 - not found
===>Verifying install for Xft.1 in
/usr/ports/x11/XFree86-4-libraries
===>  Extracting for XFree86-libraries-4.2.0_2
>> Checksum OK for xc/X420src-1.tgz.
>> Checksum OK for xc/4.2.0-xlib-i18n-module.patch.
>> Checksum OK for xc/4.2.0-libGLU-bad-extern.patch.
===>   XFree86-libraries-4.2.0_2 depends on executable: imake - not
found
===>Verifying install for imake in /usr/ports/devel/imake-4
===>  Extracting for imake-4.2.0_1
>> Checksum OK for xc/X420src-1.tgz.
===>   imake-4.2.0_1 depends on executable: perl5.6.1 - found

-- 
Eric Anholt <[EMAIL PROTECTED]>
http://people.freebsd.org/~anholt/dri/



Index: Mk/bsd.port.mk
===
RCS file: /home/ncvs/ports/Mk/bsd.port.mk,v
retrieving revision 1.418
diff -u -r1.418 bsd.port.mk
--- Mk/bsd.port.mk	5 Jul 2002 09:14:53 -	1.418
+++ Mk/bsd.port.mk	11 Jul 2002 21:40:30 -
@@ -1026,8 +1026,13 @@
 PERL5=			${LOCALBASE}/bin/perl${PERL_VERSION}
 PERL=			${LOCALBASE}/bin/perl
 .if defined(USE_PERL5)
+.if ${OSVERSION} >= 500036
+BUILD_DEPENDS+=	${LOCALBASE}/bin/perl${PERL_VERSION}:${PORTSDIR}/lang/perl5
+RUN_DEPENDS+=	${LOCALBASE}/bin/perl${PERL_VERSION}:${PORTSDIR}/lang/perl5
+.else
 BUILD_DEPENDS+=	perl${PERL_VERSION}:${PORTSDIR}/lang/perl5
 RUN_DEPENDS+=	perl${PERL_VERSION}:${PORTSDIR}/lang/perl5
+.endif
 .endif
 .endif
 

Re: don't know how to make /usr/X11R6/bin/ucs2any.pl. on v.r ecen t-CURRENT when trying to build ports/x11/XFree86-4

[Eric Anholt]

On Thu, 2002-07-11 at 13:49, Eric Anholt wrote:
> http://people.freebsd.org/files/x420diff-1), I would be happy to
Augh, why can't I type?
http://people.freebsd.org/~anholt/files/x420diff-1
-- 
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: don't know how to make /usr/X11R6/bin/ucs2any.pl. on v.r ecen t-CURRENT when trying to build ports/x11/XFree86-4

[Eric Anholt]

On Thu, 2002-07-11 at 13:02, David O'Brien wrote:
> On Thu, Jul 11, 2002 at 04:28:06PM +0200, Jeremy Lea wrote:
> > http://people.freebsd.org/~reg/x11.patch
> 
> Would someone PLEASE commit these!?!?!?!?!?!!
> Before I get totally sick and tired of the main in my inbox and do it
> myself.
> 
> I _truely_ fail to see what is so hard about fixing X to compile with
> -CURRENT at this point.

I'm currently asking my mentor (DES) about committing a subset of these
patches that has it compiling on -current for me, and am looking for
feedback on it.  Some of the patches from Jeremy Lea don't appear to be
necessary any more.  If I get my set in (available at
http://people.freebsd.org/files/x420diff-1), I would be happy to
continue working on further patches necessary (and getting them
committed) to get the compiling of X working the best we can.  (in
particular, I think the perl dependency is missing in some of them, but
I'm not sure if it's a compile-time only dependency as iirc other
X-related ports require it as a run_depends, too)

-- 
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: Update to the DRM

[Eric Anholt]

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

-- 
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: Update to the DRM

[Eric Anholt]

On Wed, 2002-07-10 at 17:17, Eric Anholt wrote:
> I've posted a diff to the DRM at
> http://people.freebsd.org/~anholt/dri/files/currentdrm-20020709.ta 

Evolution's "send" button is way too big.

http://people.freebsd.org/~anholt/dri/files/currentdrm-20020709.diff
is the file.  The patch brings the current DRM from DRI CVS into the
system.  It includes PCI Rage 128 support and support for "transform,
clipping, & lighting" (TCL) hardware on Radeons.  Another user and I
have been banging on it with DRI CVS X Servers on Radeon, and I've
tested it with several other cards with DRI CVS.  What is probably least
tested is using 4.2.0 X Servers with the new DRM, I'll work on that
soon.

I'm looking for testers of this code in -current.  Hopefully this will
support 4.2.0 as well as the old code did, in which case I would like to
commit this soon.

-- 
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

Update to the DRM

[Eric Anholt]

I've posted a diff to the DRM at
http://people.freebsd.org/~anholt/dri/files/currentdrm-20020709.ta 

-- 
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: crash when starting X

[Eric Anholt]

On Sun, 2002-05-26 at 03:46, 山田　健 wrote:
> I have the same symptom with binary package of XFree86-4.  And furthermore I
> cannot compile XFree86-4-libraries with FreeBSD-current.
> It says;
> UIThrStubs.c:102: alias arg not a string
> UIThrStubs.c:103: alias arg not a string
> :  :  :
> UIThrStubs.c:115: alias arg not a string
> UIThrStubs.c:131: warning: `_Xthr_self_stub_' defined but not used
> UIThrStubs.c:139: warning: `_Xthr_zero_stub_' defined but not used
> 
> Any fix ?

I just made this patch today while working on X stuff.  Unfortunately
after that it dies with a compiler error in the DRI compile for me. DRI
CVS doesn't have the compiler error.

making all in lib/GL/mesa/src...

In file included from translate.c:779:
../../../../extras/Mesa/src/trans_tmp.h: In function
`trans_1_GLdouble_1ub_elt':
../../../../extras/Mesa/src/trans_tmp.h:124: could not find a spill
register
(insn 96 94 97 (set (subreg:SF (reg:QI 75) 0)
(plus:SF (reg:SF 8 st(0) [76])
(reg:SF 9 st(1) [80]))) 525 {*fop_sf_comm_nosse} (insn_list
87 (nil))
(expr_list:REG_DEAD (reg:SF 8 st(0) [76])
(nil)))
../../../../extras/Mesa/src/trans_tmp.h:124: Internal compiler error in
failed_reload, at reload1.c:5050
Please submit a full bug report,
with preprocessed source if appropriate.
See http://www.gnu.org/software/gcc/bugs.html> for instructions.

If someone is interested I can give them more full logs.

-- 
Eric Anholt <[EMAIL PROTECTED]>
http://gladstone.uoregon.edu/~eanholt/dri/



--- lib/XThrStub/UIThrStubs.c.orig  Sat May 25 16:01:07 2002
+++ lib/XThrStub/UIThrStubs.c   Sat May 25 16:28:25 2002
@@ -99,6 +99,26 @@
 #else
 #include 
 typedef pthread_t xthread_t;
+#if __GNUC__ >= 3
+static xthread_t _Xthr_self_stub_();
+static int _Xthr_zero_stub_();
+
+xthread_t pthread_self() __attribute__ ((weak, alias ("_Xthr_self_stub_")));
+int pthread_mutex_init() __attribute__ ((weak, alias ("_Xthr_zero_stub_")));
+int pthread_mutex_destroy() __attribute__ ((weak, alias ("_Xthr_zero_stub_")));
+int pthread_mutex_lock() __attribute__ ((weak, alias ("_Xthr_zero_stub_")));
+int pthread_mutex_unlock() __attribute__ ((weak, alias ("_Xthr_zero_stub_")));
+int pthread_cond_init() __attribute__ ((weak, alias ("_Xthr_zero_stub_")));
+int pthread_cond_destroy() __attribute__ ((weak, alias ("_Xthr_zero_stub_")));
+int pthread_cond_wait() __attribute__ ((weak, alias ("_Xthr_zero_stub_")));
+int pthread_cond_signal() __attribute__ ((weak, alias ("_Xthr_zero_stub_")));
+int pthread_cond_broadcast() __attribute__ ((weak, alias ("_Xthr_zero_stub_")));
+/* These are added for libGL */
+int pthread_key_create() __attribute__ ((weak, alias ("_Xthr_zero_stub_")));
+void * pthread_getspecific() __attribute__ ((weak, alias ("_Xthr_zero_stub_")));
+int pthread_setspecific() __attribute__ ((weak, alias ("_Xthr_zero_stub_")));
+/*int pthread_equal __attribute__ ((__weak__)) = _Xthr_equal_stub_;*/  /* See 
+Xthreads.h! */
+#else
 #pragma weak pthread_self = _Xthr_self_stub_
 #pragma weak pthread_mutex_init = _Xthr_zero_stub_
 #pragma weak pthread_mutex_destroy = _Xthr_zero_stub_
@@ -113,6 +133,7 @@
 #pragma weak pthread_key_create = _Xthr_zero_stub_
 #pragma weak pthread_getspecific = _Xthr_zero_stub_
 #pragma weak pthread_setspecific = _Xthr_zero_stub_
+#endif /* __GNUC__ */
 #if defined(_DECTHREADS_) || defined(linux)
 #pragma weak pthread_equal = _Xthr_equal_stub_ /* See Xthreads.h! */
 int

Re: DRM in the sys/ tree: looking for testers

[Eric Anholt]

On Fri, 2002-04-26 at 01:03, moto kawasaki wrote:
> 
> Thank you very much,  Mr. Eric Anholt,
> 
> I have been testing your code on my PC, and found that kernel cannot
> initialize agpgart device so far.

The i8x0 DRM drivers require AGP to be working.  I took a look at your
i830 patch today, and compared it to the linux kernel version.  I added
some more checks for invalid options (binding memory into offsets used
by the stolen memory), and added the enabling of the gatt that linux
does.  The only difference that I see between our drivers after this
diff is that linux forces enabling of the integrated graphics.

The diff is at http://gladstone.uoregon.edu/~eanholt/dri/i810diff

If we aren't sure how well the driver is working, testgart might help
for debugging without using X.  A copy of linux testgart from utah-glx
is at http://gladstone.uoregon.edu/~eanholt/dri/testgart.c



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

DRM in the sys/ tree: looking for testers

[Eric Anholt]

The DRM kernel modules (kernel support for 3d hardware acceleration
through the DRI) may be integrated into our sys tree soon.  I may be
getting a commit bit soon to work on this.  I think getting the modules
in the sys tree will help keep the DRI supported on FreeBSD even if I
become less active, and will help users by keeping the modules up to
date with their kernels.  It may also act as an incentive to keep me
working on the DRI when my patches may go in sooner.

So, I have been working over the last few days on integrating the
modules from drm-kmod-0.9.5 into the sys tree again, and have it almost
done.  The files are up at the website
. This also includes my
current set of code for mesa4 (XFree86 CVS, DRI CVS) and TCL (DRI CVS
tcl-0-0-1-branch) compatible DRM modules if anyone is interested in
experimenting, though they are much less tested.  For now instructions
on using it are on the news page of that website.

Could people test this in-kernel DRM and tell me how it works for them?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

ppp troubles

[Eric Anholt]

I've been seeing these errors for about a month now.  When PPP is 
first started, it outputs:
calwell:/usr/src/bzflag>ppp -ddial -nat papchap
Working in ddial mode
Using interface: tun0
Warning: Add route failed: 0.0.0.0: errno: Network is unreachable

It still dials and connects, then gets an IP, but I never get the 
default route.  I have to manually ifconfig to find the ip and route 
add default it.
Before:
calwell:/usr/src/bzflag> netstat -rn | head
Routing tables

Internet:
DestinationGatewayFlags  Netif Expire
127.0.0.1  127.0.0.1  UH  469726  lo0
192.168/16 link#1 UC  00  rl0 =>
192.168.0.10:c0:ca:12:7d:30   UHLW08  lo0
192.168.0.11   0:5:2:b6:ad:21 UHLW1   106946  rl0251
192.168.0.12   0:80:ad:b0:3b:ef   UHLW2  342  rl0   1162
192.168.255.255ff:ff:ff:ff:ff:ff  UHLWb   3  155  rl0

After:
calwell:/usr/src/bzflag> netstat -rn | head
Routing tables

Internet:
DestinationGatewayFlags  Netif Expire
default216.26.1.5 UGSc3   24 tun0
127.0.0.1  127.0.0.1  UH  469750  lo0
192.168/16 link#1 UC  00  rl0 =>
192.168.0.10:c0:ca:12:7d:30   UHLW08  lo0
192.168.0.11   0:5:2:b6:ad:21 UHLW1   106973  rl0208
192.168.0.12   0:80:ad:b0:3b:ef   UHLW2  342  rl0   1119

calwell:/usr/src/bzflag> ifconfig tun0
tun0: flags=8051 mtu 1524
inet6 fe80::2c0:caff:fe12:7d30%tun0 --> :: prefixlen 64 scopeid 0xa
inet 216.26.2.219 --> 216.26.1.5 netmask 0xff00
Opened by PID 21106

Excerpts from ppp.conf
default:
  set device /dev/cuaa0

  set log Phase Chat LCP IPCP tun command connect
#CCP
  set speed 115200
  set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \
\"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT"
  set timeout 120   # 3 mintue idle timer (the default)
  set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0
  add default HISADDR   # Add a (sticky) default route

(then the regular papchap stuff)

Can anyone help me?  This is really annying, especially since I have 
a very nasty connection that keeps dropping and making me route 
delete, ifconfig -a ( & repeat), route add again.
If there is any other info needed, I would be glad to post.
-- 

--
Eric Anholt
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: syscons hangs with -current

[Eric Anholt]

I'm afraid I don't quite understand how that desribes the fix to my 
problem (Freezing on boot after having probed a non-existant vga1 and 
sc1).  What I did do, I went into sys/dev/fb/vga.c and commented out 
the second vga head detection.  Works beautifully now, though it 
would be better to actually figure out why it was finding another vga 
card.  Still, it's up and running.

Now, if I could just figure out why ppp doesn't work (keeps complaining about
"tun0: Warning: Add route failed: 0.0.0.0: errno: Network is unreachable",
dials, and then sits and does nothing.)

>On Mon, 10 Jul 2000 10:39:44 MST, Eric Anholt wrote:
>
>>  Nope, same old device sc 1.  I've tried unmodified GENERIC, and it
>>  does the same thing.  Why am I special?
>
>I believe that the attached commit message describes the fix to the
>problem.  However, I'd recommend going all the way to rev 1.10 or
>whatever the latest is by the time you get this mail. :-)
>
>Ciao,
>Sheldon.
>
>
>green   2000/07/10 23:47:38 PDT
>
>   Modified files:
> sys/dev/randomdevyarrow.c
>   Log:
>   One should never allocate 4-kilobyte structs and such on the interrupt
>   stack.  It's bad for your machine's health.
>
>   Make the two huge structs in reseed() static to prevent crashes.  This
>   is the bug that people have been running into and panic()ing on for the
>   past few days.
>
>   Reviewed by:phk
>
>   Revision  ChangesPath
>   1.8   +7 -3  src/sys/dev/randomdev/yarrow.c

-- 

--
Eric Anholt
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

syscons hangs with -current

[Eric Anholt]

I am getting freezes  on -current as of my last two updates, Jul. 9 
and today, Jul. 10.  My previous update was around Jun 14.  I can 
boot the kernel from the last update just fine, though ppp doesn't 
work due to net changes. (I'm stuck using the mac with a modem as a 
natting router.  ugh.)  Bootblocks are from the Jul 9 update.  The 
system is a BP6 with non-overclocked Celeron 366s, 256MB ram, voodoo3 
pci.  I've tried both GENERIC and my configured kernel, I've tried 
swapping video cards to an s3, and changed every other card in the 
system one time or another while examining this.  I played with the 
video irq in the bios, the pnp bios options, and the hints.  The 
hints are from GENERIC with the addition of my soundblaster pcm 
entries.  I tried unsetting various hints related to sc from the 
loader, but there was never any change (a boot without any extra 
hints at all gives the same error, too).  I compiled up a kernel with 
pcvt rather than sc, but that just panicked at the atkbd area, as 
reported by someone else in the mail archives.  I can't find anything 
in the archives or UPDATING about this situation.  All kernels were 
compiled with default optimization.

(copying by hand, junk left out)

pci0: <3dfx Voodoo 3 graphics accelerator> at 15.0
vga0:  at port 0x3c0-0x3df iomem 0xa-0xv on isa0
sc0:  on isa0
sc0: VGA <16 virtual consoles, flags=0x200>
fdc0: ...
fdc0: ...
fd0: ...
isa0: <@@@> found
isa0: <@@@> found
isa0: <@@@> found
atkbdc0:  at port 0x60, 0x64 on isa0
atkbd0:  flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
vga1: Generic ISA VGA at port 0x3v0-0x3bb iomem 0xb-0xb7fff on isa0
sc1:  at flags 0x100 on isa0
_
At this point, the cursor shows but the kb doesn't respond.

A few bits of the hints, as reported by "show" from the loader
console=vidconsole
hint.atkbd.at=atkbdc
hint.atkbd.0.flags=0x1
hint.atkbd.0.irq=1
hint.atkbdc.0.at=isa
hint.atkbdc.0.port=0x060
hint.sc.0.at=isa
hint.sc.0.flags=0x100
hint.vga.0.at=isa
hint.vt.0.at=isa

Any help would be greatly appreciated.
-- 

--
Eric Anholt
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: fcnt, ecvt, gcvt and XFree86 2.9.16f build errors

[Eric Anholt]

>Hi,
>The latest XFree86 snapshot, 3.9.16f (which is about to become
>the public 3.9.17 snapshot) does not build on FreeBSD -current.
>
>It compains about fcvt, ecvt and gcvt.
>The exact error log from building XFree86 3.9.16f follows.
>
>It compiles ok on my 3.4 box (just CVSuped)
>

The problem is that gcc 2.95.2 in -current does not include #define
__FreeBSD__ any more. XF can't tell the OS, so it assumes you lack
snprintf(), and tries a different way of putting strings into numbers
(fcvt, ecvt, gcvt).  Check the top of a log from make World to see the OS
detection.

If you drop a #define __FreeBSD__ in config/cf/Imake.cf, it'll detect and
get at least farther along.  (still having troubles compiling from their
cvs, going to submit a report rsn).  Hopefully we can find a bit nicer way
of doing things soon.


--
Eric Anholt
[EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message