[PATCH 2.6.12.4] sata_sis.c: Introducing device ID 0x182

ipset and then transfered the hard disk to the new system, looks like the new chipset is compatible enough to run without problems. Regards Rainer Patch signed-off-by: Rainer Koenig <[EMAIL PROTECTED]> --- linux-2.6.12.4/drivers/scsi/sata_sis.c 2005-08-05 09:04:37.0 +0200 +++ li

Re: SATA status report updated

PC platforms and we already got anouncements that future platforms will come with SATA only. So can't emphasize enought that SATA support is absolutely important for Linux on the desktop. If there is something I can do to help or contribute let me know. Best regards Rainer -- Dipl.-Inf

Re: SATA status report updated

Hi Jeff, Jeff Garzik <[EMAIL PROTECTED]> writes: > Here is a list of problems with the patch. I'll paste this into the > bug as well: [Lot of interesting issues] > 8) The DMA pad code is very buggy. It uses the dma_map_single() to > map a buffer, but never synchronizes nor flushes the buffer.

Re: SATA status report updated

Hi Simon, Simon Oosthoek <[EMAIL PROTECTED]> writes: > Unfortunately I'm not able to check the logic of the driver, because > although I can read C, I'm totally unfamiliar with the disk controler > logic in the kernel... Well, today I've spent some time in looking at the SiS driver and compared

[x86_64] SATA disks on ICH5 not detected in 2.6.{8,9}

(and not before in any testing environment) makes me think that there much sense in using part of my ressources for testing of new kernels. Thanks for reading this, comments are welcome. Rainer P.S.: I'm not subscribed to the LKML, but I read it via the NNTP gateway. -- Dipl.-Inf. (FH) Ra

Re: How do I debug PCI resource allocation problems

Am Freitag, 9. November 2007 00:51 Robert Hancock wrote: > Rainer Koenig wrote: > > > > Ok, short description of the problem: > > > > I run 64-bit Linux using 2 GB of RAM, no problem at all. Then I turn off > > the machine, add 2 more GB so that now I have 4 GB of

How do I debug PCI resource allocation problems

This will get long, sorry. But I'm a bit desperate because I encounter strange problems on a new mainboard with Intel Q35 chipset and a shared memory graphics card. The logs and data I use here are from a SLED10 SP1 (x86_64) installation, but the problem occurs whatever distribution I try out.

How do I analyze a soft lockup?

Hi there, Environment: Kernel is 2.6.16.27, arch x86_64 on a Dual Core AMD64 machine with 4 GB of RAM. Also involved is an Areca 1100 SATA RAID controller with the drives from the Tekram website. Problem: We get customer reports that a system stops with the following kernel messages (as they

sched: How does the scheduler determine which CPU core gets the job?

ed the details how the scheduler works. But that's why I'm asking here. So, if anyone has an idea what to look for please post it here and add me to Cc: TIA Rainer -- Dipl.-Inf. (FH) Rainer Koenig Project Manager Linux Clients FJ EMEIA PR PSO PM&D CCD ENG SW OSS&C Fujitsu T