[PATCH] radeonfb: Implement proper workarounds for PLL accesses

Hi ! After discussion with ATIs, it seems that the workarounds they initially gave me were not completely correct. This patch implements the proper ones, which includes sleeping in PLL accesses, and thus requires the previous patch to make sure we do not call unblank at interrupt time (unless

Re: select() doesn't respect SO_RCVLOWAT ?

On Thu, Mar 10, 2005 at 04:58:51PM -0500, Felix Matathias wrote: I am running a 2.4.21-9.0.3.ELsmp #1 kernel and I can setsockopt and getsockopt correctly the SO_RCVLOWAT option, but select() seems to mark a socket readable even if a single byte is ready to be read. Then, a read() blocks

Re: [PATCH, RFC 1/3] Add sem_getcount() to arches that lack it

Jody McIntyre [EMAIL PROTECTED] wrote: On Thu, Mar 10, 2005 at 08:55:03PM -0800, Andrew Morton wrote: Jody McIntyre [EMAIL PROTECTED] wrote: parisc and frv define sem_getcount() in semaphore.h, which returns the current semaphore value. This is cleaner than doing

2.4 fix for write throttling on x86 1G

Hello Marcelo, I've got a fix for you on 2.4. I got reports of stalls with heavy writes on 2.4. There was a mistake in nr_free_buffer_pages. That function is definitely meant _not_ to take highmem into account (dirty cache cannot spread over highmem in 2.4 [even when on top of fs]). For unknown

[PATCH] ppc64: Export proper version from vDSO

Hi ! The ppc64 vDSO is still exporting LINUX_2.6.11 (from -mm) for symbol versioning. The glibc folks asked me to export the first kernel version that will contain it, so this patch fixes it to LINUX_2.6.12 Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Index:

Re: inappropriate use of in_atomic()

Hi Andrew, On Thu, 10 Mar 2005 20:40:06 -0800 Andrew Morton [EMAIL PROTECTED] wrote: in_atomic() is not a reliable indication of whether it is currently safe to call schedule(). arch/ppc64/kernel/viopath.c in_atomic() in viopath.c was just used to determine if we had initialised

Re: [PATCH] ide: hdio.txt update

Greetings Bartlomiej, I've updated the following * in_flags modification when out_flags != 0 in_flags == 0 * more than one - one or more than one * tf_{in|out}_flags - {in|out}_flags as tf_* are in-kernel names I'll update the taskfile patch series after receiving your comments about the

[PATCH] ppc64: Add IDE-pmac support for new Shasta chipset

Hi ! The iMac G5 and new single CPU PowerMac G5 come with a new revision of the K2 ASIC called Shasta. The PATA cell in there now does 133Mhz. This patch adds support for it. It also adds some power management bits to the old 100MHz cell that was in Intrepid based ppc32 machines. The original

[PATCH] ppc64: Fix some PCI interrupt routing issues on iMac G5

Hi ! The iMac G5 has some issues with Apple chips not having a valid PCI_INTERRUPT_PIN. This patch fixes IRQ routing on PowerMac platforms so that it only relies on the Open Firmware informations which are correct. Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Signed-off-by: J. Mayer

[PATCH] ppc64: Add basic support for the SMU chip in iMac G5

Hi ! The iMac G5 and latest single-cpu PowerMac G5 have seen the venerable PMU (Power Management Unit) chip been sent to well deserved retirement. It has been replaced by a newcomer, the SMU (System Management Unit ?) which is of course totally undocumented and has no open source darwin driver...

Re: [ANNOUNCE 0/6] Open-iSCSI High-Performance Initiator for Linux

On Thu, 2005-03-10 at 11:27 +0100, Lars Marowsky-Bree wrote: On 2005-03-09T18:36:37, Alex Aizman [EMAIL PROTECTED] wrote: That works well in our current development series, and if you want to share code, you can either rip it off (Open Source, we love ya ;) or we can spin off these parts

Re: [RFC] -stable, how it's going to work.

Chris Friesen [EMAIL PROTECTED] writes: Neil Brown wrote: If a data corruption bug has been there for 10 weeks without being noticed, then the real risk is not that great. We are calling it -release, not -hardened. I disagree. If there's a simple, obvious, small fix that passes all the

Re: Microstate Accounting for 2.6.11

Andrew Morton [EMAIL PROTECTED] writes: Why does the kernel need this feature? Have you any numbers on the overhead? It does RDTSC and lots of complicated stuff twice for each system call. On P4 this will be extremly slow ( 1000cycles combined) It is pretty unlikely that whatever it does

Re: [PATCH] ppc64: Add IDE-pmac support for new Shasta chipset

Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: The iMac G5 and new single CPU PowerMac G5 come with a new revision of the K2 ASIC called Shasta. The PATA cell in there now does 133Mhz. This patch adds support for it. It also adds some power management bits to the old 100MHz cell that was

Re: User mode drivers: part 2: PCI device handling (patch 1/2 for 2.6.11)

On Fri, Mar 11, 2005 at 02:37:17PM +1100, Peter Chubb wrote: +/* + * The PCI subsystem is implemented as yet-another pseudo filesystem, + * albeit one that is never mounted. + * This is its magic number. + */ +#define USR_PCI_MAGIC (0x12345678) If you make it a real, mountable filesystem,

Last night Linus bk - netfilter busted?

Hi, My box gets stuck while booting (actually starting ntpd) whith tonight pull from Linus. It looks like it is spinning in ipt_do_table when I do SysRq-P. No call trace though. Anyone else seeing it? Any ideas? -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel

Re: oom with 2.6.11

On Fri, Mar 11, 2005 at 02:14:14AM +0100, Christian Kujau wrote: Andrew Morton wrote: Christian Kujau [EMAIL PROTECTED] wrote: i was going to compile 2.6.11-rc5-bk4, to sort out the bad kernel. compiling went fine. ok, finished some email, ok, suddenly my swap was used up again, and no

Re: [01/11] fix amd64 2.6.11 oops on modprobe (saa7110)

On Thu, Mar 10, 2005 at 07:37:40PM -0600, Josh Boyer wrote: On Thu, 2005-03-10 at 15:07 -0800, Greg KH wrote: -stable review patch. If anyone has any objections, please let us know. -- This is a rewrite of the saa7110_write_block function, which was plain broken in

<    3   4   5   6   7   8