Bug#325733: Please add xvattr to xbase-clients
> It should be packaged on its own (it's in Marillat's repository, IIRC), > but certainly not in xbase-clients. Why's that? xvinfo is also in xbase-clients. Either way, it's not in the archive yet. I'd package it separately, just don't want to step on anyone's toes. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#325733: Please add xvattr to xbase-clients
Package: xbase-clients Version: 4.3.0.dfsg.1-14 Severity: wishlist Please add the xvattr tool (http://freshmeat.net/projects/xvattr/?topic_id=100%2C125) to xbase-clients. It's useful to tweak XV stuff at runtime without server restart, for instance to get xine running on the external CRTC port instead of the laptop panel (xvattr -a XV_SWITCHCRT -v 1). Found this hack mentioned on http://www.winischhofer.at/linuxsispart3.shtml#download (quite a lot of other good XV hints at http://www.winischhofer.at/linuxsispart2.shtml) Thanks, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#236132: libx11-6 postrm bug prevents removal of package
> this bug should have been fixed in 4.3.0-3. The build of xfree86_4.3.0-3 (in > pbuilder chroot) will probably fail due to a bug in tetex-bin (2.0.2-8), > though. How very encouraging. We're not using pbuilder, though. I'll shut my autobuilder down for the time being, until after 4.3.0-3 has been installed. Michael
Bug#236132: More weirdness with libx11-6 postrm
The libx11-6 postrm script still dies (with my change applied) because /usr/X11R6/lib is the _only_ line in ld.so.conf, and the output file is empty after the fgrep -v. set -e makes the postrm script die. Suggested change: fgrep -qsvx "$dir" "$ldsoconf" > "$ldsoconf.dpkg-tmp" || echo "empty ld.so.conf!" or some such. Michael
Bug#236132: libx11-6 postrm bug prevents removal of package
Package: libx11-6 Version: 4.3.0-2 Severity: critical quoting the postrm script: # is the line present? if fgrep -qsx "$dir" "$ldsoconf"; then # are there any shared objects in the directory? if [ "$(echo "$dir"/lib*.so.*.*)" = "$dir/lib*.so.*.*" ]; then # glob expansion produced nothing, so no shared libraries are present observe "removing $dir directory from $ldsoconf" fgrep -qsvx "$dir" > "$ldsoconf.dpkg-tmp" mv "$ldsoconf.dpkg-tmp" "$ldsoconf" fi fi Note: fgrep -qsvx "$dir" > "$ldsoconf.dpkg-tmp" should perhaps read fgrep -qsvx "$dir" "$ldsoconf" > "$ldsoconf.dpkg-tmp" Congrats, you just directed fgrep to read from stdin, effectively hangig the process: [EMAIL PROTECTED]:~$ bin/chrootapt unstable remove libx11-6 libxpm4 libice6 xfree86-common xlibs-data Reading Package Lists... Done Building Dependency Tree... Done The following packages will be REMOVED: libice6 libx11-6 libxpm4 xfree86-common xlibs-data 0 packages upgraded, 0 newly installed, 5 to remove and 8 not upgraded. Need to get 0B of archives. After unpacking 10.5MB will be freed. Do you want to continue? [Y/n] y (Reading database ... 13171 files and directories currently installed.) Removing libice6 ... Removing libx11-6 ... 17340 pts/0S 0:28 apt-get -o Dir::State=/usr/local/chroot/unstable/var/state/apt 17345 pts/0S 0:10 /usr/bin/dpkg --root=/usr/local/chroot/unstable --force-depends 17355 pts/0S 0:01 sh /var/lib/dpkg/info/libx11-6.postrm remove 17363 pts/0S 0:00 grep -F -qsvx /usr/X11R6/lib This happening on a buildd machine, the log watcher kills the parent process, leaving the package installed which in turn borks further builds by way of dependency conflicts (hence the severity). Please fix. Side note: same bug also affects libxpm4 and perhaps others. Michael
Re: a small C program to test xdm's /dev/mem reading on your architecture
> I and the other folks at the X Strike Force need to know the following
> things:
>
> 1) whether or not this program works when you run it without arguments
Runs without any problem ("read of /dev/mem returned 1") on PPC Powerbook
1999 "Lombard" (ran it multiple times, before and after sleep mode but not
much else happening on it).
> 3) if scenario 1) causes problems, whether invoking this program with
> the argument "fragile" helps it
Tried it anyway, same thing.
HTH,
Michael
Re: xserver-xfree86 4.1.0-2 fails where 4.0.2-7puetzk worked
> > > I'll try your kernel patch -- should I also perhaps try the 2.4 kernel? > > > > Try the 2.4 kernel first. If that doesn't fix it, my patch won't either. > > Sorry, I went ahead and stuck with kernel 2.2.19 with your patch. > > Your patch fixed it. Should I file a bug against the pmac to ask that > this patch be applied? It seems like I should... The patch is rather hackish (there's no way to easily find a free PCI resource region in 2.2 kernels) and might not make it through BenH's or Alan's 'no brute force hacks' filter. If the Debian kernel package maintainer accepts it, fine. Michael
Re: xserver-xfree86 4.1.0-2 fails where 4.0.2-7puetzk worked
> > > I'll try your kernel patch -- should I also perhaps try the 2.4 kernel? > > > > Try the 2.4 kernel first. If that doesn't fix it, my patch won't either. > > Sorry, I went ahead and stuck with kernel 2.2.19 with your patch. > > Your patch fixed it. Should I file a bug against the pmac to ask that > this patch be applied? It seems like I should... The patch is rather hackish (there's no way to easily find a free PCI resource region in 2.2 kernels) and might not make it through BenH's or Alan's 'no brute force hacks' filter. If the Debian kernel package maintainer accepts it, fine. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xserver-xfree86 4.1.0-2 fails where 4.0.2-7puetzk worked
> > should have read X -probeonly (where did that go?), sorry. > > That crashes it as well. I just tested with xserver-xfree86 4.1.0-5 > and -6, same results. > > I'll try your kernel patch -- should I also perhaps try the 2.4 kernel? Try the 2.4 kernel first. If that doesn't fix it, my patch won't either. Michael
Re: xserver-xfree86 4.1.0-2 fails where 4.0.2-7puetzk worked
> > should have read X -probeonly (where did that go?), sorry. > > That crashes it as well. I just tested with xserver-xfree86 4.1.0-5 > and -6, same results. > > I'll try your kernel patch -- should I also perhaps try the 2.4 kernel? Try the 2.4 kernel first. If that doesn't fix it, my patch won't either. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xserver-xfree86 4.1.0-2 fails where 4.0.2-7puetzk worked
> > Please send the full X server log (the section about PCI device
> > probing/fixup might prove interesting)
>
> I can't, due to the kernel crash which occurs when running this.
Sorry, I forgot how bad this can be... Does it also panic with X
> Should I file a bug on kernel-image-2.2.19-pmac about how it's
> crashing like this? I doubt there's anything the Debian maintainers
> can do, though...
They could try including a patch that's been floating around on
debian-powerpc and linuxppc-dev since the first XFree 4.0 days (ajoshi's
xserver devel tree, that's predating Branden's packages by a huge margin).
I thought this had been fixed in 4.1 though. Anyway, try rebuilding your
kernel with the patch I attached (it's for 2.2.18 but should apply to
2.2.19 as well).
> > and the output of lspci -v
> > before starting X (and perhaps after if you manage to do that :-P).
>
> Here's the one running after, is that good enough?
After? How'd you do that?
> 00:11.0 Display controller: ATI Technologies Inc 3D Rage LT Pro (rev dc)
> Flags: bus master, stepping, medium devsel, latency 32, IRQ 24
> Memory at 8200 (32-bit, non-prefetchable)
> I/O ports at 0400
> Memory at 82fff000 (32-bit, non-prefetchable)
> Capabilities: [5c] Power Management version 1
Just what I thought.
The first memory region (8200, video memory) and the second
(82fff000, MMIO registers) overlap. Now my guess is the X server detects
this, and changes one of the mappings (can someone on debian-x explain
exactly what the X server does with overlapping PCI resources these
days?). If it touches the 8200 region, there's no way for the kernel
atyfb driver to figure out its memory mappings just got changed, oops
(that's been a problem with 4.0 at least).
Michael
--- drivers/video/atyfb.c.orig Thu Oct 19 19:49:53 2000
+++ drivers/video/atyfb.c Fri Oct 20 12:10:37 2000
@@ -3242,14 +3242,72 @@
return 1;
}
+/*
+ * Check PCI resource overlap between any PCI device (but mydev) and this
region.
+ * This function does not discriminate between IO and memory space so memory
regions
+ * will be considered to overlap IO regions though they might be decoded
separate on
+ * machines with separate memory and IO access. This being for PPC I don't
care - MSch.
+ */
+__initfunc(int atyfb_check_overlap(struct pci_dev *mydev, unsigned long
mybase, unsigned int mysize))
+{
+
+int i,j;
+struct pci_dev *pdev;
+
+for (pdev = pci_devices; pdev; pdev = pdev->next) {
+
+ if (pdev == mydev)
+ continue;
+
+for (i = 0, j = 2; i < 6 && pdev->base_address[i]; i++) {
+ int io, breg = PCI_BASE_ADDRESS_0 + (i << 2);
+ unsigned long base;
+ u32 size, pbase;
+
+ base = pdev->base_address[i];
+
+ if (!base)
+ continue;
+
+ io = (base & PCI_BASE_ADDRESS_SPACE)==PCI_BASE_ADDRESS_SPACE_IO;
+
+ pci_read_config_dword(pdev, breg, &pbase);
+ pci_write_config_dword(pdev, breg, 0x);
+ pci_read_config_dword(pdev, breg, &size);
+ pci_write_config_dword(pdev, breg, pbase);
+
+ if (io) {
+ size &= PCI_BASE_ADDRESS_IO_MASK;
+ base &= PCI_BASE_ADDRESS_IO_MASK;
+ } else {
+ size &= PCI_BASE_ADDRESS_MEM_MASK;
+ base &= PCI_BASE_ADDRESS_MEM_MASK;
+ }
+ size = ~(size) + 1;
+
+ if ( (base < mybase+mysize-1 && base+size-1 >= mybase)
+|| (mybase < base+size-1 && mybase+mysize-1 >= base) ) {
+ printk("\nPCI resource conflict: %lx-%lx overlaps %lx-%lx !\n",
+ base, base+size-1, mybase, mybase+mysize-1);
+ return 1; /* conflicting region overlaps */
+ }
+
+}
+}
+
+return 0; /* no conflicting region found */
+
+}
+
+
#ifdef CONFIG_FB_OF
__initfunc(void atyfb_of_init(struct device_node *dp))
{
-unsigned long addr;
+unsigned long addr, io_base=NULL;
u8 bus, devfn;
u16 cmd;
struct fb_info_aty *info;
-int i;
+int i, i_frame, i_regs, i_io, naddr;
if (device_is_compatible(dp, "ATY,264LTPro")) {
/* XXX kludge for now */
@@ -3284,6 +3342,12 @@
}
memset(info, 0, sizeof(struct fb_info_aty));
+/*
+ * Use register set in the little endian aperture regardless of what was
set
+ * up in OF or the PCI registers for MMIO. We could use the registers in
the
+ * big endian aperture as well (at least on some LTPro), or set up a
separate
+ * PCI mapping. Seems to work either way (again, on my Lombard) - MSch.
+ */
info->ati_regbase_phys = 0x7ff000+addr;
info->ati_regbase = (unsigned long)ioremap(info->ati_regbase_phys,
0x1000);
@@ -3297,8 +3361,49 @@
info->ati_regbase_phys += 0xc00;
info->ati_regbase += 0xc00;
-/
Re: xserver-xfree86 4.1.0-2 fails where 4.0.2-7puetzk worked
> > I can't, due to the kernel crash which occurs when running this. > > Sorry, I forgot how bad this can be... Does it also panic with X should have read X -probeonly (where did that go?), sorry. Michael
Re: xserver-xfree86 4.1.0-2 fails where 4.0.2-7puetzk worked
> > Please send the full X server log (the section about PCI device
> > probing/fixup might prove interesting)
>
> I can't, due to the kernel crash which occurs when running this.
Sorry, I forgot how bad this can be... Does it also panic with X
> Should I file a bug on kernel-image-2.2.19-pmac about how it's
> crashing like this? I doubt there's anything the Debian maintainers
> can do, though...
They could try including a patch that's been floating around on
debian-powerpc and linuxppc-dev since the first XFree 4.0 days (ajoshi's
xserver devel tree, that's predating Branden's packages by a huge margin).
I thought this had been fixed in 4.1 though. Anyway, try rebuilding your
kernel with the patch I attached (it's for 2.2.18 but should apply to
2.2.19 as well).
> > and the output of lspci -v
> > before starting X (and perhaps after if you manage to do that :-P).
>
> Here's the one running after, is that good enough?
After? How'd you do that?
> 00:11.0 Display controller: ATI Technologies Inc 3D Rage LT Pro (rev dc)
> Flags: bus master, stepping, medium devsel, latency 32, IRQ 24
> Memory at 8200 (32-bit, non-prefetchable)
> I/O ports at 0400
> Memory at 82fff000 (32-bit, non-prefetchable)
> Capabilities: [5c] Power Management version 1
Just what I thought.
The first memory region (8200, video memory) and the second
(82fff000, MMIO registers) overlap. Now my guess is the X server detects
this, and changes one of the mappings (can someone on debian-x explain
exactly what the X server does with overlapping PCI resources these
days?). If it touches the 8200 region, there's no way for the kernel
atyfb driver to figure out its memory mappings just got changed, oops
(that's been a problem with 4.0 at least).
Michael
--- drivers/video/atyfb.c.orig Thu Oct 19 19:49:53 2000
+++ drivers/video/atyfb.c Fri Oct 20 12:10:37 2000
@@ -3242,14 +3242,72 @@
return 1;
}
+/*
+ * Check PCI resource overlap between any PCI device (but mydev) and this region.
+ * This function does not discriminate between IO and memory space so memory regions
+ * will be considered to overlap IO regions though they might be decoded separate on
+ * machines with separate memory and IO access. This being for PPC I don't care -
+MSch.
+ */
+__initfunc(int atyfb_check_overlap(struct pci_dev *mydev, unsigned long mybase,
+unsigned int mysize))
+{
+
+int i,j;
+struct pci_dev *pdev;
+
+for (pdev = pci_devices; pdev; pdev = pdev->next) {
+
+ if (pdev == mydev)
+ continue;
+
+for (i = 0, j = 2; i < 6 && pdev->base_address[i]; i++) {
+ int io, breg = PCI_BASE_ADDRESS_0 + (i << 2);
+ unsigned long base;
+ u32 size, pbase;
+
+ base = pdev->base_address[i];
+
+ if (!base)
+ continue;
+
+ io = (base & PCI_BASE_ADDRESS_SPACE)==PCI_BASE_ADDRESS_SPACE_IO;
+
+ pci_read_config_dword(pdev, breg, &pbase);
+ pci_write_config_dword(pdev, breg, 0x);
+ pci_read_config_dword(pdev, breg, &size);
+ pci_write_config_dword(pdev, breg, pbase);
+
+ if (io) {
+ size &= PCI_BASE_ADDRESS_IO_MASK;
+ base &= PCI_BASE_ADDRESS_IO_MASK;
+ } else {
+ size &= PCI_BASE_ADDRESS_MEM_MASK;
+ base &= PCI_BASE_ADDRESS_MEM_MASK;
+ }
+ size = ~(size) + 1;
+
+ if ( (base < mybase+mysize-1 && base+size-1 >= mybase)
+|| (mybase < base+size-1 && mybase+mysize-1 >= base) ) {
+ printk("\nPCI resource conflict: %lx-%lx overlaps %lx-%lx !\n",
+ base, base+size-1, mybase, mybase+mysize-1);
+ return 1; /* conflicting region overlaps */
+ }
+
+}
+}
+
+return 0; /* no conflicting region found */
+
+}
+
+
#ifdef CONFIG_FB_OF
__initfunc(void atyfb_of_init(struct device_node *dp))
{
-unsigned long addr;
+unsigned long addr, io_base=NULL;
u8 bus, devfn;
u16 cmd;
struct fb_info_aty *info;
-int i;
+int i, i_frame, i_regs, i_io, naddr;
if (device_is_compatible(dp, "ATY,264LTPro")) {
/* XXX kludge for now */
@@ -3284,6 +3342,12 @@
}
memset(info, 0, sizeof(struct fb_info_aty));
+/*
+ * Use register set in the little endian aperture regardless of what was set
+ * up in OF or the PCI registers for MMIO. We could use the registers in the
+ * big endian aperture as well (at least on some LTPro), or set up a separate
+ * PCI mapping. Seems to work either way (again, on my Lombard) - MSch.
+ */
info->ati_regbase_phys = 0x7ff000+addr;
info->ati_regbase = (unsigned long)ioremap(info->ati_regbase_phys,
0x1000);
@@ -3297,8 +3
Re: xserver-xfree86 4.1.0-2 fails where 4.0.2-7puetzk worked
> > I can't, due to the kernel crash which occurs when running this. > > Sorry, I forgot how bad this can be... Does it also panic with X should have read X -probeonly (where did that go?), sorry. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xserver-xfree86 4.1.0-2 fails where 4.0.2-7puetzk worked
> Distribution: pure 'testing' > Version: 4.1.0-2 > Kernel: kernel-image-2.2.19-pmac 2.2.19-2 > > Installing the new xserver-xfree86 4.1.0-2 from unstable causes an > error: > > (WW) ATI: PCI/AGP Mach64 in slot 0:17:0 could not be detected! > (EE) No devices detected. > > With a subsequent kernel crash: > > flan kernel: Kernel panic: machine check Wallstreet and 2.2 kernel, and you boot using BootX I suppose? Please send the full X server log (the section about PCI device probing/fixup might prove interesting) and the output of lspci -v before starting X (and perhaps after if you manage to do that :-P). Michael
Re: xserver-xfree86 4.1.0-2 fails where 4.0.2-7puetzk worked
> Distribution: pure 'testing' > Version: 4.1.0-2 > Kernel: kernel-image-2.2.19-pmac 2.2.19-2 > > Installing the new xserver-xfree86 4.1.0-2 from unstable causes an > error: > > (WW) ATI: PCI/AGP Mach64 in slot 0:17:0 could not be detected! > (EE) No devices detected. > > With a subsequent kernel crash: > > flan kernel: Kernel panic: machine check Wallstreet and 2.2 kernel, and you boot using BootX I suppose? Please send the full X server log (the section about PCI device probing/fixup might prove interesting) and the output of lspci -v before starting X (and perhaps after if you manage to do that :-P). Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree-4.1.0-1 vs benh-kernel
> 1. at wakeup, after sleep, the computer crashes! [kernel] Each time? Only after sleep for a long time? > 2. one single touch of the trackpad is like a double-click [kernel] Use trackpad notap, perhaps. Should be in pmac-utils. > 3. group of pixels change color, like moving around [both fbdev and ati > servers] Wrong memclk or pll setting. > Am I the only one seeing this? Apparently so. 2.4.6 (-benh from two weeks back or so) works just fine here. So does the X server (4.1.0-0pre1v2; I doubt 4.1.0-1 is much different). Michael
Re: xfree-4.1.0-1 vs benh-kernel
> 1. at wakeup, after sleep, the computer crashes! [kernel] Each time? Only after sleep for a long time? > 2. one single touch of the trackpad is like a double-click [kernel] Use trackpad notap, perhaps. Should be in pmac-utils. > 3. group of pixels change color, like moving around [both fbdev and ati > servers] Wrong memclk or pll setting. > Am I the only one seeing this? Apparently so. 2.4.6 (-benh from two weeks back or so) works just fine here. So does the X server (4.1.0-0pre1v2; I doubt 4.1.0-1 is much different). Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: r128 driver, unresolved symbols, XF86 4.0.2-1
> Some Mach64 based chips cause problems with 2.2 kernels so he might need to > also use a 2.4 one or a patch from Michael Schmitz (check the -powerpc > archives). Or use yaboot. Michael
Re: r128 driver, unresolved symbols, XF86 4.0.2-1
> Some Mach64 based chips cause problems with 2.2 kernels so he might need to > also use a 2.4 one or a patch from Michael Schmitz (check the -powerpc > archives). Or use yaboot. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sorry, I can't build 4.0.1-9pre10v1 for powerpc
> > Appears to be a memory/swap related problem. Open up another tty and run > > 'top' while the make is going on, and watch your total free memory and your > > total free swap..they might get too small for cc to run > > successfully. (VM is the virtual memory driver) > > Tried that; I did some testing in real-time with the folks in > #debian-devel. It appears to be a problem with the kernel VM handler > (perhaps ppc specific) in 2.2.18pre21. > memory : 56MB > > 56MB ain't a lot but it should be plenty for almost any compile. How about swap, and how much VM did the compiler actually take? The error message looks like the kernel ran into trouble swapping out pages. I haven't tried pre21 but pre18 had no such trouble I could notice ... Michael
Re: sorry, I can't build 4.0.1-9pre10v1 for powerpc
> > Appears to be a memory/swap related problem. Open up another tty and run > > 'top' while the make is going on, and watch your total free memory and your > > total free swap..they might get too small for cc to run > > successfully. (VM is the virtual memory driver) > > Tried that; I did some testing in real-time with the folks in > #debian-devel. It appears to be a problem with the kernel VM handler > (perhaps ppc specific) in 2.2.18pre21. > memory : 56MB > > 56MB ain't a lot but it should be plenty for almost any compile. How about swap, and how much VM did the compiler actually take? The error message looks like the kernel ran into trouble swapping out pages. I haven't tried pre21 but pre18 had no such trouble I could notice ... Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4 phase2v5 available for powerpc
> >Yeap thats the problem, looking at Franz's patch it seems that if > > keyboard_sends_linux_keycodes doesn't exist, the server assumes AT keycodes. > > I am not sure how to handle APUS as well, even the pmac test through xkb > > will only work if xkb is enabled (not always the case), i think it should > > be better to handle all the cases through the config file although it will > > make it harder for the users :( > > Erm... this doesn't make sense to me. On powerpc, if the file does not > exist, shouldn't we maintain the old behavior? Feel free to discuss this with Franz. I've had my fruitless discussion about keeping backwards compatibility already (about adbmouse and mouse button emulation), I won't repeat it. To be fair: implementing/backporting the new input layer code for APUS would be another solution to this problem. Michael
Re: XFree86 4 phase2v5 available for powerpc
> >Yeap thats the problem, looking at Franz's patch it seems that if > > keyboard_sends_linux_keycodes doesn't exist, the server assumes AT keycodes. > > I am not sure how to handle APUS as well, even the pmac test through xkb > > will only work if xkb is enabled (not always the case), i think it should > > be better to handle all the cases through the config file although it will > > make it harder for the users :( > > Erm... this doesn't make sense to me. On powerpc, if the file does not > exist, shouldn't we maintain the old behavior? Feel free to discuss this with Franz. I've had my fruitless discussion about keeping backwards compatibility already (about adbmouse and mouse button emulation), I won't repeat it. To be fair: implementing/backporting the new input layer code for APUS would be another solution to this problem. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4 phase2v5 available for powerpc
> > > The ATI Mach64 driver is known broken in these packages. We're working > > > on a viable solution to it. Sorry. > > > > I'll resync with Ani Joshi's source sometime soon and try if that's hosed > > as well. I had it working as late as July 18, maybe something broke after > > that date. > > It'll be fine. The problem was in my merge from Ani's code; we're > working out a better solution now, and should have something next week. OK, I'm not really holding my breath for it anyway, I'm using Xfree 4 since a while :-) Michael
Re: XFree86 4 phase2v5 available for powerpc
> > > The ATI Mach64 driver is known broken in these packages. We're working > > > on a viable solution to it. Sorry. > > > > I'll resync with Ani Joshi's source sometime soon and try if that's hosed > > as well. I had it working as late as July 18, maybe something broke after > > that date. > > It'll be fine. The problem was in my merge from Ani's code; we're > working out a better solution now, and should have something next week. OK, I'm not really holding my breath for it anyway, I'm using Xfree 4 since a while :-) Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4 phase2v5 available for powerpc
> The ATI Mach64 driver is known broken in these packages. We're working > on a viable solution to it. Sorry. I'll resync with Ani Joshi's source sometime soon and try if that's hosed as well. I had it working as late as July 18, maybe something broke after that date. > > Found a Mach64 on a PowerPC > > (WW) INVALID IO ALLOCATION b: 0xc00 e: 0xcff correcting > > (II) window: > > [0] -1 0x - 0x (0x1) IX[B] > > Hmm, that's wierd, not seen that one before. I'm not inclined to pay > any attention to it until we finish fixing the driver, though. It's perfectly normal for me, and does not interfere with the function of the driver in any way I could notice (speaking of the July 18 snapshot of 4.01+ajoshi). Michael
Re: XFree86 4 phase2v5 available for powerpc
> The ATI Mach64 driver is known broken in these packages. We're working > on a viable solution to it. Sorry. I'll resync with Ani Joshi's source sometime soon and try if that's hosed as well. I had it working as late as July 18, maybe something broke after that date. > > Found a Mach64 on a PowerPC > > (WW) INVALID IO ALLOCATION b: 0xc00 e: 0xcff correcting > > (II) window: > > [0] -1 0x - 0x (0x1) IX[B] > > Hmm, that's wierd, not seen that one before. I'm not inclined to pay > any attention to it until we finish fixing the driver, though. It's perfectly normal for me, and does not interfere with the function of the driver in any way I could notice (speaking of the July 18 snapshot of 4.01+ajoshi). Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libc5 support in X?
> > In that case, I plan to drop Xlib libc5-compatibility for m68k in woody. > > > > We might as well retain it in potato, this close to the release. > Michael, did you read Brandens announcement by now? Yep (the URL you quoted, if that's what you mean; there were no 'corrections'). > Please, no more (unnecessary) changes to xfree, last time I built it, libc5 > packages were built fine, and that is good. Its the first time since a very > long time that it worked. Lets let libc5 in for xfree-3.3.6 and drop it > whenever we have a chance to get a working x4.0 for m68k. Last I heard, my > hardware is not even supported yet. I have never been advocating using 4.0 for anything right now. I'm in the 15 minute 'add trace message, rebuild, reinstall, start X server, reboot, fsck' cycle myself right now on PPC. Sorry if I did sound more optimistic than that. > I will start building the lastest xfree 3.3.6 tonight, 4.0 has to wait till > after potato, lets give Branden some time to repackage it. XFree 4.0 needs major fixes not only on m68k. I'm sure Branden is done packaging it long before we can reasonably hope to have functional binaries. Michael
