headers
Michael Tokarev | 1 Jun 2005 01:01
Picon

PNP parallel&serial ports: module reload fails (2.6.11)?

I noticied that parport_pc and 8250[_pnp] modules
can't be re-loaded without rebooting when PNP is
turned on in kernel config.  Here's how it looks
like:

[boot]
May 26 07:58:41 linux kernel: pnp: PnP ACPI init
May 26 07:58:41 linux kernel: pnp: PnP ACPI: found 15 devices
May 26 07:58:41 linux kernel: pnp: 00:09: ioport range 0x680-0x6ff has been reserved
May 26 07:58:41 linux kernel: pnp: 00:0d: ioport range 0x400-0x47f could not be reserved
May 26 07:58:41 linux kernel: pnp: 00:0d: ioport range 0x680-0x6ff has been reserved
May 26 07:58:41 linux kernel: pnp: 00:0d: ioport range 0x500-0x53f has been reserved
May 26 07:58:41 linux kernel: pnp: 00:0d: ioport range 0x500-0x53f has been reserved
May 26 07:58:41 linux kernel: pnp: 00:0d: ioport range 0x400-0x47f could not be reserved
May 26 07:58:41 linux kernel: pnp: 00:0d: ioport range 0x295-0x296 has been reserved
May 26 07:58:41 linux kernel: pnp: 00:0d: ioport range 0x3e0-0x3e7 has been reserved
May 26 07:58:41 linux kernel: isapnp: Scanning for PnP cards...
May 26 07:58:41 linux kernel: isapnp: No Plug & Play device found

[modprobe parport_pc]
May 26 07:58:44 linux kernel: parport: PnPBIOS parport detected.
May 26 07:58:44 linux kernel: parport0: PC-style at 0x378, irq 7 [PCSPP]
May 26 07:58:44 linux kernel: lp0: using parport0 (interrupt-driven).

[rmmood parport_pc]
Jun  1 02:45:38 linux kernel: pnp: Device 00:08 disabled.

[modprobe parport_pc]
Jun  1 02:45:46 linux kernel: pnp: Device 00:08 activated.
Jun  1 02:45:46 linux kernel: parport: PnPBIOS parport detected.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Keshavamurthy Anil S | 1 Jun 2005 01:08
Picon
Favicon

[patch 1/1] Kprobes temporary disarming of reentrant probe for IA64


From: Anil S Keshavamurthy <anil.s.keshavamurthy <at> intel.com>
Subject: kprobes temporary disarming of reentrant probe for ia64

This patch includes IA64 architecture specific changes(ported form i386)
to support temporary disarming on reentrancy of probes.

In case of reentrancy we single step without calling user handler.

signed-of-by: Anil S Keshavamurth <anil.s.keshavamurthy <at> intel.com>
======================================================================

 arch/ia64/kernel/kprobes.c |   49 +++++++++++++++++++++++++++++++++++++++------
 1 files changed, 43 insertions(+), 6 deletions(-)

Index: linux-2.6.12-rc5/arch/ia64/kernel/kprobes.c
===================================================================
--- linux-2.6.12-rc5.orig/arch/ia64/kernel/kprobes.c
+++ linux-2.6.12-rc5/arch/ia64/kernel/kprobes.c
 <at>  <at>  -41,8 +41,8  <at>  <at>  extern void jprobe_inst_return(void);
 #define KPROBE_HIT_ACTIVE	0x00000001
 #define KPROBE_HIT_SS		0x00000002

-static struct kprobe *current_kprobe;
-static unsigned long kprobe_status;
+static struct kprobe *current_kprobe, *kprobe_prev;
+static unsigned long kprobe_status, kprobe_status_prev;
 static struct pt_regs jprobe_saved_regs;

 enum instruction_type {A, I, M, F, B, L, X, u};
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Huey | 1 Jun 2005 01:14

Re: RT patch acceptance

On Tue, May 31, 2005 at 05:33:02PM -0500, NZG wrote:
> RTAI is a very mature, completely open source real time system these days. 
> Regardless of the skill and manpower being leveraged on the RT patch, I gotta 
> say it looks like your re-inventing the wheel by not using the work that's 
> already been done in RTAI.

Wrong, read the beginning of the thread downward.

> Seems like there is a lot of RTAI speculation going on here.
> Maybe their list should be CC'd on this thread?

You came onto this thread very late and Karim of RTAI has been involved
in this thread from the very beginning.

bill
Permalink | Reply | 0 comments |
headers
john cooper | 1 Jun 2005 01:09
Favicon

Re: RT and Cascade interrupts

john cooper wrote:
> Trond Myklebust wrote:
> 
>> I've appended a patch that
>> should check for strict compliance of the above rules. Could you try it
>> out and see if it triggers any Oopses?
> 
> 
> Yes, the assert in rpc_delete_timer() occurs just before
> the cascade list corruption.  This is consistent with
> what I have seen.  ie: the timer in a released rpc_task
> is still active.

I've captured more data in the instrumentation and found
the rpc_task's timer is being requeued by an application
task which is preempting ksoftirqd when it wakes up in
xprt_transmit().  This is what I had originally suspected
but likely didn't communicate it effectively.

The scenario unfolds as:

                                          [high priority app task]
                                              :
                                          call_transmit()
                                             xprt_transmit()
                                             /* blocks in xprt_transmit() */
ksoftirqd()
     __run_timers()
         list_del("rpc_task_X.timer") /* logically off cascade */
         rpc_run_timer(data)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg KH | 1 Jun 2005 01:20
Gravatar

Re: [RFC] SPI core

On Wed, Jun 01, 2005 at 12:44:34AM +0400, Alexey Dobriyan wrote:
> On Tuesday 31 May 2005 20:09, dmitry pervushin wrote:
> > In order to support the specific board, we have ported the generic SPI core
> > to the 2.6 kernel. This core provides basic API to create/manage SPI devices
> > like the I2C core does. We need to continue providing support of SPI devices
> > and would like to maintain the SPI subtree.
> 
> > +#ifdef CONFIG_DEVFS_FS
> > +#include <linux/devfs_fs_kernel.h>
> > +#endif
> 
> devfs will be removed from mainline in a month.

True, but the #ifdef should never be there in the first place...

thanks,

greg k-h
Permalink | Reply | 0 comments |
headers
Greg KH | 1 Jun 2005 01:32
Gravatar

Re: [RFC] SPI core

On Tue, May 31, 2005 at 08:09:16PM +0400, dmitry pervushin wrote:
> Hello guys,
> 
> In order to support the specific board, we have ported the generic SPI
> core to the 2.6 kernel. This core provides basic API to create/manage
> SPI devices like the I2C core does. We need to continue providing
> support of SPI devices and would like to maintain the SPI subtree. It
> would be nice if SPI core patch were applied to the vanilla kernel.
> I2C people do not like to mainain this code as well as I2C, so...

What do you mean by this?  Which i2c people?

Is this code intergrated into the driver model?
What does the /sys/ tree look like?
Why are you using a char device node?

> +/**
> + * spi_add_adapter - register a new SPI bus adapter
> + *  <at> adap: spi_adapter structure for the registering adapter
> + *
> + * Make the adapter available for use by clients using name adap->name.
> + * The adap->adapters list is initialised by this function.
> + *
> + * Returns 0;

You have this a lot.  If the function can not fail, just make it a void
type :)

> +int spi_add_adapter(struct spi_adapter *adap)
> +{
(Continue reading)

Permalink | Reply | 0 comments |
headers
Benjamin Herrenschmidt | 1 Jun 2005 01:31

Re: [RFC] Add some hooks to generic suspend code


> Why do you need it? Do you initiate suspend without userland asking
> you to?

Because there is an existing API, via /dev/apm_bios, and that's all X
understands ! And because I've always done that ;)

> Anyway, it should not be arch-dependend. We need one good mechanism of
> notifying userland, not one per architecture.

We need to define a new mecanism, I think. In the meantime, my APM
emulation works though and I won't drop it. 

> > > > 	/* called after unfreezing userland */
> > > > 	void (*post_freeze)(suspend_state_t state);
> > > > 
> > > > That one is the mirror of pre-freeze, gets called after userland has been re-enabled,
> > > > it also calls my old-style notifiers, which includes APM emulation, which is important
> > > > for sending the APM wakeup events to things like X.
> > > 
> > > Could this be marked deprecated, too?
> > > 
> > > Alternatively, proper way of notifying X (etc) should be created, and
> > > done from generic code....
> > 
> > Sure, ideally. However, existing X knows how to deal with APM events,
> > and thus APM emulation is an important thing to get something that
> > works. Pne thing I should do is consolidate PPC APM emu with ARM one as
> > I think Russell improve my stuff significantly.
>
(Continue reading)

Permalink | Reply | 12 comments |
headers
Christoph Schulz | 1 Jun 2005 01:33
Picon

[PATCH] cs4236.c, kernel 2.6.11

Hello,

please consider attached patch for the cs4236.c driver module, located
in sound/isa/cs423x/ in the Linux 2.6.11 kernel.

Background: The card/chipset supports an external MIDI interrupt. By
default, this interrupt isn't used (because the isapnp mechanism chooses
a configuration without an assigned interrupt). If the user wishes to
explicitly select an interrupt via the mpu_irq parameter for such a
configured device, it doesn't work: The driver always shows:

isapnp MPU: port=0x330, irq=-1

(note the "irq=-1")

Problem: The driver only allows to set the irq if pnp_irq_valid returns
true for this particular pnp device. This, however, is only true if an
interrupt has already been assigned (pnp_valid_irq returns true if the
flag IORESOURCE_IRQ is set and IORESOURCE_UNSET is not set). If no
interrupt has been assigned so far, IORESOURCE_UNSET is set and
pnp_irq_valid returns false, thereby inhibiting the selection of a valid
irq.

Solution: Don't check for a valid (= already assigned) irq at the point
of calling pnp_resource_change.

Tested successfully on Linux 2.6.11.

Before applying the patch:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Benjamin Herrenschmidt | 1 Jun 2005 01:41

Re: [PATCH] ppc64: actually call prom_send_capabilities


> 
> Index: arch/ppc64/kernel/prom_init.c
> ===================================================================
> --- 3ac19ebb77c3cd8a1df31b7170c6eaf9e1afb1a4/arch/ppc64/kernel/prom_init.c  (mode:100644 sha1:6f79b7b9b445e8669411e34b48c1ea8ce5135965)
> +++ 11f504429d5e6708259f376b76e96cafd3bf9215/arch/ppc64/kernel/prom_init.c  (mode:100644 sha1:bc53967a86436d6b3f4a4f324273e01fdab934b3)
>  <at>  <at>  -1881,6 +1881,12  <at>  <at>  unsigned long __init prom_init(unsigned 
>  		     &getprop_rval, sizeof(getprop_rval));
>  
>  	/*
> +	 * On pSeries, inform the firmware about our capabilities
> +	 */
> +	if (RELOC(of_platform) & PLATFORM_PSERIES)
> +		prom_send_capabilities();
> +
> +	/*
>  	 * On pSeries, copy the CPU hold code
>  	 */
>         	if (RELOC(of_platform) & PLATFORM_PSERIES)
> -

/* Platforms supported by PPC64 */
#define PLATFORM_PSERIES      0x0100
#define PLATFORM_PSERIES_LPAR 0x0101
#define PLATFORM_ISERIES_LPAR 0x0201
#define PLATFORM_LPAR         0x0001
#define PLATFORM_POWERMAC     0x0400
#define PLATFORM_MAPLE        0x0500

Hrm... this will trigger on Maple too... Should I change Maple
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steven Rostedt | 1 Jun 2005 01:41
Gravatar

Re: RT patch acceptance

On Tue, 2005-05-31 at 17:47 -0400, Lee Revell wrote:
> On Tue, 2005-05-31 at 17:22 -0400, Steven Rostedt wrote:
> > I wouldn't call RTAI, RTLinux or a nano-kernel (embedded with Linux)
> > "Diamond" hard.  Maybe "Ruby" hard, but not diamond.  Remember, I use to
> > test code that was running airplane engines, and none of those mentioned
> > would qualify to run that.
> 
> I think trying to make these types of distinctions is a waste of time.
> What matters is the MTBF of the software relative to the hardware on a
> given system.  It would be stupid to use a commercial RTOS for a cell
> phone because they fall apart in a year anyway and users don't seem to
> care.  Ditto anything running on PC hardware.  For an airplane the MTBF
> obviously must be more in line with that hardware which hopefully is way
> more reliable.

Agreed.  I only brought up the stupid names just to show that there's
not a black and white aspect to what RT is.  It's mainly a black art
since there's no way to know how many bugs a program has, and how do you
truly calculate the MTBF, other than running it on the hardware itself?

> Only the engineer who designs the system knows for sure, so if the RT
> app people say PREEMPT_RT is good enough for a *very* large set of the
> applications that they currently need a commercial RTOS for, they should
> be given the benefit of the doubt.  To say otherwise is to assert that
> you know their hardware (be it desktop PC, digital audio workstation, or
> airplane) better than they do.

True, but do they really know how good PREEMPT_RT is, compared to those
that develop it and the kernel?  But I'm fighting to get PREEMPT_RT into
the kernel, since I really think it would be used by quite a lot in the
(Continue reading)

Permalink | Reply | 2 comments |

Gmane