Re: Searchin for a package
On Fri, Jul 20, 2007 at 08:47:16AM -0400, Lennart Sorensen wrote: > On Fri, Jul 20, 2007 at 10:57:03AM +0200, Hans-J. Ullrich wrote: > > I am am looking for the package, which is containing these two files: > > > > /etc/auto.master > > /etc/auto.misc autofs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cpu overheating
On Wed, Apr 04, 2007 at 08:39:25PM +0300, Constantine Kousoulos wrote: > Hello, > > When i do a cold start, the cpu fan barely spins. The result is that in > a few minutes the cpu overheats and the system automatically shuts down. > When i immediately turn it on again, the system detects the cpu's high > temperature and begins spinning at higher speeds for the rest of the > time. In both cases, the cpu fan never icreases or decreases it's speed, > it just continues spinning at a constant speed since the system's startup. > > I have a debian-amd64 notebook, with a turion64 processor. The above > mentioned behavior remains no matter what kernel i use. Perhaps there is a BIOS option to enable/disable dynamic fan speed control. Sounds like it's enabled and not working too well. Disabling it shouldn't interfere with user/kernel software that tries to control it later. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: openoffice.org-hyphenation-en package missing?
On Thu, Dec 21, 2006 at 12:19:01AM +0100, Kurt Roeckx wrote: > On Wed, Dec 20, 2006 at 02:56:45PM -0800, Andrew Sharp wrote: > > I thought I would ping the list to see if anyone knows why the > > openoffice.org-hyphenation-en* packages are missing from etch. They're > > in i386. In fact, only a handfull of the hyphenation packages are > > available on amd64. > > Those packages do not exist anymore, and have been removed because of > license problems. They do not exist on i386 anymore either, but it > could be you still have it installed from a time before it got removed. Doh, I forgot to check, that package is from sarge, which I don't have in my sources.list for amd64. Shoot. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
openoffice.org-hyphenation-en package missing?
I thought I would ping the list to see if anyone knows why the openoffice.org-hyphenation-en* packages are missing from etch. They're in i386. In fact, only a handfull of the hyphenation packages are available on amd64. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: USB hubs and storage no go on 2.6.17-2
On Wed, Dec 13, 2006 at 12:17:32AM -0500, Jim Crilly wrote: > On 12/12/06 10:45:45AM -0800, Andrew Sharp wrote: > > Howdy listers, > > > > I'm running etch with a custom compiled 2.6.19 and it sure seems to work > > brilliantly better that the Debian 2.6.17 kernel package when it comes > > to USB storage and USB hubs. In other words, those didn't work at all > > on the 2.6.17-? kernel package. > > > > It seems that those don't work unless you choose 'desktop environment' > > in tasksel, which I don't do because I like to keep 1GB of disk space > > free of Gbloatware. > > > > That makes no sense. Are you saying that your USB hub and storage stuff > wasn't working with the Debian 2.6.17 kernels unless you had the full > desktop environment installed? If so, I can't say I share that experience, > a few weeks ago I reloaded a box with etch without any X or desktop > packages (but now running sid) and USB storage works just fine with it. You're right, it doesn't make any sense, but there it is. The exact same kernel package, except on i386 and with all the Gnobe dependencies installed, worked for the same USB disk. But plugging the disk into my amd64 system did not work. It didn't even load the usbstorage module. If I then loaded usbstorage by hand, the usb<->scsi-disk connection wasn't made at all (I'm running SATA disks, so sd_mod and friends were already loaded). Furthermore, the hub on my Dell 2407WFP was completely non-functional -- it didn't even show up in usbview. I built a 2.6.18.3 kernel from stable-git, and bingo all was working. My guess as to why it works is that scsi and scsi disk support aren't modules in my custom kernel. I figured with sd_mod and scsi_mod being, well, modules, in the Debian kernel, something like hald or some other obnoxious daemon I don't want was "helping" the scsi subsystem rescan or whatever. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: AMD64-generic doesn't see all 4GB RAM?
On Mon, Nov 06, 2006 at 08:26:35PM +0100, Goswin von Brederlow wrote: > > There is almost never a reason to not run one of debian's prebuilt > > kernels. They work perfectly and optimally for probably 99% of users. > > I only know of two (in my eyes) valid reasons to build your own kernel: > > 1. you hate initrd since it too often doesn't work > 2. you need/want some extra patch There is at least a couple of other reasons ~:^) One is the Debian removes some things they find objectionable from the stock kernel sources. A really good example is USB serial dongle support. The Debian kernels have almost all of them removed, probably because they object to the firmware license agreement, or lack thereof. But they are in the stock kernel and so if you need to use one of them you have to build your own kernel, not from Debian kernel sources. Lately, I cannot get USB storage or hubs to work on the stock kernel, unless I do an install and select 'desktop environment' in tasksel. Yuck. > The "stock" kernels aren't slower and the disk space wasted for > unneeded (for you) modules is irelevant on any modern harddisk. The > times when you rebuild your kernel to get a slimmer one and save > memory are long gone. And on amd64 there is no change in optimizations Except maybe on embedded systems. Yes, there are opteron based embedded systems. OK, not a good example, sorry. This thread originated with a problem getting all the physical mem on a Tyan S2877. Now I have one of these, and I experienced the same problem. The problem is that the Bios doesn't say "enable IOMMU", it says "map memory hole?" and your options are 'DISABLED|software|hardware' and no explanation. Lame Bios help text, as always. And it shouldn't be disabled by default either. Sheez. My question is, what is the difference between the 'hardware' and 'software' choices? Is there a performance implication? Please don't reply with speculations, I can speculate myself just fine ~:^) Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
USB hubs and storage no go on 2.6.17-2
Howdy listers, I'm running etch with a custom compiled 2.6.19 and it sure seems to work brilliantly better that the Debian 2.6.17 kernel package when it comes to USB storage and USB hubs. In other words, those didn't work at all on the 2.6.17-? kernel package. It seems that those don't work unless you choose 'desktop environment' in tasksel, which I don't do because I like to keep 1GB of disk space free of Gbloatware. Does anybody know if USB storage and hubs work better on the latest 2.6.18 package? Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NVIDIA mismatch
On Tue, Nov 28, 2006 at 09:23:45AM -0800, Alan Ianson wrote:
> On Tue November 28 2006 08:42 am, Alan Ianson wrote:
> > On Tue November 28 2006 02:58 am, [EMAIL PROTECTED] wrote:
> > > Sending from my provider (previous attempt apparently failed) while
> > > receiving at my usual address. Writing from knoppix pivot-root install of
> > > debian because my X system suddenly broken (mismatch of nvis kernel
> > > module (1.0.8756) and X module version (1.0.7174) following apt-get
> > > upgrade. I also lost address debian users. I took the opportunity to
> > > upgrade from 2.6.15 without success (main contrib non-free present in
> > > sources.list debian).
> > >
> > > 1) nvidia-installer --uninstall
> > >
> > > 2)apt-get install kernel-image-2.6-k7
> > > installing 2.6.17-2-k7
> > >
> > > 3)reboot
> > >
> > > 4)m-a -i -prepare
> > > installing headers and kbuild
> > >
> > > 5)m-a a-i nvidia
> > >
> > > apt-cache policy nvidia-kernel-$(uname -r) nvidia-glx
> > > nvidia-kernel-common shows
> > > n-vidia-kernel-2.6.17-2-k7 (1.0.8762-2+2.6.17-9)
> > > nvidia-kernel-common (20051028+1 0)
> > > nvidia-glx
> > > not installed and no candidate (I was unable to install it)
> > >
> > > Hope to get help although I regret not to have learned in the past how to
> > > do.
> >
> > When I built that module I had to add unstable to my /etc/apt/sources.list
> > and then apt-get update and then rebuild the module with "m-a a-i nvidia"
>
> I almost forgot,
>
> Be sure to remove the unstable lines from your sources.list and apt-get
> update
> before you do anything else with apt, unless you want to run unstable.. :)
Or, you could leave that in sources.list and simply add a line similar
to this one
APT::Default-Release "etch";
to your /etc/apt/apt.conf file. I usually use the name of the release
rather than the alias ('testing' for 'etch') as that prevents me from
doing an "accidental dist-upgrade" if, say, etch were to be released
without me knowing it ~:^)
Cheers,
a
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: writing dvd problem
On Mon, Oct 09, 2006 at 11:50:09PM +1000, garrone wrote: > Hi, > Writing to dvd's appears to work as normal, but reading them back > fails, with the following appearing from dmesg > > cdrom: This disc doesn't have any tracks I recognize! What do you mean by "reading them back"? Mounting them? I've never seen that error message when mount fails. > I am running 2.6.17, testing distribution, with version 6.1-3 of > dvd+rw-tools package. > > I can boot up to 2.6.11 recovery mode, running an old ubuntu distro, > and am able to write and read back OK then. I also definitely did > a backup with an amd64 setup, but cannot recall the version. It may > have been the stable version. > > If I attempt to boot to recovery mode and write, I get the message > on the console: > > :-( Unable to anonymously mmap 33554432: resource temporarily > unavailable. I used to get this all the time. I don't really know what made it go away, but eventually it did. Either a kernel upgrade or a libc upgrade or something. That was quite a few months ago now. a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MSI K9N Diamond main board?
On Tue, Sep 26, 2006 at 04:26:30PM -0400, [EMAIL PROTECTED] wrote: > I'm going to be buying a new main board and have a short list > all based on the nVidia nForce 590 SLI chipset. At this point, > I'll be going with the Athlon AM2 (model depends on price when I get > it). > Most reviews are for Asus but have heard comments about decreasing > reliability after a couple of years. I've heard the same comments. > Tyan has great reliability and would be my first choice but their AM2 > uses the nVidia Pro chipset which nVidia says doesn't have mainstream > kernel drivers, they provide binary drivers for RHES and SLES. I'm not sure what's up with that comment. I've got a board with that chipset (Tyan K8WE) and it works fantastically. Like a rock. My previous system that I built was a Tyan something dual Athlon, built in July 2002, still running strong. I'm pretty sold on them at this point. The following functions work excellently for me: forcedeth driver for gigabit ports -- IP NAT between them USB2.0 ports -- both back panel and headers; audio SATA -- dual 200GB drives running raid1 for everything PATA -- DVD burner 4 x 512MB dual channel DDR ECC dual PCIe -- no SLI, it's just craptastic anyway nvidia I2C module -- sensors works quite well with stock Debian packages serial port What support is not included here that you would want? I don't recall anyone mentioning any problems with this board, apart from Sarge installation problems because of the need for recent 2.6.12+ kernels. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: performance of AAC-RAID (ICP9087MA)
On Tue, Sep 12, 2006 at 02:17:48PM +0200, Erik Mouw wrote: > On Tue, Sep 12, 2006 at 11:50:46AM +0200, Raimund Jacob wrote: > > Erik Mouw wrote: > > > > Hello! And thanks for your suggestions. > > > > > On Fri, Sep 08, 2006 at 05:08:52PM +0200, Raimund Jacob wrote: > > >> Checking out a largish CVS module is no fun. The data is retrieved via > > >> cvs pserver from the file server and written back via NFS into my home > > >> directory. This process is sometimes pretty quick and sometimes blocks > > >> in between as if the RAID controller has to think about the requests. I > > >> know this phenomenon only from a megaraid controller, which we > > >> eventuelly canned for a pure linux software raid (2 disks mirror). Also, > > >> compiling in the nfs-mounted home directory is too slow - even on a > > >> 1000Mbit link. > > > > > Try with a different IO scheduler. You probably have the anticipatory > > > scheduler, you want to give the cfq scheduler a try. > > > > > > echo cfq > /sys/block/[device]/queue/scheduler > > > > > > For NFS, you also want to increase the number of daemons. Put the line > > > > > > RPCNFSDCOUNT=32 > > > > > > in /etc/default/nfs-kernel-server . > > > > Thanks for these hints. In the meantime I was also reading up the > > NFS-HOWTO on the performance subject. Playing around with the > > rsize/wsize did not turn up much - seems they dont really matter in my case. > > In my case it did matter: setting them to 4k (ie: CPU pagesize) > increased throughput. > > > My largish CVS-module checks out (cvs up -dP actually) in about 1s when > > I do it locally on the server machine. It also takes about 1s when I > > check it out on a remote machine but on a local disk. On the same remote > > machine via NFS it takes about 30s. So NFS is actually the problem here, > > not the ICP. > > One of the main problems with remote CVS is that it uses /tmp on the > server. Make sure that is a fast and large disk as well, or tell CVS to > use another (fast) directory as scratch space. > > > Furthermore I observed this: I ran 'vmstat 1'. Checking out locally > > shows a 'bo' of about 1MB during the second it takes. During the > > checkount via NFS there is a sustained 2 to 3 MB 'bo' on the server. So > > my assumption is that lots of fs metadata get updated during that 30s > > (files dont actually change) and due to the sync nature of the mount > > everything is committed to disk pretty hard (ext3) - and that is what > > I'm waiting for. > > Mounting filesystems with -o noatime,nodiratime makes quite a > difference. > > If you're using ext3 with lots of files in a single directory, make > sure you're using htree directory indexing. To see if it is enabled: > > dumpe2fs /dev/whatever > > Look for the "features" line, if it has dir_index, it is enabled. If > not, enable it with (can be done on a mounted filesystem): > > tune2fs -O dir_index /dev/whatever > > Now all new directories will be created with a directory index. If you > want to enable it on all directories, unmount the filesystem and run > e2fsck on it: > > e2fsck -f -y -D /dev/whatever > > Increasing the journal size can also make a difference, or try putting > the journal on a separate device (quite invasive, make sure you have a > backup). See tune2fs(8). These are all good suggestions for speedups, especially this last one, but I would think that none of this should really be necessary unless your load is remarkably high, not just one user doing a cvs check out. I would strace the cvs checkout with timestamps and see where it is waiting. It seems to me like this has more to do with some configuration snafu than any of this stuff. Why are you trying to configure it this way anyway? Just use the standard client/server configuration. You'll probably be glad you did. And it seems to work a lot faster that way anyway ~:^) > > Here is what I will try next (when people leave the office): > > > > - Mount the exported fs as data=journal - the NFS-HOWTO says this might > > improve things. I hope this works with remount since reboot is not an > > option. I personally would NOT do this. There is a good reason why none of the top performing journaling file systems journal data by default. > I don't think it makes a difference, I'd rather say it makes things > worse cause it forces all *data* (and not only metadata) through the > journal. Eggxacly. a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: which package to play DVD's ???
On Wed, Sep 06, 2006 at 03:20:38PM +0200, Albert Dengg wrote: > On Wed, Sep 06, 2006 at 07:59:19AM -0500, helices wrote: > > What do you think? > well, i personally user xine-ui or mplayer from > deb http://www.debian-multimedia.org sid main Well, slightly OT because this isn't about DVDs, but currently mplayer and xine both have the same bug when playing mpeg4's -- they show only the upper left corner of the content in the video window. vlc is not having this problem, but vlc has other annoyances, one of which is that it is somewhat cruder. This issue with mp4's is not amd64 specific, it is the same on my 32 bit boxen. This is for etch. Older versions of both those programs work fine. I don't know if they are both using the same broken library/codec or what, but vlc uses a slightly different version of one of the libraries. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bad MD5SUM on http://http.us.debian.org/debian/dists/testing/non-free/binary-amd64/Packages.gz
On Thu, Aug 03, 2006 at 01:25:10PM -0600, edwardsa wrote: > This appears to be a problem with the repository. Will this be fixed soon? I'm experiencing this on i386 as well, so I've been too chicken to update my amd64 system for fear I'd be similarly stuck. Anybody know what's going on? The main Source.gz and non-free Packages.gz and Sources.gz are messed up on i386. a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problems with dhcpd3-server
On Mon, Jun 26, 2006 at 06:07:58PM +0200, Andreas Richter wrote: > Am Montag, 26. Juni 2006 00:39 schrieb Alexander Samad: > > > > had the same problem, I tried the new version and still the same old > > problem with the lease time, I am sticking with > > Version 3.0.4-6 works here. My clients have a correct lease time. It's working for me as well. I checked it with ethereal. It's sending the parameter with 4 bytes now. My client is being somewhat obnoxious though. The lease time is being set to 10 minutes (600 seconds); the client was renewing the lease roughly every 4.5 minutes. I set the lease time to 24 hours; we'll see what the client (debian/etch i386) does with that. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
sylpheed-claws-gtk2 missing package in testing/etch
So I noticed people whining about missing packages, so I thought I would mention one that's annoying me. sylpheed-claws-gtk2 has gone missing from testing/etch a few months ago and never reappeared. I checked the buildd web page even though I'm not really sure what the relationship is, and it seems to have been building fine since March. Is it some issue where it's just not dropping into testing from unstable for some reason? Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problems with dhcpd3-server
On Fri, Jun 23, 2006 at 05:26:11PM -0400, Lennart Sorensen wrote: > On Fri, Jun 23, 2006 at 04:27:09PM -0400, Lennart Sorensen wrote: > > According to RFC 2132, option 51 MUST by 4 in length, so unless there is > > a newer spec (which would be incompatible with prior dhcp versions), > > then the dhcp server is currently buggy/broken. > > > > Probably the code uses long somewhere that was supposed to be 32bit, but > > on amd64 that is 64bit. > > By the way according to the changelog of dhcp3-server in sid, on Tuesday > of this week, a patch to deal with problems on 64bit systems was > applied. So if you get dhcp3-server 3.0.4-6, it might actually work > properly on a 64bit system now. > > See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=368302 for details > of the bug filed about 64bit problems. Nice grab, I didn't even look at sid. At least I know the clients aren't to blame. Thanks, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: General advice needed : rebuilding server
On Fri, Jun 23, 2006 at 02:30:37PM +0100, Rory Campbell-Lange wrote: > Dear All > > This is going to be a long email about various issues. Some are > management issues rather than 64bit issues exactly, but I thought that I > would post a full narrative in the hope that people would comment on > parts of it. > > The Server > -- > > We installed a new dual 2.GHz Xeon (1 MB Cache) 2U fileserver with a > S5350-1 U Dual Opteron Motherboard, 2GB RAM and AMCC/3Ware 9500S-8 SATA Well, maybe there's your problem. You apparently installed Xeons in an Opteron MB. Obviously kidding, but I wonder what else is confused here. If /var and /boot are missing, most likely they were mounted to something before, and aren't mounted now, or vice versa. Or a newbie sysadmin who LARTed things to death. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
problems with dhcpd3-server
I'm wondering if anyone else is running dhcp3-server on their amd64 box and seeing (or not seeing) the same problem. The problem is that dhcp3-server is sending out dhcp offer packets with an 8 byte lease time, for reasons that I can't fathom. Ie, I think it's a bug. However, it does properly say that the option is 8 bytes long, the only thing is, apparently all clients (that I have tried) assume that the option is 4 bytes long and don't observer the length specified by dhcp3-server. In addition, the correct number 600 actually seems to be in the first four bytes, but none of the clients seem able to deal with that. Instead they set their lease time(s) to 3-4 minutes which is just nutty. So, is the bug in the clients or the server? Clients I tested were dhcp3-client (irony) on a 32-bit X86 box, and the udhcpc client in busybox on a mipsel box. Output from ethereal (on the amd64 box): . . . Option 51: IP Address Lease time - length isn't 4 . . . 33 08 00 00 02 58 00 00 00 00 . . . Yes, ethereal put's in that comment about the length not being 4. 33 (hex) is option 51, 08 is the length, and 00 00 02 58 is "600" lease time. The X86 client actually says something about 4 'garbage' bytes after the lease time, but gets the lease time wrong -- it sets it at 260 seconds or something like that. Kind of annoying. Not sure which one(s) I should file a bug against. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Random segfaults (was: Hup,hup Debian AMD64, Hup, hup)
On Thu, Jun 22, 2006 at 12:56:02PM -0400, Lennart Sorensen wrote: > On Thu, Jun 22, 2006 at 04:01:36PM +, Dimitris Lampridis wrote: > > For the CPU (x2 3800+) i cannot say, although some other OS that > > unfortunately > > can offer me Elder Scrolls Oblivion (...) is not having any problems (not > > of > > this kind anyway) > > > > For the memory (4x512MB), i did have one faulty module, i returned it, got > > a > > new one and system was sweet, plus memtest86 doesn't reveal a problem (this > > doesn't mean that its OK, but its a rather slim case) > > > > For the power supply its a very robust Tagan, 480W and it was taking the > > heat > > fine for many months now. Also, Dutch power company has never caused me any > > trouble or reason to worry. > > > > My system is as cool as it can get with stock CPU fan, CPU under 30 > > Celsius, > > case under 40 Celsius, so no overheating problem too. > > > > I'll start checking all those things the best I can (memory is the easiest > > to > > check me thinks, at least at a per-module basis), but I'm almost sure its > > not > > my HW. > > Hmm, well most of the programs you mentioned were c++ programs. I guess > there could be a c++ library problem, but if that was the cause it I've recently updated my etch installation and oddly enough, cupsd seems to segfault about once a day or once every other day. Just cupsd. Very strange. Was fine before the most recent update. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT: Re: multiprocessor
On Tue, Jun 20, 2006 at 11:01:12AM -0700, Andrew Sharp wrote: > ripper:~$ sensors > smsc47b397-isa-0480 > Adapter: ISA adapter > temp1: +33?C <-- cpu1 > temp2: +33?C <-- cpu2 > temp3: +29?C > temp4: -128?C These read as 33\260C when I'm reading the email, but as 33C when I'm editing the email or reading the output from sensors on an xterm. So, sorry about that if your email client didn't like those. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT: Re: multiprocessor
On Tue, Jun 20, 2006 at 02:00:29PM +0200, Erik Mouw wrote: > On Tue, Jun 20, 2006 at 11:03:28AM +0200, Christoph Anton Mitterer wrote: > > Francesco Pietra wrote: > > > Mother bowrd Tyan K8WE S 2895, two 265 dual opteron, all eight slots of > > > ram > > > filled (1 GB each) > > > > > > At computer on: > > > CPU0=Dual Core amd64 opteron 265 > > > CPU1=Dual Core amd64 opteron 265 > > > > > Hi,.. this is off topic: > > I have the same board with two 275 Opterons and these days where its > > hot here in Munich (for what we are used to here) I have enormous heat > > Problems. > > > > I'm using BIOS Version 1.03 of the board and it shows me about the > > following temeratures: > > CPU0 45? C > > CPU1 73? C (I think this must be a BIOS error) > > Ambient 50 ?C > > > > And this when the systems does nothing (expect from running X and the > > usual stuff). > > > > Also the chipsets get very hot... > > > > Could you please tell me your experiences with that board? > > Try the lm_sensors.conf from Tyan: > > ftp://ftp.tyan.com/software/lms/lms_s2895.conf > > I experienced similar problems with an S2885, and most of it went away > by using Tyan's lm_sensors config file. The config file still needed a > little tweaking (high temp for the two CPUs were completely different) > but at least it gives you a working config file to start with. The lmsensors package in etch seems to work perfectly w/o any downloads. Actually, I checked it and it seems it has been updated with the mods from tyan already. So, as debian users, you're in luck as usual! ripper:~$ sensors smsc47b397-isa-0480 Adapter: ISA adapter temp1: +33?C <-- cpu1 temp2: +33?C <-- cpu2 temp3: +29?C temp4: -128?C fan1: 1393 RPM <-- cpu1 fan fan2: 1348 RPM fan3: 1357 RPM fan4: 1428 RPM <-- cpu2 fan This is with 265s "basicall" idle. The CPUs (temp1 and 2) get as high as 43C when running for a while at 100%. [This is the ideal machine for compiling 800 java files several times a day ~:^) ] If you're seeing anything higher, then you need to triple check your fans and heat sink mounting. They're probably not working right. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFS support
Sounds like pilot error to me. I've been using XFS on my md0/raid1 for 7 months, works like a charm. This with debian/etch, netinstall, grub boot loader. Installed and ran straight out of the box, narry a problem. I think for the first 3 months I was using debian kernel 2.6.12.something. In fact, the only reason I went to my own kernels is that debian refuses to put in USB serial stuff that requires firmware support. Just trying to counter the blizzard of misinformation available on the internet these days ~:^) Cheers, a On Fri, May 12, 2006 at 05:33:33PM +0200, [EMAIL PROTECTED] wrote: > The XFS support of the packed kernel of the NetInstall image isn't > working properly. It does install but keeps throwing kernel oops and > fails to install grub. And after we take a long detour to get things > to work at the sight of a little load it pulls a xfs_force_shutdown of > md0 and thereby crashing the whole system. I already tried with > hardware and software raid, both were plagued with problems. The > 2.6.8.x -2.6.12.x had a couple of bug reports related to XFS and raid. > > Changed to JFS and everything is working now, as I can't wait. Just > wanted to give some feedback. > > PS: I am not on the list, so CC to me if you reply to the list. > > > -- > 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]
Re: pci express card on debian amd64 sarge
On Wed, Mar 22, 2006 at 07:42:06PM -0300, Mauricio Ortiz Calvao wrote: > > Hi, > > I am about to buy a workstation with: > > 1) motherboard: Supermicro H8DCE > > 2) CPU's: 2 AMD Opteron 246 cpu's > > This motherboard seems to support a PCI Express slot and thus I would > like, if > possible, to take advantage of this resource, when acquiring a graphics > board. > Specifically, I would like to check whether any one knows that either (i) > an > nVidia 6200 120 PCie, or (ii) an ATI Radeon X300SE PCI-e video card would > be > supported in Debian AMD64 sarge and how these cards compare (which one is > better?). Probably would depend on a few things, but I have that exact ATI card (the author asked about PCIe cards) in my system, and it works for me without a second thought. No extra packages or drivers to install. D-I brought up X and I didn't even have to answer any questions. Drives my Dell FPW2005 panel like a champ. I experience no lockups or any other kind of hardware or software problem. One thing I like about it is that X initializes and comes up very fast. Caveat: I don't do any significant 3D; this is a development workstation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multiple hardware and RAID failures
On Tue, Mar 14, 2006 at 08:54:58AM -0500, Lennart Sorensen wrote: > On Tue, Mar 14, 2006 at 09:43:55AM +0100, Frank Hart wrote: > > My Athlon 3400Mhz server was running flawlessly until a couple of weeks > > ago. The system is fitted with 2 SATA 200GB Maxtor disks in a Raid 1 > > configuration with mdadm and a seperate IDE disk. The motherboard is an > > Asus MB K8V-MX AMD S754. > > > > All of a sudden the system freezed. I did a hard reset and after an hour > > it stopped again. The logging reported dma errors on the seperate IDE > > disk and RAID failures. Now, the server also refused to boot. After I > > disconnected one SATA disk it would start again. Thinking it was a disk > > failure, I replaced the disk the following day only to find out that > > after installing the new disk, the system wouldn't boot at all. After > > disconnecting all cables (except to power :P) and removing the memory > > the system beeped a couple of times. I replaced the motherboard with a > > new K8V-MX and all seemed fine again. But one day later the other SATA > > disk got thrown out of the mirror and the system again didn't want to > > boot. I replaced the SATA disk and the IDE disk with brand new ones. > > > > Now, I was pretty convinced all this horror happened because of some > > power surge so after replacing the disks I installed an APC with power > > overload protection. But after just a couple of days the SATA disk I > > replaced first started to give errors again. Mdadm reports errors on all > > mirror sets and after an upgrade to kernel 2.6.15 I can't get the disk > > out of faulty status. > > > > Can someone enlighten me what the hell is going on here? I replaced all > > components except the power supply. Could this be the problem? The only > > one who is benefitting from all this is the local PC store ;) > > Perhaps your power supply is defective and not providing steady power, > or isn't happy with the load that is on it. I have seen quite a few > systems that were unstable and had disk issues and crashed, where the > problem disappeared once a quality power supply was installed. True enough. If you had a power spike, anything connected to power could be now suspect. PS on down. I didn't read where you checked your disk cables. I've had more than a couple of cables of various sorts just suddenly go bad for no reason. Good luck with it. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multiple hardware and RAID failures
On Tue, Mar 14, 2006 at 09:43:55AM +0100, Frank Hart wrote: > Can someone enlighten me what the hell is going on here? I replaced all > components except the power supply. Could this be the problem? The only Sounds like your PS is bad. Even if it's not, it's never a bad idea to have a spare one around. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
mayby OT: growisofs not happy with recent 2.6 changes?
Howdy, I don't know if this is a 2.6 problem or an amd64 problem, but I can't run growisofs on my box. I just get :-( unable to anonymously mmap 33554432: Resource temporarily unavailable every time. That number, in case anyone wants to know, is precisely 32MB. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can't mount CD/DVD drives
On Thu, Feb 16, 2006 at 10:01:15AM +0100, Gabor Gombas wrote: > On Wed, Feb 15, 2006 at 03:45:01PM -0500, Austin Denyer wrote: > > > I had a similar problem to you, Andy, with the 2.6.15 kernel and a > > RAID1 setup - it could not find /dev/md3 to mount it (/dev/md3 was the > > root partition). It looked like udev had not yet created the device. > > Unless you have the RAID code compiled into the kernel (not modules) and > you are using kernel-based RAID autodetection, the /dev/md* entries are > created by mdadm, not by udev (udev can not create them until the array > is created, and mdadm needs to create the device first to be able to > build the array). The raid code doesn't have to be compiled in, it can be modularized in an initrd image. So long as grub can load the kernel and the initrd image, you're good to go with whatever modules you want in the initrd image. I believe current versions of grub can do raid0 and raid5 now, but, well, you know, test it first ~:^) Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can't mount CD/DVD drives
On Wed, Feb 15, 2006 at 03:45:01PM -0500, Austin Denyer wrote: > On Wed, 15 Feb 2006 12:28:01 -0800 > Andrew Sharp <[EMAIL PROTECTED]> wrote: > > > > On Wed, Feb 15, 2006 at 01:51:54PM -0500, Lennart Sorensen wrote: > > > On Wed, Feb 15, 2006 at 08:39:11AM -0500, Carl Brown wrote: > > > > > > > > Would this mess perhaps have something to do with udev/hotplug? > > > > Dpkg says: > > > > rc udev 0.056-3 > > > > ii hotplug 0.0.20040329-25 > > > > > > There was a problem around 2.6.12 days as far as I remember where a > > > bad initrd tool generated initrd images which loaded ide-scsi, and > > > once that is done the initrd tool will make future ones to match > > > your setup. I think 2.6.15 kernel will force it to not use > > > ide-scsi at all, but I am not sure. > > > > All true. I was a faithful user of 2.6.12 debian kernel up until > > yesterday. If you unloaded the ide-scsi, it would at least oops, > > sometimes harmlessly, sometimes fatally. > > > > It sounds like there is some extra step to using debian kernels now? > > It would be nice to get an FYI at least when installing one of these. > > I tried the 2.6.15.x debian kernel yesterday, and it couldn't mount > > root, I think because it wasn't loading the nv_sata module or the > > md/raid1 or something. > > My feeling is along the lines of Carl's in that I think it is a udev > issue. > > I had a similar problem to you, Andy, with the 2.6.15 kernel and a > RAID1 setup - it could not find /dev/md3 to mount it (/dev/md3 was the Mine is not a udev issue, as it works with kernel.org kernel built w/o need for an initrd. Also, I'm only using md0, so the kernel can handle that. You might be having a udev issue however if you're using md3. You might have to do a little extra configing with udev and/or /etc/mdadm.conf. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can't mount CD/DVD drives
On Wed, Feb 15, 2006 at 01:51:54PM -0500, Lennart Sorensen wrote: > On Wed, Feb 15, 2006 at 08:39:11AM -0500, Carl Brown wrote: > > Ide_scsi is loaded, and refuses to unload. > > > > # rmmod ide_scsi > > ERROR: Removing 'ide_scsi': Device or resource busy > > > > It is unclear why it is busy: > > > > # lsmod|grep ide_scsi > > ide_scsi 18116 0 > > ide_core 144888 5 ide_cd,amd74xx,ide_generic,ide_disk,ide_scsi > > scsi_mod 151512 9 > > sbp2,sg,aic79xx,ide_scsi,sr_mod,sd_mod,libata,aic7xxx,scsi_transport_spi > > > > ide_scsi is not listed in /etc/modules. > > > > Would this mess perhaps have something to do with udev/hotplug? > > Dpkg says: > > rc udev 0.056-3 > > ii hotplug 0.0.20040329-25 > > There was a problem around 2.6.12 days as far as I remember where a bad > initrd tool generated initrd images which loaded ide-scsi, and once that > is done the initrd tool will make future ones to match your setup. I > think 2.6.15 kernel will force it to not use ide-scsi at all, but I am > not sure. All true. I was a faithful user of 2.6.12 debian kernel up until yesterday. If you unloaded the ide-scsi, it would at least oops, sometimes harmlessly, sometimes fatally. > Perhaps just adding ide-cd to the list of modules to load first > explicitly in the initrd tool config will make it do the right thing if > you then regenerate the initrd. It sounds like there is some extra step to using debian kernels now? It would be nice to get an FYI at least when installing one of these. I tried the 2.6.15.x debian kernel yesterday, and it couldn't mount root, I think because it wasn't loading the nv_sata module or the md/raid1 or something. So what I'm hearing is that you have to boot your old kernel, run some kind of command vis-a-vis the new kernel, and then you can boot your new kernel? I didn't see any mention of that when I installed it. Am I blind or are we getting hosed by silent changes? Instead, I downloaded the latest 2.6.15 from kernel.org, configured it and it works great. No initrd needed. I had to anyway, because debian rudely removes the keyspan USB serial drivers for some reason. OT: If you're configuring your kernel with make gconfig here's a tip: save early and often. I spent 90 minutes mulling through the config, and when I went to save it, it segfaulted and I had to start all over. Sigh. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Jumbo Frames?
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 MDI-X is in the port wiring; one of them has
> the transmit and receive lines swapped over. You need a straight-through
> cable to go from MDI to MDI-X, or a crossover {pin 1 swapped with pin 3 and
> pin 2 swapped with pin 6} to go from either type to the same type.
>
> Much modern kit seems to be capable of auto-sensing which is which.
Ur, you cannot use a crossover cable with gigabit+. It has to be an
8 wire cable of type "straight thru" which is the standard twisted
pair wire. Make sure your cable, if you didn't make it yourself,
has all 8 wires (the spec for 100BT is really only 4 wires, but most
cables have 8 hooked up) and that it's not a crossover. Example: to
connect two gigabit interfaces together, use a straight through cable.
To connect a gigabit interface to a switch, use a straight through cable.
Makes it easy, right? ~:^)
Some uber smart switches will detect a crossover cable, drop the
interface to 100BT and fix up the wiring auto-sensibly, but mine
certainly doesn't do that.
Cheers,
a
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian ADM64 Etch (testing/unstable) system freeze
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. Apparently I was too > > hasty at the first time. > > > > I have one more stupid question: as it may take couple of days for me to > > get the new memory. Is there any way to block / reserve the faulty > > memory area so that it would not be available for use? > > If memtest86+ is consistently reporting a few addresses, then you can > use the badram kernel patch: > > http://rick.vanrein.org/linux/badram/ > > I had some very slight stability issues with my machine after I build > it, and memtest86+ reported one memory failure after I ran it for a > while. The problem turned out to be that my BIOS was, for some reason, > setting the memory timing (CAS/RAS/etc. -- I don't remember which) more > aggressively than the values at which the RAM was specced to operate. > So, if memtest86+ seems to be reporting random, sporadic failures, you > might try checking and increasing your memory timings. You might also want to try reseating the memory once or twice, and checking the cooling to make sure it isn't a heat problem. If you haven't already, that is. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Jumbo Frames?
On Mon, Jan 30, 2006 at 01:58:56PM -0800, mike wrote: > Thanks for the reply. > > I've tried that and now this is giving me confusing results: > > A has jumbo frames (mtu 9000) > B has jumbo frames (mtu 9000) > C has normal (mtu 1500) > > B -> A = 3.4MB/sec > C -> A = around 50MB/sec > > I'm just scp'ing a 170 meg video file back and forth - it's over 10 > times slower... does anything stand out to you instantly as to what > the problem would be? C -> A will end up at 1500 since C can only do 1500, obviously. B -> A, your switch is choking, is my *guess*. I suspect your switch it not working as well as you think it is, unfortunately. Is it firmware upgradeable? If so, check for updates. Also check the Dell forums. I have a unmanaged Dell switch, it exhibits the same behavior. Unfortunately, not upgradeable in my case ~:^( You should get better than 50MB/s however. What are the NICs? Using a hacked version of netcat, to eliminate disk I/O from the picture, I see steady 90ish MB/s. Between two 64/66 Intel NICs across my Dell switch. Between any other NIC hardware combos, I see 70-80 MB/s max. Actually, the only other hardware I have that isn't 32bit is a Broadcom 57XX, also 64/66. On a dual core, or even a single core, Opteron, the encryption overhead would be minimal. The heavy encryption calculations comes at key generation time, ie., when the connection is setup. Once it's going, I'm going to estimate that the overhead from encryption is less than 1% of CPU. The default encryption algorythms are pretty fast and efficient. Try netcat and just time it, for cleaner results. After the first time you run it, your caches should be warmed up, so you should get pretty clean results of just the network xfer speed. a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: udev+amd64
On Fri, Jan 27, 2006 at 05:05:17PM +0100, Gudjon I. Gudjonsson wrote:
> Hi
>I am trying to run a program using USB hardware. I added the following
> lines to /etc/udev/permissions.rules:
> SUBSYSTEM=="usb_device",GROUP="plugdev", \
> SYSFS{idVendor}=="0abf", SYSFS{idProduct}=="3370"
> Since then I have upgraded udev to 0.82-1 and reastarted my computer but the
> program only works when run as root. A normal user does not have the
> permissions to write to the device ( I am in the plugdev group ).
>I do run the same program on an i386 machine and there everything works
> when run as a normal user with the same lines in /etc/udev/permissions.rules.
I always have to re-do my permissions.rules file after an upgrade.
Check that your mods are still present. Aside from that possibility, I
have no idea.
Cheers,
a
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian ADM64 Etch (testing/unstable) system freeze
On Fri, Jan 27, 2006 at 01:57:59AM +0200, Rami Saarinen wrote: > On Thursday 26 January 2006 15:21, Andrew Syrewicze wrote: > > I wouldn't rule out the possibility of your processor getting to hot. The > > newcastle cores aren't as solid as venice cores, and i hear they run a > > little hotter too. I use a venice core and i can overclock the crap out of > > that thing. (with a huge thermaltake fan on it of course ) :-P. > > > > Anyway i would start by checking your cpu temp. I would first check in > > BIOS. > > Froze two times again today. First time I was moving a 2.1 Gb file to another > location on the disk and the second time I was doing the same as in the my > previous post. This time I was lucky as there was actually some output. > > First time froze with: "kernel stack segment [1]" > and the second: "general protection fault " > > Afrer reboot I checked the temperature from BIOS - 32 celsius, so it is not > overheating issue. > > I doubt the memory issue also as I'd expect alternating symptoms like > programs > crashing etc. not just full system freeze every time. (?) > Thanks for everyone for help. I don't know why you would assume that. Memory problems can cause any/all of these symptoms, but don't have to cause any particular one. It sure sounds like a hardware/memory problem to me. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How big will the 32-bit chroot end up being? What goes in these days?
On Fri, Jan 27, 2006 at 09:50:10AM +0100, Helge Hafting wrote: > Thomas Steffen wrote: > > >On 1/23/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > >>So, as I understand it, the following stuff would need to go into the > >>32-bit chroot (assuming one wants/needs these things): > >> > >>- Sun's J2RE > >> > >>- OpenOffice > >> > >>- Flash > >> > >>- RealPlayer/Helix/whatever > >> > >>- win32codecs + other misc A/V codecs one might scrounge up elsewhere > >> > >>- Any web browser that you want to be able to use Java/Flash/embedded > >>AV stuff in > >> > >>- the Acrobat Reader > >> > >>- cdrecord/cdrdao plus whatever front end you're using to call them > >> > >>Is that correct? Anything I'm missing? > >> > >> > > > >Don't forget all the dependencies that all pulled in by these apps. > >You might end up with nearly a typical Linux installation. > > > > > Not quite that bad. There is no need for the xserver for example, > as the 32-bit processes have no problem talking to the 64-bit server. > And of course the chroot don't need any utilities, bootup scripts, > window managers, printing subsystem, login software . . . You will need the printing client software, however. I discovered that when I tried to print from OO the other day. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How big will the 32-bit chroot end up being? What goes in these days?
On Tue, Jan 24, 2006 at 03:39:09AM +, [EMAIL PROTECTED] wrote: > > > Hi; thanks for your reply. No need to cc me; I read the list. > > Lennart Sorensen wrote: > > On Mon, Jan 23, 2006 at 05:34:13AM +, [EMAIL PROTECTED] wrote: > >> So, as I understand it, the following stuff would need to go into the > >> 32-bit chroot (assuming one wants/needs these things): > >> > >> - Sun's J2RE > > > > There is 64bit java as far as I know. Not sure about browser plugins. > > Heh. I had assumed that Sun didn't have an AMD64 version out; but > I just went and looked, and there it is. Thanks for the tip. You forgot I guess that Sun sells tons and tons of these machines now, so amd64 is likely to be well supported by their software. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: No swap on my Debian Sid system
On Mon, Jan 23, 2006 at 08:51:01PM +0100, Jack Malmostoso wrote: > Ok, this is funny. I doublechecked some things on my system, and here's a > couple of useful outputs: > > [EMAIL PROTECTED]:~$ cat /etc/mdadm/mdadm.conf > DEVICE partitions > ARRAY /dev/md2 level=raid1 num-devices=2 > UUID=9dae3f6b:a3e79fbb:6044c75b:9f1939bd > ARRAY /dev/md1 level=raid1 num-devices=2 > UUID=6f583480:58ae2560:eac2cfa7:882022da > ARRAY /dev/md0 level=raid1 num-devices=2 > UUID=877c34c4:dfed29c7:4338e75f:35082da1 > > So, /dev/md1 (the one created during installation for swap raid) exists, > but: > > [EMAIL PROTECTED]:~$ dmesg | grep md1 > md: md1 stopped. > > I asked myself why: > > [EMAIL PROTECTED]:~$ sudo /sbin/mdadm -Q /dev/md1 > Password: > /dev/md1: is an md device which is not active > /dev/md1: is too small to be an md component. > > And mdstat says: > > [EMAIL PROTECTED]:~$ cat /proc/mdstat > Personalities : [raid1] > md2 : active raid1 sda3[0] sdb3[1] > 229046656 blocks [2/2] [UU] > > md0 : active raid1 sda1[0] sdb1[1] > 14651136 blocks [2/2] [UU] > > unused devices: > > I looked for bugs on Debian and this one looks quite right (and s long > to read): > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294404 Yeah, udev and raid have a few problems to work out, although it works pretty well now. Mostly. For md0 anyway. I had a problem where my machine got power-outed, and when I booted it back up, the md0 raid device (root device) was running degraded. I never got the email, either ~:^) The tip off was that I was very used to the super fast read performance, which wasn't there anymore. When the box seemed "slow" I started poking around for the reason. Bottom line, you have to check your raid devices after a boot to make sure they're all up and running correctly. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: is it em64t ?
On Thu, Jan 12, 2006 at 11:38:08PM -0400, Peter Cordes wrote: > I think that's all wrong. The flags are more or less a decoding of the > CPUID result codes. > > As for HT, my dad's old laptop 1.7GHz P4-mobile (Northwood) has the ht > flag, but it sure as hell doesn't have two logical CPUs. I looked at (but > didn't really come close to understanding ;P) the relevant kernel code, and I Nak. Are you sure you are running an SMP kernel on it? The ht flag means that the processor is hyperthreading capable. If your dad's lappy doesn't show 2 cpus, it may be because HT is disabled in the BIOS. If the BIOS doesn't have an option for enabling HT, then check for a BIOS update! Some manufacturers actually shipped machines with HT capable processors in the early days that couldn't do HT. Doesn't mean the processor wasn't capable of it. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: boot failure: default kernel without ELF support
On Wed, Jan 11, 2006 at 12:01:05AM +0100, jose wrote: > > hi all, > > i've downloaded the latest debian amd64 iso cd from testing to install on my > turion64 notebook, i've choosed the 2.6.12-1-amd64-k8 kernel and the > installation went fine. > > at the first boot i have this error in endless loop : > > request_module: runaway loop modprobe binfmt-464c > request_module: runaway loop modprobe binfmt-464c I don't know what's causing this ... > after some googling it seems that this kernel is not compiled with ELF > support so it tries to load an external module. ... but that's definitely not it. You most likely are using some hideously old iso image with a long fixed bug in d-i. I think this was fixed in 2004 or something. Try the netinst iso, it should work pretty well. It downloads all the latest and greatest, and usually working best -- versions of everything. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eterm broken on AMD64
On Mon, Jan 09, 2006 at 09:02:52PM +0100, Andreas Fester wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > I suppose you are talking about bug #332781, > garbage characters in eterm on (amd)64 port. > > Laurence, > > I would like to help with this bug. I have created new > packages for libast and eterm, available at > > http://littletux.homelinux.org/debian/pool/main/liba/libast/ > http://littletux.homelinux.org/debian/pool/main/e/eterm/ > > They include fixes for the garbage bug and for > > #346907: libast: FTBFS: build-depends on removed xlibs-dev > > The AMD64 eterm package installs cleanly, and the > garbage is gone (making eterm much more usable again :-)) > > Maybe someone can build and check it on Sparc64... > > Would be great if you could upload it to make this annoying > bug disappear ... I second that, and mucho thanks for fixing this eterm bug! Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mount USB memory stick in 32 bit chroot as well
On Wed, Jan 04, 2006 at 09:14:12PM +, Koen Vermeer wrote: > On Wed, 2006-01-04 at 11:23 -0800, Andrew Sharp wrote: > > When you have bind mounted /media into your chroot, and after inserting > > the stick, does the directory media/Kingston exist inside the chroot? > > I'm not a gnome user, thank 5od, but I'm guessing that that directory > > gets created on the fly by gnomadness when you insert the stick. So, > > without anything inserted, she said, verify that the Kingston directory > > doesn't exist anywhere, then do the bind mount, then insert your > > memory, and see if the Kingston directory is created and exists inside > > the chroot. If so, then you have solved your basic problem. If not, > > then back to the drawing board. > > The directory is created after inserting the stick, but there is only > one file in there (.created_by_pmount). Following your recipe didn't > change anything, unfortunately. I can't tell if you answered the question or not. Does the directory show up in the chroot environment? If so, then your problem lies elsewhere, like maybe a permissions thing. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: System Monitor shows only 1 CPU (2 present)
On Wed, Jan 04, 2006 at 03:04:01PM -0600, Russ Cook wrote: > Hi all, > I'm running an AMD64 dual core processor, debian64 stable. > Sources.list is attached. My problem is that System Monitor 2.8.1 lists > only 1 CPU. I have a dual core processor, and kernel 2.6.14.4 is > compiled with smp enabled. The system logs show that both processors > are detected and enabled. I briefly was running etch, and System > Monitor did show both CPUs. I don't remember what version System > Monitor was at the time under Etch. I have since done a clean reinstall > of stable. > Might this be a problem from running stable? If not, can anyone offer > a suggestion? If I had to guess, which I do, then I'd guess the version of "System Monitor" [whatever that is] is stable is not capable of dealing with SMP under 2.6, but the newer version in etch (2.10.1-3) is. Possible? a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 64/32 with DRI
On Wed, Jan 04, 2006 at 03:36:42PM -0600, Stephen Olander Waters wrote: > On Wed, 2006-01-04 at 10:58 -0800, Andrew Sharp wrote: > > I think this started over DRI support for the ancient 7000 Radeon. > > However, I haven't seen any testing results posted. I know there is a > > comment in the code that it's experimental, but have you actually tried > > it and found it to be buggy? > > I believe this is the bug I am experiencing: > https://bugs.freedesktop.org/show_bug.cgi?id=5104 Hmm, is it possible to downgrade to X.org 6.7? Er, 6.8.2 is the version even in etch, so downgrading would be difficult. It looks to me to be 64-bit specific, like, it's iterating through a 4294967295 planes trying to do something the chip doesn't even support, instead of skipping that feature. So if you can live without DRI for a little while, they will probably have this fixed, or at least a patch available. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mount USB memory stick in 32 bit chroot as well
On Wed, Jan 04, 2006 at 06:51:51PM +, Koen Vermeer wrote: > Hi, > > I'm still trying to integrate the 32 bit chroot and the normal system as > much as possible, so that, from a user's point of view, it's just like > running a full 64 bits system. > > Currently, when I insert an USB memory stick, it gets mounted > automatically in /media/Kingston. This is done by gnome-volume-manager, > hal, dbus, pmount, and maybe even more programs are involved. Anyway, > I'd like to have it linked to /chroot32/media/Kingston as well. I can > easily mount /media as /chroot32/media, just like /tmp and /home, but > unfortunately, I don't see anything in /chroot32/media/Kingston after > inserting the memory. When you have bind mounted /media into your chroot, and after inserting the stick, does the directory media/Kingston exist inside the chroot? I'm not a gnome user, thank 5od, but I'm guessing that that directory gets created on the fly by gnomadness when you insert the stick. So, without anything inserted, she said, verify that the Kingston directory doesn't exist anywhere, then do the bind mount, then insert your memory, and see if the Kingston directory is created and exists inside the chroot. If so, then you have solved your basic problem. If not, then back to the drawing board. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 64/32 with DRI
On Tue, Jan 03, 2006 at 09:36:04AM -0600, Stephen Olander Waters wrote: > On Mon, 2006-01-02 at 20:35 +1100, Hamish Moffatt wrote: > > On Mon, Jan 02, 2006 at 01:45:16AM -0600, Stephen Olander Waters wrote: > > > Radeon 7000 DRI in xorg 6.8.2 is "unstable" apparently. See this > > > message: > > [...] > > > Man that sucks. > > > > That's ATI for you. > > I'm not using ATI's proprietary driver. I'm using the buggy open source > driver maintained by X.org which used to work just fine... Geez you guys sound like a couple of teenagers who just found their favorite football team. If the open source ATI Radeon driver has bugs you don't like, you are free to jump in and fix them. It works quite well for me on multiple systems including my amd64. I think this started over DRI support for the ancient 7000 Radeon. However, I haven't seen any testing results posted. I know there is a comment in the code that it's experimental, but have you actually tried it and found it to be buggy? a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is AMD-64 mature enough to start using? (possibly on K8V-MX moptherboard)
On Wed, Dec 21, 2005 at 04:56:59PM +0100, Goswin von Brederlow wrote: > Paolo Alexis Falcone <[EMAIL PROTECTED]> writes: > > > On 12/21/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> I have had it proposed to me that I might set up a server for > >> my LAN (Not the internet gateway) as a Sempron system running > >> Linux. Specifically, an Asus K8V-MX Athlon 64 motherboard, > >> an AMD Sempron64 2600, 512 meg DDR PC-3200 w/o ECC. > >> to quote from the quotation. > > >> My question is, is the Debian AMD64 platform ready for such use? > > It is quite widely used and apart from figuring out the initial > install on some new hardware nobody seems to scream about problems. My install experience went like this: I downloaded and burned a netinst iso, and the install failed miserably. I fooled around gentoo for a week, and then I stuck in the same iso again, and it succeeded amazingly well. I installed with dual nics using the forcedeth driver, the nvidiaPro chipset SATA, all worked seamlessly. This was the netinst iso for etch. I installed with mirrored root filesystem and all the nutty stuff. > >> I can see lots of complaints on the mailing lists, but that > >> doesn't make it clear whether troubles are normal or unusual. I see a lot of complaints on the list ... repeated with some regularity, but few new complaints. > Sarge is the reliable one. Unstable is unreliable and etch/testing is > mostly useless on amd64. The script handling our testing migration is > suboptimal and needs someone intrested in writing a full britney clone > that keeps in sync with debian where possible. Not sure where you get that idea about etch, but my experience is completely counter to that. I'm using etch, with nothing from the highly unstable sid, not even kernel packages. It seems like once every week or so I read a complaint about some problem with sid, like such and such library can't be installed because of broken dependencies and the like. I don't want to waste my time with that. > Imho at the moment etch is only good to downgrade package in case sid > breaks. Not as standalone use. I highly disagree. It's been working flawlessly for me and as stable as sarge on my non-amd64 machines. Of course, YMMV. > > For the purposes you mentioned the AMD64 machine would not only be > > seamless. It's also a very good/overkill setup :D I call that a "happy setup." > And if you hit any problems you can always back down to Debian i386 > and go 32bit. The speed difference is not that relevant and certainly > both are way fast enough to saturate the 100MBit ethernet. I would be quite surprised if that became necessary. I have solved my two problems (openoffice and a very specialized build environment compantibility) with the 32bit chroot solution, which was easier than I anticipated. It's my impression that with a little work tracking down special packages and instructions, you can get openoffice to work w/o the chroot nowadays. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: many lost ticks, clock drifts problems also with debian smp kernel?
On Sat, Dec 10, 2005 at 07:16:13AM -0500, mikepolniak wrote: > On 01:22 Sat 10 Dec , Andrew Sharp wrote: > > This must be specific to some chipsets as I do not have this problem on > > my SMP system running Debian kernel 2.6.12-whatever. > > This shows up when running dual cpu's under heavy load (compiling, > encoding etc) for an extended time. Define extended period of time. I do builds of my project dozens of times a day, they take about 5 minutes using 100% cpu of all four cores for that time period. Sometimes I do full builds, which uses 100% for about 25 minutes. Never the slightest problem. It currently has a 20 day uptime, but it would be 30 days if not for the fact that I had to power it down to mount it in a case. A sad day that was. ~:^) I should point out that the full build builds from scratch, gcc, glibc, libstc++, a whole bunch of java extension libs, a 2.4 kernel, and our software, in that 25 minutes. Does this AMD64 stuff rock or what? The dual xeon build server takes 2 hours to do the same work. a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: many lost ticks, clock drifts problems also with debian smp kernel?
On Fri, Dec 09, 2005 at 06:39:26AM -0500, mikepolniak wrote: > On 10:36 Fri 09 Dec , [EMAIL PROTECTED] wrote: > > > > > > Hi, > > > > I have a machine with an AMD64 x2 4800+ mounted on an asus A8V Deluxe. I > > have > > experienced massive clock drift problems with smp kernels from the fedora > > core > > 4 x86_64 distribution, also with the newer 2.6.14.3 kernel from kernel.org: > > > > -- > > dmesg : > > > > Losing some ticks... checking if CPU frequency changed. > > warning: many lost ticks. > > Your time source seems to be instable or some driver is hogging interupts > > rip 0x435036 > > --- > > > > I have tried the pci=routeirq, acpi=off, noapic, nolapic, no_timer_check, > > no_tsc... bootparams without any real succes, my system clock keeps on > > drifting > > away faster and faster after the system has been up for some time. > > > > My question to the list is : > > > > Are the debian amd64-k8-smp kernels also subject to this problem? > > > This is a kernel problem with SMP having unsynced TSC's running at > different freqs, supposedly fixed in kernel 2.6.14. Before 2.6.14 i > needed to boot with pci=noacpi and clock=pmtmr to solve the 'lost > 'ticks'. > > A Debian kernel won't change anything. assuming you have a similar config > (e.g. HPET_TIMER=y PM_TIMER=y). You may want to post this on the LKML. This must be specific to some chipsets as I do not have this problem on my SMP system running Debian kernel 2.6.12-whatever. a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DualCore Dual-Opteron Board - suggestion?
On Fri, Dec 09, 2005 at 08:08:40PM +0100, Lubos Vrbka wrote: > >No clue personally, just seems amusing given supermicro I believe is the > >company that doesn't even want to admit to making AMD compatible boards. > >:) > maybe it changed (see below) > > >You can go through their website looking at models and they only > >mention intel cpus. once in a while you can click on something, like > >say the SC812S-420C in the chassis section, clearly labeled as DP Xeon / > >EM64T in the chart, but once you go to the details of it, you discover > >that amazingly it apparently can also be had with opterons installed. > >About the only way to find anything non intel, is by random clicking, > >or doing a site search for opteron. They sure aren't trying to get you > >to buy their opteron offerings. Maybe that would make intel mad at them > >or something. I wonder if they have any experience dealing with opterons > >yet? I wonder what the service would be like if there is a problem in > >the bios. > well i think that there is some information: > http://www.supermicro.com/Aplus/motherboard/ > > the truth is, that tyan is our favorite :) it's classics after all... > and has sata... > http://www.tyan.com/products/html/thunderk8sdpro.html > however, the question is when it will be available - not possible to get > it in czech republic, nor in germany... maybe there is a shortage because dell is buying them all up. word on the street is that dell is going to starting selling amd64 systems early next year. i guess customer pressure can affect change. anyway, it sounds like what you need is a good contact in the US. ~:^) Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DualCore Dual-Opteron Board - suggestion?
On Wed, Dec 07, 2005 at 04:06:54PM -0500, Lennart Sorensen wrote: > On Wed, Dec 07, 2005 at 01:04:43PM -0800, mike wrote: > > > I believe there is an issue with kernels < 2.6.14-2 with Opteron SMP. > > > That is why I'm running 2.6.14-2 myself. > > > > > > The issue was an AMD errata rather than a bug with the kernel - > > > 2.6.14-2 contained a workaround. > > > > I think that's all that NUMA stuff right? It wasnt optimized properly > > or something... > > Probably the assumption that TSCs were synced between cores in a dual > core, which they apparently are not. Like I said, it's been working flawlessly, and, when I'm not home sick with the @[EMAIL PROTECTED] flu, I routinely work all four cores pretty hard during the day. No oopses, nothing. In fact, the only time it's been down was when I had to put it in a case. Sad day, that. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DualCore Dual-Opteron Board - suggestion?
On Wed, Dec 07, 2005 at 03:58:19PM -0500, Lennart Sorensen wrote: > On Wed, Dec 07, 2005 at 12:53:01PM -0800, Andrew Sharp wrote: > > I am running dual 265s on a K8WE, it is quite flawless. I installed > > with the standard netinst iso, the installation went w/o a hitch. I'm > > running with a 2.6.12 something kernel that it installed with, and I > > haven't had reason to upgrade. lm-sensors worked right out of the box > > as well as the dual gigabit NICs. > > Well sarge installs with 2.6.8 normally, so you either used another > installer or upgraded afterwards. etch Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DualCore Dual-Opteron Board - suggestion?
On Wed, Dec 07, 2005 at 11:45:18AM -0500, Austin Denyer wrote: > > On Wed, 07 Dec 2005 16:25:38 +0100 > Lars Schimmer <[EMAIL PROTECTED]> wrote: > > > > Just for a quick note: > > anyone has a suggestion for a dual-Opteron board for Dualcore opterons > > which works flawless under debian amd64? > > E.G. the Tyan Tiger K8WE looks nice for me, but does it run flawless > > with debian amd64? > > At least this board has to power up 4 firewire bus for us here. > > I'm not running dual-core, but I do run dual-processor (Opteron 246) on > the K8WE, and it runs great. > > You will probably want to use Len's 2.6.12 install cd though. I am running dual 265s on a K8WE, it is quite flawless. I installed with the standard netinst iso, the installation went w/o a hitch. I'm running with a 2.6.12 something kernel that it installed with, and I haven't had reason to upgrade. lm-sensors worked right out of the box as well as the dual gigabit NICs. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building amd64 kernels on i386
On Wed, Nov 30, 2005 at 05:18:15PM +0100, Brice Figureau wrote: > On Wed, 2005-11-30 at 16:57 +0100, Goswin von Brederlow wrote: > > Brice Figureau <[EMAIL PROTECTED]> writes: > > > I own an amd64 server on which no gcc environment has been installed for > > > security reasons. > > > > Point out to the server admin that not having a gcc is just stupid and > > not a security measure. > > First, that's not the point of my question ;-) It might be easier to just add the compiler, make your kernel, and then remove it. Rather than get a working cross build environment going on an i386 machine. Make note of all the packages installed and remove them afterwards. Or you could just create a chroot environment with all the packages installed, and when you're done, you could tar that up and save it on the i386 machine before deleting it off the "secure" machine. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: HP nx6125 cdrom problem
Disable your desktop software's automount/media handling daemon. a On Sat, Nov 26, 2005 at 10:51:17AM +0100, Stefan G?del wrote: > Hi, > > On Sat, 2005-11-26 at 14:27 +1100, martin Haig wrote: > > I've just installed debian-amd64 on a HP nx6125 AMD Turion(tm) 64 > > Mobile ML-40 with 2Gb of ram. Most things worked and I've tweaked > > other bits with info gathered from the web. One thing I have no idea > > about, is that when I boot without a cd in the drive I get a scrolling > > message, see dmesg below. When I have a cd in the drive all is OK. I > > think the OS sees the cdrom as a scsi drive. Any ideas how I can fix > > this or should I scrap all the setting up that I've done and > > reinstall? > > at first I would try the latest kernel from unstable: > linux-image-2.6.14-2-amd64-k8_2.6.14-3_amd64.deb > > As you can see here: > > > fstab > ... > > /dev/hdc/media/cdrom0 iso9660 ro,user,noauto 0 0 > > and here: > > > Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 > > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > > Probing IDE interface ide0... > > hda: ST9808211A, ATA DISK drive > ... > > hdc: TSSTcorpCD/DVDW TS-L532M, ATAPI CD/DVD-ROM drive > > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > > ide1 at 0x170-0x177,0x376 on irq 15 > ... > > hdc: ATAPI 24X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache > > your cdrom is configured and recognized as IDE/ATAPI drive /dev/hdc. > However, the next few lines indicate a problem with the drive access: > > > Uniform CD-ROM driver Revision: 3.20 > > ATAPI device hdc: > > Error: Not ready -- (Sense key=0x02) > > Incompatible medium installed -- (asc=0x30, ascq=0x00) > > The failed "Read Cd/Dvd Capacity" packet command was: > > "25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 " > > Since the drive is working OK if you boot with a cd in the drive, it > does'nt seem to be the drive that's broken. > > Greetings, > > Stefan > > > -- > 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]
Re: Kernel BUG at lib/radix-tree.c:347
On Thu, Nov 24, 2005 at 10:17:52AM -0800, Alex Malinovich wrote:
> I'm getting frequent (daily) hangs with my PC running 2.6.14 on AMD64.
> Every time the problem comes up I get the error below.
>
> For a bit of background here, I had tried 2.6.11 and 2.6.12 previously
> and had this same problem (with a different line number shown for
> radix-tree.c). I reverted to 2.6.8 with the old udev, and everything was
> fine. Once 2.6.14 came out I decided to give it another shot. While it
> has been behaving much better than .11 and .12 did, I'm still having to
> put up with kernel crashes.
>
> I have also run .11 and .12 (but not .14) in my i386 install on this
> same machine and I have had no problems.
>
> Any suggestions?
>
>
> Nov 23 21:08:37 localhost kernel: --- [cut here ] - [please
> bite here ] -
snip
> Nov 23 21:08:37 localhost kernel: Pid: 142, comm: pdflush Tainted: P
> 2.6.14-2-amd64-k8 #1
> Nov 23 21:08:37 localhost kernel: RIP: 0010:[radix_tree_tag_set+111/160]
> {radix_tree_tag_set+111}
snip
> Nov 23 21:08:37 localhost kernel: Call
> Trace:{__set_page_dirty_nobuffers+181}
> {:reiserfs:do_journal_end+2094}
> Nov 23 21:08:37 localhost kernel:{pdflush+0}
> {pdflush+0}
> Nov 23 21:08:37 localhost kernel:
> {:reiserfs:reiserfs_sync_fs+59}
> {sync_supers+128}
> Nov 23 21:08:37 localhost kernel:{wb_kupdate+42}
> {pdflush+0}
> Nov 23 21:08:37 localhost kernel:{pdflush+266}
> {wb_kupdate+0}
> Nov 23 21:08:37 localhost kernel:{kthread+205}
> {child_rip+8}
> Nov 23 21:08:37 localhost kernel:
> {keventd_create_kthread+0} {kthread+0}
> Nov 23 21:08:37 localhost kernel:{child_rip+0}
> Nov 23 21:08:37 localhost kernel:
> Nov 23 21:08:37 localhost kernel: Code: 0f 0b 68 a0 72 30 80 c2 5b 01 66 66
> 66 90 66 66 90 41 ff c3
I believe this is a know bug in reiserfs. Try XFS, JFS or ext3. I
suspect you will see the problem disappear.
Cheers,
a
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: any java/jre debs newer than 1.4?
On Tue, Nov 22, 2005 at 03:59:05PM -0500, Lennart Sorensen wrote: > On Tue, Nov 22, 2005 at 11:05:52AM -0800, Andrew Sharp wrote: > > Howdy, > > > > A while ago I saw a post that mentioned the java debs on a metalab > > server for 1.4, but I was wondering if anyone knew of some newer debs > > for, say, 1.5-ish? Or have people just been installing the stuff that > > they get directly from sun? > > .bin from sun + make-jpkg = debian package. ahahaha. completely forgot about this, even though that's how i installed java on my laptop, like, a year ago. sometimes when something is almost too easy, it doesn't stick in your brain. once again, debian/rules molto grazie, a Luckily, I don't have personal need for the browser plugin thang. I just need to be able to run the @#!$%i# java code that is part of our product at work. The real version uses gcj to compile the @[EMAIL PROTECTED]@ java, which works perfectly with the pure64 gcc, but the emulated version of the product needs the @#$!^&* sdk/jre/whatever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
any java/jre debs newer than 1.4?
Howdy, A while ago I saw a post that mentioned the java debs on a metalab server for 1.4, but I was wondering if anyone knew of some newer debs for, say, 1.5-ish? Or have people just been installing the stuff that they get directly from sun? Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Open office
On Tue, Nov 22, 2005 at 10:07:03AM +0100, Goswin von Brederlow wrote: > Rob van Kraanen <[EMAIL PROTECTED]> writes: > > > Hi all, > > > > I'm quite new with Debian 64-bits. > > I just installed it on my laptop and it's great :) > > I just had one question, openoffice is currently not available as a > > debian-package, does anyone know when it will be available? > > Also is openoffice 2 available on AMD 64? > > > > Regards, > > > > Rob > > Probably never. Maybe OOo 3 or 4. Er um hmm, but why has gentoo had OOo 2 working on their amd64 port for a while now? I'm considering just getting a gentoo precompiled package and untarring it on my system or actually trying to hack a deb out of it or something. If they can do it, there's no excuse for debian not having it. a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to install nvidia driver
On Mon, Nov 21, 2005 at 10:47:46AM +, Tony Power wrote: > On 11/21/05, Corey Hickey <[EMAIL PROTECTED]> wrote: > > > > > Hi again! > > > Now I have another problem. > > > After installing nvidia drivers, my consoles (ctrl+alt+F1,F2,...) have a > > > diferent color. Not the normal black and white. > > > Now I get blue (background) and white (characters) consoles, and most of > > the > > > times, fuzzy blue and white. Sometimes I get a complete white screen (no > > > charaters) that shows coloured lines progressively. > > > Anybody knows why is that? > > > > I've never seen that before, and I probably can't help. I have a few > > questions, though. > > > > 1. At what point are your consoles messed up? Do they look weird right > > after > > the nvidia module loads, or only after you start X and switch back to a > > console? > > They get messed up after I start X and then switch to console mode. (blue > and white) > And when I kill X with ctrl+alt+backspace (complete white screen) I've had this before. I'm not sure if the problem is with the video chip itself or the way it is integrated into the system, but basically your VGA font memory and possibly some other VGA settings aren't being restored properly. I used to have a shell script that would fix this for me, but I can't find it. IIRC it was just a simple command something like consolechars --char-height=8 or something like that. The console wasn't perfect after that, but quite useable. I put it into a shell script that was easy to type blindly, because until you run it, you can't see anything. I'm pretty sure switching to using a frame buffer would fix this, but I've never had much luck running a frame buffer setup. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X86_64 on Shuttle-XPC ST20G5
On Fri, Nov 18, 2005 at 03:23:40PM -0500, Lennart Sorensen wrote: > On Thu, Nov 17, 2005 at 03:49:52PM +0100, Thomas Drillich wrote: > > debian runs on that machine but suboptimal, here are some notes I send > > to the manufacturer support: > > > > ATI XPress 200 graphics: > > Currently the usage of X is only possible with the standard vesa > > module of the Xorg 6.8.2 server. If I use the ati fglrx driver the > > monitor flickers on every redraw, a multiple horizontal movement > > of the contents on the Monitor on every update of contents inside a > > window. > > It's an ati, that is how support for ati usually is in my experience. > Eventually they get it to work. > > > Hardware: > > ST20G5 BIOS: update on ft20s016 > > sata-hdd: Maxtor 6L200MD > > sata-dvd: Plextor Px-716sa (not useable) > > CPU: AMD Athlon(tm) 64 X2 dual core Processor 3800+ stepping 02 > > RAM: 2Gbyte -- 2x 1024MB Infineon DDR400 CL3 > > Kbd: Microsoft Natural Ergonomic 4000 > > Mouse: Logitech MouseMan Wheel at USB (not useable) > > Monitor: Philips 180P2 at DVI port > > Chipset: ULI 1573 > > > > Software: > > Linux 2.6.14 > > Debian Etch > > Xorg server 6.8.2 > > > > may you have Ideas to get rid of these problems > > Never buy anything with ATI chips on it. Especially to run linux. > Quite seriously. I won't. :) That's just too funny. This is pure rationalizing of all the hassles you've had to go through to get nvidia video cards working. Christ, you have to get a kernel module built and installed every time you make yourself a new kernel, what a PITA. I've got an ATI X300SE PCIe on my system, came right up with X when I installed etch, it works fast and furious, I didn't have to do anything except answer a couple of questions from debconf (or whatever) when it was installing. All the bending and twisting I've read on this list to get nvidia video cards working make me laugh when I hear ignorant comments like this. I've got a laptop with an nvidia controller, and I have to go throught the nvidia pain all the time. With this version of the driver, fonts are funky, with that version of the driver, you can't use kernel version xxx ... it's never ending. As for their chipset chips, I've no experience so I won't say anything. Perhaps they suck ~:^) My amd64 system (Tyan K8WE) is fabulous with the nforce4 chipset, I must say. To get 3d working, it's a bit of work regardless of which you choose. For for fast and easy as pie 2d, ATI just works. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ip own modem/router ADSL
On Tue, Nov 15, 2005 at 09:55:13AM +, antonio giulio wrote: > > go to www.whatismyip.com > > Sorry, > > my request it's only via shell, without using external addresses for > various web-sites (and I have not password to log in router). > Just an "internal" procedure if it's possible. Let's see, you can't get to external addresses ... why do you care what your internet address is? Use a text browser like lynx www.whatismyip.com I don't think doing a dig on your gateway will tell you anything useful. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to install nvidia driver
On Sun, Nov 13, 2005 at 04:01:46AM +0100, Christoph Fassbach wrote: > Well, > > I did not read any of the refered pages yet. I did not know why I should. > Right now I am using an GeForce 6600LE powered PCI-X card with the I'm sure you meant PCI-E. Although many of us may wish it, no manufacturers are making PCI-X video cards. Even though they should. a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
qps package for amd64: fixed for 2.6MP and depends
I may be the only person who likes this program, but qps is my favorite graphical ps utility. It has a bug in that it's broken for 2.6 kernels on MP machines (all archs). I submitted a patch with a bug report on it ages ago, but nothing. Also, it currently has build depends that conflict with install depends -- sheez. Anyway, I've built a version for amd64 with those problems fixed (it depends on libqt3-mt, not libqt3-mt-c103whatever-nonsense, which in turn depended on gcc-3.3-base or something stupid like that). Let me know if you want it. I've got etch installed, so I'm guessing it depends on etch's glibc version and all that. a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem with NICs on Amd64 installer
On Thu, Nov 10, 2005 at 06:45:43PM +, David Goodenough wrote: > Hi, > > I am new to Amd64, but have been using Debian for a long time. > > I was asked to install Debian on a couple of 1U servers running AMD-64 > CPUs. They have NICs that require the TG3 driver. > > I got hold of the sid D-I business card ISO, and booted it up. It booted > just find and correctly identified the need to load the TG3 driver. But > it then failed to load it, and if I change to the second console and try to > use modprobe explicitly it says that the TG3 driver is not found. > > Now I know there was a problem with the TG3 driver in that it required > binary firmware, but I understand that there is now a version which > does not need the firmware but does not enable all the facilities. The tg3 driver doesn't need/use firmware. I've heard from several sources that there is some amd64 hardware that has built in NICs that detect as tg3 but the driver either doesn't load or loads but doesn't work. It could be the case that it's being mis-detected, or it's such a new variant on Broadcoms tigon family that the tg3 driver doesn't like it. You might try the GPL'd Broadcom source for bcm5700, but that probably won't help you during install. > Having failed with that driver I then tried to plug in a USB ethernet > adapter which would have needed the pegasus driver. But that is > not auto-detected and again not loadable. > > There is a PCI slot spare, but it does not seem designed for > ethernet cards in that I don't think I can get connected to it. You mean for physical reasons, like there is no case opening? Perhaps you need a PCI riser card to use the slot. a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RAID
On Thu, Nov 10, 2005 at 01:46:08AM -0600, Colin Baker wrote: > lordSauron wrote: > > >okay... so, let's just say that hypothetically I choose to be a little > >less than intelligent and try to use the motherboard built-in software > >RAID. Would that work? > > > >Also, I'm a little skeptical of Linux's software RAID being better > >(ie. faster) than my motherboards. Is there any statistics I can look > >at in regard to this? > > > >Once more, thanks for your considerable patience in dealing with me - > >someday I might evolve into a semi-respectable linux sub-guru... > > > > > > Don't have any numbers to point you toward, but I would expect them to > be pretty much the same. In either case, your CPU handles the > mirroring/striping. One method (linux or your motherboard's controller) > may just be more efficient about it than the other. Exactly. The important thing to remember is that the "onboard" chipset raid IS software raid, just not linux kernel software raid. Other than that, the only difference is that chipset raid provides boot support for clueless loaders. Say "Winblows." But it's really just software raid in the BIOS, with the CPU doing all the heavy lifting as usual. Since both lilo and grub support linux software raid, there really isn't anything to discuss, and linux software raid is supported with all the tools and whatnot. There's just no reason at all to use the chipset raid. a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Temporary 'lock-up' under heavy write, MegaRAID RAID-5
On Thu, Nov 10, 2005 at 08:11:17AM +, Dave Ewart wrote: > On Wednesday, 09.11.2005 at 22:07 -0800, Andrew Sharp wrote: > > > [...] > > > > This whole thread may be OT for this list, but you guys running 4 way > > SMP opterons with three whole drives in a raid 5, throw away those > > raid cards and just use the software raid. > > That's a perfectly sensible suggestion and I'm guessing it would work > reasonably well. > > However, the system in question is a live system and it's not easy to > simply change the disk arrangement on the fly: we are unfortunate in > that the problem of "some apps locking-up during heavy write conditions" > only manifested itself once the system was deployed and came into heavy > use. Ah, a production system. Drat. > However, I am planning on flashing the BIOS on the RAID controller > during our next maintenance window. If that doesn't fix it, then we can > perhaps try a backup-n-restore and use software RAID. Hopefully that will fix it. > Are you implying that the RAID card (or the megaraid driver) is faulty? > Would you suggesting using a different controller in this case? Well, no, not necessarily faulty, but some default parameters might not be agreeing so well with some other default parameters. Like stride size and disk cache size, fs type, etc. Hopefully the raid card's default stride size doesn't disagree with its own cache size. And all this is ruling out that there isn't something specific that needs to be done to this card/setup to pull the cork out. Have you googled? a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Temporary 'lock-up' under heavy write, MegaRAID RAID-5
On Wed, Nov 09, 2005 at 06:42:37PM +0100, Markus Boas wrote: > Am Mittwoch 09 November 2005 12:25 schrieb Joost Kraaijeveld: > > On Wed, 2005-11-09 at 11:46 +0100, Dave Ewart wrote: > > > The above system is incredibly fast under almost all conditions, except > > > when writing very large files (say, 100s of MB, or even GB). When > > > > > > > > > Any other suggestions or reports of similar experiences? > > > > Sorry, no solution, but a me too post. I have similar experience with a > > 2-way Opteron, 3Ware9500 SATA RAID5 with 5 disks: short updateing > > transactions with PostgreSQL fly, long updates start fast but after a > > few seconds everthing locks up, and the update lasts forever. > > > Adaptec 3410s had at starting the same troble. Also Raid 5 with 5 disks. > By updateing the "Bios" of the raid-controller it is better. > Dual Xeon This whole thread may be OT for this list, but you guys running 4 way SMP opterons with three whole drives in a raid 5, throw away those raid cards and just use the software raid. Then try those tests. Also try and measure the amount of cpu overhead the software raid incurs. A lot of people don't use software raid because 'It uses some CPU, doesn't it?' I tell them, get over the fear and measure. Then decide. On processors like these, max io performance can be had for about 3-5% of one of the 4 cpus. Sure beats kicking back and cleaning out your briefcase every time someone does a write. And when you measure, measure write performance, and use something like bonnie, which will tell you the cpu overhead and other useful info. The IO wait data is also good to know. Despite what many anecdotally informed people will tell you, software raid is almost always way faster. Think about it: a modern processor running at multiple GHz rates with DDR/DDR2 memory, and MMX instructions versus some tiny little CRC hardare cell on a card running at 50/100 MHz. It's not even a fair fight. And typically at the limits of your hardware, the CPU is barely even off idle dealing with it. The only way to know for sure is to try both and see which one you're happiest with. Also, many, many factors can interact subtley to affect raid performance, and often have to be experimented with to find out the best combination. Stride size, raid controller cache size, disk cache size, controller capabilities/limitations, file system block size, file system capabilities/limitations. XFS has typically worked vastly best for me, then JFS, then ext3, and lastly, reiserfs, which I have had some *very* bad experiences with. a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
