Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VMnow?

2000-09-03 Thread Benjamin Herrenschmidt
Hi ! I've read the discussion about the truncate() problem and tried to understand ;) However, there's somethign I don't catch in your code (typo ? bug ? misunderstanding on my side ?) Linus wrote: There's a really simple way to avoid this: compare the thing you're going to zero out against

Re: who maintains linux 4 the powerpc

2000-09-08 Thread Benjamin Herrenschmidt
Can somebody please tell me, who is currently maintaining arch/ppc? The link http://www.ppc.kernel.org/ in the MAINTAINERS file is dead. Cort Dougan ([EMAIL PROTECTED]) and Paul Mackerras ([EMAIL PROTECTED]) There's also a SourceForge site recently created to gather pending patches and bug

Re: New topic (PowerPC Linux PCI HELL)

2000-09-18 Thread Benjamin Herrenschmidt
All I wanted was a function that allows the driver to decide that which needs to be enabled. pci_enable_device(struct pci_dev *dev, byte enable_mask) This would allow drivers to enable that which it needs and not weird out the hardware that does not like all of this extra fluff. This is

Re: [DOC] Debugging early kernel hangs

2000-09-22 Thread Benjamin Herrenschmidt
Hmm, good idea, but how does this work on, say, non-x86 architectures which don't have a VGA text frame buffer, or whose VGA text frame buffer is not mapped in, or whose VGA text frame buffer is not initialised. You will still end up with those "my kernel hangs during boot" messages. A lot of

Re: [DOC] Debugging early kernel hangs

2000-09-23 Thread Benjamin Herrenschmidt
2.4 and 2.2 PPC have progress() for writing progress messages to the screen. They're setup in a per-board very early in the boot so we can see what's going on as soon as the MMU is turned on and lets us get around. Ben, can you just make your changes talk through that? I used to use it with

removal of include/linux/openpic.h

2000-09-26 Thread Benjamin Herrenschmidt
Hi ! Is any arch other than PPC using include/linux/openpic.h ? I'm doing some cleanup work on various parts of the PPC arch, and it's now time for the openpic driver to suffer. That file exports to everybody all the functions data structures of the driver, which is wrong with the way the

Re: __bad_udelay in 2.2.18pre15

2000-10-11 Thread Benjamin Herrenschmidt
2.2.18pre15 defines udelay as (in file include/asm-i386/delay.h) : extern void __bad_udelay(void); #define udelay(n) (__builtin_constant_p(n) ? \ ((n) 2 ? __bad_udelay() : __const_udelay((n) * 0x10c6ul)) : \ __udelay(n)) ... It seems __bad_udelay is not defined

Re: __bad_udelay in 2.2.18pre15

2000-10-11 Thread Benjamin Herrenschmidt
Well, at first, I wanted to implement it the same way on PPC. However, it dies on all occurences where udelay is called with a non-constant expression. I spotted this case in a few PPC specific stuffs (fixable), but also in the sys_nanosleep code, and in the de4x5 driver. Hrm... looks like I

Re: __bad_udelay in 2.2.18pre15

2000-10-11 Thread Benjamin Herrenschmidt
Well, at first, I wanted to implement it the same way on PPC. However, it dies on all occurences where udelay is called with a non-constant expression. __builtin_constant_p means non constant expressions will always call udelay I spotted this case in a few PPC specific stuffs (fixable),

Re: __bad_udelay in 2.2.18pre15

2000-10-11 Thread Benjamin Herrenschmidt
Yep. This is a huge release patch anyway so resynching the stuff is fine. What I wont take is stuff touching core code I do have a 2 lines patch to the common ide code that fix a problem when revalidating a CD-ROM after sleep, but it was ack'ed by Andre Hedrick. I also have a two-liners to

Problem with include/linux/fs.h vs. glibc

2000-10-12 Thread Benjamin Herrenschmidt
Hi ! Sorry if this have already been the cause of a flamewar on the list, but... I need to compile an app with the 2.4 kernel headers glibc (our stable glibc on PPC is based on 2.1.3). However, the compiler is barking on a change done in 2.4 version of include/linux/fs.h: The 2.2.x version

Re: Problem with include/linux/fs.h vs. glibc

2000-10-12 Thread Benjamin Herrenschmidt
- I mean, it's legal to include linux/fs.h from userland, Everybody who thinks so will be severely disappointed. Ok, so if it's not, then I have to fix that app. Thanks. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL

Re: dual head r128

2000-10-12 Thread Benjamin Herrenschmidt
Note to linux-kenrel readers: This discussion is the Nth attempt to find a solution to handle both legacy IOs and PCI IOs on machines with several IO busses memory mapped at different locations in the CPU space. No please, is there anybody bloat-conscious on this damned list ? Burying more and

The IO problem, ISA vs. PCI

2000-10-12 Thread Benjamin Herrenschmidt
. (There might still be problems with VGA vs. parallell, I don't know x86 world well enough to be sure). Ben. -- RFC822 Header Follows -- From: Benjamin Herrenschmidt [EMAIL PROTECTED] To: Gabriel Paubert [EMAIL PROTECTED], Linux/PowerPC Devel List [EMAIL PROTEC

Re: Any dual AGP slot motherboards?

2000-10-19 Thread Benjamin Herrenschmidt
Apple sells a computer with dual AGP slots. I just was looking for a intel box like this. Since AGP is a port on the PCI bus it is possible to have more than one AGP port on a/each PCI bus but this requires the PCI chipset to support this. Well, I don't know of such a Mac. To my knowledge, the

The IO problem on multiple PCI busses

2001-03-01 Thread Benjamin Herrenschmidt
Here's the return of an ld problem for which we really need a solution asap since it's now biting us in real life configurations... So the problem happens when you have a machine with more than one PCI host bridge. This is typically the case of all new Apple machines as they have 3 host

Re: The IO problem on multiple PCI busses

2001-03-01 Thread Benjamin Herrenschmidt
If we want to go a bit further, and allow ISA drivers that don't have a pci_dev structure to work on legacy devices on any bus, we could provide a set of function of the type int isa_get_bus_count(); unsigned long isa_get_bus_io_offset(int busno); I would add that I'd prefer to keep it

Re: The IO problem on multiple PCI busses

2001-03-01 Thread Benjamin Herrenschmidt
As a side note, Alpha has a special PCI syscall to get the "PCI controller number" a given PCI device is behind. We could add another ioctl number which does the same thing on /proc/bus/pci/*/* nodes. This way sparc64 and Alpha could have the same user visible API for this as well. And on PPC

Re: The IO problem on multiple PCI busses

2001-03-01 Thread Benjamin Herrenschmidt
I'm, of course open to any comments about this (in fact, I'd really like some feedback). One thing is that we also need to find a way to pass those infos to userland. Currently, we implement an arch-specific syscall that allow to retreive the IO physical base of a given PCI bus. That may

Re: The IO problem on multiple PCI busses

2001-03-02 Thread Benjamin Herrenschmidt
I do not want an interface where the user still has to do grotty stuff like mmap() on /dev/{mem,kmem}, this was the core of the problem I had with the syscall idea, don't bring it back. Make mmap()'s on a PCI--ISA bridge do something special, for example. The user doesn't need to know anything

Re: IO issues vs. multiple busses

2001-03-03 Thread Benjamin Herrenschmidt
Here are my comments directly responding to your mail. Hi ! Thanks for taking the time to respond in details. Large systems have problems with I/O port space and legacy devices. There just isn't enough I/O port space to support large configs and ISA aliasing and all the other crud. That's why

Re: The IO problem on multiple PCI busses

2001-03-03 Thread Benjamin Herrenschmidt
No, don't do this, it is evil. Use mappings, specify the device related info somehow when creating the mapping (in the userspace variant you do this by openning a specific device to mmap, in the kernel variant you can encode the bus/dev/etc. info in the device's resource and decode this at

Question about IRQ_PENDING/IRQ_REPLAY

2001-03-03 Thread Benjamin Herrenschmidt
Hi Linus ! I've some questions regarding the behaviour of arch/i386/kernel/irq.c regarding IRQ_PENDING and IRQ_REPLAY. Especially, my question is about the code in enable_irq() which checks for IRQ_PENDING, and then "replays" the interrupt by asking the APIC to issue it again. I don't have a

Re: The IO problem on multiple PCI busses

2001-03-03 Thread Benjamin Herrenschmidt
I/O is not supposed to be fast, that's what MMIO is for. :) Just do void outb (u8 val, u16 addr) { void *addr = ioremap (ISA_IO_BASE + addr); if (addr) { writeb (val, addr); iounmap (addr); } } You can map and unmap for each call :) Ugly and

Re: Question about IRQ_PENDING/IRQ_REPLAY

2001-03-04 Thread Benjamin Herrenschmidt
In particular, if an edge-triggered interrupt comes in on an x86 IO-APIC while that interrupt is disabled, enabling the interrupt will have caused that irq to get dropped. And if it gets dropped, it will never ever happen again: the interrupt line is now active, and there will never be another

Re: IO issues vs. multiple busses

2001-03-04 Thread Benjamin Herrenschmidt
So once again I vote for the introduction of isa_{request,release}_mem_region(), just like we already have isa_readb() and friends. Well, it's the same problem as the IO, there may be more than one ISA mem region, especially when you put 2 video cards on 2 different PCI hosts (even without a

Re: Question about IRQ_PENDING/IRQ_REPLAY

2001-03-04 Thread Benjamin Herrenschmidt
We do have broken interrupt controllers in this respect. We already have a way of handling it. Ben, take a look at set_lost(). Heh, I know, thanks ;) However, our current scheme implies a hack to __sti() that I'd like to get rid of since it adds an overhead allover the place that could

Re: Question about IRQ_PENDING/IRQ_REPLAY

2001-03-05 Thread Benjamin Herrenschmidt
More generic in terms of using irq_desc[] and some similar structures I can see. Making do_IRQ() and enable/disable use the same names and structures as x86 isn't sensible. They're different ports, with different design philosophies. I don't believe that the plan is a common irq.c - lets stay

Re: Question about IRQ_PENDING/IRQ_REPLAY

2001-03-05 Thread Benjamin Herrenschmidt
handled correctly, does nothing more than what we need (well it does, but those parts, mostly the irq locking, got already removed), etc... Sorry, I meant mostly the irq probing Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL

Re: Question about IRQ_PENDING/IRQ_REPLAY

2001-03-05 Thread Benjamin Herrenschmidt
And I seriously doubt that PPC SMP irq handling has gotten _nearly_ the amount of testing and hard work that the x86 counterpart has. Things like support for CPU affinity, per-irq spinlocks, etc etc. Some of those are the reason I moved part of the x86 irq.c code to PPC indeed. Now, I'm not

Re: Question about IRQ_PENDING/IRQ_REPLAY

2001-03-05 Thread Benjamin Herrenschmidt
We have about 12 interrupt controllers we end up using on PPC. I'm suspicious of any effort to base Linux/PPC generic interrupt control code paths on a software architecture that's been tested with 3. More to the point, we get ASIC's that roll in a standard interrupt controller and add some

[RFC] fbdev power management

2001-03-13 Thread Benjamin Herrenschmidt
I'm working on improving some aspects of Power Management on the PowerBooks, and among other things, I have a problem with fbdevs. Currently, each fbdev registers a power management callback to sleep/ wakeup the device. We handle HW related things (shutting the backlight off, putting the chip to

Re: [Linux-fbdev-devel] [RFC] fbdev power management

2001-03-14 Thread Benjamin Herrenschmidt
I think registering fbcon as a PM client and doing the above when the fbdev suspend/resume hooks are called should work. A memory backup is worked on until the resume is run and the backup is restored to the display. So the fbdev drivers would register PM with fbcon, not PCI, correct? Either

Re: [Linux-fbdev-devel] [RFC] fbdev power management

2001-03-15 Thread Benjamin Herrenschmidt
Now for fbcon its simpler. Things get writing to the shadow buffer (vc_screenbuf). When the console gets woken up update_screen is called. While power down the shadow buffer can be written to which is much faster than saving a image of the framebuffer. Of course if you still want to do this

RE: kernel_thread vs. zombie

2001-03-22 Thread Benjamin Herrenschmidt
Have a look at: http://www.scs.ch/~frey/linux/kernelthreads.html I have an example there that starts and stops kernel threads from init_module and never produced a zombie. I use the same code also to start threads from ioctl and it works for me. I tested it on UP and SMP, Intel and Alpha, 2.2.18

RE: kernel_thread vs. zombie

2001-03-22 Thread Benjamin Herrenschmidt
The stuff done in daemonize() and the exit_files could need the kernel lock. At least on some 2.2.x version it does, I did not check whether it is still needed on 2.4. Well, I don't really plan to backport this to 2.2.x. I'll try to see if my problem is related to the lack of kernel lock, or

Re: PCI bridge setup weirdness

2000-12-08 Thread Benjamin Herrenschmidt
No, pci_read_bridge_bases() is obsoleted by new pci setup code. ;-) You have to set up bus resources properly in pcibios_fixup_bus(). For a single root bus configuration, you don't need to do anything with the root bus itself - its resources already point to ioport_resource and iomem_resource,

Fwd: kernel oops with rm in hfs - hit BUG() in line 236 of dcache.h

2000-12-10 Thread Benjamin Herrenschmidt
Begin Forwarded Message Subject: kernel oops with rm in hfs - hit BUG() in line 236 of dcache.h Date Sent: Sunday, December 10, 2000 12:56 AM From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED] PowerCenter Pro 210mhz 604e,

Re: 2.2.X patches for fbcon

2000-12-11 Thread Benjamin Herrenschmidt
--- atyfb.cMon Dec 11 14:28:19 2000 +++ atyfb.c.orig Wed Oct 4 22:22:28 2000 @@ -2796,7 +2796,7 @@ * works on iMacs as well as the G3 powerbooks. - paulus */ if (default_vmode == VMODE_CHOOSE) { - if ((Gx == LG_CHIP_ID)||(Gx == LI_CHIP_ID)||(Gx == LP_CHIP_ID)) +

aic7xxx.c vs. Adaptec 29160N

2001-01-04 Thread Benjamin Herrenschmidt
I have a 29160N card in a PowerMac G4. It used to work fine with an old UW SCSI disk I had there. Today, I flipped this drive with a real Ultra160 one , and now, the kernel won't boot. It's giving me an endless stream of SCSI reset timeouts on bus 0. Any clue ? I don't really need this disk in

Re: aic7xxx.c vs. Adaptec 29160N

2001-01-04 Thread Benjamin Herrenschmidt
Anything I can do to help tracking the problem ? It's difficult to get the actual output of the driver in verbose mode as it is scrolling quite fast and I have nothing like a serial console on this box. The kernel won't boot without noprobe so I can't dump dmesg output. I was wrong, even

Re: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCIresourcecollisions (fwd)

2000-10-26 Thread Benjamin Herrenschmidt
Ben. -- RFC822 Header Follows -- From: Benjamin Herrenschmidt [EMAIL PROTECTED] To: Martin Mares [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd) Date: Thu, 26 Oct 2000 14:3

Re: B/W G3 - big IDE problems with 2.4.0-test10

2000-11-09 Thread Benjamin Herrenschmidt
On Wed, 8 Nov 2000, Andre Hedrick wrote: What is your chipset, CMD646 rev 5 Ultra DMA 33 ??? Yep. I've tried building with the CMD64x driver, and that didn't help matters, if you were wondering. Any thoughts? Did you try the bitkeeper PPC kernel ? (or Paul Mackerras rsync tree ?) Not all PPC

About IOs, ISA, PCI, and life (WAS: VGA PCI IO port...)

2000-11-18 Thread Benjamin Herrenschmidt
One way to do this is to treat PCI IO and ISA IO as two separate address spaces. The PCI IO address space is a 14-bit address space (bits 9:8 are always zero) ranging from 0x1000 to 0xFCFF. ISA IO is a 10-bit space (bits 15:10 are available for the card to use) ranging from 0x100 to 0x3FF.

Re: PCI power management

2001-04-19 Thread Benjamin Herrenschmidt
Hi ! Glad to see things moving around Power Management ;) This was originally a private reply to Patrick Mochel, but the e-mail kept getting longer and longer :) Note: we have setup a list for PM issues http://lists.sourceforge.net/lists/listinfo/linux-pm-devel Not very much used yet, but I,

Re: PCI power management

2001-04-19 Thread Benjamin Herrenschmidt
Hi ! Glad to see things moving around Power Management ;) This was originally a private reply to Patrick Mochel, but the e-mail kept getting longer and longer :) Note: we have setup a list for PM issues http://lists.sourceforge.net/lists/listinfo/linux-pm-devel Not very much used yet, but I,

Re: PCI power management

2001-04-19 Thread Benjamin Herrenschmidt
On Thu, Apr 19, 2001 at 11:19:31AM +0100, Benjamin Herrenschmidt wrote: Hi ! Glad to see things moving around Power Management ;) This was originally a private reply to Patrick Mochel, but the e-mail kept getting longer and longer :) Note: we have setup a list for PM issues http

Re: PCI power management

2001-04-19 Thread Benjamin Herrenschmidt
- Some devices just can't be brought back to life from D3 state without a PCI reset (ATI Rage M3 for example) and that require some arch specific support (when it's possible at all). Putting on a driver author hat what I want is pci_power_on_generic pci_power_off_generic

Re: PCI power management

2001-04-19 Thread Benjamin Herrenschmidt
null = 'do absolutely nothing' generic = 'do D3 as per the specification' The idea being the PM layer would go around calling dev-power_off(dev); as a default notifier for PCI devices. Ok, I see. I didn't understand that the functions you were talking about would be defaults to put

Re: PCI power management

2001-04-20 Thread Benjamin Herrenschmidt
All devices should handle having power removed from them. And, all of the drivers should as well, since that is the only way we're going to get power management out of legacy devices and other things on the board. This involves saving the current context on suspend, and reinitializing the device,

Re: PCI power management

2001-04-20 Thread Benjamin Herrenschmidt
Some devices (bad bad HW designers ;) just can't do it themselves. The Rage M3 requires the host to assert PCI RST#, and some motherboards provide no documented facility for that (it might be possible with Apple ASICs for example, it's just not documented). Why should we support such a

Re: isa_read/write not available on ppc - solution suggestions ??

2001-05-02 Thread Benjamin Herrenschmidt
I would suggest the opposite approach instead: make the PPC just support isa_readx/isa_writex instead. We can certainly do that, no problem. BUT that won't get a token ring pcmcia card working in the newer powerbooks, such as the titanium G4 powerbook, because the PCI host bridge doesn't map

pci_disable_device() vs. arch

2001-06-16 Thread Benjamin Herrenschmidt
Hi ! Would it make sense to add a pcibios_disable_device(pci_dev*) called from the end of pci_disable_device() ? I'm adding a call to it to sungem along with other pmac stuffs so that the chip can be properly power down (actually it's not really powered down but unclocked) after module

Re: Going beyond 256 PCI buses

2001-06-14 Thread Benjamin Herrenschmidt
It's funny you mention this because I have been working on something similar recently. Basically making xfree86 int10 and VGA poking happy on sparc64. Heh, world is small ;) But this has no real use in the kernel. (actually I take this back, read below) yup, fbcon at least... You have a

Re: pci_disable_device() vs. arch

2001-06-16 Thread Benjamin Herrenschmidt
Its not clutter -- what you are doing is hiding pieces of the driver from the driver maintainer. pcibios_enable_device should not be cluttered up with such mess, too. Well... pcibios_enable_device() has to at least make sure the device gets powered up as it's powered down after PCI probe.

VFS locking HFS problems (2.4.6pre6)

2001-06-29 Thread Benjamin Herrenschmidt
I've had a deadlock twice with 2.4.6pre6 today. It's an SMP kernel running on an UP box (a PowerBook Pismo). The deadlock happen in the HFS filesystem in hfs_cat_put(), apparently (quickly looking at addresses) in spin_lock(). I don't have the complete backtrace at hand right now, but it

Re: [RFC] I/O Access Abstractions

2001-07-02 Thread Benjamin Herrenschmidt
Last time I checked, ioremap didn't work for inb() and outb(). It should :) it doesnt need to. pci_find_device returns the io address and can return a cookie, ditto isapnp etc Yes, but doing that require 2 annoying things: - Parsing of this cookie on each inx/outx access, which can

Re: [RFC] I/O Access Abstractions

2001-07-02 Thread Benjamin Herrenschmidt
Last time I checked, ioremap didn't work for inb() and outb(). ioremap itself cannot work for inb/outb as they are different address spaces with potentially overlapping addresses, I don't see how a single function would handle both... except if we pass it a struct resource instead of the

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-06 Thread Benjamin Herrenschmidt
Nope. I do not want to maintain two interfaces. If we make user space the way to do these things, then we will do pretty much most of the driver setup etc in user space. We'd have to: we'd enter user space before drivers have had a chance to initialize, exactly because features like these can

ide_revalidate_disk() fix

2001-02-12 Thread Benjamin Herrenschmidt
Hi Andre ! Any reason other than usual programmer "too many things to remember" for 2.4 lacking the small ide_revalidate_disk() fix we did recently in 2.2 to keep the blocksize of the device intact ? (Just diff the 2 functions, it's pretty obvious) I'd be glad to send Linus a patch, but I

Re: PCI GART (?)

2001-02-13 Thread Benjamin Herrenschmidt
I have RTFM but on the matter of enabling DRI for the ATI Mobility video chipset, which on that notebook is a PCI model, there is practically nil information. The DRI website mentions using PCI GART, but there is no option for that in the kernel. How do I enable this? You need to get

RE: kernel_thread vs. zombie

2001-03-22 Thread Benjamin Herrenschmidt
daemonize() makes calls that are all protected with the big kernel lock in do_exit(). All usages of daemonize have the big kernel lock held. So I guess it just needs it. Please let me know whether you have success if it makes a difference with having it held. With a bit more experiments, I have

console.c unblank_screen problem

2001-03-25 Thread Benjamin Herrenschmidt
There is a problem with the power management code for console.c The current code calls do_blank_screen(0); on PM_SUSPEND, and unblank_screen() on PM_RESUME. The problem happens when X is the current display while putting the machine to sleep. The do_blank_screen(0) code will do nothing as the

Re: console.c unblank_screen problem

2001-04-04 Thread Benjamin Herrenschmidt
Thanks for this patch. I've been using it on my Dell Latitude laptop for the last 10 days, and it has been a significant improvement. Before the patch: After a few days with a 2.4 kernel and RH7.0 (XFree86-4.0.1-1 and XFree86-SVGA-3.3.6-33) the latop would misbehave at a resume event: when I

[PATCH] binfmt_elf.c fix with PPC update

2001-04-11 Thread Benjamin Herrenschmidt
Hi Linus ! Enclosed is a (not big ;) patch against 2.4.4pre1 that does a few inter-dependant things, one beeing a bug fix for everybody, the other is a mix of bug fix cleanup on PPC: - binfmt_elf.c : fix DLINFO_ITEMS so that final alignement on the stack takes into account the AT_NULL

[PATCH] [resent] binfmt_elf.c fix with PPC update

2001-04-16 Thread Benjamin Herrenschmidt
Hi Linus ! Enclosed is a (not big ;) patch against 2.4.4pre1 that does a few inter-dependant things, one beeing a bug fix for everybody, the other is a mix of bug fix cleanup on PPC: - binfmt_elf.c : fix DLINFO_ITEMS so that final alignement on the stack takes into account the AT_NULL

Re: [PATCH] macintosh/mediabay: Convert to kthread API.

2007-04-20 Thread Benjamin Herrenschmidt
Looks OK - there's no way of stopping the kernel thread anyway. It appears that nobody has tried to use this driver at the same time as software-suspend. At least, not successfully. A strategic try_to_freeze() should fix it. This will become (a little) more serious when cpu hotplug is

Re: [PATCH] macintosh/therm_windtunnel.c: Convert to kthread API.

2007-04-20 Thread Benjamin Herrenschmidt
On Thu, 2007-04-19 at 16:37 -0700, Andrew Morton wrote: On Thu, 19 Apr 2007 01:58:48 -0600 Eric W. Biederman [EMAIL PROTECTED] wrote: Start the g4fand using kthread_run not a combination of kernel_thread and deamonize. This makes the code a little simpler and more maintainable. I had

Re: [PATCH] powerpc pseries eeh: Convert to kthread API

2007-04-23 Thread Benjamin Herrenschmidt
The only reason for using threads here is to get the error recovery out of an interrupt context (where errors may be detected), and then, an hour later, decrement a counter (which is how we limit these to 6 per hour). Thread reaping is trivial, the thread just exits after an hour. In

Re: [PATCH] powerpc pseries eeh: Convert to kthread API

2007-04-23 Thread Benjamin Herrenschmidt
On Mon, 2007-04-23 at 20:08 -0600, Eric W. Biederman wrote: Benjamin Herrenschmidt [EMAIL PROTECTED] writes: The only reason for using threads here is to get the error recovery out of an interrupt context (where errors may be detected), and then, an hour later, decrement a counter (which

Re: [PATCH] powerpc pseries eeh: Convert to kthread API

2007-04-23 Thread Benjamin Herrenschmidt
Further in general it doesn't make sense to grab a module reference and call that sufficient because we would like to request that the module exits. Which is, btw, I think a total misdesign of our module stuff, but heh, I remember that lead to some flamewars back then... Like anything else,

[PATCH 0/12] Pass MAP_FIXED down to get_unmapped_area

2007-04-23 Thread Benjamin Herrenschmidt
This is a first step as there are still cleanups to be done in various areas touched by that code but I think it's probably good to go as is and at least enables me to implement what I need for PowerPC. (Andrew, this is also candidate for 2.6.22 since I haven't had any real objection, mostly

[PATCH 1/12] get_unmapped_area handles MAP_FIXED on powerpc

2007-04-23 Thread Benjamin Herrenschmidt
Handle MAP_FIXED in powerpc's arch_get_unmapped_area() in all 3 implementations of it. Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Acked-by: William Irwin [EMAIL PROTECTED] arch/powerpc/mm/hugetlbpage.c | 21 + 1 file changed, 21 insertions(+) Index: linux

[PATCH 2/12] get_unmapped_area handles MAP_FIXED on alpha

2007-04-23 Thread Benjamin Herrenschmidt
Handle MAP_FIXED in alpha's arch_get_unmapped_area(), simple case, just return the address as passed in Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] arch/alpha/kernel/osf_sys.c |3 +++ 1 file changed, 3 insertions(+) Index: linux-cell/arch/alpha/kernel/osf_sys.c

[PATCH 3/12] get_unmapped_area handles MAP_FIXED on arm

2007-04-23 Thread Benjamin Herrenschmidt
ARM already had a case for MAP_FIXED in arch_get_unmapped_area() though it was not called before. Fix the comment to reflect that it will now be called. Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] arch/arm/mm/mmap.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Index

[PATCH 11/12] get_unmapped_area handles MAP_FIXED in generic code

2007-04-23 Thread Benjamin Herrenschmidt
generic arch_get_unmapped_area() now handles MAP_FIXED. Now that all implementations have been fixed, change the toplevel get_unmapped_area() to call into arch or drivers for the MAP_FIXED case. Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] mm/mmap.c | 25

[PATCH 10/12] get_unmapped_area handles MAP_FIXED in hugetlbfs

2007-04-23 Thread Benjamin Herrenschmidt
Generic hugetlb_get_unmapped_area() now handles MAP_FIXED by just calling prepare_hugepage_range() Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Acked-by: William Irwin [EMAIL PROTECTED] fs/hugetlbfs/inode.c |6 ++ 1 file changed, 6 insertions(+) Index: linux-cell/fs

[PATCH 12/12] get_unmapped_area doesn't need hugetlbfs hacks anymore

2007-04-23 Thread Benjamin Herrenschmidt
Remove the hugetlbfs specific hacks in toplevel get_unmapped_area() now that all archs and hugetlbfs itself do the right thing for both cases. Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Acked-by: William Irwin [EMAIL PROTECTED] mm/mmap.c | 16 1 file changed, 16

[PATCH 9/12] get_unmapped_area handles MAP_FIXED on x86_64

2007-04-23 Thread Benjamin Herrenschmidt
Handle MAP_FIXED in x86_64 arch_get_unmapped_area(), simple case, just return the address as passed in Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] arch/x86_64/kernel/sys_x86_64.c |3 +++ 1 file changed, 3 insertions(+) Index: linux-cell/arch/x86_64/kernel/sys_x86_64.c

[PATCH 8/12] get_unmapped_area handles MAP_FIXED on sparc64

2007-04-23 Thread Benjamin Herrenschmidt
Handle MAP_FIXED in hugetlb_get_unmapped_area on sparc64 by just using prepare_hugepage_range() Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Acked-by: William Irwin [EMAIL PROTECTED] arch/sparc64/mm/hugetlbpage.c |6 ++ 1 file changed, 6 insertions(+) Index: linux-cell/arch

[PATCH 7/12] get_unmapped_area handles MAP_FIXED on parisc

2007-04-23 Thread Benjamin Herrenschmidt
Handle MAP_FIXED in parisc arch_get_unmapped_area(), just return the address. We might want to also check for possible cache aliasing issues now that we get called in that case (like ARM or MIPS), leave a comment for the maintainers to pick up. Signed-off-by: Benjamin Herrenschmidt [EMAIL

[PATCH 6/12] get_unmapped_area handles MAP_FIXED on ia64

2007-04-23 Thread Benjamin Herrenschmidt
Handle MAP_FIXED in ia64 arch_get_unmapped_area and hugetlb_get_unmapped_area(), just call prepare_hugepage_range in the later and is_hugepage_only_range() in the former. Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Acked-by: William Irwin [EMAIL PROTECTED] arch/ia64/kernel/sys_ia64

[PATCH 5/12] get_unmapped_area handles MAP_FIXED on i386

2007-04-23 Thread Benjamin Herrenschmidt
Handle MAP_FIXED in i386 hugetlb_get_unmapped_area(), just call prepare_hugepage_range. Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Acked-by: William Irwin [EMAIL PROTECTED] arch/i386/mm/hugetlbpage.c |6 ++ 1 file changed, 6 insertions(+) Index: linux-cell/arch/i386/mm

[PATCH 4/12] get_unmapped_area handles MAP_FIXED on frv

2007-04-23 Thread Benjamin Herrenschmidt
Handle MAP_FIXED in arch_get_unmapped_area on frv. Trivial case, just return the address. Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] arch/frv/mm/elf-fdpic.c |4 1 file changed, 4 insertions(+) Index: linux-cell/arch/frv/mm/elf-fdpic.c

Re: [patch 2.6.20-1] radeonfb: Add support for Radeon xpress 200m

2007-03-09 Thread Benjamin Herrenschmidt
- radeonfb_pm_init(rinfo, rinfo-is_mobility ? 1 : -1, ignore_devlist, force_sleep); + radeonfb_pm_init(rinfo, rinfo-is_mobility rinfo-family != CHIP_FAMILY_RS480 ? 1 : -1, ignore_devlist, force_sleep); I'd rather you add a check for RS480 inside radeonfb_pm_* Ben.

Re: [PATCH] Fix atomicity of TIF update in flush_thread() for powerpc

2007-03-09 Thread Benjamin Herrenschmidt
.../... Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED] Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Nice catch ! --- a/arch/powerpc/kernel/process.c +++ b/arch/powerpc/kernel/process.c @@ -476,8 +476,13 @@ void flush_thread(void) #ifdef CONFIG_PPC64 struct thread_info

Re: [PATCH] Complain about missing system calls.

2007-03-09 Thread Benjamin Herrenschmidt
On Fri, 2007-03-09 at 17:11 +0100, Andi Kleen wrote: David Woodhouse [EMAIL PROTECTED] writes: Most system calls seem to get added to i386 first. This patch automatically generates a warning for any new system call which is implemented on i386 but not the architecture currently being

Re: Make sure we populate the initroot filesystem late enough

2007-03-13 Thread Benjamin Herrenschmidt
Hmm. The crash came back after I booted into Mac OS X and back. It was however a different crash, I believe it was coming from the USB modules (as it would keep going when it happened, and get another crash, which tended to scroll away too fast for me to capture) but I believe it was still

Re: [PATCH] BLK_DEV_IDE_CELLEB dependency fix

2007-03-15 Thread Benjamin Herrenschmidt
On Thu, 2007-03-15 at 17:30 +0300, Sergei Shtylyov wrote: Hello. Akira Iguchi wrote: It's bool and it depends on BLK_DEV_IDE = should depend on BLK_DEV_IDE=y Hm, why I'm seeing module_init() in the driver? :-) And move it to if BLK_DEV_IDEDMA_PCI block because it depends on

Re: remote debugging via FireWire

2007-02-11 Thread Benjamin Herrenschmidt
On Sat, 2007-02-10 at 20:16 +0100, Stefan Richter wrote: [ohci1394_early] Some remarks to the September 2006 version at http://www.suse.de/~bk/firewire/ : - Seems its .remove won't work properly if more than one OHCI-1394 controller is installed. And it's .probe isn't reentrant,

[PATCH] powerpc: Fix vDSO page count calculation

2007-02-11 Thread Benjamin Herrenschmidt
really need to be done -that- early. Applogies for not catching the breakage earlier, Roland _did_ CC me on his patches a while ago, I got busy with other things and forgot to test them. Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Index: linux-work/arch/powerpc/kernel/vdso.c

Re: remote debugging via FireWire

2007-02-11 Thread Benjamin Herrenschmidt
On Mon, 2007-02-12 at 07:49 +0100, Andi Kleen wrote: On Sunday 11 February 2007 22:35, Benjamin Herrenschmidt wrote: I'd like to have that on ppc as well, so I'd rather keep it in drivers/ This will need some abstraction at least -- there are some early mapping hacks that are x86 specific

Re: undefined symbol 'PS3_PS3AV'

2007-02-14 Thread Benjamin Herrenschmidt
On Wed, 2007-02-14 at 19:17 +0900, Paul Mundt wrote: On Wed, Feb 14, 2007 at 11:02:06AM +0100, Geert Uytterhoeven wrote: On Wed, 14 Feb 2007, Paul Mundt wrote: This would seem like a reasonable candidate for a 'depends on' instead of a select.. That's what we originally had. But for

Re: [RFC] killing the NR_IRQS arrays.

2007-02-16 Thread Benjamin Herrenschmidt
On Fri, 2007-02-16 at 05:10 -0700, Eric W. Biederman wrote: Getting the drivers changed actually looks to be pretty straight forward it will just be a very large mechanical change. We change the type where of variables where appropriate and every once in a while introduce an irq_nr(irq) to

Re: [RFC] killing the NR_IRQS arrays.

2007-02-16 Thread Benjamin Herrenschmidt
On Fri, 2007-02-16 at 13:41 +0100, Ingo Molnar wrote: * Eric W. Biederman [EMAIL PROTECTED] wrote: So I propose we remove all assumptions from the code that we actually have an array of irqs. That will allow for irq_desc to be dynamically allocated instead of statically allocated

Re: [RFC] killing the NR_IRQS arrays.

2007-02-16 Thread Benjamin Herrenschmidt
Rather than having the job of rewriting this code during 2.6, I'd much prefer to get something sorted, even if it is ARM only before 2.6. I believe that there are some common problems with the existing API which have been hinted at over the last few days, such as large NR_IRQS. As

Re: [RFC] killing the NR_IRQS arrays.

2007-02-16 Thread Benjamin Herrenschmidt
On Sat, 2007-02-17 at 02:37 +0100, Arnd Bergmann wrote: On Friday 16 February 2007 23:37, Benjamin Herrenschmidt wrote: You might want to have a look at the powerpc API with it's remaping capabilities. It's very nice for handling multiple domain spaces. It might be of some use for you. I

Re: [RFC] killing the NR_IRQS arrays.

2007-02-17 Thread Benjamin Herrenschmidt
No. I don't think we should make your irq_hwnumber_t thingy general because it is not general. I don't understand why you need it to be an unsigned long, that still puzzles me. But for the rest it actually appears that ppc has a simpler model to deal with. I think you might have

Re: [RFC] killing the NR_IRQS arrays.

2007-02-17 Thread Benjamin Herrenschmidt
On Sat, 2007-02-17 at 02:06 -0700, Eric W. Biederman wrote: Benjamin Herrenschmidt [EMAIL PROTECTED] writes: In addition, if we remove the numbers, archs will need basically the exact same services provided by the powerpc irq core for reverse mapping (going from a HW irq number on a given

Re: [RFC] killing the NR_IRQS arrays.

2007-02-17 Thread Benjamin Herrenschmidt
#define NO_IRQ architecture-defined-int-constant When did you need a magic constant NO_IRQ in generic code. One of the reasons I want to convert the drivers is so we can kill the NO_IRQ nonsense. As for struct irq. Instead of struct irq_desc I really don't care, although the C++

  1   2   3   4   5   6   7   8   9   10   >