Re: [suse-amd64] compile problems for Nat'l Instruments software - help, anyone?
Yes, I did those things, but it sounds like the NIKAL kernel module just
won't work on my 64-bit system. I was hoping to get around it, but I
may be stuck. . .
----- Original Message -----
From: Markus Koßmann
Hello all! I am new here (and pretty new to Linux, for that matter) and was referred here for some assistance.
Recently I built an AMD Sempron machine for my lab and installed SuSE> 10.0 x86_64. I want to install and run National Instruments software> (LabVIEW, NIDAQmx) to control my DAQ PCI card. There is a problem, however, with the compiling of the NI-KAL kernel module, upon which the rest of the installation seems to depend. The "./configure"
Am Mittwoch, 8. Februar 2006 17:11 schrieb Jonathan Puthoff: script that
I need to run prior to my "make" checks for a file called /usr/src/linux/include/asm/asm_offsets.h and returns an "kernel not configured correctly" error. asm_offsets.h is a generated file. Did you do a
cd /usr/src/linux make cloneconfig make prepare-all
to prepare the kernel sources for external module compilation ?
Hello *, Problem: frequent messages like this in syslog ( SLES 9 ) Mar 2 18:29:50 celsius01 kernel: hdi: drive_cmd: status=0x51 { DriveReady SeekComplete Error } Mar 2 18:29:50 celsius01 kernel: hdi: drive_cmd: error=0x04 { DriveStatusError } Mar 2 18:29:51 celsius01 [powersave_proxy][7632]: WARNING: hdparm returned error 5 Mar 2 18:29:51 celsius01 kernel: hdk: drive_cmd: status=0x51 { DriveReady SeekComplete Error } Mar 2 18:29:51 celsius01 kernel: hdk: drive_cmd: error=0x04 { DriveStatusError } Questions: -is there any resolution else than disabling write back cache or enabling write barrier with ext3 ? -can i disable write back cache for SATA Disks by command or only if BIOS provides this funktionality ? -if there is already a ext3 FS on the disk, can i change it without recreate to -o barrier=1 ? Kernel: Linux celsius01 2.6.5-7.252-smp #1 SMP Tue Feb 14 11:11:04 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux thx Micha
On Sunday 05 March 2006 14:26, Michael Arndt wrote:
frequent messages like this in syslog ( SLES 9 )
Mar 2 18:29:50 celsius01 kernel: hdi: drive_cmd: status=0x51 { DriveReady SeekComplete Error } Mar 2 18:29:50 celsius01 kernel: hdi: drive_cmd: error=0x04 { DriveStatusError } Mar 2 18:29:51 celsius01 [powersave_proxy][7632]: WARNING: hdparm returned error 5 Mar 2 18:29:51 celsius01 kernel: hdk: drive_cmd: status=0x51 { DriveReady SeekComplete Error } Mar 2 18:29:51 celsius01 kernel: hdk: drive_cmd: error=0x04 { DriveStatusError }
It just looks like a dying disk to me or a bad cable. Better get off the data quickly. Why do you think it's related to the barriers? -Andi
Hello Andy
It just looks like a dying disk to me or a bad cable. Better get off the data quickly. Why do you think it's related to the barriers?
The disks in question are brand new and two times exchanged Google References re the entries below pointed to write through cache / barrier problems if the hint you gave was not the most probable reason ... Mar 2 18:29:50 celsius01 kernel: hdi: drive_cmd: status=0x51 { DriveReady +SeekComplete Error }
Mar 2 18:29:50 celsius01 kernel: hdi: drive_cmd: error=0x04 { +DriveStatusError } Mar 2 18:29:51 celsius01 [powersave_proxy][7632]: WARNING: hdparm returned +error 5 Mar 2 18:29:51 celsius01 kernel: hdk: drive_cmd: status=0x51 { DriveReady +SeekComplete Error } Mar 2 18:29:51 celsius01 kernel: hdk: drive_cmd: error=0x04 { +DriveStatusError }
TIA Micha
participants (3)
-
Andi Kleen -
Jonathan Puthoff -
Michael Arndt