Problem with GTK
Hi, when I try to start "xsane" I get the following erroremessage. GdkPixbuf-WARNING **: Error loading XPM image loader: Bildlader-Modul konnte nicht geladen werden: /usr/lib32/gtk-2.0/2.10.0/loaders/libpixbufloader-xpm.so: /usr/lib32/gtk-2.0/2.10.0/loaders/libpixbufloader-xpm.so: wrong ELF class: ELFCLASS32 I get the same message with other gtk-tools. I tried google ... there is an entry in /etc/gtk-2.0/gdk-pixbuf.loaders - /usr/lib32/gtk-2.0/2.10.0/loaders/libpixbufloader-xpm.so" "xpm" 0 "gtk20" "The XPM image format" "image/x-xpixmap" "" "xpm" "" "/* XPM */" "" 100 --- It's Debian unstable. Regards Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: resizing partition with Windows Vista
> Googling for a solution, the only one seems to > be to buy a partitioning proprietary software that knows how to resize > NTFS partitions with Vista on it. Has anybody been successful resizing > such a partition to create space for a dual boot system? Dear Seb, This past spring I bought a Dell computer and was able to shrink the Vista partition so that I could install Debian and have a dual boot. Originally I had a 'Dell Utility' partition of about 58 MB, then a small partition (I forget what was there), then the Vista partition of about 228 GB, then another small partition of free space. When I tried to use the Windows utility to shrink the Vista partition I found that it would only free up about 77 GB. (It tells you how much space you will get before actually doing it.) Because I have the Vista system restore disk I decided to go ahead and re-partition the drive using the Debian install CD. First I ran the Vista defragmentation routine twice, then in the Debian install I resized the Vista partition to about 50 GB. The installation went fine, and at the end Grub installed the boot routine in the MBR. Peter Christensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Software vs Hardware RAID 10?
On Sun, Aug 26, 2007 at 10:42:40AM -0400, Lennart Sorensen wrote: > I just figure it out by the numbers. Maximum on plain PCI is 33MHz x > 32bit = 132MB/s. There is a bit of overhead so expect maybe 100MB/s > actual throughput. 66MHz pci would double that, 64bit PCI would double > it too, and PCI-X can be 100 or 133MHz which gives even more. PCIe has > I believe 250MB/s (in each direction so you can read and write at the > same time unlike PCI) per lane, so x4 would have 1GB/s and x8 would have > 2GB/s. Once you get to 2GB/s you are starting to approach the limit of > the cpu bus (athlon 64's hytertransport does 6.4 to 8 GB/s depending on > the chipset and cpu model in each direction). At an effective 1066MHz > by 64bit intel's bus does about 9GB/s (although combined, not each > direction). What about SATA ports on the main board? dmesg shows that ata1 and ata2 are on one interrupt, ata3 and ata4 on another, etc Since SATA is still ATA, if you have two drives in software raid1, should they be on ata1 and ata3 or is ata1 and ata2 OK (unlike PATA)? This is an Asus M2N-SLI Deluxe AM/2 MB, Athlon64 running Etch amd64. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: AMD64 X2 questions
On 08/26/07 11:26:27PM +0200, Michael wrote: > > Just to avoid confusion...cpuset seems to be the kernel thing, and taskset is > the related userspace tool ? > Yes taskset is the userland tool for setting CPU affinity but it's only for setting CPU affinity while cpusets also restrict the nodes from which a process is allowed to allocate memory in addition to CPU affinity. > > What is an 'optical imbalance'? > > If one pane of the load-monitor is green and the other is black ;) > It looks like it's not 'balanced' but you really clarified that issue now. > Ah, ok. Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Software vs Hardware RAID 10?
On Sun, Aug 26, 2007 at 09:59:47AM -0500, Neil Gunton wrote: > Interesting! Unfortunately, this is an existing server, it's all I've > got and I have to make the best of it. I would certainly be willing to > ditch the Adaptec RAID card if it helped improve things for software > RAID. I vaguely know that more SCSI channels is better... however I > don't know if motherboards generally have more than one SCSI channel... > is there any way to tell that? > > slim:~# lspci -v > 00:06.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07) > (prog-if 00 [Normal decode]) > Flags: bus master, 66MHz, medium devsel, latency 64 > Bus: primary=00, secondary=03, subordinate=03, sec-latency=64 > I/O behind bridge: 9000-bfff > Memory behind bridge: fc90-feaf > Capabilities: [c0] HyperTransport: Slave or Primary Interface > Capabilities: [f0] HyperTransport: Interrupt Discovery and > Configuration > > 00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC (rev 05) > Subsystem: Advanced Micro Devices [AMD] AMD-8111 LPC > Flags: bus master, 66MHz, medium devsel, latency 0 > > 00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE (rev > 03) (prog-if 8a [Master SecP PriP]) > Subsystem: Advanced Micro Devices [AMD] AMD-8111 IDE > Flags: bus master, medium devsel, latency 32 > I/O ports at ffa0 [size=16] > > 00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 (rev 02) > Subsystem: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 > Flags: medium devsel, IRQ 10 > I/O ports at cc00 [size=32] > > 00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05) > Subsystem: Advanced Micro Devices [AMD] AMD-8111 ACPI > Flags: medium devsel > > 00:0a.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge > (rev 12) (prog-if 00 [Normal decode]) > Flags: bus master, 66MHz, medium devsel, latency 64 > Bus: primary=00, secondary=02, subordinate=02, sec-latency=64 > Memory behind bridge: fc60-fc8f > Prefetchable memory behind bridge: > f640-fc4f > Capabilities: [a0] PCI-X bridge device > Capabilities: [b8] HyperTransport: Interrupt Discovery and > Configuration > Capabilities: [c0] HyperTransport: Slave or Primary Interface > > 00:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01) > (prog-if 10 [IO-APIC]) > Subsystem: Advanced Micro Devices [AMD] Unknown device 36c0 > Flags: bus master, medium devsel, latency 0 > Memory at febff000 (64-bit, non-prefetchable) [size=4K] > > 00:0b.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge > (rev 12) (prog-if 00 [Normal decode]) > Flags: bus master, 66MHz, medium devsel, latency 64 > Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 > Capabilities: [a0] PCI-X bridge device > Capabilities: [b8] HyperTransport: Interrupt Discovery and > Configuration > > 00:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01) > (prog-if 10 [IO-APIC]) > Subsystem: Advanced Micro Devices [AMD] Unknown device 36c0 > Flags: bus master, medium devsel, latency 0 > Memory at febfe000 (64-bit, non-prefetchable) [size=4K] > > 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > HyperTransport Technology Configuration > Flags: fast devsel > Capabilities: [80] HyperTransport: Host or Secondary Interface > Capabilities: [a0] HyperTransport: Host or Secondary Interface > Capabilities: [c0] HyperTransport: Host or Secondary Interface > > 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > Address Map > Flags: fast devsel > > 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > DRAM Controller > Flags: fast devsel > > 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > Miscellaneous Control > Flags: fast devsel > > 00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > HyperTransport Technology Configuration > Flags: fast devsel > Capabilities: [80] HyperTransport: Host or Secondary Interface > Capabilities: [a0] HyperTransport: Host or Secondary Interface > Capabilities: [c0] HyperTransport: Host or Secondary Interface > > 00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > Address Map > Flags: fast devsel > > 00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > DRAM Controller > Flags: fast devsel > > 00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > Miscellaneous Control > Flags: fast devsel > > 02:05.0 RAID bus controller: Adaptec (formerly DPT) SmartRAID V > Controller (rev 01) > Subsyst
Re: How to use aptitude
> So, if I have that right, I need to keep a close eye on > what aptitude offers to uninstall, if I previously used > 'apt-get install package' extensively? You always need to have a close eye on packages being additionally uninstalled. > I can abort, and use aptitude to install/reinstall said > important packages, and after that aptitude might better > resolve the original conflict in dependencies? Possible. You can set the package status explicitly in aptitude. But it's rarely necessary, except perhaps setting packages on 'hold' ( = key), in which case they won't get touched anymore, not even for upgrade. Of course, if you remove a lib they depend on, they remain broken. You will be shown broken things immediately after the first 'g'. You can configure the dependency handling, when and if aptitude should try to fix situations. Have a look at F10->Options. There's much useful stuff. You can anytime see the number of actually broken packages in the top bar, and search (/) for them explicitly with ~b. Search has a history (arrow up) btw. Usually conflicts are shown after 'g' in smart-scenario view, where you can decide about the best solution. You won't need plain apt-get anymore anyway. If you really like to do, you can always use aptitude as replacement from commandline. Well i don't pretend to have seen any possible case, and usually i try to avoid difficulties instead of solving them ;) all i can say is it's long since i needed apt-get, and most often surely to install aptitude on a base install. (But it's already in there nowadays, IIRR) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to use aptitude
On Sun, 26 Aug 2007, [EMAIL PROTECTED] wrote: On Sun, Aug 26, 2007 at 01:12:26PM -0500, Don Montgomery wrote: Michael, thanks very much. I have only used apt-* previously, I will check out aptitude. --Don WARNING: aptitude keeps track of which packages you requested explicitly, and which were only installed to satisfy a dependency. Unfortunately, ir t only knows you explicitly requested a package if you used aptitude to request it. This means you may find it offering to delete important packages if that would solve a conflict. If it does, it's a sign you need to exokicitly request something using aptitude! So, if I have that right, I need to keep a close eye on what aptitude offers to uninstall, if I previously used 'apt-get install package' extensively? And, in that case, I can abort, and use aptitude to install/reinstall said important packages, and after that aptitude might better resolve the original conflict in dependencies? Thanks, Don -- hendrik -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: AMD64 X2 questions
Just to avoid confusion...cpuset seems to be the kernel thing, and taskset is the related userspace tool ? > What is an 'optical imbalance'? If one pane of the load-monitor is green and the other is black ;) It looks like it's not 'balanced' but you really clarified that issue now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to use aptitude
On Sun, Aug 26, 2007 at 01:12:26PM -0500, Don Montgomery wrote: > > Michael, thanks very much. I have only used apt-* > previously, I will check out aptitude. --Don WARNING: aptitude keeps track of which packages you requested explicitly, and which were only installed to satisfy a dependency. Unfortunately, ir t only knows you explicitly requested a package if you used aptitude to request it. This means you may find it offering to delete important packages if that would solve a conflict. If it does, it's a sign you need to exokicitly request something using aptitude! -- hendrik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: AMD64 X2 questions
On 08/25/07 01:22:50PM +0200, Michael wrote: > > Thanks Lennart, thanks Jim, for the good points. > I think i can accept the matter of facts ;) > > It's generally a great fun to read your postings. > Just let me say thx here for sharing your insight. > That should apply to all those real freaks on this list. > > kr micha > > > ps. I imagine quadcore (and beyond) may be able to solve what appears a > little 'optical imbalance'. > I would be interested to know if linux has specific schedulers for these > archs but it's probably getting offtopic - i think quadcore is still rare at > least in PC world yet. > What is an 'optical imbalance'? No, Linux only has 1 CPU scheduler for all arches no matter how many CPUs are there. You can use cpusets to constrain processes to a specific set of memory and processors but they're never used automatically. Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to use aptitude
Michael, thanks very much. I have only used apt-* previously, I will check out aptitude. --Don On Sun, 26 Aug 2007, Michael wrote: Aptitude has nice scenario resolvers. It looks odd to someone not used to ncurses GUI and admittedly it's very special. But when it comes to difficult problems where you need intelligence and details there's probably nothing better, besides the apt commandline tools and dpkg itself. It's worth to learn the few main keys you need. First of all have F10 -> (right arrow)Help -> (arrow down)Help(Enter) for a first clue. Read them all and remember those you need mainly, like + - _ q / and arrow keys, enter, and g. Ctrl+u=undo After your choices are done, press g to see what would happen. Aptitude tries to resolve your requests, sometimes offering scenario alternatives. You can move back from the 'g' screen (main scenario) screen with 'q', or accept and start download with another 'g'. 'q' is generally an important key ;) Subscenarios have a small menu bar (next,previous,...) which works with arrow keys. Note that although there's custom to cancel or close a window with Esc key (sometimes quickly twice), in aptitude you need to activate a button (like OK) with Tab, then hit Enter. Old GNU custom, or maybe Unix i don't know. I say this because i know people who even couldn't finish the first installation because they simply didn't know ;) Usually even hard cases can be solved by deinstalling some packages temporarily. Often, upstream coders or maintainers upgrade to some requested library within days or weeks and the package becomes installable then. If that doesn't work for you you can tune your sources.list to include several alternatives, like testing/unstable/experimental. My experience is that i could trust apt (and aptitude) to great extend to manage this intelligent without even tweaking /etc/apt/conf.d. If there's something looking really unresolvable, it can often still be done via dpkg --force. Consider if you really need a package that hard that you risk to break something else, and if you can deal with occuring problems. Better ask this (or debian-user) list about it first. hth -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to use aptitude
Aptitude has nice scenario resolvers. It looks odd to someone not used to ncurses GUI and admittedly it's very special. But when it comes to difficult problems where you need intelligence and details there's probably nothing better, besides the apt commandline tools and dpkg itself. It's worth to learn the few main keys you need. First of all have F10 -> (right arrow)Help -> (arrow down)Help(Enter) for a first clue. Read them all and remember those you need mainly, like + - _ q / and arrow keys, enter, and g. Ctrl+u=undo After your choices are done, press g to see what would happen. Aptitude tries to resolve your requests, sometimes offering scenario alternatives. You can move back from the 'g' screen (main scenario) screen with 'q', or accept and start download with another 'g'. 'q' is generally an important key ;) Subscenarios have a small menu bar (next,previous,...) which works with arrow keys. Note that although there's custom to cancel or close a window with Esc key (sometimes quickly twice), in aptitude you need to activate a button (like OK) with Tab, then hit Enter. Old GNU custom, or maybe Unix i don't know. I say this because i know people who even couldn't finish the first installation because they simply didn't know ;) Usually even hard cases can be solved by deinstalling some packages temporarily. Often, upstream coders or maintainers upgrade to some requested library within days or weeks and the package becomes installable then. If that doesn't work for you you can tune your sources.list to include several alternatives, like testing/unstable/experimental. My experience is that i could trust apt (and aptitude) to great extend to manage this intelligent without even tweaking /etc/apt/conf.d. If there's something looking really unresolvable, it can often still be done via dpkg --force. Consider if you really need a package that hard that you risk to break something else, and if you can deal with occuring problems. Better ask this (or debian-user) list about it first. hth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: flash on amd64: my report
Looks like gnash works now at least for youtube stuff. (Still not for myspace.) Otherwise you can play flash flv files externally with vlc plugin. # Machine: x86_64 # Kernel: Linux 2.6.22-rc5-amd64 (custom) # Debian GNU/Linux lenny/sid # Installed: libc6 2.6.1-1 gnash 0.8.0~cvs20070611.1016-1+b2 gnash-tools 0.8.0~cvs20070611.1016-1+b2 libgnash0 0.8.0~cvs20070611.1016-1+b2 mozilla-plugin-gnash0.8.0~cvs20070611.1016-1+b2 mozilla-plugin-vlc 0.8.6.c-3 iceweasel 2.0.0.6-1 m°
Re: openoffice.org crashes testing
I am using oo 2.0.4 and linux 2.6.18-4-amd64. How do I upgrade open office without pulling everything else along with it? Thanks, Don On Sat, 25 Aug 2007, Michael wrote: Date: Sat, 25 Aug 2007 22:12:32 +0200 From: Michael <[EMAIL PROTECTED]> To: debian-amd64@lists.debian.org Subject: Re: openoffice.org crashes testing Resent-Date: Sat, 25 Aug 2007 20:18:17 + (UTC) Resent-From: debian-amd64@lists.debian.org Also, with oo 2.2.1-8, linux 2.6.22-rc5-amd64, and java j2re1.4 no problems. m° --
Re: HP DV9540 laptop AMD64 with nVidia G8400M graphic card will not start in X mode
* Lennart Sorensen <[EMAIL PROTECTED]> [2007-08-26 10:55:37 -0400]: > apt-cache show packagename > dpkg --info package.deb > To see what files a package is using: > dpkg -L packagename > To see what package owns a file: > dpkg -S /path/to/filename Thanks! -- Tux rox! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Software vs Hardware RAID 10?
Lennart Sorensen wrote: SCSI has no purpose to me anymore. SATA or SAS is the only type of drive I will consider for use. SAS is really quite impresive, although I tend to just use SATA for what I do. I don't run servers in my current job (someone elses job, and they do use SAS drives). Don't forget the scsi bus is a serious bottle neck. If all your drives at 320MB/s scsi drives, then you have a total of 320MB/s available for all transfers on that bus. That's about the same as a single SAS or SATA drive has for itself. Parallel scsi is seriously outdated and fortunately going away quickly now that SAS is available. Interesting! Unfortunately, this is an existing server, it's all I've got and I have to make the best of it. I would certainly be willing to ditch the Adaptec RAID card if it helped improve things for software RAID. I vaguely know that more SCSI channels is better... however I don't know if motherboards generally have more than one SCSI channel... is there any way to tell that? slim:~# lspci -v 00:06.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 64 Bus: primary=00, secondary=03, subordinate=03, sec-latency=64 I/O behind bridge: 9000-bfff Memory behind bridge: fc90-feaf Capabilities: [c0] HyperTransport: Slave or Primary Interface Capabilities: [f0] HyperTransport: Interrupt Discovery and Configuration 00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC (rev 05) Subsystem: Advanced Micro Devices [AMD] AMD-8111 LPC Flags: bus master, 66MHz, medium devsel, latency 0 00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE (rev 03) (prog-if 8a [Master SecP PriP]) Subsystem: Advanced Micro Devices [AMD] AMD-8111 IDE Flags: bus master, medium devsel, latency 32 I/O ports at ffa0 [size=16] 00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 (rev 02) Subsystem: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 Flags: medium devsel, IRQ 10 I/O ports at cc00 [size=32] 00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05) Subsystem: Advanced Micro Devices [AMD] AMD-8111 ACPI Flags: medium devsel 00:0a.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 64 Bus: primary=00, secondary=02, subordinate=02, sec-latency=64 Memory behind bridge: fc60-fc8f Prefetchable memory behind bridge: f640-fc4f Capabilities: [a0] PCI-X bridge device Capabilities: [b8] HyperTransport: Interrupt Discovery and Configuration Capabilities: [c0] HyperTransport: Slave or Primary Interface 00:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01) (prog-if 10 [IO-APIC]) Subsystem: Advanced Micro Devices [AMD] Unknown device 36c0 Flags: bus master, medium devsel, latency 0 Memory at febff000 (64-bit, non-prefetchable) [size=4K] 00:0b.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 Capabilities: [a0] PCI-X bridge device Capabilities: [b8] HyperTransport: Interrupt Discovery and Configuration 00:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01) (prog-if 10 [IO-APIC]) Subsystem: Advanced Micro Devices [AMD] Unknown device 36c0 Flags: bus master, medium devsel, latency 0 Memory at febfe000 (64-bit, non-prefetchable) [size=4K] 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration Flags: fast devsel Capabilities: [80] HyperTransport: Host or Secondary Interface Capabilities: [a0] HyperTransport: Host or Secondary Interface Capabilities: [c0] HyperTransport: Host or Secondary Interface 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map Flags: fast devsel 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller Flags: fast devsel 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control Flags: fast devsel 00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration Flags: fast devsel Capabilities: [80] HyperTransport: Host or Secondary Interface Capabilities: [a0] HyperTransport: Host or Secondary Interface Capabilities: [c0] HyperTransport: Host or Secondary Interface 00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address M
Re: HP DV9540 laptop AMD64 with nVidia G8400M graphic card will not start in X mode
On Sat, Aug 25, 2007 at 09:58:46AM -0400, Chris Ahlstrom wrote: > Is there any way to list all the dependencies of a package, or do a > manual verification of the web of dependencies? The "Examine/!Apply" in > aptitude is helpful. apt-cache show packagename dpkg --info package.deb To see what files a package is using: dpkg -L packagename To see what package owns a file: dpkg -S /path/to/filename -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Software vs Hardware RAID 10?
On Sun, Aug 26, 2007 at 09:46:26AM -0500, Neil Gunton wrote: > I guess the reason the YouTube guys used hardware RAID 1 and then put > software RAID 0 on top of that is that this means only sending the data > once, but with the kernel doing the striping you get improved > parallelization by seeing multiple SCSI devices rather than just one. > > One thing has occurred to me: The Adaptec 2015S is a zero-channel SCSI > RAID controller, which (I think) means it has no SCSI controller onboard > but rather uses the one on the motherboard. Apparently this saves space: > > http://www.avadirect.com/product_details_parts.asp?PRID=1740 Yeah I am not quite sure how the 'zero channel' controllers communicate with the actual scsi controller. Perhaps it actually ends up having to do all the pci bus transfers that software raid does, in which case I hardly see any benefit. Real raid cards have the drives connected directly so that you know they won't be wasting anyone elses bandwidth to do their work. > So... now I'm wondering if I could actually just remove the Adaptec > altogether and simply attach the SCSI drives directly to the > motherboard? Has anybody done that? Is it possible, or even a good idea? > I'm only thinking about this because maybe it would enable cutting one > more possible point of failure out of the equation, plus the fact that > the dpt_i2o drivers on AMD64 are still a pain in the ass. Of course I > wouldn't have hot-swap capability any more (I think?) because that's one > of the things that the Adaptec gives you... but, honestly, I really have > little knowledge of this stuff. I am pretty much poking around in the > dark with a flashlight here. Anybody got any real experience, please let > me know... SCSI has no purpose to me anymore. SATA or SAS is the only type of drive I will consider for use. SAS is really quite impresive, although I tend to just use SATA for what I do. I don't run servers in my current job (someone elses job, and they do use SAS drives). > I am liking the idea of software RAID. But the niggling thing in the > back of my mind is that for RAID 1, it might be better to use the > Adaptec, since it means only sending the data once. However... if the > Adaptec is using the motherboard's SCSI controller, then surely it too > must be sending the data twice over the SCSI bus. It's just doing it for > us, rather than the kernel doing it. I mean, all the four drives are > still on the SCSI, and if the Adaptec doesn't have its own SCSI > controller, then it must just be a middleman doing some additional work > that could just as well be done by the kernel. Or is that too naive? Don't forget the scsi bus is a serious bottle neck. If all your drives at 320MB/s scsi drives, then you have a total of 320MB/s available for all transfers on that bus. That's about the same as a single SAS or SATA drive has for itself. Parallel scsi is seriously outdated and fortunately going away quickly now that SAS is available. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Software vs Hardware RAID 10?
Lennart Sorensen wrote: Linux software raid (at least for raid 0 and 1 and combinations) is often faster than what a hardware raid card can do, and almost certainly better than what any fakeraid pulls off (since their drivers are often crap at doing the raid in software). raid 5 on the other hand can often be done faster by a dedicated xor engine, and since you don't have to do as much reading to write you reduce bus bandwidth. Probably the main advantage of hardware raid is reduced us usage since only the actual desired data goes over the bus, while with software raid, raid 1 involves twice as much bus traffic to write to both devices. I guess the reason the YouTube guys used hardware RAID 1 and then put software RAID 0 on top of that is that this means only sending the data once, but with the kernel doing the striping you get improved parallelization by seeing multiple SCSI devices rather than just one. Certainly many people run 3ware cards as just large driver controllers and use linux software raid on them to get the best performance. One thing has occurred to me: The Adaptec 2015S is a zero-channel SCSI RAID controller, which (I think) means it has no SCSI controller onboard but rather uses the one on the motherboard. Apparently this saves space: http://www.avadirect.com/product_details_parts.asp?PRID=1740 So... now I'm wondering if I could actually just remove the Adaptec altogether and simply attach the SCSI drives directly to the motherboard? Has anybody done that? Is it possible, or even a good idea? I'm only thinking about this because maybe it would enable cutting one more possible point of failure out of the equation, plus the fact that the dpt_i2o drivers on AMD64 are still a pain in the ass. Of course I wouldn't have hot-swap capability any more (I think?) because that's one of the things that the Adaptec gives you... but, honestly, I really have little knowledge of this stuff. I am pretty much poking around in the dark with a flashlight here. Anybody got any real experience, please let me know... If you have a fast cpu and you aren't using it for anything else (like is often the case on a file server) and if you don't cause your pci bus to be saturated, then software raid will probably be faster than hardware raid in general. I am liking the idea of software RAID. But the niggling thing in the back of my mind is that for RAID 1, it might be better to use the Adaptec, since it means only sending the data once. However... if the Adaptec is using the motherboard's SCSI controller, then surely it too must be sending the data twice over the SCSI bus. It's just doing it for us, rather than the kernel doing it. I mean, all the four drives are still on the SCSI, and if the Adaptec doesn't have its own SCSI controller, then it must just be a middleman doing some additional work that could just as well be done by the kernel. Or is that too naive? Thanks again, /Neil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Software vs Hardware RAID 10?
On Sun, Aug 26, 2007 at 09:00:10AM -0500, Neil Gunton wrote: > Interesting stuff. So how do you test your pci bus saturation? I just figure it out by the numbers. Maximum on plain PCI is 33MHz x 32bit = 132MB/s. There is a bit of overhead so expect maybe 100MB/s actual throughput. 66MHz pci would double that, 64bit PCI would double it too, and PCI-X can be 100 or 133MHz which gives even more. PCIe has I believe 250MB/s (in each direction so you can read and write at the same time unlike PCI) per lane, so x4 would have 1GB/s and x8 would have 2GB/s. Once you get to 2GB/s you are starting to approach the limit of the cpu bus (athlon 64's hytertransport does 6.4 to 8 GB/s depending on the chipset and cpu model in each direction). At an effective 1066MHz by 64bit intel's bus does about 9GB/s (although combined, not each direction). > I guess I will try and do a test with bonnie++ using both the hardware > and software RAID... will that be a reasonable test of the differences? I often just see what hdparm -t says for each disk, and for the software raid or hardware raid. Gives a vaque idea of the throughput ability of the setup, although of course it doesn't test what happens if everything is in use at once. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Software vs Hardware RAID 10?
On Sun, Aug 26, 2007 at 01:15:00PM +, Douglas A. Tutty wrote: > If the raid card was PCI-e, would it matter? Certainly better than plain PCI. More bandwidth. > Worst case for the bus would be data to and from the drive's cache. For > SATA-II, that's 300 MB/s. So to write to two drives at once it takes > 600 MB/s. Since each lane of a PCI-e has a raw max rate of 250 MB/s, > each drive needs two lanes to achieve this. So for a 5-port raid card, > it would need to be x8 (300 MB/s x 5 / 250 MB/s = 6). Are they > available? Or would there be contention within the north/south bridge > where all the buss lanes meet? > > How do file servers address this? Well I wouldn't worry about cache speed of the drives since it really doesn't matter most of the time. More reasonable is to expect 50 to 75MB/s sustained on a modern large drive. So with software raid1 you would use 100 to 150MB/s when writing and 50 to 75MB/s reading, while a hardware raid card would only need 50 to 75MB/s for either. Of course that is assuming the raid card can even work that fast (I have in the past seen cases where installing a serveraid 4 card running raid 1 was slower with the same disks than with the serveraid card, The raid card of course was simpler to manage since the system saw just one disk making booting and recovery much simpler, although software raid is pretty easy to manage too). You can certainly get x8 cards from areca and 3ware and others. If your board has a free x8 or x16 connector you can run such a card in that. The speed between the north and south bridge (on systems that have one) should not be a problem. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Software vs Hardware RAID 10?
Hi Neil (2007.08.26_16:00:10_+0200) > I guess I will try and do a test with bonnie++ using both the hardware > and software RAID... will that be a reasonable test of the differences? I've had a *bad* experince with hardware RAID... http://tumbleweed.org.za/2007/02/16/horrific-performance-with-3ware-raid/ SR -- Stefano Rivera http://rivera.za.net/ H: +27 21 794 7937 C: +27 72 419 8559 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Software vs Hardware RAID 10?
Lennart Sorensen wrote: If you have a fast cpu and you aren't using it for anything else (like is often the case on a file server) and if you don't cause your pci bus to be saturated, then software raid will probably be faster than hardware raid in general. Interesting stuff. So how do you test your pci bus saturation? I guess I will try and do a test with bonnie++ using both the hardware and software RAID... will that be a reasonable test of the differences? Thanks, /Neil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Software vs Hardware RAID 10?
On Sun, Aug 26, 2007 at 02:01:24AM -0400, Lennart Sorensen wrote: > Linux software raid (at least for raid 0 and 1 and combinations) is > often faster than what a hardware raid card can do, and almost certainly > better than what any fakeraid pulls off (since their drivers are often > crap at doing the raid in software). raid 5 on the other hand can often > be done faster by a dedicated xor engine, and since you don't have to do > as much reading to write you reduce bus bandwidth. Probably the main > advantage of hardware raid is reduced [b]us usage since only the actual > desired data goes over the bus, while with software raid, raid 1 > involves twice as much bus traffic to write to both devices. If the raid card was PCI-e, would it matter? Worst case for the bus would be data to and from the drive's cache. For SATA-II, that's 300 MB/s. So to write to two drives at once it takes 600 MB/s. Since each lane of a PCI-e has a raw max rate of 250 MB/s, each drive needs two lanes to achieve this. So for a 5-port raid card, it would need to be x8 (300 MB/s x 5 / 250 MB/s = 6). Are they available? Or would there be contention within the north/south bridge where all the buss lanes meet? How do file servers address this? Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
