date:20050112

On 05-Jan-12 22:51, Harald Dunkel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Harald Dunkel wrote:
> | Hi folks,
> |
> | Since the most recent upgrade of apt (0.5.27.2.0.0.1.gcc4)
> | aptitude dies with a core dump immediately.
> |
> 
> PS: Going back to the old version built with gcc 3.4 (AFAIK)
> fixes the problem.

I just uploaded a new version of aptitude which has been compiled
with gcc-4.0 to the archive. This new version fixes the segfault
issue.

Regards
Andreas Jochens


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New soundcard, no cd sound

Hi Ernest,
I tried
"Solution:
- don't run alsaconfig after startup
- run alsamixer, 
- scroll right until you have rewewed all the mixer settings, and
probably  
the one which is completly to the right will be muted."
Unfortunately this did not solve the problem.
In alsamixer the far right channel is called Multi Track Volume Rate and
is not muted. I have to learn more about alsamixer..
Thanks,
Norv

On Tue, 2005-01-11 at 20:14 +0100, Ernest jw ter Kuile wrote:
> On Tuesday 11 January 2005 20:05, Ernest jw ter Kuile wrote:
> > On Tuesday 11 January 2005 08:26, Norval Watson wrote:
> 
> > - run alsamixer,
> > - scroll right until you have rewewed all the mixer settings, and probably
> > the one which is completly to the right will be mutted.
> 
> Oops, warning! warning! warning! Not clear at all !!
> 
> So ... Important :
> 
> Running alsamixer does _not_ show you all the mixer settings.
> 
> when I said _scroll_ right, you should ! 
> 
> just press richt arrow key until you saw all the hidden mixer settings too.
> 
> Have fun,
> 
> E.
> 
> 
> 
> 
> 
> 
> 
> 
> >
> > Wel, at least mine was.
> >
> > I'm not sure how the default settings where saved after that, but I think
> > doing this in alsamixer did the trick here.
> >
> > Drove me crazy too.
> >
> > Ernest.
> 
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New soundcard, no cd sound

Hi Len,
The internal audio cable from the cdrom is connected to the mobo.
Norv

On Tue, 2005-01-11 at 13:23 -0500, Lennart Sorensen wrote:
> On Tue, Jan 11, 2005 at 06:26:46PM +1100, Norval Watson wrote:
> > I have just installed a M-Audio Delta Audiophile 2496 soundcard in
> > Gigabyte K8NSPro mobo, running pure64/sid.
> > 
> > Sound is working on dvd playback but no sound from cd playback.
> > Driver is ice1712. I have run alsaconf (actually, I have to run it each
> > time I restart the box..)
> > 
> > What might I need to I need to configure to get the cd playback working?
> 
> Is the internal audio cable from the cd connected to the sound card
> cdaudio input?
> 
> Windows hasn't used this since win98 by default, but instead uses
> digital extraction to playback CDs.  Linux still uses the audio playback
> feature found in the hardware unless you use one of the programs that
> plays using digital extraction.
> 
> Len Sorensen
> 
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New soundcard, no cd sound

Hi Erik,
By 'cd playback' I just mean to play back an audio cd. On my GA-K8NSPro
mobo the CD-rom audio cable plugs into the mobo.
Thanks for the alsa link, there is a lot of good info there.
I can play sound from DVD, mp3, onboard synth (freebirth), etc, it seems
to be just the audio cd that has no sound.
I got a lot of replies to this query, thanks to all who replied and I am
working my way thru your suggestions. And I got a new coffee-pot and
some strong coffee.
Regards,
Norv

On Tue, 2005-01-11 at 10:39 +0100, Erik Mouw wrote:
> On Tue, Jan 11, 2005 at 06:26:46PM +1100, Norval Watson wrote:
> > I have just installed a M-Audio Delta Audiophile 2496 soundcard in
> > Gigabyte K8NSPro mobo, running pure64/sid.
> > 
> > Sound is working on dvd playback but no sound from cd playback.
> > Driver is ice1712. I have run alsaconf (actually, I have to run it each
> > time I restart the box..)
> > 
> > What might I need to I need to configure to get the cd playback working?
> 
> Don't know what you mean with "CD playback", my Audiophile doesn't have
> connectors for an internal CDROM. Check out the .asoundrc files over
> here (sorry, long url):
> 
>   
> http://www.alsa-project.org/alsa-doc/doc-php/template.php?company=Midiman%2FMAudio&card=Delta+Audiophile+2496.&chip=ICE1712+%28Envy24%29&module=ice1712
> 
> I use this .asoundrc to be able to record from the S/PDIF input:
> 
> # Midiman Audiophile 2496
> pcm.ice1712 {
> type hw
> card 0
> }
> 
> ctl.ice1712 {
> type hw
> card 0
> }
> 
> # Plug device for 2 channel S/PDIF input
> pcm.ice_spdif {
> type plug
> ttable.0.8 1
> ttable.1.9 1
> slave.pcm {
> type hw
> card 0
> device 0
> }
> }
> 
> 
> Erik
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Mainboard report...

2005-01-12 Thread Brendan Burns

I've sucessfully installed debain amd64 on a Biostar K8VGA-M mother board. 
network works (via-rhine) as does sound (via82xx) haven't tried 
serial-ata...

Currently working on compiling the xserver for the onboard video 
(Unichrome/S3)

Thanks for your hard work!

--brendan burns


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "rock solid" motherboard

Hi Filippo,
I have GA-K8NSPro mobo, onboard sound is AC97 and works OK,LAN OK, USB
ok.
nv driver is OK but I don't run games so I haven't pushed it.
There was an issue with two of the SATA inputs not being detected by the
installer, if you connect the SATA drive/s to the inputs associated with
the sata_sil module you will be OK.
This may have been fixed now.
Norv

On Wed, 2005-01-12 at 10:11 +0100, Filippo Carone wrote:
>  Hi everybody,
>  I'm going to buy an AMD64 system and being a debian user I plan to
> install the AMD64 port. The main matter is about the mainboard. Reading
> this list and googling in general is not easy to understand if a
> mainboard is well supported or not. For example the ASUS K8V Deluxe is
> somewhere said to be linux "rock solid", while some messages in this
> list report problems with sound, acpi and random system reboots (which
> really scare me).
> Anyway the page: 
> 
>  https://alioth.debian.org/docman/view.php/30192/27/mainboards.html
> 
>  shows every field without "?", thus making me think the mainboard is
> fully supported.
> 
>  Almost the same applies for the nforce3 250-gb, in this list some say
> some say the network and audio are well supported, while a mainboard
> using this chipset, Gigabyte GA-K8N PRO shows a "?" in the sound
> column of the "supported hardware" page.
> 
>  I'm a bit puzzled, but I think this is because motherboards come with
> different BIOS versions and people have different experiences from the
> same hardware.
> 
>  The choices I have are:
> 
>  Gigabyte GA-K8NS
>  Chipset: NVIDIA nForce3 250 + ITE IT8712F
>  Audio: Realtek ALC850 Ac'97
>  Lan:   ICS 1883 10/100Tx RJ45 or Marvell 8001
> 
>  Gigabyte GA-K8NF-9
>  Chipset: NVIDIA nForce4 4X MCPs
>  Audio: Realtek ALC850 Ac'97
>  Lan:   CICADA8201 Gigabit
> 
>  Asus K8V-DELUXE
>  Chipset: VIA K8T800 + VT8237
>  Audio: ADI 1980
>  Lan:   3COM 3C940 Gb
> 
>  These are almost in the same price range, the first being the
> cheapest. Which one would you suggest? Are nvidia proprietary drivers
> working well?
>  
>   cheers
> 
> --
>  P E A C E
> 
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "rock solid" motherboard

2005-01-12 Thread doubletwist

Hank Barta wrote:
I have an ABIT AV8 (v1.1) The LAN driver did not load so I put in a
RealTek card and moved on. Sound on the motherboard works fine.
I do have RAM issues in that I have to run the RAM at DDR333 instead
of DDR400 (for which it is speced) and this board is known to be
sensitive to the quality of the RAM. (I think that means that not all
RAM will work at advertised rates. ;) But at DDR333 the system is rock
solid.
I have an Abit KV8-MAX3. I had a similar issue with the RAM. After doing 
some research I came up with the explaination for my issue. The Athlon 
64 [at least the version I have, 2800+] is designed only allow the 
DDR400 on a single ram slot. But if you have more than 1 stick of ram, 
you need to drop it down to DDR333. I don't know if newer boards have 
gotten around this limitation or what.
I was kind of bummed since if I had known that, I'd have just bought a 
single stick instead of the two smaller ones I have.

With that said, this system is rock solid at DDR333 with everything I've 
thrown at it, with the minor exception that the amd64 port of FreeBSD 
has some problems with the NIC. It works, but there are issues.

DT


--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.10 - Release Date: 1/10/2005
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

gcc-3.4/gcc-4.0 archive [Was: Re: amd64(gcc4): aptitude dumps core]

2005-01-12 Thread Kurt Roeckx

On Wed, Jan 12, 2005 at 11:44:33PM +0100, Harald Dunkel wrote:
> Peter Nelson wrote:
> |
> | The gcc-3.4 (well, I guess it's now 4.0 but still has the old name)
> | distrobution should be considered experimental.  If you just want
> | something that works use the pure64 version.
> 
> But the compiler used to build pure64 doesn't work for amd64.
> Thats why a lot of packages in pure64 have been built with
> gcc 3.4, too. The problem is: You never know.

No it's not.  There are maybe 10 packages build using gcc-3.4.
We have less problems using gcc-3.3 then gcc-3.4.  There are even
more packages available in the pure64 archive then in the gcc-3.4
archive.

Note that currently I will not even look at problems if you're
using the gcc-3.4 archive.  I also hope that people don't go and
file bugs when using the gcc-3.4 archive since it's very likely
not a problem with the package but with the compiler.

Has anyone even read the branch status of gcc-4.0?  It's at:
http://gcc.gnu.org/ml/gcc/2004-12/msg00958.html

To quote from it:
| I've spent the afternoon looking through Bugzilla.  My conclusion is
| that we're making progress (down to 169 regressions open against 4.0),
| but we've still got quite a ways to go.  There are a lot of
| optimization issues, and as usual, a lot of C++ issues.  We've got bug
| reports about bad code generation in the Linux kernel, a variety of
| other wrong-code issues, and a lot of issues about inferior code generation.

To me that looked rather scary.  And by the recent problems
reported here about it, I'd just don't touch gcc-4.0 at all until
it's atleast released.  The debian gcc maintainers have put it in
experimental, and that's where it belongs.  It shouldn't be used
to build unstable yet.

Kurt

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: amd64(gcc4): aptitude dumps core

2005-01-12 Thread Frederik Schueler

Hello,

On Wed, Jan 12, 2005 at 11:44:33PM +0100, Harald Dunkel wrote:
> But the compiler used to build pure64 doesn't work for amd64.

How does gcc-3.3 not work for amd64?

> Thats why a lot of packages in pure64 have been built with
> gcc 3.4, too. The problem is: You never know.

Pure64 tracks unstable as close as possible, the number of patched 
packages is around 37, most of them where uploaded in june during
the initial porting efford. 

5 where uploaded during the last 4 months, 2 java packages and
modconf, libc6 and basefiles (the /lib64 symlink transition).

what is compiled with gcc-3.4 has the blessing of the corresponding 
maintainers. Currently, the mozilla-* family is built with gcc-3.4, 
and the kernel images are. 

Everything else is compiled with the default compiler for unstable, 
wich still is gcc-3.3.

Kind regards
Frederik Schueler

-- 
ENOSIG

pgpaGCocRx8Xt.pgp
Description: PGP signature

Re: Problem with /lib64 in libc6 2.3.2.ds1-20.0.0.1.gcc4

2005-01-12 Thread Frederik Schueler

Hello,

On Wed, Jan 12, 2005 at 10:14:25PM +0100, Stephan Seitz wrote:
> or insert
> "--force-overwrite" into /etc/dpkg/dpkg.cfg.

Don't do this. You will forget about it, things _will_ break and you will
search for the cause days over days until you remember. 

The --force-overwrite switch should only be used as last resort, and not
to "fix" a temporary bug.

Kind regards
Frederik Schueler

-- 
ENOSIG

pgpJBC7MEjFb8.pgp
Description: PGP signature

Re: "rock solid" motherboard

*** Regarding Re: "rock solid" motherboard; [EMAIL PROTECTED] adds:

seb> The kernel reports : 
seb> NFORCE3-250: IDE controller at PCI slot :00:08.0
seb> NFORCE3-250: chipset revision 162
seb> NFORCE3-250: not 100% native mode: will probe irqs later
seb> NFORCE3-250: BIOS didn't set cable bits correctly. Enabling workaround.

In my logs I have:

  NFORCE3-250: IDE controller at PCI slot :00:08.0
  NFORCE3-250: chipset revision 162
  NFORCE3-250: not 100%% native mode: will probe irqs later
  NFORCE3-250: :00:08.0 (rev a2) UDMA133 controller

The difference seems to be the message about the BIOS and the cable
bits.

seb> Judgind by the description, I can hope that a future BIOS will
seb> correct this problem.

Right.

Per

-- 
Per Bojsen  <[EMAIL PROTECTED]>
7 Francis Road
Billerica, MA 01821-3618
USA


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation disks should be using 2.6.10 kernel

*** Regarding Re: Installation disks should be using 2.6.10 kernel;
[EMAIL PROTECTED] adds:

seb> This one is easy.  In the modprobe.conf put the following line:

seb> alias eth0 forcedeth alias eth1 eth1394 alias eth2 eth1394

Thanks for the tip,
Per

-- 
Per Bojsen  <[EMAIL PROTECTED]>
7 Francis Road
Billerica, MA 01821-3618
USA


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: amd64(gcc4): aptitude dumps core

2005-01-12 Thread Harald Dunkel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Nelson wrote:
|
| The gcc-3.4 (well, I guess it's now 4.0 but still has the old name)
| distrobution should be considered experimental.  If you just want
| something that works use the pure64 version.
But the compiler used to build pure64 doesn't work for amd64.
Thats why a lot of packages in pure64 have been built with
gcc 3.4, too. The problem is: You never know.
Thats why I had selected amd64(gcc-3.4): All packages were
built with gcc 3.4.x. And now this gets corrupted by sneaking
in the experimental gcc 4.0 compiler. This is _really_ ugly.
Regards
Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB5ahRUTlbRTxpHjcRAlpRAJ9cRn9j6CJH3q8lUPAQfrbkfytzbQCdGFwb
bdmwBv2RrppIr/ai//ggxOs=
=64QZ
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: amd64 / x86-64 as i386? [Going OT]

2005-01-12 Thread Ernest jw ter Kuile

On Wednesday 12 January 2005 22:26, Didde Brockman wrote:
> Thanks for all your answers. It's good to hear that I won't be
> "limited" to a specific port.
>
> Just one more question; is this particular CPU not used to its fullest
> extent while running the i386 port? What I mean is to ask if the Athlon
> 64's are good 32-bit processors or if I'd be utilizing it poorly not
> running the amd64 port. Perhaps a dumb question, but I hope you get my
> point.

Yes and no.

Yes, because obviously the x86-64 extentions add quite a bit to the old x86 
arch which you will miss out. For the normal user, the 64bit extentions 
themselfs are actually not the most important part of this cpu. These you 
will in fact  rarely need.  But, you will miss out the extra registers which 
the traditional x86 arch badly misses.

But No, because this cpu adds an onboard memory controler which is just as 
active when running in x86 mode, As will Hypertransport. These other 
extentions make this cpu just as worth while when running in 32 bits mode.

Don't worry, the amd64 will run your 386 soft at least as fast but usually  
faster than  it would be running on a AMD XP with same clock speed.

>
> Thanks again for your help. People on the Debian mailinglists are
> probably the most helpful ones around  =)

Getting slimy there ;o) 

Ernest.

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: amd64(gcc4): aptitude dumps core

2005-01-12 Thread Peter Nelson

Harald Dunkel wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Harald Dunkel wrote:
| Hi folks,
|
| Since the most recent upgrade of apt (0.5.27.2.0.0.1.gcc4)
| aptitude dies with a core dump immediately.
|
PS: Going back to the old version built with gcc 3.4 (AFAIK)
fixes the problem.
Folks, I need my PC. amd64(gcc-3.4) is on Unstable, but not
Experimental. Don't use an experimental compiler, please.
The gcc-3.4 (well, I guess it's now 4.0 but still has the old name) 
distrobution should be considered experimental.  If you just want 
something that works use the pure64 version.

-Peter
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "rock solid" motherboard

On Wed, Jan 12, 2005 at 04:50:32PM -0500, Per Bojsen wrote:
> *** Regarding Re: "rock solid" motherboard; [EMAIL PROTECTED] adds:
> I have an Iwill DK8N motherboard which is also nForc3 250 based.  I'm
> running a 2.6.9 kernel and have no problems with SATA disks on the
> nForce3 SATA interface.  The install image had an 2.6.8 kernel and
> worked fine as well.  I am wondering if your problem is specific to
> the disk you are using?  I have 2 WD2500JD drives.
> 
This problem occurs on certain hardware. The symptoms are :
the chipset is recognized and the disk too, but the probe of the disk
fails with timeout (you have to wait 30 seconds at each drive connected
to the nforce3).

The kernel reports :
NFORCE3-250: IDE controller at PCI slot :00:08.0
NFORCE3-250: chipset revision 162
NFORCE3-250: not 100% native mode: will probe irqs later
NFORCE3-250: BIOS didn't set cable bits correctly. Enabling workaround.

Judgind by the description, I can hope that a future BIOS will correct
this problem.

The drive attached is a  Maxtor 6B200M0.

Seb

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation disks should be using 2.6.10 kernel

On Wed, Jan 12, 2005 at 04:46:12PM -0500, Per Bojsen wrote:
> *** Regarding Installation disks should be using 2.6.10 kernel;
> [EMAIL PROTECTED] adds:
> 
[snip]
> 
> Later, once the system was installed I still had the issue with the
> firewire ports being detected before the Ethernet port and DHCP always
> running on eth0.  I could change that to eth2 but next thing I new the
> interfaces got detected in a different order and eth0 was now the
> Ethernet port.  This probably changed as a result to upgrading
> packages or possibly when switching kernel versions.  I am not really
> sure.  I ended up disabling the eth1394 module in the kernel
> configuration so that I now only have eth0 and it is always the
> Ethernet port.  This was the easiest workaround for me as I have no
> 1394 network and do not plan to have one.
> 
> However, out of curiosity, I'd still like to know how to set things up
> so that eth0 is always the Ethernet port and eth1/eth2 are always the
> Ethernet over firewire ports.

This one is easy.
In the modprobe.conf put the following line:

alias eth0 forcedeth
alias eth1 eth1394
alias eth2 eth1394

It will prevent the firewire from taking the eth0 and force the nforce
driver to be at the eth0.

Hopes this helps.

Seb


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dhel_parse segfaults

*** Regarding Re: dhel_parse segfaults; Andreas Jochens <[EMAIL PROTECTED]> 
adds:

Andreas> I just uploaded a fixed version of dhelp compiled with
Andreas> gcc-4.0 and -O0 to the gcc-3.4 archive.

I just installed it and it works!  Thanks.

Andreas> Thank you for your help!

Thanks for the quick response!

Per

-- 
Per Bojsen  <[EMAIL PROTECTED]>
7 Francis Road
Billerica, MA 01821-3618
USA


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: amd64(gcc4): aptitude dumps core

2005-01-12 Thread Harald Dunkel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Harald Dunkel wrote:
| Hi folks,
|
| Since the most recent upgrade of apt (0.5.27.2.0.0.1.gcc4)
| aptitude dies with a core dump immediately.
|
PS: Going back to the old version built with gcc 3.4 (AFAIK)
fixes the problem.
Folks, I need my PC. amd64(gcc-3.4) is on Unstable, but not
Experimental. Don't use an experimental compiler, please.
Many thanx
Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB5Zv8UTlbRTxpHjcRAqXoAJ0WmD+iCuya3dXTisaZeht3Lqr/vQCaAxhn
EHdPhXRgZ3rlbJ8HzlIuzQY=
=NyGb
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "rock solid" motherboard

*** Regarding Re: "rock solid" motherboard; [EMAIL PROTECTED] adds:

seb> According to Tom's Hardware, the nForce3 250gb kicks ass of the
seb> VIA chipset. If you want some extra bits of performance.  None of
seb> the nforce3 component of my K8N-E is unsupported. My only concern
seb> is a bug in 2.6.[789] kernel wich prevent SATA disks from beeing
seb> used if they are connected to the nforce sata ports.

I have an Iwill DK8N motherboard which is also nForc3 250 based.  I'm
running a 2.6.9 kernel and have no problems with SATA disks on the
nForce3 SATA interface.  The install image had an 2.6.8 kernel and
worked fine as well.  I am wondering if your problem is specific to
the disk you are using?  I have 2 WD2500JD drives.

Per

-- 
Per Bojsen  <[EMAIL PROTECTED]>
7 Francis Road
Billerica, MA 01821-3618
USA


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation disks should be using 2.6.10 kernel

*** Regarding Installation disks should be using 2.6.10 kernel;
[EMAIL PROTECTED] adds:

seb> Second problem, the netboot installer detected first the firewire
seb> port and then the forcedeth (eth1). And then tried get an adress
seb> on the DHCP port. I had to remove the modules and insert both of
seb> them in the correct order (first forcedeth, last ohci1394).  Of
seb> course this has nothing to do with the amd64, it is more a bug
seb> from debian-installer.

I have an Iwill DK8N board (nForce 3 250 based) and experienced
something very similar.  I installed the gcc-3.4 distribution back in
mid-November.  Actually, I think the boot CD didn't see the Ethernet
port so I had to manually insert the forcedeth module.  I have two
firewire ports (one on the motherboard, one on the sound card) so I
ended up with eth0, eth1, eth2. I think I had to remove the eth1394
module to get rid of the firewire Ethernet ports and then insert
forcedeth.

Later, once the system was installed I still had the issue with the
firewire ports being detected before the Ethernet port and DHCP always
running on eth0.  I could change that to eth2 but next thing I new the
interfaces got detected in a different order and eth0 was now the
Ethernet port.  This probably changed as a result to upgrading
packages or possibly when switching kernel versions.  I am not really
sure.  I ended up disabling the eth1394 module in the kernel
configuration so that I now only have eth0 and it is always the
Ethernet port.  This was the easiest workaround for me as I have no
1394 network and do not plan to have one.

However, out of curiosity, I'd still like to know how to set things up
so that eth0 is always the Ethernet port and eth1/eth2 are always the
Ethernet over firewire ports.

Per

-- 
Per Bojsen  <[EMAIL PROTECTED]>
7 Francis Road
Billerica, MA 01821-3618
USA


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

amd64(gcc4): aptitude dumps core

2005-01-12 Thread Harald Dunkel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi folks,
Since the most recent upgrade of apt (0.5.27.2.0.0.1.gcc4)
aptitude dies with a core dump immediately.
Can anybody reproduce this?
Regards
Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB5ZoBUTlbRTxpHjcRAiy+AJ9NWG8ZHpQF5ApkcNTKWhbgZD9EgwCeI+Hg
broqYme2ZhP8Mx1HWTHVFAM=
=nMVQ
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: amd64 / x86-64 as i386? [Going OT]

2005-01-12 Thread Didde Brockman

Thanks for all your answers. It's good to hear that I won't be "limited" to a specific port.

Just one more question; is this particular CPU not used to its fullest extent while running the i386 port? What I mean is to ask if the Athlon 64's are good 32-bit processors or if I'd be utilizing it poorly not running the amd64 port. Perhaps a dumb question, but I hope you get my point.

Thanks again for your help. People on the Debian mailinglists are probably the most helpful ones around =)

//d.

On 12 jan 2005, at 22.01, Alex Perry wrote:

The machine I'm typing at is an Athlon64 3000+ running standard Debian/Testing/i386. It has no special modifications ... other than a custom compiled kernel to handle our specific engineering needs for USB drivers. It is rock solid (as are the other half dozen we have around here).

The purpose of this list is to discuss the 64 bit build of Debian for Unstable and Testing. For me, the 64 bit Debian/Unstable/amd64 has been just as reliable as the Debian/Unstable/i386 but your mileage may vary of course. We use the 32 bit and 64 bit versions depending on the needs of the specific situation. The combination of dual boot, plus biarch kernels and chroots, means we can easily switch or mix-and-match as needed.

Didde Brockman wrote:

Hey all!

Sorry about me coming with this stuped question, but I have browsed the documentation for the amd64 port but did not find a complete answer. I will be ordering a new system in couple of days time and through a local reseller I got a _really_ good offer on an AMD Athlon 64 2800+ CPU. Almost too good to resist...

Anyway, I want to run Debian (testing or unstable) on the final machine and I did not not even come to think of the fact that the CPU has a 64-bit architecture until now! So, is it possible to run the i386 "version" of testing or unstable on this particular CPU or will I be limited to the amd64 port?

I googled on the matter and all I found was some outdated posts about Athlon 64's segfaulting on basically everything... Is this still the case?

Does anyone have any experience on running Debian on this CPU? I'd _really_ appreciate any pointers. Again, sorry about the level of this question =)

Re: dhel_parse segfaults

On 05-Jan-12 16:10, Per Bojsen wrote:
> This appears to be a gcc 4.0 problem.  If I compile the dhelp package
> with gcc 3.4 it does not segfault both with and without the -O2
> option.  If I compile with gcc 4.0 it segfaults *with* -O2 but works
> fine with -O1 and -O0.  The segfault occurs when the html_w_head()
> function returns.

I just uploaded a fixed version of dhelp compiled with gcc-4.0 and -O0 
to the gcc-3.4 archive.

Thank you for your help!

Regards
Andreas Jochens


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "rock solid" motherboard

On Wed, 2005-01-12 at 15:48 -0500, David Wood wrote:
> On Wed, 12 Jan 2005, Ron Johnson wrote:
> 
> >> Another note would be that if you plan on using SATA, make sure you stay
> >> current with kernels (even despite this not being an nvidia board), and if
> >> you plan on trying a SATA RAID, you will not be able to dual boot with it
> >
> > What about installing to a SATA JBOD?  Will that work fine?
> 
> Yes, definitely.

Thanks.  Too bad I'm now lusting over a Mac Mini...

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

"Peace is that brief glorious moment in history when everybody
stands around reloading."
Unknown



signature.asc
Description: This is a digitally signed message part

Re: Problem with /lib64 in libc6 2.3.2.ds1-20.0.0.1.gcc4

2005-01-12 Thread Stephan Seitz

On Wed, Jan 12, 2005 at 04:06:50PM -0500, Per Bojsen wrote:
At least a warning on the list about what to do when this occurs would
be nice.  Apologies if I missed it.
Use "dpkg --force-overwrite" to install the package or insert
"--force-overwrite" into /etc/dpkg/dpkg.cfg.
Shade and sweet water!
Stephan
--
| Stephan SeitzE-Mail: [EMAIL PROTECTED] |
|  WWW: http://fsing.rootsland.net/~stse/|
| PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |


signature.asc
Description: Digital signature

Re: dhel_parse segfaults

*** Regarding Re: dhel_parse segfaults; Andreas Jochens <[EMAIL PROTECTED]>
adds:

Andreas> If you could provide a hint or a patch to fix this, I would
Andreas> of course apply it and upload a fixed version to the gcc-3.4
Andreas> archive soon.

This appears to be a gcc 4.0 problem.  If I compile the dhelp package
with gcc 3.4 it does not segfault both with and without the -O2
option.  If I compile with gcc 4.0 it segfaults *with* -O2 but works
fine with -O1 and -O0.  The segfault occurs when the html_w_head()
function returns.

I have no patch, just the above analysis.

Thanks,
Per

-- 
Per Bojsen  <[EMAIL PROTECTED]>
7 Francis Road
Billerica, MA 01821-3618
USA


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Problem with /lib64 in libc6 2.3.2.ds1-20.0.0.1.gcc4

*** Regarding Re: Problem with /lib64 in libc6
2.3.2.ds1-20.0.0.1.gcc4; Andreas Jochens <[EMAIL PROTECTED]> adds:

Andreas> It was located in base-files for a long time, but this has
Andreas> been changed lately to libc6. A patched version of base-files
Andreas> with /lib64 had been used, but since version 2.3.2.ds1-20 of
Andreas> the glibc package it finally has been moved to libc6, where
Andreas> it really should be.

Ok, so this is a transient problem.  I see now that the new base-files
package no longer has /lib64 in it.  Thanks for clarifying this.

Andreas> Depending on the order in which the packages are upgraded,
Andreas> some problems like this one may occur. Unfortunately I do not
Andreas> know a perfect way to avoid this.

At least a warning on the list about what to do when this occurs would
be nice.  Apologies if I missed it.

Thanks,
Per

-- 
Per Bojsen  <[EMAIL PROTECTED]>
7 Francis Road
Billerica, MA 01821-3618
USA


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: amd64 / x86-64 as i386?

2005-01-12 Thread Alex Perry

The machine I'm typing at is an Athlon64 3000+ running standard 
Debian/Testing/i386.  It has no special modifications ... other than a 
custom compiled kernel to handle our specific engineering needs for USB 
drivers.  It is rock solid (as are the other half dozen we have around 
here).

The purpose of this list is to discuss the 64 bit build of Debian for 
Unstable and Testing.  For me, the 64 bit Debian/Unstable/amd64 has been 
just as reliable as the Debian/Unstable/i386 but your mileage may vary 
of course.  We use the 32 bit and 64 bit versions depending on the needs 
of the specific situation.  The combination of dual boot, plus biarch 
kernels and chroots, means we can easily switch or mix-and-match as needed.

Didde Brockman wrote:
Hey all!
Sorry about me coming with this stuped question, but I have browsed the 
documentation for the amd64 port but did not find a complete answer. I 
will be ordering a new system in couple of days time and through a 
local reseller I got a _really_ good offer on an AMD Athlon 64 2800+ 
CPU. Almost too good to resist...

Anyway, I want to run Debian (testing or unstable) on the final machine 
and I did not not even come to think of the fact that the CPU has a 
64-bit architecture until now! So, is it possible to run the i386 
"version" of testing or unstable on this particular CPU or will I be 
limited to the amd64 port?

I googled on the matter and all I found was some outdated posts about 
Athlon 64's segfaulting on basically everything... Is this still the 
case?

Does anyone have any experience on running Debian on this CPU? I'd 
_really_ appreciate any pointers. Again, sorry about the level of this 
question  =)

//d.
 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "rock solid" motherboard

2005-01-12 Thread David Wood

On Wed, 12 Jan 2005, Ron Johnson wrote:
Another note would be that if you plan on using SATA, make sure you stay
current with kernels (even despite this not being an nvidia board), and if
you plan on trying a SATA RAID, you will not be able to dual boot with it
What about installing to a SATA JBOD?  Will that work fine?
Yes, definitely.
When you install the disks, they default to JBOD. If you do not configure 
the disks for RAID, then Linux and Windows (using the vendor-provided 
drivers) are perfectly comfortable "interoperating" on them, and 
furthermore you can use LVM2 or Linux md RAID without interfering with 
Windows (obviously). The only problem is that there is no equivalent 
feature in Windows, at least as far as I know, so you will end up with 
Windows running from one of the disks or the other (or, more to the point, 
split equally across both, as C: and D:).

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dhel_parse segfaults

On 05-Jan-12 15:30, Per Bojsen wrote:
> Hi,
> 
> I'm using the gcc-3.4 distribution and did a large upgrade yesterday.
> The postinst step of the dhelp 0.5.19.0.0.1.gcc4 failed with a
> segmentation fault in dhelp_parse.  Many other packages that use
> dhelp_parse had warnings about dhelp_parse failing presumably due to
> segfaults as well.
> 
> Has anyone seen that?  I can do some debugging if this has not been
> fixed already.  Let me know.

Thank you for the report. I do not think that there is a fix already.

If you could provide a hint or a patch to fix this, I would of course
apply it and upload a fixed version to the gcc-3.4 archive soon.

Regards
Andreas Jochens


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Problem with /lib64 in libc6 2.3.2.ds1-20.0.0.1.gcc4

On 05-Jan-12 15:26, Per Bojsen wrote:
> Is /lib64 supposed to be in the libc6 or base-files package?

It was located in base-files for a long time, but this has been 
changed lately to libc6. A patched version of base-files with /lib64 
had been used, but since version 2.3.2.ds1-20 of the glibc package 
it finally has been moved to libc6, where it really should be.

> Has anyone else seen this?

> I worked around it by manually installing the libc6 package with dpkg
> and using the --force-overwrite option and then continuing with
> `apt-get dist-upgrade'.

Depending on the order in which the packages are upgraded, some problems
like this one may occur. Unfortunately I do not know a perfect way to 
avoid this.

Regards
Andreas Jochens

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

dhel_parse segfaults

Hi,

I'm using the gcc-3.4 distribution and did a large upgrade yesterday.
The postinst step of the dhelp 0.5.19.0.0.1.gcc4 failed with a
segmentation fault in dhelp_parse.  Many other packages that use
dhelp_parse had warnings about dhelp_parse failing presumably due to
segfaults as well.

Has anyone seen that?  I can do some debugging if this has not been
fixed already.  Let me know.

Thanks,
Per

-- 
Per Bojsen  <[EMAIL PROTECTED]>
7 Francis Road
Billerica, MA 01821-3618
USA


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: amd64 / x86-64 as i386?

2005-01-12 Thread Martin Wodrich

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Didde Brockman schrieb:
|So, is it possible to run the i386 "version" of testing or unstable
|on this particular CPU or will I be limited to the amd64 port?
Yes, you can run the i386-Port on a AMD64-CPU. This CPU-Type can run
every i386 OS.
- --
Mit freundlichen Grüssen,
Martin Wodrich
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB5Yh5fymBmdFa7LcRAve/AJ4wZceQIONcsYdFUfJU66HI97pS+ACeLkbo
H1YnnnplVzSTns/nDqHqKR0=
=DhiC
-END PGP SIGNATURE-

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "rock solid" motherboard

On Wed, 2005-01-12 at 14:15 -0500, David Wood wrote:
> On Wed, 12 Jan 2005, Hank Barta wrote:
> 
[snip]
> Another note would be that if you plan on using SATA, make sure you stay 
> current with kernels (even despite this not being an nvidia board), and if 
> you plan on trying a SATA RAID, you will not be able to dual boot with it 

What about installing to a SATA JBOD?  Will that work fine?

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

"Not peace at any price! Chains are worse than bayonets."
Douglas William Jerrold



signature.asc
Description: This is a digitally signed message part

Problem with /lib64 in libc6 2.3.2.ds1-20.0.0.1.gcc4

Hi,

I upgraded the base-files and libc6 packages (among a large number of
other packages) yesterday to the following versions:

  libc6   2.3.2.ds1-20.0.0.1.gcc4
  base-files  3.1.2.0.0.2.gcc4

However, I got the following error for libc6:

  dpkg: error processing 
/var/cache/apt/archives/libc6_2.3.2.ds1-20.0.0.1.gcc4_amd64.deb (--unpack):
   trying to overwrite `/lib64', which is also in package base-files

Is /lib64 supposed to be in the libc6 or base-files package?

Has anyone else seen this?

I worked around it by manually installing the libc6 package with dpkg
and using the --force-overwrite option and then continuing with
`apt-get dist-upgrade'.

Thanks,
Per

-- 
Per Bojsen  <[EMAIL PROTECTED]>
7 Francis Road
Billerica, MA 01821-3618
USA


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: amd64 / x86-64 as i386?

2005-01-12 Thread David Wood

As the list archives will show, the unofficial debian pure64 port does 
work and is in use by many people, although it is not perfect.

You can run the i386 version if you like.
On Wed, 12 Jan 2005, Didde Brockman wrote:
Hey all!
Sorry about me coming with this stuped question, but I have browsed the 
documentation for the amd64 port but did not find a complete answer. I will 
be ordering a new system in couple of days time and through a local reseller 
I got a _really_ good offer on an AMD Athlon 64 2800+ CPU. Almost too good to 
resist...

Anyway, I want to run Debian (testing or unstable) on the final machine and I 
did not not even come to think of the fact that the CPU has a 64-bit 
architecture until now! So, is it possible to run the i386 "version" of 
testing or unstable on this particular CPU or will I be limited to the amd64 
port?

I googled on the matter and all I found was some outdated posts about Athlon 
64's segfaulting on basically everything... Is this still the case?

Does anyone have any experience on running Debian on this CPU? I'd _really_ 
appreciate any pointers. Again, sorry about the level of this question  =)

//d.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

amd64 / x86-64 as i386?

2005-01-12 Thread Didde Brockman

Hey all!
Sorry about me coming with this stuped question, but I have browsed the 
documentation for the amd64 port but did not find a complete answer. I 
will be ordering a new system in couple of days time and through a 
local reseller I got a _really_ good offer on an AMD Athlon 64 2800+ 
CPU. Almost too good to resist...

Anyway, I want to run Debian (testing or unstable) on the final machine 
and I did not not even come to think of the fact that the CPU has a 
64-bit architecture until now! So, is it possible to run the i386 
"version" of testing or unstable on this particular CPU or will I be 
limited to the amd64 port?

I googled on the matter and all I found was some outdated posts about 
Athlon 64's segfaulting on basically everything... Is this still the 
case?

Does anyone have any experience on running Debian on this CPU? I'd 
_really_ appreciate any pointers. Again, sorry about the level of this 
question  =)

//d.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "rock solid" motherboard

2005-01-12 Thread David Wood

On Wed, 12 Jan 2005, Hank Barta wrote:
I have an ABIT AV8 (v1.1) The LAN driver did not load so I put in a
RealTek card and moved on. Sound on the motherboard works fine.
I do have RAM issues in that I have to run the RAM at DDR333 instead
of DDR400 (for which it is speced) and this board is known to be
sensitive to the quality of the RAM. (I think that means that not all
RAM will work at advertised rates. ;) But at DDR333 the system is rock
solid.
(I should probably disclaim that I'm currently running Ubuntu, but
under the covers it sure looks like Debian.)
I could say this is another "vote" for the Via chipset; I have an Asus K8V 
Deluxe. However, the road has not been entirely smooth.

For one, I had exactly the same problem with instability and RAM speed 
that my colleague describes here. I figured Asus and Kingston were two 
brands big enough to work out their issues with each other, but it took 
something like 4 rounds of RMA replacement with Kingston to get a stable 
system operating at rated (DDR400) speeds. That was a raving nightmare. My 
strong advice would be to "buy the expensive RAM" if you are building 
yourself (Corsair, Mushkin).

Another note would be that if you plan on using SATA, make sure you stay 
current with kernels (even despite this not being an nvidia board), and if 
you plan on trying a SATA RAID, you will not be able to dual boot with it 
the way you expect. This is because the Via SATA RAID drivers are software 
RAID implemented in a Win32 driver. There is a binary only Linux module of 
same. Don't use it. I ended up doing an LVM2 Linux RAID with Win32 
installed non-RAID on a single partition on one of the disks.

Another note: I had to do this LVM raid setup by hand; at the time I tried 
it, the amd64 debian installer couldn't get through an LVM raid install 
without crashing. Root raid was even harder, requiring a hand-assembled 
init RAM disk. Don't know if there has been much movement in the installer 
since.

All that said, the board does work very well now that I have it going 
(100% stable), and it is indeed fast. Fully functional USB, quite good 
audio quality, SATA, IDE, AGP, Serial/Parallel, ethernet (at 100Mb only 
for me), on board sensors, etc.  Did not try the packaged Wifi hardware.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "rock solid" motherboard

2005-01-12 Thread Hank Barta

On Wed, 12 Jan 2005 15:04:40 +0200, Kyuu Eturautti <[EMAIL PROTECTED]> wrote:
> 
> My best experiences by far have been with Abit KV8-Pro and AV8 boards,
> both with K8T800 Pro chipsets. I have not used audio in a single
> AMD64+Linux system though, but as for stability, quality and hardware
> compatibility (except for audio, not tested) with Debian Pure64, I
> haven't had any problems.  As for onboard LAN, the via-velocity has
> performed quite well. Via kindly provides sources that work with older
> kernel versions too, as I believe the driver came with the kernel only
> starting from 2.6.9.

I have an ABIT AV8 (v1.1) The LAN driver did not load so I put in a
RealTek card and moved on. Sound on the motherboard works fine.

I do have RAM issues in that I have to run the RAM at DDR333 instead
of DDR400 (for which it is speced) and this board is known to be
sensitive to the quality of the RAM. (I think that means that not all
RAM will work at advertised rates. ;) But at DDR333 the system is rock
solid.

(I should probably disclaim that I'm currently running Ubuntu, but
under the covers it sure looks like Debian.)

-- 
Beautiful Sunny Winfield

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation disks should be using 2.6.10 kernel

2005-01-12 Thread Fabien Meghazi

> you can install a debian install onto a different partition (quite
> easily). setup another partition to be the root of your debian install.
> mount it onto your ubuntu system somewhere, then follow the faq alioth:
> https://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id274055.

Excellent, that's exactly what I need. Thanks for this information ,
I'll try this today.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation disks should be using 2.6.10 kernel

2005-01-12 Thread Nick Hemsley

Fabien Meghazi wrote:
I was the happy owner of a K8N-E with an Athlon 64.
I went crazy to upgrade the debian I had from my previous installation
to the current one.
   

Well I've got exactly the same problem with the same motherboard.
First I saw that the kernel on the install CD didn't recognized my onboard
gigabit network adapter, so I put a ne2000 pci card in my computer and
tried again, then it was unable to use my SATA drive so I gave up.
Debian sarge i386 won't be instalable on my computer neither.
So I tryed Ubuntu and it installed imediatly without problem but ubuntu
is gnome oriented and their kde packages sucks, so I wonder if it's possible
to "convert" an ubuntu installation to an amd64-sid ? (sounds weird but perhaps
there's a way) Of course, the best would be to include 2.6.10 in the amd64-sid
install CD.
 

you can install a debian install onto a different partition (quite 
easily). setup another partition to be the root of your debian install. 
mount it onto your ubuntu system somewhere, then follow the faq alioth: 
https://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id274055. 
I am not sure exactly where you would get cdebootstrap from (ubuntu is 
debian based, so perhaps it would have it?), perhaps just try and 
install it from a .deb downloaded from a debian archive.

Hope it helps.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation disks should be using 2.6.10 kernel

On Wed, Jan 12, 2005 at 10:13:50AM -0500, Stephen Frost wrote:

> execve("/sbin/grub", ["grub", "--batch", 
> "--device-map=/boot/grub/device.map"], [/* 39 vars */]) = 0
> uname({sys="Linux", node="elros", ...}) = 0
> brk(0)  = 0x80dc000
> brk(0x80fd000)  = 0x80fd000
> sync()  = 0
> old_mmap(0x401000, 14602067, 
> PROT_READ|PROT_WRITE|PROT_EXEC|PROT_SEM|PROT_GROWSDOWN|PROT_GROWSUP|0xfcf0,
>  0xa /* MAP_??? */, 4095, 0x80dc340080dac5c) = 0x5000
> open("/boot/grub/device.map", O_RDONLY|0x8000) = 3
> fstat64(0x3, 0xc07c)= 0
> old_mmap(0x1000, 14602067, 
> PROT_READ|PROT_WRITE|PROT_EXEC|PROT_SEM|PROT_GROWSDOWN|PROT_GROWSUP|0xfcf0,
>  MAP_SHARED|MAP_DENYWRITE, 0, 0x181a4) = 0x55956000
> read(3, "(hd0)\t/dev/sda\n(hd1)\t/dev/sdb\n", 4096) = 30
> read(3, "", 4096)   = 0
> close(3)= 0
> munmap(0x55956000, 4096)= 0
> sync()  = 0
> open("/dev/sda", O_RDWR|0x8000) = 3
> read(3, "\353H\220\20\216\320\274\0\260\270\0\0\216\330\216\300"..., 512) = 
> 512
> ioctl(3, 0x301, 0x555bcc98) = 0
> ioctl(3, BLKGETSIZE, 0x555bcc94)= 0
> ioctl(3, BLKFLSBUF, 0)  = 0
> open("/dev/sdb", O_RDWR|0x8000) = -1 ENXIO (No such device or address)
> fstat64(0x1, 0x555bcdb4)= 0
> old_mmap(0x1000, 14602067, 
> PROT_READ|PROT_WRITE|PROT_EXEC|PROT_SEM|PROT_GROWSDOWN|PROT_GROWSUP|0xfcf0,
>  0x3 /* MAP_??? 
> */|MAP_NORESERVE|MAP_POPULATE|MAP_GROWSDOWN|MAP_DENYWRITE|MAP_EXECUTABLE|MAP_LOCKED|0x400,
>  1442545993, 0x181a4) = 0x55956000
> fstat64(0, 0x555bcd94)  = 0
> old_mmap(0x1000, 14602067, 
> PROT_READ|PROT_WRITE|PROT_EXEC|PROT_SEM|PROT_GROWSDOWN|PROT_GROWSUP|0xfcf0,
>  0x3 /* MAP_??? 
> */|MAP_NORESERVE|MAP_POPULATE|MAP_GROWSDOWN|MAP_DENYWRITE|MAP_EXECUTABLE|MAP_LOCKED|0x400,
>  135059904, 0x181a4) = 0x55957000
> read(0, "root (hd0,0)\nsetup --stage2=/boo"..., 4096) = 77
> ioctl(3, BLKFLSBUF, 0)  = 0
> _llseek(3, 0, 0, 0x555bcab4 /* SEEK_??? */) = 0
> read(3, "\353H\220\20\216\320\274\0\260\270\0\0\216\330\216\300"..., 512) = 
> 512
> read(3, "RV\276\3!\350*\1^\277\370!f\213-\203}\4\0\17\204\312\0"..., 31744) = 
> 31744
> _llseek(3, 32256, ptrace: umoven: Input/output error
> 0x7e00, 0x555bcda4 /* SEEK_??? */) = 0
> read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32256) = 
> 32256
[snip]

Sorry, but nothing obvious is showing up from the strace.
Next step, is to compare .config files from 2.6.9 and 2.6.10.
To check the difference between the two kernels.
You can report to the LKML too.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation disks should be using 2.6.10 kernel

On Wed, Jan 12, 2005 at 04:36:34PM +0100, Fabien Meghazi wrote:
> > Just to be precise : I downloaded the amd64-sarge-cd1, and the netboot-sid.
> > 
> > Both discovered the gigabit ethernet correctly. But they found the
> > firewire interface before and gave the eth0 interface to it.
> > Then it did DHCP requests on the firewire instead of the ethernet.
> > To me, the sarge did discover your gigabit interface but didn't dhcp on
> > it.
> 
> Ok thanks, that's good news for my ehternet adapter, anyway I'm force
> to wait for a 2.6.10 install in order to install it on my SATA drive
> that is not recognized. (I guess you have the same problem)
> 
I did the install on the PATA driver where the 32bit sid was installed.
there was some PE left in the Volume group to install it.
So I created LV root64, usr64, var64 and installed a gcc-3.4 on it.
This saved my life because for the final install (the lilo execution), I
had to use the one from my 32bit to make it work.

Seb


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation disks should be using 2.6.10 kernel

2005-01-12 Thread Fabien Meghazi

> Just to be precise : I downloaded the amd64-sarge-cd1, and the netboot-sid.
> 
> Both discovered the gigabit ethernet correctly. But they found the
> firewire interface before and gave the eth0 interface to it.
> Then it did DHCP requests on the firewire instead of the ethernet.
> To me, the sarge did discover your gigabit interface but didn't dhcp on
> it.

Ok thanks, that's good news for my ehternet adapter, anyway I'm force
to wait for a 2.6.10 install in order to install it on my SATA drive
that is not recognized. (I guess you have the same problem)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation disks should be using 2.6.10 kernel

2005-01-12 Thread Stephen Frost

* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> You're welcome. Can you strace the grub process and see what's wrong
> with it ?
> For my installation, grub is pretty useless since I'm full LVM/DM.

Not sure how useful this is, but...

From dmesg:
grub[15266]: segfault at 555bcb30 rip 555bcb30 rsp 
555bc9fc error 15

Attached is the strace output, I didn't see anything obvious in it.

Thanks,

Stephen
execve("/sbin/grub", ["grub", "--batch", "--device-map=/boot/grub/device.map"], 
[/* 39 vars */]) = 0
uname({sys="Linux", node="elros", ...}) = 0
brk(0)  = 0x80dc000
brk(0x80fd000)  = 0x80fd000
sync()  = 0
old_mmap(0x401000, 14602067, 
PROT_READ|PROT_WRITE|PROT_EXEC|PROT_SEM|PROT_GROWSDOWN|PROT_GROWSUP|0xfcf0, 
0xa /* MAP_??? */, 4095, 0x80dc340080dac5c) = 0x5000
open("/boot/grub/device.map", O_RDONLY|0x8000) = 3
fstat64(0x3, 0xc07c)= 0
old_mmap(0x1000, 14602067, 
PROT_READ|PROT_WRITE|PROT_EXEC|PROT_SEM|PROT_GROWSDOWN|PROT_GROWSUP|0xfcf0, 
MAP_SHARED|MAP_DENYWRITE, 0, 0x181a4) = 0x55956000
read(3, "(hd0)\t/dev/sda\n(hd1)\t/dev/sdb\n", 4096) = 30
read(3, "", 4096)   = 0
close(3)= 0
munmap(0x55956000, 4096)= 0
sync()  = 0
open("/dev/sda", O_RDWR|0x8000) = 3
read(3, "\353H\220\20\216\320\274\0\260\270\0\0\216\330\216\300"..., 512) = 512
ioctl(3, 0x301, 0x555bcc98) = 0
ioctl(3, BLKGETSIZE, 0x555bcc94)= 0
ioctl(3, BLKFLSBUF, 0)  = 0
open("/dev/sdb", O_RDWR|0x8000) = -1 ENXIO (No such device or address)
fstat64(0x1, 0x555bcdb4)= 0
old_mmap(0x1000, 14602067, 
PROT_READ|PROT_WRITE|PROT_EXEC|PROT_SEM|PROT_GROWSDOWN|PROT_GROWSUP|0xfcf0, 
0x3 /* MAP_??? 
*/|MAP_NORESERVE|MAP_POPULATE|MAP_GROWSDOWN|MAP_DENYWRITE|MAP_EXECUTABLE|MAP_LOCKED|0x400,
 1442545993, 0x181a4) = 0x55956000
fstat64(0, 0x555bcd94)  = 0
old_mmap(0x1000, 14602067, 
PROT_READ|PROT_WRITE|PROT_EXEC|PROT_SEM|PROT_GROWSDOWN|PROT_GROWSUP|0xfcf0, 
0x3 /* MAP_??? 
*/|MAP_NORESERVE|MAP_POPULATE|MAP_GROWSDOWN|MAP_DENYWRITE|MAP_EXECUTABLE|MAP_LOCKED|0x400,
 135059904, 0x181a4) = 0x55957000
read(0, "root (hd0,0)\nsetup --stage2=/boo"..., 4096) = 77
ioctl(3, BLKFLSBUF, 0)  = 0
_llseek(3, 0, 0, 0x555bcab4 /* SEEK_??? */) = 0
read(3, "\353H\220\20\216\320\274\0\260\270\0\0\216\330\216\300"..., 512) = 512
read(3, "RV\276\3!\350*\1^\277\370!f\213-\203}\4\0\17\204\312\0"..., 31744) = 
31744
_llseek(3, 32256, ptrace: umoven: Input/output error
0x7e00, 0x555bcda4 /* SEEK_??? */) = 0
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32256) = 
32256
_llseek(3, 0, 0, 0x555bcde4 /* SEEK_??? */) = 0
read(3, "\353H\220\20\216\320\274\0\260\270\0\0\216\330\216\300"..., 512) = 512
read(3, "RV\276\3!\350*\1^\277\370!f\213-\203}\4\0\17\204\312\0"..., 31744) = 
31744
ioctl(3, BLKFLSBUF, 0)  = 0
_llseek(3, 0, 0, 0x555bc7b4 /* SEEK_??? */) = 0
read(3, "\353H\220\20\216\320\274\0\260\270\0\0\216\330\216\300"..., 512) = 512
read(3, "RV\276\3!\350*\1^\277\370!f\213-\203}\4\0\17\204\312\0"..., 31744) = 
31744
_llseek(3, 32256, ptrace: umoven: Input/output error
0x7e00, 0x555bcaa4 /* SEEK_??? */) = 0
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32256) = 
32256
_llseek(3, 548352, ptrace: umoven: Input/output error
0x85e00, 0x555bc614 /* SEEK_??? */) = 0
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32256) = 
32256
_llseek(3, 32256, ptrace: umoven: Input/output error
0x7e00, 0x555bc614 /* SEEK_??? */) = 0
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32256) = 
32256
_llseek(3, 209728512, ptrace: umoven: Input/output error
0xc803400, 0x555bc614 /* SEEK_??? */) = 0
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32256) = 
32256
_llseek(3, 214986240, ptrace: umoven: Input/output error
0xcd06e00, 0x555bc614 /* SEEK_??? */) = 0
read(3, "\316\223\266\26\217\303\10\264}9>pK\3136\301\217u\267\366"..., 32256) 
= 32256
_llseek(3, 32256, ptrace: umoven: Input/output error
0x7e00, 0x555bc614 /* SEEK_??? */) = 0
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32256) = 
32256
_llseek(3, 218115072, ptrace: umoven: Input/output error
0xd002c00, 0x555bc614 /* SEEK_??? */) = 0
read(3, " tty_ldisc_ref_wait\n8022"..., 32256) = 32256
_llseek(3, 224404992, ptrace: umoven: Input/output error
0xd602600, 0x555bc614 /* SEEK_??? */) = 0
read(3, "\372\305\200h>\240\31h\243F\25009~\367\372\275\230\334"..., 32256) = 
32256
_llseek(3, 32256, ptrace: umoven: Input/output error
0x7e00, 0x555bc614 /* SEEK_??? */) = 0
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32256) = 
32256
_llseek(3, 218115072, ptrace: umoven: Input/

Re: Installation disks should be using 2.6.10 kernel

On Wed, Jan 12, 2005 at 09:08:33AM -0500, Stephen Frost wrote:
> Sorry to jump in here in the middle.  A 2.6.10 amd64 ISO would be nice
> but I've noticed at least one problem w/ 2.6.10 - grub segfaults on my
> amd64 box when attempting to install the stage2 boot loader under
> 2.6.10.  It works fine under the 2.6.8 from the amd64 d-i ISO.  Anyone
> else seen this or have any idea what's up with it?  It's a Tyan
> motherboard, AMD-8111 using an LSI 53c1030 PCI-X Dual Ultra320 w/ an
> external SCSI hardware RAID array.  I've got two partitions, a regular
> ext3 one for root and everything else on an LVM/DM partition w/ multiple
> LVs for usr, var, home, data.
> 
>   Stephen
You're welcome. Can you strace the grub process and see what's wrong
with it ?
For my installation, grub is pretty useless since I'm full LVM/DM.

Seb


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation disks should be using 2.6.10 kernel

2005-01-12 Thread Stephen Frost

* brad ([EMAIL PROTECTED]) wrote:
> [EMAIL PROTECTED] wrote:
> >That's exactly my point. The 2.6.10 is vastly superior to the previous
> >kernel and should be elected as the kernel of choice for installation on
> >amd64 motherboards (or at least, on motherboards with the nforce3 250).
> >
> >But, such netboot image don't exist at this time.
> >
> >I wondered how difficult it is to refresh the netboot ISO ?

Sorry to jump in here in the middle.  A 2.6.10 amd64 ISO would be nice
but I've noticed at least one problem w/ 2.6.10 - grub segfaults on my
amd64 box when attempting to install the stage2 boot loader under
2.6.10.  It works fine under the 2.6.8 from the amd64 d-i ISO.  Anyone
else seen this or have any idea what's up with it?  It's a Tyan
motherboard, AMD-8111 using an LSI 53c1030 PCI-X Dual Ultra320 w/ an
external SCSI hardware RAID array.  I've got two partitions, a regular
ext3 one for root and everything else on an LVM/DM partition w/ multiple
LVs for usr, var, home, data.

Stephen

signature.asc
Description: Digital signature

putting together pure64 and the 32bit chroot...

2005-01-12 Thread Giacomo Mulas

	I am in the process of installing a full-fledged pure64 
scientific workstation with a similarly full-fledged 32 bit installation 
in a chroot. This is because this computer is replacing a pre-existent 
32 bit workstation, and I want users to have available everything they 
previously had available in 32 bit versions. Apart from the obvious waste 
of disk space, I did not find major problems. I do have a few overall 
questions/problems as to how to make the 64 bit and 32 bit systems to 
behave as consistently as possible, i.e.:

1) Which filesystems ought to be bind-mounted in the chroot? /home, /tmp, 
/var/tmp are quite obvious, but what about /var/mail? Configuration files 
in /etc?

2) (related to 1) In many cases, a system user and/or group is created 
upon installation of a package. These will obviously happen to be 
different between the chroot and the pure64 system. Should /etc/passwd, 
/etc/group etc. be shared between the pure64 and ia32 systems? Any 
problems to be expected in this case? Or should I compare the uids/gids in 
the chroot to the ones in the pure64 system and get them to agree by hand, 
using something like find to locate and change file ownerships 
accordingly?

3) I suppose (hope?) I am not the first to do something like this. People 
who went through it already (and survived): hints, suggestions?

Thanks, bye
Giacomo
--
_
Giacomo Mulas <[EMAIL PROTECTED]>
_
OSSERVATORIO ASTRONOMICO DI CAGLIARI
Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA)
Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222
Tel. (UNICA): +39 070 675 4916
_
"When the storms are raging around you, stay right where you are"
 (Freddy Mercury)
_
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Inkscape Bug!

2005-01-12 Thread Wolfram Quester

Hi,

On Mon, Jan 10, 2005 at 12:11:25AM +, Ludovic watteaux wrote:
> 
> I've install the later version of inkscape 0.40-2.0.0.1.gcc4 and it work 
> great 
> now.
Hm where did you get it from? Is it just the unstable package with the
patch from Andreas Jochens?
> 
> Many thanks.
> 
> What very nice software.
> 
> Ludovic
Thanks,

Wolfi


signature.asc
Description: Digital signature

Re: bug reporting?

On Wed, Jan 12, 2005 at 02:41:07PM +0100, Giacomo Mulas wrote:
> Problem description: when I run
> 
> /usr/lib/yp/ypinit -s 
> 
> on the wannabe pure64 nis slave server, I get something like:
> 
> Transferring passwd.byuid...
> Trying ypxfrd ...rpc.ypxfrd doesn't support the needed database type
> call to rpc.ypxfrd failed: RPC: Can't decode result
> 
>  (failed, fallback to enumeration)
> 
> which is replicated for each and every nis map. The above occurs also each 
> and every time I start the nis server/daemon using the provided 
> /etc/init.d/nis script. If I replicate the configuration in the 32 bit 
> chroot and run the 32 bit ypinit and/or server/daemon, everything runs 
> smoothly.
> 
> Any hints, suggestions (apart from abandoning nis, which I would if I 
> could, but I cannot...)
> 
My suggestion is to analyse the exchange between your machine and the
master with a network analyser and spot the differences between both
(the 64bit run and the 32bit run).
Ethereal is the boss for this. Once you have got the differences, check
to the part of the code that is responsible for the encoding. The bug is
certainly there.

Seb


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

bug reporting?

2005-01-12 Thread Giacomo Mulas

	Hello, I am a long time Debian user but a newcomer to the amd64 
port. I met a problem in setting up a pure64 machine as a slave nis 
server, connected to a standard debian woody x86 nis master. It looks like
the problem is in the 64 bit version, as it does not appear in the 32 bit 
version I installed (as a test) in the chroot.

Now the questions: should I use the standard debian bug tracking system to 
report amd64 bugs? I am uncertain, since it is not (yet) an official port. 
In the meanwhile, the second question: did anybody (try to) install a 
slave nis server on a pure64 and get it to transfer the nis maps from a 
debian x86 nis master server? Did anybody actually _succeed_ at it?

Problem description: when I run
/usr/lib/yp/ypinit -s 
on the wannabe pure64 nis slave server, I get something like:
Transferring passwd.byuid...
Trying ypxfrd ...rpc.ypxfrd doesn't support the needed database type
call to rpc.ypxfrd failed: RPC: Can't decode result
 (failed, fallback to enumeration)
which is replicated for each and every nis map. The above occurs also each 
and every time I start the nis server/daemon using the provided 
/etc/init.d/nis script. If I replicate the configuration in the 32 bit 
chroot and run the 32 bit ypinit and/or server/daemon, everything runs 
smoothly.

Any hints, suggestions (apart from abandoning nis, which I would if I 
could, but I cannot...)

Thanks, bye
Giacomo
--
_
Giacomo Mulas <[EMAIL PROTECTED]>
_
OSSERVATORIO ASTRONOMICO DI CAGLIARI
Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA)
Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222
Tel. (UNICA): +39 070 675 4916
_
"When the storms are raging around you, stay right where you are"
 (Freddy Mercury)
_
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "rock solid" motherboard

2005-01-12 Thread Steve McIntyre

Kyuu 'Vekotin' Eturautti wrote:
>
>My best experiences by far have been with Abit KV8-Pro and AV8 boards, 
>both with K8T800 Pro chipsets. I have not used audio in a single 
>AMD64+Linux system though, but as for stability, quality and hardware 
>compatibility (except for audio, not tested) with Debian Pure64, I 
>haven't had any problems.  As for onboard LAN, the via-velocity has 
>performed quite well. Via kindly provides sources that work with older 
>kernel versions too, as I believe the driver came with the kernel only 
>starting from 2.6.9.
>
>Personal and friends' recommendations suggest that problematic hardware 
>includes Asus and MSI (low quality, too many faulty products received) 
>and several nForce motherboards from various manufacturers (stability 
>issues).
>
>Experiences with Athlon64 Windows systems have provided similar results. 
>Abit+Via is a stable combination.
>
>I want to emphasize that I'm talking about only a bit over ten tested 
>systems with Debian Pure64 and none of these have been in workstation 
>use. But if I'd need a Linux workstation, I'd probably be betting on 
>K8T800 Pro or K8T890 as the chipset of choice and probably Abit as 
>motherboard.
>
>Out of your listed choices, I'd probably bet on Asus, due to the Via 
>chipset. I haven't had too many positive Asus experiences, but then 
>again, I haven't tested any in the past half year.

Hmmm. I'm surprised to hear of any bad experiences with Asus boards;
of the last 10 machines I've built, 7 have been Asus and they've been
incredibly stable. My current A8V Deluxe-based workstation runs very
well with amd64, with lovely performance and no problems at all.

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"...In the UNIX world, people tend to interpret `non-technical user'
 as meaning someone who's only ever written one device driver." -- Daniel Pead


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 'rock solid' motherboard

2005-01-12 Thread Manuele Rampazzo

Hi,

Filippo Carone disse:
>  Gigabyte GA-K8NS
>  Chipset: NVIDIA nForce3 250 + ITE IT8712F
>  Audio: Realtek ALC850 Ac'97
>  Lan:   ICS 1883 10/100Tx RJ45 or Marvell 8001

I've got this board and everything works very well [*] and it looks very
stable... I use the snd_intel8x0 alsa module for the audio card and the
forcedeth one for the network card.

[*] I just have some troubles with my 2 SATA disks (which I use with
software raid1), because when I/O grows the system slows a little too
much, modem connection hangs, etc.: when I had IDE disks I was able to
improve performances with hdparm, now I'm still looking for a good
solution.

Ciao,
Manu

-- 
"È ricercando l'impossibile che l'uomo ha sempre realizzato il
possibile. Coloro che si sono saggiamente limitati a ciò che appariva
loro come possibile, non hanno mai avanzato di un solo passo."
Michail Bakunin (1814 - 1876)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "rock solid" motherboard

2005-01-12 Thread Kyuu Eturautti


The choices I have are:
Gigabyte GA-K8NS
Chipset: NVIDIA nForce3 250 + ITE IT8712F
Audio:Realtek ALC850 Ac'97
Lan:  ICS 1883 10/100Tx RJ45 or Marvell 8001
Gigabyte GA-K8NF-9
Chipset: NVIDIA nForce4 4X MCPs
Audio:Realtek ALC850 Ac'97
Lan:  CICADA8201 Gigabit
Asus K8V-DELUXE
Chipset: VIA K8T800 + VT8237
Audio:ADI 1980
Lan:  3COM 3C940 Gb
These are almost in the same price range, the first being the
cheapest. Which one would you suggest? Are nvidia proprietary drivers
working well?
 

This is obviously a matter with several many opinions and experiences. 
Here's one.

My best experiences by far have been with Abit KV8-Pro and AV8 boards, 
both with K8T800 Pro chipsets. I have not used audio in a single 
AMD64+Linux system though, but as for stability, quality and hardware 
compatibility (except for audio, not tested) with Debian Pure64, I 
haven't had any problems.  As for onboard LAN, the via-velocity has 
performed quite well. Via kindly provides sources that work with older 
kernel versions too, as I believe the driver came with the kernel only 
starting from 2.6.9.

Personal and friends' recommendations suggest that problematic hardware 
includes Asus and MSI (low quality, too many faulty products received) 
and several nForce motherboards from various manufacturers (stability 
issues).

Experiences with Athlon64 Windows systems have provided similar results. 
Abit+Via is a stable combination.

I want to emphasize that I'm talking about only a bit over ten tested 
systems with Debian Pure64 and none of these have been in workstation 
use. But if I'd need a Linux workstation, I'd probably be betting on 
K8T800 Pro or K8T890 as the chipset of choice and probably Abit as 
motherboard.

Out of your listed choices, I'd probably bet on Asus, due to the Via 
chipset. I haven't had too many positive Asus experiences, but then 
again, I haven't tested any in the past half year.

-Kyuu 'Vekotin' Eturautti
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Sparc64 as amd64 ?

On Wed, 2005-01-12 at 11:44 +, Steve McIntyre wrote:
> Ron Johnson wrote:
> >On Wed, 2005-01-12 at 10:10 +0100, Tollef Fog Heen wrote:
> >> You could, but in the general case, you don't want to do that.
> >> Sparc64 is slower than sparc32, so the only cases where you actually
> >> want 64 bit support is in the kernel and glibc (so you can run 64 bit
> >> apps) and in special applications such as Postgres.
> >
> >What's the point, then, of SPARC64?  Don't say "more memory", because
> >that can be dealt with.
> 
>  * More memory available to each application

Ah.

>  * Larger native pointers and types, so large files etc. become easier

So some things are faster in SPARC64.  You'd think that things
like cryptography (SSL, for example) would also be faster.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

Don't think of it as a flame, think of it as an argument that
does 3d6 fire damage!



signature.asc
Description: This is a digitally signed message part

Re: Sparc64 as amd64 ?

2005-01-12 Thread Steve McIntyre

Ron Johnson wrote:
>On Wed, 2005-01-12 at 10:10 +0100, Tollef Fog Heen wrote:
>> You could, but in the general case, you don't want to do that.
>> Sparc64 is slower than sparc32, so the only cases where you actually
>> want 64 bit support is in the kernel and glibc (so you can run 64 bit
>> apps) and in special applications such as Postgres.
>
>What's the point, then, of SPARC64?  Don't say "more memory", because
>that can be dealt with.

 * More memory available to each application
 * Larger native pointers and types, so large files etc. become easier
 
-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
We don't need no education.
We don't need no thought control.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Sparc64 as amd64 ?

On Wed, 2005-01-12 at 10:10 +0100, Tollef Fog Heen wrote:
> * 
> 
> | I wondered if one could build a pure 64 bit distribution for sparc64 in
> | the very same way as the pure64 amd64 build was done ?
> | Maybe I should ask the sparc list too.
> 
> You could, but in the general case, you don't want to do that.
> Sparc64 is slower than sparc32, so the only cases where you actually
> want 64 bit support is in the kernel and glibc (so you can run 64 bit
> apps) and in special applications such as Postgres.

What's the point, then, of SPARC64?  Don't say "more memory", because
that can be dealt with.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

"The irony is that Bill Gates claims to be making a stable
operating system and Linus Torvalds claims to be trying to take
over the world."
seen on the net



signature.asc
Description: This is a digitally signed message part

Re: "rock solid" motherboard