Problems with Wine on Debian AMD 64
Hi ,
I'm a total noob to linux so bare with me, I've had a friend help me
through alot of this so far.
I am trying to get 'wine' installed with 32bit libraries in order to
run some 32 bit applications.
Initially I started with installing ia32-libs and ia32-libs-dev
packages as per http://wiki.winehq.org/WineOn64bit
using apt-get.
After this we checked the symlinks as per http://wiki.winehq.org/WineOn64bit
Downloaded the source files, ran configure and than make when the
below message is returned.
"Relocatable linking with relocations from format elf64-x86-64
(/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.0GpWwq.o)
is not supported"
After this error was returned and we check what package contained
libsicuuc.a we than downgraded libicu36-dev to libicu34-dev this
didn't solve the problem. Thus after more bashing my mate stumbled
across the following article
http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg253544.html
which contained a patch. On attempting to apply this patch it returns
an error of
' patch: malformed patch at line 7:
TEST_ICUDATA_LIB="${ICUDATA_LIB-${i}data.a}" '
Can someone help, please I getting desperate to play CS: Source and DoD again.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: strange network problem
On Wed, 2006-11-01 at 19:19 -0500, Douglas Tutty wrote: > I agree that limiting the gigabit to 10 Mb/s is probably a kernel module > parameter but the forcedeth module is not mentioned in the kernel > documentation that I can see. (rgrep forcedeth .) I don't see it in any > of the generic networking kernel docs either. Hrm... the parameters don't look that helpful. You might contact the author, I guess. $ modinfo forcedeth filename: /lib/modules/2.6.18-1-amd64/kernel/drivers/net/forcedeth.ko author: Manfred Spraul <[EMAIL PROTECTED]> description:Reverse Engineered nForce ethernet driver license:GPL vermagic: 2.6.18-1-amd64 SMP mod_unload gcc-4.1 depends: alias: pci:v10DEd01C3sv*sd*bc*sc*i* alias: pci:v10DEd0066sv*sd*bc*sc*i* alias: pci:v10DEd00D6sv*sd*bc*sc*i* alias: pci:v10DEd0086sv*sd*bc*sc*i* alias: pci:v10DEd008Csv*sd*bc*sc*i* alias: pci:v10DEd00E6sv*sd*bc*sc*i* alias: pci:v10DEd00DFsv*sd*bc*sc*i* alias: pci:v10DEd0056sv*sd*bc*sc*i* alias: pci:v10DEd0057sv*sd*bc*sc*i* alias: pci:v10DEd0037sv*sd*bc*sc*i* alias: pci:v10DEd0038sv*sd*bc*sc*i* alias: pci:v10DEd0268sv*sd*bc*sc*i* alias: pci:v10DEd0269sv*sd*bc*sc*i* alias: pci:v10DEd0372sv*sd*bc*sc*i* alias: pci:v10DEd0373sv*sd*bc*sc*i* alias: pci:v10DEd03E5sv*sd*bc*sc*i* alias: pci:v10DEd03E6sv*sd*bc*sc*i* alias: pci:v10DEd03EEsv*sd*bc*sc*i* alias: pci:v10DEd03EFsv*sd*bc*sc*i* alias: pci:v10DEd0450sv*sd*bc*sc*i* alias: pci:v10DEd0451sv*sd*bc*sc*i* alias: pci:v10DEd0452sv*sd*bc*sc*i* alias: pci:v10DEd0453sv*sd*bc*sc*i* parm: dma_64bit:High DMA is enabled by setting to 1 and disabled by setting to 0. (int) parm: msix:MSIX interrupts are enabled by setting to 1 and disabled by setting to 0. (int) parm: msi:MSI interrupts are enabled by setting to 1 and disabled by setting to 0. (int) parm: poll_interval:Interval determines how frequent timer interrupt is generated by [(time_in_micro_secs * 100) / (2^10)]. Min is 0 and Max is 65535. (int) parm: optimization_mode:In throughput mode (0), every tx & rx packet will generate an interrupt. In CPU mode (1), interrupts are controlled by a timer. (int) parm: max_interrupt_work:forcedeth maximum events handled per interrupt (int) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: strange network problem
On Wed, Nov 01, 2006 at 04:31:35PM -0600, Stephen Olander Waters wrote: > On Wed, 2006-11-01 at 15:16 -0500, Douglas Tutty wrote: > > I just thought of something: those LAN-UDP modules specifically say > > that they do not work with gigabit ethernet. (and the switch is a > > 10/100, not a 10/100/1000). Even though the Athlon's port is connecting > > to the 486's 10 Mb/s NIC, could this be an issue? > > I agree with the poster before that you should manually set your gigabit > to 10mbit before loading LAN-UDP or any other network modules. I think > it's a kernel module parameter. > Clarification: LAN-UDP module referrs to a hardware-addon module to the surge supressor. I agree that limiting the gigabit to 10 Mb/s is probably a kernel module parameter but the forcedeth module is not mentioned in the kernel documentation that I can see. (rgrep forcedeth .) I don't see it in any of the generic networking kernel docs either. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Kernel 2.6.19-rc4 custom debian package
Dear friends, Because of several daily freezes under AMD64 + nvidia, I decided to make a custom 2.6.18-rc4 Debian package. I followed the normal procedure: * Download 2.6.18 kernel and patch agains 2.6.19-rc4 This is done by patch -p1 < patch.txt * cp /boot/config.xxx /usr/src/linux * make gconfig (and save) * make-kpkg kernel-image --initrd * make-kpkg kernel-headers After kernel installation and reboot, the freeze *** seem to dissapear ***, as I could copy three DVDs of DV content to my hard disc. Just a few questions: * How do I enable console debugging in the kernel. I heard it was possible, after a crash, to hit a few keys and display an error message. * What 64 bits kernel flavor should I choose? Debian chooses standard, but I have an Athlon64x2. Should I choose Athlon64 type? If people are interested, I can publish my kernel debs. But I doubt it is very interesting, as it is so easy to build a custom package with Debian. Kind regards, Jean-Michel Pouré -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: strange network problem
On Wed, 2006-11-01 at 15:16 -0500, Douglas Tutty wrote: > I just thought of something: those LAN-UDP modules specifically say > that they do not work with gigabit ethernet. (and the switch is a > 10/100, not a 10/100/1000). Even though the Athlon's port is connecting > to the 486's 10 Mb/s NIC, could this be an issue? I agree with the poster before that you should manually set your gigabit to 10mbit before loading LAN-UDP or any other network modules. I think it's a kernel module parameter. -s -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: strange network problem
On Wed, Nov 01, 2006 at 12:47:51PM -0500, Lennart Sorensen wrote: > I have had problems with NE2k cards doing that (specifically RTL8019A > based cards). > > > It seems strange that this would only happen now with the new computer. > > It wasn't an issue when I accessed my old P-II the same way (the P-II > > died which is why I built the Athlon). > > Maybe the auto negotiation is confusing it. Maybe something about the > gigabit ethernet is making it mess up. Once I've got the next lot of debs downloaded, I'll try seeing exactly what is happening when it locks up. Note that it is only the network connection, I can still operate both computers from the keyboard/screen. > You could try and force the nic on the amd64 to 10FD or whatever you > have the 486 configured for. Make sure you do configure both ends, > since 10mbit cards don't generally support auto negotiation. Can you point me to how to do that? Is there an option to put in /etc/network/interfaces? I don't see it in man interfaces nor in debian-reference. I see no mention of the forcedeth driver/module or options for in in the kernel-docs. The ISA card in the 486 is only 10 Mb/s. I don't think 100 Mb/s where ever available for plain ISA. Thanks. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: strange network problem
On Wed, Nov 01, 2006 at 07:22:58PM +0100, Adam Stiles wrote: > What's changed is that your two network cards are now connected directly > together, not connected through a switch. It's possible that some strange > voltages coming out of the Athlon are causing the network card on the '486 to > go into latch-up. It was doing this when connected via the switch. I removed the switch and changed to a cross-over cable to remove the switch from the equation. > [snip: technical discussion of voltage spikes] Both computers powered from the same dedicated circuit, in ajoining rooms. Each computer powered through a PowerMax modular secondary surge suppressor (includes a LAN-UDP module). I just thought of something: those LAN-UDP modules specifically say that they do not work with gigabit ethernet. (and the switch is a 10/100, not a 10/100/1000). Even though the Athlon's port is connecting to the 486's 10 Mb/s NIC, could this be an issue? > > Even if your network card is permanently damaged, NE2K-alike cards with the > old 16-bit connector are still available second-hand for not much money. > Realtek 8019 or 8029-based cards work well. > I haven't checked eBay for an NIC. However, I have ordered the 3Com Courier modem from eBay. Thanks for the ideas. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: strange network problem
On Wed, Nov 01, 2006 at 07:22:58PM +0100, Adam Stiles wrote: > What's changed is that your two network cards are now connected directly > together, not connected through a switch. It's possible that some strange > voltages coming out of the Athlon are causing the network card on the '486 to > go into latch-up. > > The input and output circuits of any CMOS IC are designed with diodes to each > power rail, business ends up, for static protection. In normal circumstances > both are reverse biased. If a negative voltage is applied, the bottom diode > goes forward-biased and clamps it to -0.7V. If a voltage greater than +5V is > applied, the top diode goes forward-biased and clamps it to +5.7V. Except > these aren't just ordinary diodes; they're more like a sort of cross between > a zener diode and a triac, and if you stick enough current through them while > forward-biased and maintain it for long enough then they stay conductive ever > after, or at least until you cut the power. > > One cause of these voltage spikes can be poor bonding between equipment > chassis. The metal chassis of a computer case is connected to mains earth. > If the earth connection is sound, the two chassis should be at the same > potential. > > Now, I notice from your e-mail address that you're in Canada, where they > don't > have quite as sophisticated an electrical system as we have here in the UK > (all wall sockets earthed and individually switched, all plugs non-reversible > and fused in the live phase, all sockets wired in one big ring). Plugs here are earthed (unless very old), unlike many places of europe that only recently started doing such things (say denmark for example). I have never understood why the brits believe every plug needs a fuse in it. Makes the plugs rather expensive, and the device ought to already have a fuse, as should the electrical panel of the house. Does anyone else on the planet use that system? Our plugs also can not be reversed unless the device was designed with a plug that specifically can be reversed. Again I know denmark that isn't the case. On the other hand denmark typically has residual current detector breakers, which we only seem to use in bathrooms and such here. Why we don't use them here I don't really know. > First, make sure the power sockets serving both computers are properly > earthed -- preferably using the proper test equipment. If there is a > problem, get it fixed as soon as possible because it could be a death trap. > Second, try running both computers from the same power socket, via a long > extension lead. > > > Even if your network card is permanently damaged, NE2K-alike cards with the > old 16-bit connector are still available second-hand for not much money. > Realtek 8019 or 8029-based cards work well. My 8019s did not work well. My 3c509 on the other hand does work well. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: strange network problem
On Wednesday 01 November 2006 16:21, Douglas Tutty wrote: > My 486 computer (ISA bus) has an internal modem and an ne2000 clone NIC. > Everything has been fine with this for years. > > My new computer . accesses the internet via eth0 to the 486 > connected now by cross-over cable after I disconnected the LinkSys > 10/100 switch while trying to solve this problem. > > I'm still in the process of getting things installed on the Athlon via > aptitude and haven't got xorg working yet although it is installed. > Until then, I access the Athlon (in the basement) via the 486 (upstairs) > via ssh. > > The problem I'm having is that the NIC on the 486 seems to die and only > starts to work again after I cycle the power on the 486. What's changed is that your two network cards are now connected directly together, not connected through a switch. It's possible that some strange voltages coming out of the Athlon are causing the network card on the '486 to go into latch-up. The input and output circuits of any CMOS IC are designed with diodes to each power rail, business ends up, for static protection. In normal circumstances both are reverse biased. If a negative voltage is applied, the bottom diode goes forward-biased and clamps it to -0.7V. If a voltage greater than +5V is applied, the top diode goes forward-biased and clamps it to +5.7V. Except these aren't just ordinary diodes; they're more like a sort of cross between a zener diode and a triac, and if you stick enough current through them while forward-biased and maintain it for long enough then they stay conductive ever after, or at least until you cut the power. One cause of these voltage spikes can be poor bonding between equipment chassis. The metal chassis of a computer case is connected to mains earth. If the earth connection is sound, the two chassis should be at the same potential. Now, I notice from your e-mail address that you're in Canada, where they don't have quite as sophisticated an electrical system as we have here in the UK (all wall sockets earthed and individually switched, all plugs non-reversible and fused in the live phase, all sockets wired in one big ring). First, make sure the power sockets serving both computers are properly earthed -- preferably using the proper test equipment. If there is a problem, get it fixed as soon as possible because it could be a death trap. Second, try running both computers from the same power socket, via a long extension lead. Even if your network card is permanently damaged, NE2K-alike cards with the old 16-bit connector are still available second-hand for not much money. Realtek 8019 or 8029-based cards work well. -- AJS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: strange network problem
On Wed, Nov 01, 2006 at 11:21:43AM -0500, Douglas Tutty wrote: > I'm hoping that you can help me track down the source of this problem so > that I can address it. > > My 486 computer (ISA bus) has an internal modem and an ne2000 clone NIC. > Everything has been fine with this for years. > > My new computer is an AMD64 Athlon 3800+ AM2 on an Asus M2N-SLI Deluxe > MB with its nVidia nForce 570-SLI chip. Graphics card is an Asus > EN7300GT silent (nVidia 7300GT), although graphics doesn't seem to be a > problem. This computer accesses the internet via eth0 to the 486 > connected now by cross-over cable after I disconnected the LinkSys > 10/100 switch while trying to solve this problem. > > I'm still in the process of getting things installed on the Athlon via > aptitude and haven't got xorg working yet although it is installed. > Until then, I access the Athlon (in the basement) via the 486 (upstairs) > via ssh. > > The problem I'm having is that the NIC on the 486 seems to die and only > starts to work again after I cycle the power on the 486. I have had problems with NE2k cards doing that (specifically RTL8019A based cards). I switched to 3c509 instead and never had a problem since. I found mine used at some computer junk sale some years ago. You may still be able to do so, but then again a p2 or p3 is cheap and much faster. > It seems strange that this would only happen now with the new computer. > It wasn't an issue when I accessed my old P-II the same way (the P-II > died which is why I built the Athlon). Maybe the auto negotiation is confusing it. Maybe something about the gigabit ethernet is making it mess up. > Is there any way that a bug in amd64 Etch on the Athlon could cause the > NIC on the 486 to freeze up? (this is why I'm posting to amd64) Well no, but a bad NIC design could lock up if it sees something that wasn't considered normal when it was made. > If so, I can start tracking that down. If this is impossible, I'll > assume that my NIC is toast and the times of connecting the 486 via an > NIC are over (as ISA NICs are unavailable). Just in case, I've ordered > a 3Com Courier V.Everything 3CP3453 modem from ebay to hook up to the > Athlon via the serial port. The 486 has a great ISA internal modem now > useless. > > uname on the 486: > Linux pluto 2.6.8-3-386 #1 Thu Sep 7 05:39:52 UTC 2006 i486 GNU/Linux > > uname on the Athlon: > Linux titan 2.6.17-2-amd64 #1 SMP Wed Sep 13 17:49:33 CEST 2006 x86_64 > GNU/Linux You could try and force the nic on the amd64 to 10FD or whatever you have the 486 configured for. Make sure you do configure both ends, since 10mbit cards don't generally support auto negotiation. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: System freeze
I could reproduce the bug: I have several backup DVD with large DV files from a camcorder. If I copy the DVD files to hard disc, after 1 or 2 DVDs, the systems freezees. If I reboot using the single grub line, I copy the DVDs to hard disc. The systems crashes with the following error: "processor lockup" and 1 page of error messages. How can I redirect the console somewhere to copy of the error message? Kind regards, Jean-Michel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
strange network problem
I'm hoping that you can help me track down the source of this problem so that I can address it. My 486 computer (ISA bus) has an internal modem and an ne2000 clone NIC. Everything has been fine with this for years. My new computer is an AMD64 Athlon 3800+ AM2 on an Asus M2N-SLI Deluxe MB with its nVidia nForce 570-SLI chip. Graphics card is an Asus EN7300GT silent (nVidia 7300GT), although graphics doesn't seem to be a problem. This computer accesses the internet via eth0 to the 486 connected now by cross-over cable after I disconnected the LinkSys 10/100 switch while trying to solve this problem. I'm still in the process of getting things installed on the Athlon via aptitude and haven't got xorg working yet although it is installed. Until then, I access the Athlon (in the basement) via the 486 (upstairs) via ssh. The problem I'm having is that the NIC on the 486 seems to die and only starts to work again after I cycle the power on the 486. It seems strange that this would only happen now with the new computer. It wasn't an issue when I accessed my old P-II the same way (the P-II died which is why I built the Athlon). Is there any way that a bug in amd64 Etch on the Athlon could cause the NIC on the 486 to freeze up? (this is why I'm posting to amd64) If so, I can start tracking that down. If this is impossible, I'll assume that my NIC is toast and the times of connecting the 486 via an NIC are over (as ISA NICs are unavailable). Just in case, I've ordered a 3Com Courier V.Everything 3CP3453 modem from ebay to hook up to the Athlon via the serial port. The 486 has a great ISA internal modem now useless. uname on the 486: Linux pluto 2.6.8-3-386 #1 Thu Sep 7 05:39:52 UTC 2006 i486 GNU/Linux uname on the Athlon: Linux titan 2.6.17-2-amd64 #1 SMP Wed Sep 13 17:49:33 CEST 2006 x86_64 GNU/Linux Thanks, Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: System freeze
On Wed, Nov 01, 2006 at 03:48:37PM +0100, Hans wrote: > if you look through all the messages in this list, you could make this > summary > (IMO) > > 1. Freeze at different graphic cards (nvidia and ati) = wipes out propritrary > drivers > > 2. Freeze with framebuffer = wipes out Xorg, as one option should be stable I didn't notice anyone saying they had a crash without X running. I may have missed it. > 3. Freeze with dual-core and single core = wipes out special kernel At least it doesn't appear to be SMP related then. > 4. Freeze on 32-bit and 64-bit =wipes ou tspecial system Well so far neither my A7V tbird 700 nor my A7N8X-E-DX XP 1700+ have had any crashes, and both run nvidia binary driver. Doesn't prove there isn't a bug, doesn't prove mine won't crash, just that it seems to only affect certain systems. > 5. Freeze on Ubuntu-Systems, too, and some Fedora-Core (someone mentioned > that) = wipes out special Debian-problem Certainly sounds kernel and certain hardware related. > 6. All ones report running kernel 2.6.18 or 2.6.17 = should wipe out kernel > itself, except some modules did not change from one version to the other The majority of the kernel is the same between those versions. > 7. It is a real bug, as it appears on all machines: notebooks and desktops It appears on some machines. > 8. I myself tested the modules with kanotix (using memtest) and, checked ever > bank single: No errors ! = wipes out hardware crash (additional would it be > fany, when so much hardware would die suddenly) Memtest fails to find most subtle errors, which is hardly surprising. > 9. I had some crashes, when I was on console, so I would have seen something > abnormal. But nothing was seen ! Th emachine just stopped. Well that is certainly annoying. Usually at least a nice crash dump is nice. Freezes are not. I wonder if a kernel with deadlock debuging enabled would be useful. alt+sysrq+stuff did nothing? > Well, I hope, this would help a little to stalk to the bug. Sounds like a tricky one. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: System freeze
Am Mittwoch, 1. November 2006 15:36 schrieb Lennart Sorensen: > On Mon, Oct 30, 2006 at 11:03:12PM +0100, Jean-Michel Pour? wrote: > > I recently bought an AMD64x2 dual-core desktop. > > > > The system is running Debian AMD64 SID. > > Unfortunately, I experience system freezes. > > > > The symptoms are similar to this Debian bug: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=379480 > > > > I disabled ntpd, without success as I just experienced a system freeze. > > > > Memory is Okay (tested). > > How did you test the memory? memtest is NOT sufficient. > > Unless you removed half the memory and reproducted the problem, then > tried the other half and reproduced the problem, etc in various > combinations. If it does solve the problem you have found a bad stick > of memory. If it doesn't then you simply don't know if the type of > memory is simply bad for the system, or if something else is the > problem. > > > I removed two PCI card and disabled unused interfaces. > > > > What do you think of AMD64 changes in the next 2.6.19 kernel? > > Will it fix my problem? > > Not sure. Some people have been complaining about failure to boot > 2.6.17-2.6.18 on some nvidia chipsets due to timer interupt bugs. last > I checked the kernel people were still waiting for an answer from nvidia > on how to work around the bug/setup the hardware correctly. > > You could try booting with 'noapic' or some of the other options. You > could try booting with the option to set the system to only use one cpu > in case it is an SMP bug. Lots of things you could try. Perhaps > enabling remote logging over a serial port would be handy in case there > is a kernel crash dump that could help show the real problem (which of > course you can't see if running X at the time). > > -- > Len Sorensen Hi Len, if you look through all the messages in this list, you could make this summary (IMO) 1. Freeze at different graphic cards (nvidia and ati) = wipes out propritrary drivers 2. Freeze with framebuffer = wipes out Xorg, as one option should be stable 3. Freeze with dual-core and single core = wipes out special kernel 4. Freeze on 32-bit and 64-bit =wipes ou tspecial system 5. Freeze on Ubuntu-Systems, too, and some Fedora-Core (someone mentioned that) = wipes out special Debian-problem 6. All ones report running kernel 2.6.18 or 2.6.17 = should wipe out kernel itself, except some modules did not change from one version to the other 7. It is a real bug, as it appears on all machines: notebooks and desktops 8. I myself tested the modules with kanotix (using memtest) and, checked ever bank single: No errors ! = wipes out hardware crash (additional would it be fany, when so much hardware would die suddenly) 9. I had some crashes, when I was on console, so I would have seen something abnormal. But nothing was seen ! Th emachine just stopped. Well, I hope, this would help a little to stalk to the bug. Best regards Hans -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: System freeze
On Mon, Oct 30, 2006 at 11:03:12PM +0100, Jean-Michel Pour? wrote: > I recently bought an AMD64x2 dual-core desktop. > > The system is running Debian AMD64 SID. > Unfortunately, I experience system freezes. > > The symptoms are similar to this Debian bug: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=379480 > > I disabled ntpd, without success as I just experienced a system freeze. > > Memory is Okay (tested). How did you test the memory? memtest is NOT sufficient. Unless you removed half the memory and reproducted the problem, then tried the other half and reproduced the problem, etc in various combinations. If it does solve the problem you have found a bad stick of memory. If it doesn't then you simply don't know if the type of memory is simply bad for the system, or if something else is the problem. > I removed two PCI card and disabled unused interfaces. > > What do you think of AMD64 changes in the next 2.6.19 kernel? > Will it fix my problem? Not sure. Some people have been complaining about failure to boot 2.6.17-2.6.18 on some nvidia chipsets due to timer interupt bugs. last I checked the kernel people were still waiting for an answer from nvidia on how to work around the bug/setup the hardware correctly. You could try booting with 'noapic' or some of the other options. You could try booting with the option to set the system to only use one cpu in case it is an SMP bug. Lots of things you could try. Perhaps enabling remote logging over a serial port would be handy in case there is a kernel crash dump that could help show the real problem (which of course you can't see if running X at the time). -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installing Debian amd64 on an asus P5W DH Deluxe + E6600 : kernel on installer broken + bugs in d-i when changing kernel + modules
On Mon, Oct 30, 2006 at 09:46:03AM +0100, Eric Valette wrote: > 2) Downloaded > ftp://ftp.fr.debian.org/debian/dists/unstable/main/installer-amd64/20061022/images/gtk-miniiso > burned it and booted it. Starts well but hangs after a while because of > spurious interrupts related to disk activities (SATA) endless reset of > controller. Have also spurious irq listed in dmesg. Did not know if a > kernel was correctly running on this mtherboard + CPU combination. So > tried to find another instable AMD64 distrib. Could you please file an installation-report? There are some tools in the installer that can show us more information about the hardare you're using. You can probably also run them on an installed system. Can you please show the messages the kernel reports? Is what you're seeing simular to: http://bugs.debian.org/309964 Or: http://bugs.debian.org/393977 Have you tried booting with options like noacpi and acpi=off? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: System freeze
On Wed, 2006-11-01 at 08:42 +0100, Jean-Michel Pouré wrote: > > dmesg | grep -i aperture > > Checking aperture... > > CPU 0: aperture @ 246000 size 32 MB > > Aperture too small (32 MB) > > How to setup Aperture? > In BIOS, video shared memory is set up to 128MB. > > Kind regards, > Jean-Michel It's a BIOS setting, but is hidden on many BIOSes. On Gigabyte boards, pressing Ctrl-F1 enables the hidden options in the bios config menu.
