Thank you! I sure wish I had known that before :-)
Brian
Michael Dominok wrote:
On Tue, 2006-01-31 at 22:43 -0800, Brian R. Whitecotton wrote:
So I think, humm there must be new images, sources, headers, etc BUT I
cannot find them.
Please advise!
The naming changed. You have
On Wed, 01 Feb 2006 04:00:14 +0100, David Meggy wrote:
> Is this
> even the right place to look?
Yes, the mini.iso contains the very minimum. The rest of the installer is
then downloaded live.
Try with that!
--
Best Regards, Jack
Linux User #264449
Powered by Debian GNU/Linux on AMD64
--
To
On Tue, 2006-01-31 at 22:43 -0800, Brian R. Whitecotton wrote:
> So I think, humm there must be new images, sources, headers, etc BUT I
> cannot find them.
>
> Please advise!
The naming changed. You have to look for linux-image instead of
kernel-image now.
Cheers
Michael
--
To UNSUBSCR
On Wednesday 01 February 2006 03:44, David Meggy wrote:
> Hi
>
> I'm looking to install Debian AMD64 etch on a new hard drive, but in the
> daily snapshots
> (http://amd64.debian.net/debian-installer/2006-01-31/netboot/), I only
> see a 5.3MB mini.iso, which seems way too small for an installer. I
Hello All,
I am presently runing 2.6.11-9-amd64-k8. I think my system is broken as
it is having trouble with what it *thinks* is the correct kernel version
-sources etc.
I would like to be running the latest testing but when I attempt an
apt-get install kernel-image I get the following:
[
Do you mean disable the CPU cache (L2?) or disable the ECC memory cache?
I haven't looked at the BIOS yet to see which options I have, but I
want to make sure I do the right one :)
Wouldn't disabling some caches wind up cutting the performance down,
especially if you mean the CPU cache? Having th
Hi
I'm looking to install Debian AMD64 etch on a new hard drive, but in the
daily snapshots
(http://amd64.debian.net/debian-installer/2006-01-31/netboot/), I only
see a 5.3MB mini.iso, which seems way too small for an installer. Is
this even the right place to look?
I want to use an etch install
Hi,
After playing around for a while, I decided to go ahead and do my
AMD64 Etch install for real. At the end of it, though, I got a
surprise -- no DMA on any IDE devices. The drives are capable,
the BIOS recognizes them as UDMA5, I tried a bunch of different
80-connector cables, and hdparm sho
On Tue, Jan 31, 2006 at 03:53:04PM +, Adam Stiles wrote:
> On Tuesday 31 Jan 2006 15:51, Chaim Keren Tzion wrote:
> > I don't know this switch but why does g19 have Mode "On" and g21 have
> > Mode "Off"?
> > Also, why not try making the Mdix type the same?
>
> The difference between MDI and MD
On Tue, Jan 31, 2006 at 12:08:28AM -0800, Corey Hickey wrote:
> Rami Saarinen wrote:
> > Anyway, I am glad to inform that yes it really was the memory that was
> > causing the trouble. I let the machine run the memtest86+ last night and
> > after 10 hours it had found four memory errors. Apparent
On Tue, Jan 31, 2006 at 09:18:56PM +0200, Chaim Keren Tzion wrote:
> So what FOSS/.deb package would you recommend for the Nvidia 6600?
I would recommend the non-free (non FOSS) .deb package called nvidia-glx,
nvidia-glx-dev, and nvidia-kernel-source.
It installs cleanly and properly on a debian
So what FOSS/.deb package would you recommend for the Nvidia 6600?
Lennart Sorensen wrote:
On Tue, Jan 31, 2006 at 06:15:25PM +0200, Chaim Keren Tzion wrote:
Can you explain how to do this or point me to a link that can?
Using anything other than the package makes your system no lon
On Tue, Jan 31, 2006 at 06:15:25PM +0200, Chaim Keren Tzion wrote:
> Can you explain how to do this or point me to a link that can?
Using anything other than the package makes your system no longer be a
real debian system. Once you go overwriting things in places that by
policy is controlled by d
On Tue, Jan 31, 2006 at 03:49:05PM +, A J Stiles wrote:
> You know, if hardware manufacturers were obliged by law to release sufficient
> information to enable a competent programmer to write a driver, we would not
> be in this sorry mess in the first place.
That is no excuse for making a me
On Tue, Jan 31, 2006 at 01:45:01AM -0800, mike wrote:
> Yes, I was able to go down and get on the console, record it, and
> found a thread on how to decypher it.
>
>
> The MCE was:
>
> CPU 0: Machine Check Exception: 4 Bank 0: f60da833
> TSC 23fd7acec1e ADDR 797db2c0
> Kernel pan
I've installed sarge/amd64 on a machine with a couple of Opteron
275s. We're using make (Debian version), ccache 2.4 and distcc 2.18.3
to build quite a large amount of code using -j12.
At some point during the build make will stop spawning new
jobs. Looking at the process listing there are a large
On Tue, 2006-01-31 at 09:40 -0600, Michael Langley wrote:
> It literally takes me 2 to 3 minutes
> to have everything setup and ready with the installers from
> nvidia.com.
2-3 minutes will become 2-3 hours when you need to remove all the cruft
that was put in non-standard locations by your DI
On Tuesday 31 Jan 2006 15:51, Chaim Keren Tzion wrote:
> I don't know this switch but why does g19 have Mode "On" and g21 have
> Mode "Off"?
> Also, why not try making the Mdix type the same?
The difference between MDI and MDI-X is in the port wiring; one of them has
the transmit and receive line
Michael Langley wrote:
Oh, and if you used nvidia-installer from www.nvidia.com, then you're
probably screwed unless you want to put in an unneccessary amount of
effort to un-screw things.
Not true at all. All I use are the installers from nvidia.com. The installer
will install th
On Tuesday 31 Jan 2006 15:23, Jo Shields wrote:
> Michael Langley wrote:
> >>Oh, and if you used nvidia-installer from www.nvidia.com, then you're
> >>probably screwed unless you want to put in an unneccessary amount of
> >>effort to un-screw things.
> >...If you have a basic knowledge of ln and kn
mike wrote:
Here's all the information I think could possibly be relevant... does
anything look out of place here?
and the two ports on the switch:
switch01# show int st
Flow Link
Back Mdix
Port Type Duplex Speed Neg ctrl S
> Why exactly aren't you just using packages, rather than having some
> random script overwrite bits of /usr for kicks?
>
>
Some things I just prefer to do myself. I've been using Linux since '97 and
got used to doing things for myself very early on. When it comes to video
drivers and kern
Michael Langley wrote:
Oh, and if you used nvidia-installer from www.nvidia.com, then you're
probably screwed unless you want to put in an unneccessary amount of
effort to un-screw things.
Not true at all. All I use are the installers from nvidia.com. The installer
will install the
> Oh, and if you used nvidia-installer from www.nvidia.com, then you're
> probably screwed unless you want to put in an unneccessary amount of
> effort to un-screw things.
>
>
Not true at all. All I use are the installers from nvidia.com. The installer
will install the 64bit driver and lib
Lars Schimmer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
I know, it was a topiv before.
But I don't get it run right now.
Teh specific problem is:
Error: API mismatch: the NVIDIA kernel module is version 1.0.8178, but
this library is version 1.0.7174
Does anyone has got a nvidia
Lars Schimmer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
I know, it was a topiv before.
But I don't get it run right now.
Teh specific problem is:
Error: API mismatch: the NVIDIA kernel module is version 1.0.8178, but
this library is version 1.0.7174
Does anyone has got a nvidia
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
I know, it was a topiv before.
But I don't get it run right now.
Teh specific problem is:
Error: API mismatch: the NVIDIA kernel module is version 1.0.8178, but
this library is version 1.0.7174
Does anyone has got a nvidia-glx-ia32 with a 1.0.817
|--==> Junichi Uekawa writes:
>>
>>However the package seems to be functional as well.
JU> I'll try to track down the problem, which probably is on amd64 Qt
JU> side, which I suspect might take some time.
Yes, these are nasty issues..
JU> For the timebeing, feel free to push me any ot
Hi,
> JU> Hi,
> JU> I'm trying to debug why 'fmit' is so unstable on my unstable amd64
> JU> box. Backtrace is looking suspiciously too qt to be application
> JU> specific. Anyone seen this kind of backtrace recently? At first sight
> JU> it looks like some allocator bug.
>
> Hi Junic
Here's all the information I think could possibly be relevant... does
anything look out of place here?
This is machine A:
[EMAIL PROTECTED] ~]# ethtool eth0
Settings for eth0:
Supported ports: [ MII ]
Supported link modes: 10baseT/Half 10baseT/Full
1
Yes, I was able to go down and get on the console, record it, and
found a thread on how to decypher it.
The MCE was:
CPU 0: Machine Check Exception: 4 Bank 0: f60da833
TSC 23fd7acec1e ADDR 797db2c0
Kernel panic - not syncing: Machine check
the output from "mcelog" was:
web03:~
Rami Saarinen wrote:
> Anyway, I am glad to inform that yes it really was the memory that was
> causing the trouble. I let the machine run the memtest86+ last night and
> after 10 hours it had found four memory errors. Apparently I was too
> hasty at the first time.
>
> I have one more stupid q
32 matches
Mail list logo
