[gentoo-alpha] Xorg installation

[gentoo-alpha] Xorg installation

[Don Wilburn]

Dear alpha list,

Seems pretty quiet, but I'll try anyway.

I installed Gentoo a few days ago on a PWS500a. (says au)
I told it to emerge xorg-x11.
A simple "startx" made an effort to auto-configure.  Now it goes 
directly to a black screen with a cursor and some yellow artifacts, but 
the computer is locked up.
Xorg -configure reports failure, but it does write xorg.conf.new in the 
home directory.  Xorg -config with that file gives a black screen and 
locks up.
Either way doesn't leave any messages in the log file.

There were some "warnings" after emerge finished, but I didn't write 
them down.  I thought I'd see something on a google search, but that was 
a mistake.

FWIW, the video card is a PCI nVidia GeForce FX 5200 with 256MB.  It 
worked a couple years ago with Debian and FreeBSD alpha Xorg installations.

Gentoo packages reports xorg 1.13.4 is stable for alpha.  Any advice is 
appreciated.

Adios,  DW

Re: [gentoo-alpha] Xorg installation

[Brian Parkhurst]

what CFLAGS did you use during emerge?



On 5/10/2013 13:51, Don Wilburn wrote:
> Dear alpha list,
>
> Seems pretty quiet, but I'll try anyway.
>
> I installed Gentoo a few days ago on a PWS500a. (says au)
> I told it to emerge xorg-x11.
> A simple "startx" made an effort to auto-configure.  Now it goes
> directly to a black screen with a cursor and some yellow artifacts, but
> the computer is locked up.
> Xorg -configure reports failure, but it does write xorg.conf.new in the
> home directory.  Xorg -config with that file gives a black screen and
> locks up.
> Either way doesn't leave any messages in the log file.
>
> There were some "warnings" after emerge finished, but I didn't write
> them down.  I thought I'd see something on a google search, but that was
> a mistake.
>
> FWIW, the video card is a PCI nVidia GeForce FX 5200 with 256MB.  It
> worked a couple years ago with Debian and FreeBSD alpha Xorg installations.
>
> Gentoo packages reports xorg 1.13.4 is stable for alpha.  Any advice is
> appreciated.
>
> Adios,  DW
>
>

Re: [gentoo-alpha] Xorg installation

[Don Wilburn]

 >>what CFLAGS did you use during emerge?
I left make.conf alone after installation.  Whatever the installation 
guide said to use for CFLAGS and CXXFLAGS.
emerge complained the first time about some python problem.  So, I did a 
single time USE flag with that exact info and tried again.  It didn't 
complain any more.

CFLAGS and USE flags are new to me.  That makes it a bit tougher, but I 
can keep trying.

adios,  DW

Re: [gentoo-alpha] Xorg installation

[Brian Parkhurst]

run 
emerge --info

You should get something similar to the following, but specific to your
system.


Portage 2.1.11.63 (default/linux/alpha/13.0, gcc-4.5.4, glibc-2.15-r3,
3.7.9-gentoo alpha)
=================================================================
System uname: Linux-3.7.9-gentoo-alpha-EV67-with-gentoo-2.2
KiB Mem:     4148360 total,   1398192 free
KiB Swap:    7302840 total,   7302656 free
Timestamp of tree: Fri, 10 May 2013 15:00:01 +0000
ld GNU ld (GNU Binutils) 2.22
app-shells/bash:          4.2_p45
dev-lang/python:          2.6.8-r1, 2.7.3-r3, 3.1.5-r1, 3.2.3-r2
dev-util/cmake:           2.8.10.2-r1
dev-util/pkgconfig:       0.28
sys-apps/baselayout:      2.2
sys-apps/openrc:          0.11.8
sys-apps/sandbox:         2.6
sys-devel/autoconf:       2.13, 2.69
sys-devel/automake:       1.10.3, 1.11.6, 1.12.6, 1.13.1
sys-devel/binutils:       2.23.1
sys-devel/gcc:            4.3.6-r1, 4.4.7, 4.5.4, 4.6.3, 4.7.2-r1
sys-devel/gcc-config:     1.8
sys-devel/libtool:        2.4.2
sys-devel/make:           3.82-r4
sys-kernel/linux-headers: 3.9 (virtual/os-headers)
sys-libs/glibc:           2.15-r3
Repositories: gentoo
ACCEPT_KEYWORDS="alpha ~alpha"
ACCEPT_LICENSE="* -@EULA PUEL"
CBUILD="alpha-unknown-linux-gnu"
CFLAGS="-O2 -pipe -mcpu=ev67 -mno-soft-float -mfp-regs -mieee"
CHOST="alpha-unknown-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/apache2-php5.4/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-O2 -pipe -mcpu=ev67 -mno-soft-float -mfp-regs -mieee"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--autounmask=y"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified
distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch
protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs
unmerge-orphans userfetch"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://gentoo.gossamerhost.com
http://gentoo.mirrors.tera-byte.com/
ftp://mirrors.tera-byte.com/pub/gentoo"
LANG="en_US.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times
--compress --force --whole-file --delete --stats --human-readable
--timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X acl ads alpha alsa apache2 apng bash-completion berkdb blas
bonobo bzip2 cairo cdda cgi cli consolekit cracklib crypt cups cxx dba
dbus device-mapper dga dlloader dri ev56 extras fftw fontconfig fortran
gd gdbm gdu gentoo geoloc gif gmp gnome gnutls gpg gpm gsl gstreamer gtk
gtk2 gtk3 gudev hwdb iconv imap imaps imlib introspection introspection?
ipv6 jpeg kdrive kerberos kerberosV lapack ldap libg++ libwww maildir
mailwrapper modules motif mpfr mudflap ncurses nls nptl nptlonly
nsplugins openmp pam pcre pdf perl php pic png policykit pulseaudio
python qt qt3support qt4 readline samba sasl session smb sound sqlite
ssh ssl static-libs symlink tcpd telepathy threads tk tls truetype udev
unicode vhosts webgl winbind wxwindows xml zlib" ALSA_CARDS="ali5451
als4000 bt87x ca0106 cmipci emu10k1 ens1370 ens1371 es1938 es1968 fm801
hda-intel intel8x0 maestro3 trident usb-audio via82xx ymfpci"
ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug
file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw
multi null plug rate route share shm softvol" APACHE2_MODULES="cgi
actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm
authn_default authn_file authz_dbm authz_default authz_groupfile
authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock
dbd deflate dir disk_cache env expires ext_filter file_cache filter
headers ident imagemap include info log_config logio mem_cache mime
mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect
proxy_http rewrite setenvif so speling status unique_id userdir
usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets
stage tables krita karbon braindump author" CAMERAS="ptp2"
COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog"
ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18
garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver
oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate
tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux"
LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb
ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console
presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice"
PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7"
PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby18 ruby19"
USERLAND="GNU" VIDEO_CARDS="vga glint pm2 tga ati atimisc fbdev"
XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p
iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark
dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL,
PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS,
PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON

On Fri, 2013-05-10 at 17:30 -0500, Don Wilburn wrote: 
>  >>what CFLAGS did you use during emerge?
> I left make.conf alone after installation.  Whatever the installation 
> guide said to use for CFLAGS and CXXFLAGS.
> emerge complained the first time about some python problem.  So, I did a 
> single time USE flag with that exact info and tried again.  It didn't 
> complain any more.
> 
> CFLAGS and USE flags are new to me.  That makes it a bit tougher, but I 
> can keep trying.
> 
> adios,  DW
> 
> 
> 

-- 
------------------------
Brian C. Parkhurst
ORCA Technical Lead
Systems Programmer
UW Medicine IT Services
University of Washington
325 Ninth Ave
Box 359968
Seattle, WA 98104-2499
206-543-7458
brianp-at-u.washington.edu
brianp-pager-at-mcis.washington.edu
PGP Fingerprint DF84 0F88 AB6C F771 BB4E 7F4F F674 AA62 EEB4 1888

University of Washington e-mail messages are public records and are
subject to public inspection and copying as required under state public
records laws:

The above email may contain patient identifiable or confidential 
information. Because email is not secure, please be aware of associated 
risks of email transmission. If you are a patient, communicating to a 
UW Medicine Provider via email implies your agreement to email 
communication; see http://www.uwmedicine.org/Global/Compliance/EmailRisk.htm 

The information is intended for the individual named above. If you are
not the intended recipient, any disclosure, copying, distribution or use
of the contents of this information is prohibited. Please notify the
sender by reply email, and then destroy all copies of the message and
any attachments. See our Notice of Privacy Practices at
www.uwmedicine.org.

Re: [gentoo-alpha] Xorg installation

[Don Wilburn]

 >>what CFLAGS did you use during emerge?

I used the one from the make.conf.example.  It is
CFLAGS="-mieee -pipe -O2 -mcpu=ev4"

The gentoo alpha FAQ has a particular question about Xorg locking up. 
It says -mcpu is crucial.  I don't know what it should exactly be.  I 
figured the make.conf.example would be safe.

Adios,  DW

Re: [gentoo-alpha] Xorg installation

[Don Wilburn]

furthermore, I looked at /proc/cpuinfo

cpu                     : Alpha
cpu model               : EV56
cpu variation           : 7
cpu revision            : 0
cpu serial number       :
system type             : Miata

just like an example from gentoo's alpha porting guide.
I thought I read that EV56 is a bad one.

Adios,  DW

Re: [gentoo-alpha] Xorg installation

[Brian Parkhurst]

for ev56 the -mieee CFLAG is essential, (have and old Alpha server 800 
ev56 that's collecting dust).  My current is a DS20E, dual ev67 with a 
Texas Instruments TVP4020 [Permedia 2]  (glint driver)

make certain to emerge the Xorg driver for you particular video card

x11-drivers/xf86-video-nv is likely candidate.

might also emerge the generic vga driver to see if basic VGA works.

Also I seem to recall some models require the video card to be in Slot 1.

Would have to research that for yours.

Brian..

Re: [gentoo-alpha] Xorg installation

[Don Wilburn]

Now it's different, but not fixed.

I revised make.conf to say -mcpu=ev56
emerge --unmerge xorg-server and the nv,fbdev, and vesa drivers I 
installed.  After I emerged all that back, Xorg -configure still failed 
with a number of screens does not match the number of devices error, but 
it does write an xorg.conf.new.  That does not work, of course.
Now a simple starx brings up a graphics screen with three terminal 
instances started, but the computer is locked up.
For a lark, I --unmerged the keyboard, mouse, and evdev devices.  I did 
the same to xterm, just in case.  Emerged them back, but no difference.

I originally emerged the whole xorg-x11 package.  That took so long, I 
went directly to xorg-server for uninstall/reinstall.  I hoped that 
would be enough.
My methods seem relatively brutal and ignorant, but I don't know any 
better.

Adios,  DW

Re: [gentoo-alpha] Xorg installation

[Brian Parkhurst]

What kernel version are you running?

On 5/11/2013 13:11, Don Wilburn wrote:
> Now it's different, but not fixed.
>
> I revised make.conf to say -mcpu=ev56
> emerge --unmerge xorg-server and the nv,fbdev, and vesa drivers I
> installed.  After I emerged all that back, Xorg -configure still failed
> with a number of screens does not match the number of devices error, but
> it does write an xorg.conf.new.  That does not work, of course.
> Now a simple starx brings up a graphics screen with three terminal
> instances started, but the computer is locked up.
> For a lark, I --unmerged the keyboard, mouse, and evdev devices.  I did
> the same to xterm, just in case.  Emerged them back, but no difference.
>
> I originally emerged the whole xorg-x11 package.  That took so long, I
> went directly to xorg-server for uninstall/reinstall.  I hoped that
> would be enough.
> My methods seem relatively brutal and ignorant, but I don't know any
> better.
>
> Adios,  DW
>

Re: [gentoo-alpha] Xorg installation

[Don Wilburn]

 >>What kernel version are you running?

3.7.10-gentoo

That's what the install CD runs.  I tried to follow the installation 
guide when compiling my own.  The make menuconfig choices are a bit 
different now.

Meanwhile,  I tried editing the xorg.conf file to force different video 
drivers.  The fbdev won't start at all, so no lockup.  The vesa driver 
crashes and exits to SRM, which doesn't work and requires a hard reboot. 
  The nv results were previously described.

Not knowing any better, I may scare up the original Matrox card and 
temporarily install it instead.  I don't objectively know it's the video 
card/driver's fault, but that's my best guess.

Adios,  DW

Re: [gentoo-alpha] Xorg installation

[Don Wilburn]

Switching to Matrox didn't work.  The result was similar to nVidia- 
lockup, but the video was at a lower screen resolution.

Adios,  DW

Re: [gentoo-alpha] Xorg installation

[Don Wilburn]

Now I suspect the problem here is because udev and virtual/udev were 
built with keymap support turned off.  That's the most terse way I can 
describe it.  This may be because of the desktop profile.
I'm no developer.  I assume  keymap support was turned off for a reason. 
  Can anyone enlighten me about this?

The long story is that I knew saying my alpha was "locked up" was not a 
proper description.  I enabled login via a serial port.  Indeed, linux 
was working.  So, now I can kill X more gracefully.
After running emerge -tav to reinstall xorg-servers, it told me that 
virtual/udev without keymap may cause input device autoconfiguration to 
fail.
So, the -keymap flag is definitely set for udev and virtual/udev on my 
system.  I checked.
My plan is to wait a bit in case someone offers advice.  Failing that, 
I'll try rebuilding udev and virtual/udev without turning off keymap. 
If/when that doesn't work, I'll investigate manual configuration of the 
xorg input devices.

Adios,  DW

Re: [gentoo-alpha] Xorg installation

[Matt Turner]

On Tue, May 14, 2013 at 6:56 PM, Don Wilburn <bodhisattva@gt.rr.com> wrote:
> Now I suspect the problem here is because udev and virtual/udev were built
> with keymap support turned off.  That's the most terse way I can describe
> it.  This may be because of the desktop profile.
> I'm no developer.  I assume  keymap support was turned off for a reason.
> Can anyone enlighten me about this?
>
> The long story is that I knew saying my alpha was "locked up" was not a
> proper description.  I enabled login via a serial port.  Indeed, linux was
> working.  So, now I can kill X more gracefully.
> After running emerge -tav to reinstall xorg-servers, it told me that
> virtual/udev without keymap may cause input device autoconfiguration to
> fail.
> So, the -keymap flag is definitely set for udev and virtual/udev on my
> system.  I checked.
> My plan is to wait a bit in case someone offers advice.  Failing that, I'll
> try rebuilding udev and virtual/udev without turning off keymap. If/when
> that doesn't work, I'll investigate manual configuration of the xorg input
> devices.
>
> Adios,  DW
>

Enabling keymap support in udev sounds like it's worth a shot.

If you don't get a chance to try it I might soon. I'm updating my alpha now.

Thanks,
Matt

Re: [gentoo-alpha] Xorg installation

[Don Wilburn]

Latest attempts:
changed my profile from desktop to desktop/gnome.
rebuilt udev
rebuilt virtual/udev

This fixed the keymap error, but Xorg still failed the same way.

rebuilt xorg-server
rebuilt xorg-drivers

This did nothing too.  Again, I'm no developer, just a user.  I'm not 
that savvy about any of this, or Gentoo in general.
By "rebuilt," I mean emerge -tav <package>.  I saw that on a web page 
and it seems to be how to uninstall/reinstall stuff.

Looking through the Xorg logfile isn't spelling out the problem to me. 
There's no easy way to cut/paste or even dump that whole file here.

I'm contemplating wiping everything and reinstalling Gentoo from 
scratch.  I'm not sure if that would make a difference.  I'll ponder 
that for a while.

Adios,  DW

Re: [gentoo-alpha] Xorg installation- SOLVED!

[Don Wilburn]

Dear Alpha list,

The problem was in my kernel.  I had not enabled evdev.  Using make 
menuconfig, that's under:
Device Drivers-->Input Device Support-->Event Interface

That's not in the Gentoo Alpha handbook.  I guess it's a little stale at 
this point.
I've got a suggestion for that, if it does get updated, but I'll put it 
in separate post.

Thanks for looking in on this.

Adios,  DW

[gentoo-alpha] suggestion for the Alpha handbook

[Don Wilburn]

In case someone updates the installation procedure regarding disk 
preparation:

It says skip 2 cylinders for aboot-  I get it
fdisk defaults to using sectors-  I missed it

It was either aboot or swap, until I stared at the swriteboot man page 
and it said to skip 512 sectors...

Adios,  DW

Re: [gentoo-alpha] Xorg installation- SOLVED!

[Matt Turner]

On Wed, May 15, 2013 at 7:31 PM, Don Wilburn <bodhisattva@gt.rr.com> wrote:
> Dear Alpha list,
>
> The problem was in my kernel.  I had not enabled evdev.  Using make
> menuconfig, that's under:
> Device Drivers-->Input Device Support-->Event Interface
>
> That's not in the Gentoo Alpha handbook.  I guess it's a little stale at
> this point.
> I've got a suggestion for that, if it does get updated, but I'll put it in
> separate post.
>
> Thanks for looking in on this.
>
> Adios,  DW

Ah! Of course!

Thanks for the follow-up. I'm going to make a note to myself to add a
check for CONFIG_INPUT_EVDEV in the xf86-input-evdev ebuilds.

So to confirm, is X working for you now? With what graphics card?

Thanks,
Matt

Re: [gentoo-alpha] Xorg installation- SOLVED!

[Don Wilburn]

 >>So to confirm, is X working for you now? With what graphics card?

X is working now.  The only thing I've really done is install 
windowmaker, but it seems functional.

The graphics card is the original Matrox Millenium, using the mga driver.

In the future, I'll probably put the nVidia card back in.  It worked 
with Debian and FreeBSD alpha a few years ago, so I don't expect problems.

FWIW, my simple mind thought evdev meant "every device."  I knew Xorg 
wanted to use evdev, but I didn't realize it was in the kernel under 
"event."

Adios,  DW

[gentoo-alpha] emerge gentoo-sources fails

[Don Wilburn]

Dear Alpha list,

My hard drive crashed, so I'm trying to reinstall from scratch.
When I get to the emerge gentoo-sources step,  it seems to go all the 
way, then ends with a status 1 exit message.

The log files do not indicate the reason for failure, just that it 
happens.
During the installation, it throws up some errors about econfdir and 
/dev/fd/62 doesn't exist (I don't have it written down handy).  I'm 
thinking that happened before (when it worked) and didn't matter.

I have tried several times.  I've wiped the drive between tries, changed 
my mirror list, changed profile...  no luck.

I looked at the file date for the kernel source on a mirror.  It's 
pretty old, so it should be the same as what worked before.
I'm wondering about the ebuild, but I don't how such things work.  It 
worked fine a couple weeks ago.

Any suggestions about how to figure out the problem?

I imagine that emerging gentoo-sources is best, but could I just 
download a 3.7.10 tgz file from www.kernel.org and make one that way?

Adios,  DW

Re: [gentoo-alpha] emerge gentoo-sources fails

[Brian Parkhurst]

assuming your doing the install in the chroot environment?

are you able to emerge any other sources?  e.g. vanilla-sources?

On 5/23/2013 12:12, Don Wilburn wrote:
> Dear Alpha list,
>
> My hard drive crashed, so I'm trying to reinstall from scratch.
> When I get to the emerge gentoo-sources step,  it seems to go all the
> way, then ends with a status 1 exit message.
>
> The log files do not indicate the reason for failure, just that it happens.
> During the installation, it throws up some errors about econfdir and
> /dev/fd/62 doesn't exist (I don't have it written down handy).  I'm
> thinking that happened before (when it worked) and didn't matter.
>
> I have tried several times.  I've wiped the drive between tries, changed
> my mirror list, changed profile...  no luck.
>
> I looked at the file date for the kernel source on a mirror.  It's
> pretty old, so it should be the same as what worked before.
> I'm wondering about the ebuild, but I don't how such things work.  It
> worked fine a couple weeks ago.
>
> Any suggestions about how to figure out the problem?
>
> I imagine that emerging gentoo-sources is best, but could I just
> download a 3.7.10 tgz file from www.kernel.org and make one that way?
>
> Adios,  DW
>

Re: [gentoo-alpha] emerge gentoo-sources fails

[Don Wilburn]

 >assuming your doing the install in the chroot environment?
Yes.  The clock is right too.  (A flaky year seems to be a factory 
defect, but I digress...)

 >are you able to emerge any other sources?  e.g. vanilla-sources?
No.  I had tried gentoo-sources this morning from clean reinstall 
attempt.  That failed, so I emailed this list.  After the response, I 
tried emerge vanilla-sources.  Same result.  Then I tried emerge -tav 
vanilla-sources.
This put a lot of messages in the log.  It ended with:
--/usr/srce/linux-3.7.10/arch/m68k/kernel/
 >>>Failed to install sys-kernel/vanilla-sources-3.7.10, ...
Same result.

I looked at the log and there were one or two arches above m68k, but 
nothing after.  There was no arch/alpha, or even x86.  Looks suspicious. 
  Bad kernel source archive?

Adios,  DW

Re: [gentoo-alpha] emerge gentoo-sources fails

[Brian Parkhurst]

I'm running an emerge --sync now.

We'll see if I can't emerge gentoo-sources  (I'm currently running 3.7.9).



On 5/23/2013 14:30, Don Wilburn wrote:
>  >assuming your doing the install in the chroot environment?
> Yes.  The clock is right too.  (A flaky year seems to be a factory
> defect, but I digress...)
>
>  >are you able to emerge any other sources?  e.g. vanilla-sources?
> No.  I had tried gentoo-sources this morning from clean reinstall
> attempt.  That failed, so I emailed this list.  After the response, I
> tried emerge vanilla-sources.  Same result.  Then I tried emerge -tav
> vanilla-sources.
> This put a lot of messages in the log.  It ended with:
> --/usr/srce/linux-3.7.10/arch/m68k/kernel/
>  >>>Failed to install sys-kernel/vanilla-sources-3.7.10, ...
> Same result.
>
> I looked at the log and there were one or two arches above m68k, but
> nothing after.  There was no arch/alpha, or even x86.  Looks suspicious.
>   Bad kernel source archive?
>
> Adios,  DW
>
>

Re: [gentoo-alpha] emerge gentoo-sources fails

[Brian Parkhurst]

emerge gentoo-sources emerge'd 3.9.3 not 3.9.10

Doesn't appear that 3.9.10 is available yet.

alpha-omega linux # emerge --search gentoo-sources
Searching...    
[ Results for search key : gentoo-sources ]
[ Applications found : 1 ]

*  sys-kernel/gentoo-sources
      Latest version available: 3.9.3
      Latest version installed: 3.9.3
      Size of files: 70,535 kB
      Homepage:      http://dev.gentoo.org/~mpagano/genpatches
      Description:   Full sources including the Gentoo patchset for the
3.9 kernel tree
      License:       GPL-2 !deblob? ( freedist )

On Fri, 2013-05-24 at 11:59 -0700, Brian Parkhurst wrote: 
> I'm running an emerge --sync now.
> 
> We'll see if I can't emerge gentoo-sources  (I'm currently running 3.7.9).
> 
> 
> 
> On 5/23/2013 14:30, Don Wilburn wrote:
> >  >assuming your doing the install in the chroot environment?
> > Yes.  The clock is right too.  (A flaky year seems to be a factory
> > defect, but I digress...)
> >
> >  >are you able to emerge any other sources?  e.g. vanilla-sources?
> > No.  I had tried gentoo-sources this morning from clean reinstall
> > attempt.  That failed, so I emailed this list.  After the response, I
> > tried emerge vanilla-sources.  Same result.  Then I tried emerge -tav
> > vanilla-sources.
> > This put a lot of messages in the log.  It ended with:
> > --/usr/srce/linux-3.7.10/arch/m68k/kernel/
> >  >>>Failed to install sys-kernel/vanilla-sources-3.7.10, ...
> > Same result.
> >
> > I looked at the log and there were one or two arches above m68k, but
> > nothing after.  There was no arch/alpha, or even x86.  Looks suspicious.
> >   Bad kernel source archive?
> >
> > Adios,  DW
> >
> >
> 

Re: [gentoo-alpha] emerge gentoo-sources fails

[Brian Parkhurst]

Not sure about 3.7.10,

http://packages.gentoo.org/package/sys-kernel/gentoo-sources?arches=all&full_cat

shows the correct arch's

On 5/24/2013 13:16, Brian Parkhurst wrote:
> emerge gentoo-sources emerge'd 3.9.3 not 3.9.10
>
> Doesn't appear that 3.9.10 is available yet.
>
> alpha-omega linux # emerge --search gentoo-sources
> Searching...
> [ Results for search key : gentoo-sources ]
> [ Applications found : 1 ]
>
> *  sys-kernel/gentoo-sources
>        Latest version available: 3.9.3
>        Latest version installed: 3.9.3
>        Size of files: 70,535 kB
>        Homepage:      http://dev.gentoo.org/~mpagano/genpatches
>        Description:   Full sources including the Gentoo patchset for the
> 3.9 kernel tree
>        License:       GPL-2 !deblob? ( freedist )
>
> On Fri, 2013-05-24 at 11:59 -0700, Brian Parkhurst wrote:
>> I'm running an emerge --sync now.
>>
>> We'll see if I can't emerge gentoo-sources  (I'm currently running 3.7.9).
>>
>>
>>
>> On 5/23/2013 14:30, Don Wilburn wrote:
>>>   >assuming your doing the install in the chroot environment?
>>> Yes.  The clock is right too.  (A flaky year seems to be a factory
>>> defect, but I digress...)
>>>
>>>   >are you able to emerge any other sources?  e.g. vanilla-sources?
>>> No.  I had tried gentoo-sources this morning from clean reinstall
>>> attempt.  That failed, so I emailed this list.  After the response, I
>>> tried emerge vanilla-sources.  Same result.  Then I tried emerge -tav
>>> vanilla-sources.
>>> This put a lot of messages in the log.  It ended with:
>>> --/usr/srce/linux-3.7.10/arch/m68k/kernel/
>>>   >>>Failed to install sys-kernel/vanilla-sources-3.7.10, ...
>>> Same result.
>>>
>>> I looked at the log and there were one or two arches above m68k, but
>>> nothing after.  There was no arch/alpha, or even x86.  Looks suspicious.
>>>    Bad kernel source archive?
>>>
>>> Adios,  DW
>>>
>>>
>>
>
>
>

Re: [gentoo-alpha] emerge gentoo-sources fails

[Don Wilburn]

On 5/24/2013 3:16 PM, Brian Parkhurst wrote:
> emerge gentoo-sources emerge'd 3.9.3 not 3.9.10

3.7.10 is the last one marked stable for alpha on the gentoo packages 
site.  Mine isn's set up to allow anything unstable.

Adios,  DW

Re: [gentoo-alpha] emerge gentoo-sources fails

[Brian Parkhurst]

I'll attempt to download and install gentoo-source-3.7.10 here.  I'm 
current genkernel building 3.9.3 for kicks at the moment.


On 5/24/2013 13:56, Don Wilburn wrote:
> On 5/24/2013 3:16 PM, Brian Parkhurst wrote:
>> emerge gentoo-sources emerge'd 3.9.3 not 3.9.10
>
> 3.7.10 is the last one marked stable for alpha on the gentoo packages
> site.  Mine isn's set up to allow anything unstable.
>
> Adios,  DW
>
>

Re: [gentoo-alpha] emerge gentoo-sources fails

[Brian Parkhurst]

emerge of 3.7.10 succeeded,  currently attempting a genkernel  build.



On 5/24/2013 13:58, Brian Parkhurst wrote:
> I'll attempt to download and install gentoo-source-3.7.10 here.  I'm
> current genkernel building 3.9.3 for kicks at the moment.
>
>
> On 5/24/2013 13:56, Don Wilburn wrote:
>> On 5/24/2013 3:16 PM, Brian Parkhurst wrote:
>>> emerge gentoo-sources emerge'd 3.9.3 not 3.9.10
>>
>> 3.7.10 is the last one marked stable for alpha on the gentoo packages
>> site.  Mine isn's set up to allow anything unstable.
>>
>> Adios,  DW
>>
>>
>

Re: [gentoo-alpha] emerge gentoo-sources fails

[Brian Parkhurst]

I've successfully built a kernel.   I'll reboot the host later this 
evening when I'm home and can kick it if the boot hangs.



On 5/24/2013 13:58, Brian Parkhurst wrote:
> I'll attempt to download and install gentoo-source-3.7.10 here.  I'm
> current genkernel building 3.9.3 for kicks at the moment.
>
>
> On 5/24/2013 13:56, Don Wilburn wrote:
>> On 5/24/2013 3:16 PM, Brian Parkhurst wrote:
>>> emerge gentoo-sources emerge'd 3.9.3 not 3.9.10
>>
>> 3.7.10 is the last one marked stable for alpha on the gentoo packages
>> site.  Mine isn's set up to allow anything unstable.
>>
>> Adios,  DW
>>
>>
>

[gentoo-alpha] emerge gentoo-sources fails FINISHED

[Don Wilburn]

 >emerge of 3.7.10 succeeded,  currently attempting a genkernel  build.

That was Saturday afternoon.  I tried again after reading that.  This 
time, emerge did not give a fatal error.  I tried make menuconfig and 
failed.  There was no /usr/src/linux/Makefile.  Furthermore, there were 
_no_ files in /usr/src/linux, just directories.
So, I did a tar tvJf linux-3.7.tar.xz | less
in /usr/portage/distfiles.  Files were there.  I speculated that the 
patching process was butchering something.  Doesn't matter.

I waited until later, past midnight UTC.  I said some incantations, made 
some magic gestures, prayed, ran emerge, and went to sleep.
This time it worked.  I built a kernel and rebooted.  Hooray.  This 
thread can end with success.

Adios,  DW

[gentoo-alpha] one more thing

[Don Wilburn]

Previously, I got a question about my video card.  I switched it back to 
the nVidia GeForce FX 5200 w/256MB memory.  I emerged xorg-server after 
building my latest kernel and it seems to work fine with its nv driver.
Again, that's a preliminary observation with no real applications built 
to test it yet.

I've got a couple more questions, but I'll ponder them a while before 
asking.  Thanks for the responses before, BTW.

Adios,  DW

[gentoo-alpha] es1888 audio and PWS500au

[Don Wilburn]

My alpha has a built-in ES1888 sound card on its ISA bus.  Does anyone 
have one that works?

This old thread indicates that there are hardware problems:
http://osdir.com/ml/linux.ports.alpha/2008-03/msg00056.html

Alsa and the snd-es18xx modules load fine, the mixer works, nothing is 
muted, etc.  Trying a wav file with aplay gives some pcm error.

The obvious solution is to scare up a PCI sound card.  It would be nice 
if someone could tell me the built-in card works for them.

Adios,  DW

Re: [gentoo-alpha] es1888 audio and PWS500au

[Brian Parkhurst]

Can't help you there.  Have never bothered with the sound as I'm using 
my alpha mostly as a web server and remote X server.



On 5/28/2013 18:39, Don Wilburn wrote:
> My alpha has a built-in ES1888 sound card on its ISA bus.  Does anyone
> have one that works?
>
> This old thread indicates that there are hardware problems:
> http://osdir.com/ml/linux.ports.alpha/2008-03/msg00056.html
>
> Alsa and the snd-es18xx modules load fine, the mixer works, nothing is
> muted, etc.  Trying a wav file with aplay gives some pcm error.
>
> The obvious solution is to scare up a PCI sound card.  It would be nice
> if someone could tell me the built-in card works for them.
>
> Adios,  DW
>

[gentoo-alpha] Alpha boot CD has no jfs tools

[Don Wilburn]

The install CD for alpha has a module for jfs, but no utils for such a 
filesystem.
Could the Gentoo boot ISO builder please include them next time?

Mine is from May.  I'm guessing it's still the case.

I built a working jfs partition using my ext3 installation.  The jfs 
version won't even mount from a Gentoo CD boot.
My jfs version seems really flaky trying to emerge things.  I don't 
think it's hardware.  It may not make make a bit of difference, but I'd 
like to redo it from scratch with a "factory" install cd.

If a jfs-capable CD gets built, could somebody post a notice to this 
list?  Thanks.

Adios,  DW

Re: [gentoo-alpha] Alpha boot CD has no jfs tools

[Matt Turner]

On Thu, Jun 6, 2013 at 3:33 PM, Don Wilburn <bodhisattva@gt.rr.com> wrote:
> The install CD for alpha has a module for jfs, but no utils for such a
> filesystem.
> Could the Gentoo boot ISO builder please include them next time?
>
> Mine is from May.  I'm guessing it's still the case.
>
> I built a working jfs partition using my ext3 installation.  The jfs version
> won't even mount from a Gentoo CD boot.
> My jfs version seems really flaky trying to emerge things.  I don't think
> it's hardware.  It may not make make a bit of difference, but I'd like to
> redo it from scratch with a "factory" install cd.
>
> If a jfs-capable CD gets built, could somebody post a notice to this list?
> Thanks.

Some particular reason you want to use JFS? I don't think I've ever
used it, much less on alpha.

Probably best to file a bug to ask for jfstools to be included.

Re: [gentoo-alpha] Alpha boot CD has no jfs tools

[Don Wilburn]

On 6/12/2013 1:43 AM, Matt Turner wrote:
> Some particular reason you want to use JFS?
My two regular old computers have a partition with Slackware installed, 
one from 2005 and the other 2006.  Both are JFS and have not been killed 
by power outages or hard resets.  I see JFS as "reliable," more so than 
EXT3.  Once I figured out that aboot didn't care my root partition was 
JFS, I was happy.  The BSD disklabel has enough slices to squander one 
for a boot partition.
I don't think JFS wins any particular performance category, but I think 
it's regarded as good all around.  I'll put a couple subjective reasons 
at the end.

 > Probably best to file a bug to ask for jfstools to be included.
Can you point me in the direction of where to file such a bug report?

I figured the alpha developer list is really small and whoever makes the 
alpha install CD image would be on this mailing list.  I'll download the 
latest install image and check first.  If jfs is still lacking, I'll try 
reporting a bug.

Subjective reasons:
JFS came from IBM.  They probably had some quality people developing JFS 
for IBM products.
Hans Reiser is a convicted murderer.  I don't want ReiserFS on my 
computer.
I had a small amount of stock in SGI.  They went bankrupt and cost me 
money.  So, by association, I hate SGI->Irix->XFS. Who needs XFS?
The Gentoo alpha install CD has utils for ReiserFS and XFS.  Seems 
strange to neglect JFS.
Thanks for the reply.

Adios,  DW

Re: [gentoo-alpha] Alpha boot CD has no jfs tools

[Matt Turner]

On Wed, Jun 12, 2013 at 5:27 PM, Don Wilburn <bodhisattva@gt.rr.com> wrote:
>> Probably best to file a bug to ask for jfstools to be included.
> Can you point me in the direction of where to file such a bug report?

http://bugs.gentoo.org/

It's less likely to be forgotten if we have a bug to remind us. :)

Re: [gentoo-alpha] Alpha boot CD has no jfs tools bug report

[Don Wilburn]

 > best to file a bug to ask for jfstools to be included.

I just formally filed a bug and got a very prompt suggestion to ask the 
alpha team to include jfstools.  He said it was not included because 
it's not marked stable for alpha.

jfsutils is not marked stable for _any_ architecture on 
packages.gentoo.org.  JFS must be really wicked.

The official bug report may be enough, but I'm asking here for the alpha 
team to please include mkfs and fsck for jfs next time.  Thanks.

Adios,  DW

[gentoo-alpha] install cd won't boot

[Don Wilburn]

I've been trying to make a boot CD from the 9/6/2014 iso.  I tried more 
than than one iso, from different mirrors, using different computers, 
and different programs.  The result was always something about block 0 
is not a valid boot block.
So, I tried isomarkboot from Gentoo.  No luck.
Then I booted an old Debian (5.0 lenny) installation and used their 
isomarkboot.  I just entered isomarkboot file.iso boot/bootlx.  This 
time, it did start to boot.  It died with kernel stack not valid and 
three chevrons.
I'm out of CD-Rs.

I always figured it was my terrible IDE chip.  However, I have a Gentoo 
CD I marked 5/5/2013 that boots perfectly.  So, I have to conclude that 
my hardware can function.
I don't imagine that the aboot package has changed recently.  I don't 
know.  My hard drives are SCSI and aboot works for them.  I never tried 
isomarkboot before.
I left out any initrd parameters when I tried the Debian isomarkboot. 
There are initrd parameters passed to the kernels in the aboot.conf file 
on the CD, but I don't know what isomarkboot needs.

I assume the boot CD kernels work.
The man page says I can use a loop device or an image file.  The 
question is:
What is the proper syntax for running isomarkboot to make a Gentoo 
install CD?  Anything tricky?

Note: I ran the sha512sum on one iso file and eyballed the result.  It 
was right.
The next iso will probably be out soon.  My spindle of CD-Rs should 
arrive soon too, ha ha.  I'll keep trying.

Adios,  DW

Re: [gentoo-alpha] install cd won't boot

[Don Wilburn]

I filed a bug report on isomarkboot.

Meanwhile, I resorted to a cheat:
Booted debian lenny
mounted non-booting gentoo image using loop device
made a new image with genisofs -alpha-boot boot/bootlx ...
wrote new image to a CD using wodim and rebooted
Voila, it works.

I wish I had the knowledge to actually fix isomarkboot.  It's not 
exactly a crisis, at least.

Adios,  DW

Re: [gentoo-alpha] install cd won't boot

[Don Wilburn]

Oops, a typo
 >made a new image with genisofs -alpha-boot boot/bootlx ...

I meant genisoimage.

Re: [gentoo-alpha] install cd won't boot

[Raúl Porcel]

On 10/07/14 16:32, Don Wilburn wrote:
> Oops, a typo
>>made a new image with genisofs -alpha-boot boot/bootlx ...
> 
> I meant genisoimage.
> 

I'm doing my investigation in the bug:
https://bugs.gentoo.org/show_bug.cgi?id=524060

Thanks for the genisoimage idea, could be a workaround...

Re: [gentoo-alpha] emerge gentoo-sources fails

[Don Wilburn]

I got 3.7.10 from www.kernel.org yesterday evening.  I didn't really 
want to do it a la carte, so to speak, but it looks like I kept getting 
defective source from gentoo mirrors.  I guess my mind was closed to 
that possibility.  It worked before, so why would it change?

It took a couple iterations to get the kernel config right, but my alpha 
works once more.

 >I'm running an emerge --sync now.
I'll be curious to see the gentoo-sources result.

Adios,  DW

[gentoo-alpha] emerge failure revisited

[Don Wilburn]

A couple weeks ago, I reported that emerge gentoo-sources was failing. 
It magically worked once, so I quit yapping.

This was in the context of a fresh install, from the Gentoo CD boot.
The fix seems to be enabling a swap device, which I don't think is in 
the instructions.

It was a fluke that I came to this conclusion, but it works.
I switched to a second PWS500 (almost identical) to eliminate crazy 
hardware as a possibility.
I didn't think portage/emerge was such a hog that 256MB RAM was too 
little.  BTW, my first machine had 384MB.

I'm not going to formally report this as a bug, but I think something is 
wrong.  Maybe it only affects weakling Alphas like mine?
I don't follow the alternative architectures forum.  Maybe if someone 
shows up there with this problem, you can suggest swapon.

Adios,  DW

Re: [gentoo-alpha] emerge failure revisited

[Andrew Gaylard]

On 07/11/13 04:41, Don Wilburn wrote:
> A couple weeks ago, I reported that emerge gentoo-sources was failing. 
> It magically worked once, so I quit yapping.
>
> This was in the context of a fresh install, from the Gentoo CD boot.
> The fix seems to be enabling a swap device, which I don't think is in 
> the instructions.
>
> It was a fluke that I came to this conclusion, but it works.
> I switched to a second PWS500 (almost identical) to eliminate crazy 
> hardware as a possibility.
> I didn't think portage/emerge was such a hog that 256MB RAM was too 
> little.  BTW, my first machine had 384MB.
>
> I'm not going to formally report this as a bug, but I think something 
> is wrong.  Maybe it only affects weakling Alphas like mine?
> I don't follow the alternative architectures forum.  Maybe if someone 
> shows up there with this problem, you can suggest swapon.
>
> Adios,  DW
>
I haven't seen any error messages, but in today's world, it's really a 
good idea to run GCC with at least 1GB of (virtual) memory.  My alpha 
has 512MB, so I make sure that my swap is 2GB.  I strongly recommend you 
do likewise, disk space permitting.

-- 
Andrew

Re: [gentoo-alpha] emerge failure revisited

[Don Wilburn]

On 7/11/2013 9:37 AM, Andrew Gaylard wrote:
> 2GB.  I strongly recommend you do likewise, disk space permitting.
My swap partition is 1GB, as recommended by the handbook.  But, I have 
space to waste, so I'll see about revising that.  Thanks.

Consider that this was a fresh install from CD.  No swap file is added 
automatically, and nothing tells you to do it manually.

My first install was circa April.  I didn't think it was a big deal to 
erase it and start over, but I'm struggling to get back as far again.

Adios,  DW

[gentoo-alpha] radeon questions

[Don Wilburn]

Dear silent alpha list,

I got X to work with my GeForce card and the nv driver.  It was 
functional, but underwhelming.  So, I got a PCI Radeon card via eBay.
Specifically, it's a Visiontek 9250.  The lspci output calls it an RV280 
9200 PRO.  So far, I can't get X to work.
Like nouveau for my nVidia card, the kernel DRM radeon module won't 
load.  Running modprobe radeon fails and says "Exec format error."  The 
dmesg output says something about "Relocation (type 4) overflow vs 
radeon_resume_kms."
Question 1:  Does the kernel module work with any alpha, or is it just mine?

Even worse, the xorg driver doesn't seem to work for me.  The Xorg 
website says the radeon driver works with the RV280/9250 chip.  The 
Xorg.0.log shows a long list of radeon models, but none of the 9200/9250 
models say PCI.  They say AGP or IGP.
I tried to copycat a google result pertaining to a ppc iMac and made a 
conf file to explicitly relate the radeon driver to the device by BusID, 
but that didn't help.
Question 2:  Does anyone have a PCI radeon 9250 working in their alpha?

Should I give up?  Any advice is welcome.

Oh, I don't expect my video performance to be very good in a 500MHz 
machine with a PCI card.  I was hoping there would be an advantage with 
drivers for ATI/AMD vs hostile nVidia.

Thanks,  DW

Re: [gentoo-alpha] radeon questions

[Matt Turner]

On Sun, Nov 30, 2014 at 2:20 PM, Don Wilburn <bodhisattva@gt.rr.com> wrote:
> Dear silent alpha list,
>
> I got X to work with my GeForce card and the nv driver.  It was functional,
> but underwhelming.  So, I got a PCI Radeon card via eBay.
> Specifically, it's a Visiontek 9250.  The lspci output calls it an RV280
> 9200 PRO.  So far, I can't get X to work.
> Like nouveau for my nVidia card, the kernel DRM radeon module won't load.
> Running modprobe radeon fails and says "Exec format error."  The dmesg
> output says something about "Relocation (type 4) overflow vs
> radeon_resume_kms."
> Question 1:  Does the kernel module work with any alpha, or is it just mine?

It should work. My complete guess is that the module is too large.
Maybe try building it into your kernel? I suspect that might make the
problem more obvious.

> Even worse, the xorg driver doesn't seem to work for me.  The Xorg website
> says the radeon driver works with the RV280/9250 chip.  The Xorg.0.log shows
> a long list of radeon models, but none of the 9200/9250 models say PCI.
> They say AGP or IGP.

I don't expect the 2D driver will work without the kernel module.
Focus on the kernel module first.

> I tried to copycat a google result pertaining to a ppc iMac and made a conf
> file to explicitly relate the radeon driver to the device by BusID, but that
> didn't help.
> Question 2:  Does anyone have a PCI radeon 9250 working in their alpha?

I've had a Radeon 9100 working in an alpha, as well as others. A 9250
should work.

[gentoo-alpha] Re: radeon questions

[Måns Rullgård]

Matt Turner <mattst88@gentoo.org> writes:

> On Sun, Nov 30, 2014 at 2:20 PM, Don Wilburn <bodhisattva@gt.rr.com> wrote:
>> Dear silent alpha list,
>>
>> I got X to work with my GeForce card and the nv driver.  It was functional,
>> but underwhelming.  So, I got a PCI Radeon card via eBay.
>> Specifically, it's a Visiontek 9250.  The lspci output calls it an RV280
>> 9200 PRO.  So far, I can't get X to work.
>> Like nouveau for my nVidia card, the kernel DRM radeon module won't load.
>> Running modprobe radeon fails and says "Exec format error."  The dmesg
>> output says something about "Relocation (type 4) overflow vs
>> radeon_resume_kms."
>> Question 1:  Does the kernel module work with any alpha, or is it just mine?
>
> It should work. My complete guess is that the module is too large.
> Maybe try building it into your kernel? I suspect that might make the
> problem more obvious.

Relocation type 4 is R_ALPHA_LITERAL aka "GP relative 16 bit w/optimization"
so it can easily overflow if things get large.  Building it into the kernel
should either work or fail to link at all, hopefully with a more elaborate
error message.

Also, which kernel version are you using?  Prior to 3.9, the kernel used
the -msmall-data option, which made it especially prone to this kind of
overflow.

-- 
Måns Rullgård
mans@mansr.com

Re: [gentoo-alpha] Re: radeon questions

[Don Wilburn]

 >which kernel version are you using?

It is 3.17.4 from the gentoo-sources.  It was 3.14.14, which is still 
the newest marked "stable" for alpha.

 >I don't expect the 2D driver will work without the kernel module.
Focus on the kernel module first.

I thought the xorg radeon driver would be independent of the kernel 
module.  I will go back and make a new kernel today.  Thanks.

Re: [gentoo-alpha] Re: radeon questions

[Alex Deucher]

On Tue, Dec 9, 2014 at 1:56 PM, Don Wilburn <bodhisattva@gt.rr.com> wrote:
>>which kernel version are you using?
>
> It is 3.17.4 from the gentoo-sources.  It was 3.14.14, which is still the
> newest marked "stable" for alpha.
>
>>I don't expect the 2D driver will work without the kernel module.
> Focus on the kernel module first.
>
> I thought the xorg radeon driver would be independent of the kernel module.
> I will go back and make a new kernel today.  Thanks.
>

The radeon ddx relies on the KMS kernel driver.  The old UMS code in
the ddx was dropped a while ago.

Alex

Re: [gentoo-alpha] radeon questions

[Don Wilburn]

 >Maybe try building it into your kernel? I suspect that might make the
problem more obvious.

The first attempt failed to build.  So, I changed a few other things 
from built-in to modules.  The second one built successfully.
Indeed, X started and the window manager looked OK.  I started xterm and 
dragged it around.  Just after the kernel, I had emerged mesa-progs. 
So, I tried glxgears and CRASH.  Blank screen.  No response.  So, I 
logged in on a serial connection and tried my best to shut down 
gracefully.  I tried X a few more times and tried other programs, but 
the results have been the same or worse.
I am encouraged that X might work.  There are still problems.  I'll keep 
trying.

Re: [gentoo-alpha] radeon questions

[Don Wilburn]

Thanks for your replies.  Building the radeon driver into the kernel 
seems to work, but trying to make it a module does not (for me anyway).
It makes me wonder if nouveau could work in a similar fashion.

My X crashes were hardware problems.  The early DEC Personal Workstation 
has a DMA problem with its 64-bit PCI slots.  Some well-behaved cards 
work fine, apparently.  This Visiontek card doesn't make that list. 
This is the first time I've had objective proof.  Switching to a 32-bit 
PCI slot fixed my crashes.
Once I found out those 64-bit slots were ordinary PCI. there was no 
reason to put the vido card there anyway.  If they were PCI-X (not 
express), I could have gotten a 66MHz bus at least, but mine are fixed 
at 33.  Boo hoo.

My PNY GeForce 5200 did not cause problems in the bad slot.  Maybe the 
nv driver is too timid to cause a similar problem.  Maybe the hardware 
is less troublesome.  The question is moot.

I let X default to my 17" non-widescreen LCD monitor's 1280x1024 and 
24-bit color.  My first successful start of glxgears yielded about 
60fps.  I'm happy just to see those gears turn at all.

Now I need to figure out something better for my fb.modes file.  The 
framebuffer console text is tiny at 1280x1024.

Adios,  DW

[gentoo-alpha] Re: radeon questions

[Måns Rullgård]

Don Wilburn <bodhisattva@gt.rr.com> writes:

> Thanks for your replies.  Building the radeon driver into the kernel
> seems to work, but trying to make it a module does not (for me
> anyway).
> It makes me wonder if nouveau could work in a similar fashion.

Try and find out. :)

> My X crashes were hardware problems.  The early DEC Personal
> Workstation has a DMA problem with its 64-bit PCI slots. 

Yes, the older ones have a problem where a bus-master DMA transfer
crosses a page boundary may get corrupted.  The more recent SRM versions
include a whitelist of known-good devices, and will refuse to boot if an
unknown card is found in an affected slot (though there is an override).
The slots behind the PCI-PCI bridge have DMA transactions split on page
boundaries anyway, so those are not affected.

> Some well-behaved cards work fine, apparently.  This Visiontek card
> doesn't make that list. This is the first time I've had objective
> proof.  Switching to a 32-bit PCI slot fixed my crashes.  Once I found
> out those 64-bit slots were ordinary PCI. there was no reason to put
> the vido card there anyway.  If they were PCI-X (not express), I could
> have gotten a 66MHz bus at least, but mine are fixed at 33.  Boo hoo.
>
> My PNY GeForce 5200 did not cause problems in the bad slot.  Maybe the
> nv driver is too timid to cause a similar problem.  Maybe the hardware
> is less troublesome.  The question is moot.
>
> I let X default to my 17" non-widescreen LCD monitor's 1280x1024 and
> 24-bit color.  My first successful start of glxgears yielded about
> 60fps.  I'm happy just to see those gears turn at all.

60fps could simply be the vertical refresh rate.

-- 
Måns Rullgård
mans@mansr.com

Re: [gentoo-alpha] Re: radeon questions

[Matt Turner]

On Sat, Dec 13, 2014 at 2:22 PM, Måns Rullgård <mans@mansr.com> wrote:
> Don Wilburn <bodhisattva@gt.rr.com> writes:
>> I let X default to my 17" non-widescreen LCD monitor's 1280x1024 and
>> 24-bit color.  My first successful start of glxgears yielded about
>> 60fps.  I'm happy just to see those gears turn at all.
>
> 60fps could simply be the vertical refresh rate.

Yes, it certainly is. vblank_mode=0 will disable it.

Re: [gentoo-alpha] Re: radeon questions

[Don Wilburn]

 >Yes, it certainly is. vblank_mode=0 will disable it.
That changed it from 60 to 299, with no other changes.

Since Matt Turner has been reading:
I am probably going to file a bug on mesa-10.3.1.  It has stopped me 
from building firefox or seamonkey.  Changing VIDEO_CARDS didn't help me 
this time.  Mesa-10.0.4 is the last one marked stable for alpha and it 
works here.  I tried a newer mesa than 10.3.1, but it failed too.
I will attach the last 10.3.1 emerge info to the bug report.
Is there any other info I can provide that will help?

 >the older ones have a problem where a bus-master DMA transfer

I read in the FreeBSD documentation that some MX-5 models had a hardware 
workaround from the factory.  Since the problem hadn't revealed itself 
with my other cards, I was hoping that might apply.  Now I know for sure 
that mine is a bad one.

 >The more recent SRM versions include a whitelist of known-good 
devices, and will refuse to boot

The AphaBIOS side tells you about "illegal" cards too.  It doesn't even 
like the DEC SCSI card.  The original Matrox card is the only one I have 
that passes.

 >Try and find out.
Of the 3 ~identical alphas I saved from the garbage truck, this is the 
best one and I'm happy to find a combo that works.  If I had another 
free monitor, I might try another.
Actually, in the mean time, I came up with a Matrox G550.  I was hoping 
it might have a driver advantage too, even though the card was weaker 
than contemporary ATI/nVidia offerings.  The kernel driver doesn't list 
G550 as a choice, but Xorg says their driver does go up to G550. 
Whatever.  I'll think about it some other time.

Adios,  DW

[gentoo-alpha] Re: radeon questions

[Måns Rullgård]

Don Wilburn <bodhisattva@gt.rr.com> writes:

>>the older ones have a problem where a bus-master DMA transfer
>
> I read in the FreeBSD documentation that some MX-5 models had a
> hardware workaround from the factory.  Since the problem hadn't
> revealed itself with my other cards, I was hoping that might apply.
> Now I know for sure that mine is a bad one.

The PWS models with USB ports have the fix.

-- 
Måns Rullgård
mans@mansr.com

[gentoo-alpha] radeonfb question

[Don Wilburn]

Alpha list,

This may not be alpha-specific.  I don't know.  Perhaps Gentoo has an 
appropriate forum?

To make my radeon work, I had to build the X driver into the kernel. 
This forced me to build a radeonfb module.  The framebuffer module makes 
my console 1280x1024 32bit with 160x64 text.
I would really, really, really prefer something else on my 17" 
non-widescreen monitor.  I can't figure out a way to do it.

For X, xrandr can switch to a variety of auto-detected modes.  The 
console framebuffer only gives one choice by default.  So, I tried fbset 
and /etc/fb.modes.  Regardless of geometry, the only timings line that 
works is 0 0 0 0 0 0 0.  For example

mode "800x600"
   geometry 800 600 800 600 24
   timings 25000 88 40 23 1 128 4
   hsync high
   vsync high
endmode

That gives "ioctl FBIOPUT_VSCREENINFO: Invalid argument" as a result. 
The timings listed are from formula and are confirmed by an old example 
posted at https://github.com/Distrotech/fbset/blob/master/etc/fb.modes.ATI
(800x600 60HZ)
Changing timings to all zeroes removes the error, but gives me an 
800x600 piece of a 1280x1024 screen.

So, I tried passing a parameter to the module.  The kernel loads it 
automatically while booting.  I made a radeonfb.conf file in 
/etc/modeprobe.d, but nothing worked.
It seems strange that I can rmmod radeonfb and fb_ddc and the console 
remains unaffected.

What am I missing?  Is it not possible to change my console resolution? 
  I need help.

Thanks,  DW

Re: [gentoo-alpha] radeonfb question solved

[Don Wilburn]

The information was all over the place.  I read that KMS drivers take 
care of framebuffers themselves on one site.  It seems like I was forced 
to choose a console framebuffer too in order to make the radeon X driver 
work.  That would explain why unloading radeonfb had no effect. 
Whatever, I'm not going to try again right away.
The solution was passing a boot parameter.  Ultimately, I used xrandr to 
tell me the connector name.  So, it was video=VGA-1:width x height...
Hooray.

Adios,  DW

[gentoo-alpha] bug filed, probably happens to Alpha alone

[Don Wilburn]

The bug is with the old bsd-game of cribbage.  I don't have an x86 
Gentoo kit, just my Alpha.  The bugs.gentoo.org info said if it's not 
x86, then add the architecture team to the CC list.  So, I did, weeks later.
It's Bug 537010.
It seems strange that an ancient, text-based game wouldn't work right. 
Maybe it's too old?  I reported that the Gentoo game plays correctly in 
Debian alpha, but neither plays right in Gentoo.
Obviously, bsd-games are not critical, necessary programs.  Still, I 
like that old cribbage game.

Is there anyone else with a Gentoo alpha that has tried bsd-games and 
seen a problem with cribbage?

Note:  When I emerged the latest ncurses (which made no difference) it 
reported errors, but still installed.  It said not to bother Gentoo with 
that stuff, because it's an upstream problem.  So, if it's a problem 
with something similar, I'll shut up.  I'm crossing my fingers and 
hoping it's something easily fixed.

Adios,  DW

Re: [gentoo-alpha] bug filed, probably happens to Alpha alone

[Don Wilburn]

To all lurking cribbage players:
Mr. Klausmann proved my wild speculation was incorrect.  Cribbage is not 
only broken on Alpha.  Apparently, other architectures have the same 
problem.

[gentoo-alpha] nouveau question

[Don Wilburn]

I found a cheap SCSI drive and got my other PWS500a (el segundo) to 
work.  I put my nVidia card in and made a kernel with a built-in nouveau 
driver.  The nouveau framebuffer console works fine.
Gentoo refuses to acknowledge VIDEO_CARDS="nouveau" on my alpha.  I see 
how USE flags can be masked in profiles, but I don't know how video 
cards are masked.  I'm sure someone could tell me quicker than I can 
figure it out myself.

Is nouveau being prevented because alpha can't run it?
Am I missing some obvious answer?

Adios, DW

Re: [gentoo-alpha] nouveau question -follow up

[Don Wilburn]

 >I don't know how video cards are masked.  I'm sure someone could tell 
me quicker than I can figure it out myself.

I was looking in the wrong use.mask file.  I found it.
Nouveau was masked 4 years ago because it needs testing.  So, I'll just 
unmask it and see what happens.

One more question...  for newer cards than mine, nouveau requires 
firmware blobs for some acceleration.  Are those blobs independent of 
the computer, or do they require an intel/amd cpu?  The Gentoo nvidia 
firmware package only shows amd64 and i386, I think.

Adios,  DW

Re: [gentoo-alpha] nouveau question -follow up

[Alan Young]

Don Wilburn wrote:
> >I don't know how video cards are masked.  I'm sure someone could tell 
> me quicker than I can figure it out myself.
>
> I was looking in the wrong use.mask file.  I found it.
> Nouveau was masked 4 years ago because it needs testing.  So, I'll 
> just unmask it and see what happens.
>
> One more question...  for newer cards than mine, nouveau requires 
> firmware blobs for some acceleration.  Are those blobs independent of 
> the computer, or do they require an intel/amd cpu?  The Gentoo nvidia 
> firmware package only shows amd64 and i386, I think.
>
> Adios,  DW
>
>

The firmware should be independent of the architecture.  Looking at the 
ebuild, it looks like it downloads the x86 driver from nvidia, extracts 
the files and then runs a python script to pull the firmware blob from 
the driver. Eventually, it ends up in /lib/firmware/nouveau. Worst case 
scenario you'll have to extract it on a x86 box (or maybe under qemu 
running linux...) and copy the resulting file manually back to the Alpha.

Alan

Re: [gentoo-alpha] emerge failure revisited

[Matt Turner]

On Wed, Jul 10, 2013 at 7:41 PM, Don Wilburn <bodhisattva@gt.rr.com> wrote:
> This was in the context of a fresh install, from the Gentoo CD boot.
> The fix seems to be enabling a swap device, which I don't think is in the
> instructions.

It is: http://www.gentoo.org/doc/en/handbook/handbook-alpha.xml?part=1&chap=4

256 MB is much too little to compile things.

Re: [gentoo-alpha] emerge failure revisited

[Don Wilburn]

On 7/20/2013 11:10 PM, Matt Turner wrote:
>> I don't think is in the
>> >instructions.
> It is:

Thanks for checking up on me.

Shame on me for missing it.  It's right after the part about alternative 
filesystems, like, ahem, JFS...

I still think it would be nice to have those rudimentary JFS tools on a 
boot cd.  Mr. Klausman has marked them stable for alpha.

Adios,  DW