Re: [PATCH] x86: fix build on non-C locales.

[Ingo Molnar]

* Priit Laes <[EMAIL PROTECTED]> wrote:

> x86: fix build on some non-C locales[1].
> 
> For some locales regex range [a-zA-Z] does not work as it is supposed 
> to so we have to specify LANG=C to make it work as intended.

thanks, applied.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ps3: Fix "unlikely" incorrect usage

[Samuel Tardieu]

Fix unlikely(plug) == NO_IRQ into unlikely(plug == NO_IRQ).

Signed-off-by: Samuel Tardieu <[EMAIL PROTECTED]>
---
 arch/powerpc/platforms/ps3/interrupt.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/platforms/ps3/interrupt.c 
b/arch/powerpc/platforms/ps3/interrupt.c
index 3a6db04..a14e5cd 100644
--- a/arch/powerpc/platforms/ps3/interrupt.c
+++ b/arch/powerpc/platforms/ps3/interrupt.c
@@ -709,7 +709,7 @@ static unsigned int ps3_get_irq(void)
asm volatile("cntlzd %0,%1" : "=r" (plug) : "r" (x));
plug &= 0x3f;
 
-   if (unlikely(plug) == NO_IRQ) {
+   if (unlikely(plug == NO_IRQ)) {
pr_debug("%s:%d: no plug found: thread_id %lu\n", __func__,
__LINE__, pd->thread_id);
dump_bmp(&per_cpu(ps3_private, 0));
-- 
1.5.4.2.197.g22c43

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.25-rc2 + smartd = hang

[Anders Eriksson]

[EMAIL PROTECTED] said:
> Could you try bisecting it down to the guilty commit using git-bisect?
> [ the "old" stuff got few hundred commits in 2.6.25 ]
> Thanks, Bart 

Will do. It'll take a while though. Not a fast machine and used by the 
household...

/A

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PM: Introduce PM_EVENT_HIBERNATE (was: Re: i915 hibernation patch (was: Re: 2.6.25-rc2 System no longer ...))

[Pavel Machek]

Hi!

> Thanks, applied. 
> 
> With this, I also find that I dislike the use of suspend/resume for 
> freezing for STD a lot less. It's still too easy to get confused, but at 
> least now drivers always have total knowledge about what is really going 
> on. I'd not like this interface as a driver writer, but now it's not 
> fundamentally broken any more, just slightly confusing.

Heh, thanks :-).
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Reducing debuginfo size by removing unneeded includes

[Samuel Tardieu]

Andy> -feliminate-unused-debug-types -feliminate-unused-debug-symbols
Andy> -feliminate-dwarf2-dups

Sam> google did not turn up anything useful.  Do you have a poiter to
Sam> where these are described?

>From GCC (svn) man page:

   -feliminate-unused-debug-symbols
   Produce debugging information in stabs format (if that is sup‐
   ported), for only symbols that are actually used.

   -feliminate-unused-debug-types
   Normally, when producing DWARF2 output, GCC will emit debugging
   information for all types declared in a compilation unit, regard‐
   less of whether or not they are actually used in that compilation
   unit.  Sometimes this is useful, such as if, in the debugger, you
   want to cast a value to a type that is not actually used in your
   program (but is declared).  More often, however, this results in a
   significant amount of wasted space.  With this option, GCC will
   avoid producing debug symbol output for types that are nowhere used
   in the source file being compiled.

   -feliminate-dwarf2-dups
   Compress DWARF2 debugging information by eliminating duplicated
   information about each symbol.  This option only makes sense when
   generating DWARF2 debugging information with -gdwarf-2.

 Sam
-- 
Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Reducing debuginfo size by removing unneeded includes

[Sam Ravnborg]

On Sun, Feb 24, 2008 at 09:25:19AM +0100, Samuel Tardieu wrote:
> Andy> -feliminate-unused-debug-types -feliminate-unused-debug-symbols
> Andy> -feliminate-dwarf2-dups
> 
> Sam> google did not turn up anything useful.  Do you have a poiter to
> Sam> where these are described?
> 
> >From GCC (svn) man page:
> 
>-feliminate-unused-debug-symbols
>Produce debugging information in stabs format (if that is sup‐
>ported), for only symbols that are actually used.
> 
>-feliminate-unused-debug-types
>Normally, when producing DWARF2 output, GCC will emit debugging
>information for all types declared in a compilation unit, regard‐
>less of whether or not they are actually used in that compilation
>unit.  Sometimes this is useful, such as if, in the debugger, you
>want to cast a value to a type that is not actually used in your
>program (but is declared).  More often, however, this results in a
>significant amount of wasted space.  With this option, GCC will
>avoid producing debug symbol output for types that are nowhere used
>in the source file being compiled.
> 
>-feliminate-dwarf2-dups
>Compress DWARF2 debugging information by eliminating duplicated
>information about each symbol.  This option only makes sense when
>generating DWARF2 debugging information with -gdwarf-2.
> 

Hi Sam.

I did not include the '-f' part in my google search. When I did so I got more 
hits.

Thanks,
Sam - who is not talking to himself ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: fix build on non-C locales.

[Sam Ravnborg]

Hi Prit.

Could we just use [[:alnum:]] and drop the setting of LC_ALL?

Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] snd-hda-intel

[Takashi Iwai]

At Sat, 23 Feb 2008 19:51:39 -0500,
Dave Jones wrote:
> 
> On Wed, Feb 13, 2008 at 03:31:31PM +0100, Takashi Iwai wrote:
>  > At Wed, 13 Feb 2008 15:25:14 +0100,
>  > Peter Zijlstra wrote:
>  > > 
>  > > lspci -vvv:
>  > > 
>  > > 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio 
> Controller (rev 02)
>  > 
>  > Is this a regression, i.e. did you get similar Oops with previous
>  > kernels?
> 
> This looks like ..  
> http://www.kerneloops.org/guilty.php?guilty=azx_pcm_prepare&version=2.6.25-rc2&start=1638912&end=1639167&class=oops
> kerneloops.org claims to have 2 oopses from 2.6.24 there too, but when 
> clicked,
> they show nothing. Arjan ?

This Oops from azx_prepare is only on ATI HDMI device and is fixed now
on Linus git tree.


thanks,

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] More accessible usage of custom flags

[Nicholas Marquez]

On Sat, Feb 23, 2008 at 6:39 PM, Nick Andrew <[EMAIL PROTECTED]> wrote:
> On Sat, Feb 23, 2008 at 05:28:23PM -0500, Nicholas Marquez wrote:
>  > First of all, thanks for the input!
>  >
>  > On Sat, Feb 23, 2008 at 5:04 PM, Nick Andrew <[EMAIL PROTECTED]> wrote:
>  > > On Sat, Feb 23, 2008 at 04:28:50PM -0500, Nicholas Marquez wrote:
>  >
>
> > There are a few places in the Makefile where options would need to be
>  > entered.  This just brings those places together in a clean manner and
>  > allows for one to set the flags via the configuration interface.
>  > Though it would be excellent if the kernel had more gcc
>  > micro-optimization (facilitated by such features as the upcoming gcc
>  > 4.3's -finstrument-functions-exclude-function-list option), general
>  > CFLAGS used for the entire kernel do not impact the safety of the
>  > kernel build, assuming that the options are sane.  It would be
>  > interesting, however, to see an initiative to tune gcc flags for
>  > important functions and  sections within the kernel for optimal
>  > performance given some sort of envisioned usage.  (*hint, kernel devs,
>  > hint*)
>
>  If there are some "common" optimisation flags or sets of flags then
>  maybe they could be turned on/off by invididual config options? There's
>  already CC_OPTIMIZE_FOR_SIZE sorta tagged as experimental. But then,
>  enumerating the allowable flags may limit the user's choices whereas I
>  take it you'd like to expand them.

Yes, I would like to expand them.  If possibly, I'd like to take out
the individual config options for gcc flags and integrate them into
the help description.  I feel that the redundancy would not only be
ugly, but possibly confusing.
- Show quoted text -


>
>
>  > >  > >  @@ -487,6 +487,52 @@
>  > >  > >option.  If problems are observed, a gcc upgrade may be 
> needed.
>  > >  > >
>  > >  > >If unsure, say N.
>  > >  > >  +
>  > >  > >  +menu "Custom flags"
>  > >  > >  +
>  > >  > >  +config CUSTOM_CFLAGS
>  > >  > >  +string "Custom CFLAGS for kernel"
>  > >  > >  +default ""
>  > >  > >  +help
>  > >  > >  +You can use this to easily set custom gcc CFLAGS to be 
> used for the
>  > >  > >  +entire kernel (including modules).
>  > >  > >  +
>  > >  > >  +ONLY ADD CUSTOM CFLAGS IF YOU KNOW WHAT YOU ARE DOING
>  > >  > >  +
>  > >  > >  +If unsure, leave blank.
>  > >
>  > >  Sorry, but I don't think we need shouting. There are a few options
>  > >  already which have bad results if you unknowingly choose the wrong 
> option,
>  > >  like enabling EMBEDDED and turning off the BLOCK layer, yet the help
>  > >  description doesn't shout.
>  >
>  > Sorry about that.  I didn't mean to portray it as "shouting" so much
>  > as a very visible and stern warning.
>
>  I'm hoping we don't need any stern warnings in the kernel configuration.
>  Although I expect configuring bogus gcc flags is going to break the
>  build far worse than selecting bad options otherwise. If the user
>  makes a mistake in CUSTOM_CFLAGS is the build going to fail with
>  a message "error in CUSTOM_CFLAGS" or is it going to spew out pages
>  of gcc error messages?  It is nice if error messages can point back
>  to the source of the error, so the user doesn't have to look through
>  the entire kernel configuration for what they did wrong.

I hadn't thought of that.  It would certainly be more useful than a
stern warning.  ^^;  Have you any ideas on how to implement such a
thing?  I would imagine a configure-script-like test on the flags to
make sure that gcc could take them correctly would be in order.  Then
one could also capture any warnings or errors that gcc outputs (such
as redundant flags, improper invocation, etc.), fail the build, and
output the messages.  As far as capturing dangerous flags for the
kernel (such as -ffast-math or -fmerge-all-constants), there could be
a blacklist... but that would depend on the gcc version used... :/
Perhaps the automated catching of errors and warnings would be best
alone.
>
>
>  > Something else that could be included is a link to the manual for the
>  > (currently used) gcc's command flags
>  > (http://gcc.gnu.org/onlinedocs/gcc-4.2.3/gcc/index.html#toc_Invoking-GCC)
>  > or at least to the online docs, considering that specifying one
>  > specific gcc version's manual would yield various issues.
>
>  "info gcc" will give all that information in far more detail than I
>  have time to read.

I believe you misunderstand.  I mean to include the link in the help
message.  Like how the links to the appropriate sites for device
drivers are included in their help messages.
>
>
>  > >  The boilerplate "If unsure, leave blank" covers (or is meant to cover)
>  > >  the situation where the user does not know what they are doing. It says
>  > >  "If you don't know what you are doing, just leave this field blank,
>  > >  and everything will be OK" ... except it is put in a non-threatening,
>  > >  non-demean

help needed : kernel 2.4 sata_nv smp 4G

[Vitaly Kroivets]

Dear All,

I need help with following problem.
We use kernel 2.4.32 ,
Motherboard is Tyan k8SE which uses Nvidia Nforce 2200 (CK8-04) chips,
we have 2 Dualcore opterons and 4G ram , and SATA disk WD1600YS-01S .
Sometimes (once a 3-4 weeks) the computer stops responding with following
message:

ata1: command 0x35 timeout, stat 0xd0 host_stat 0x21
ata1: translated ATA stat/err 0xd0/00 to SCSI SK/ASC/ASCQ 0xb/47/00
ata1: status=0xd0 { Busy }
SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 802
Current sd08:03: sense key Aborted Command
Additional sense indicates Scsi parity error
I/O error: dev 08:03, sector 5367736
ATA: abnormal status 0xD0 on port 0x1447
ATA: abnormal status 0xD0 on port 0x1447
ATA: abnormal status 0xD0 on port 0x1447

Here is similar error reported in 2.6.
- http://readlist.com/lists/vger.kernel.org/linux-kernel/30/154602.html
But although we have a recent sata_nv code, it still does not work...
Unfortunately we can not upgrade  to 2.6 now.

Do you know how I reproduce and fix this problem reliably?
Why it happens?

Any help will be appreciated very much.

Thanks in advance,
  Vitaly

Below I added the output of dmesg and kernel config.

cross CPUs: passed.
migration_task 0 on cpu=0
migration_task 1 on cpu=1
migration_task 2 on cpu=2
migration_task 3 on cpu=3
ACPI: Subsystem revision 20040326
PCI: PCI BIOS revision 2.10 entry at 0xfd741, last bus=26
PCI: Using configuration type 1
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: System [ACPI] (supports S0 S1 S4 S5)
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
Transparent bridge - PCI device 10de:005c
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P2P0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.XVR0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.XVR1._PRT]
ACPI: PCI Interrupt Link [LNK1] (IRQs 16 17 18 19) *0
ACPI: PCI Interrupt Link [LNK2] (IRQs 16 17 18 19) *0
ACPI: PCI Interrupt Link [LNK3] (IRQs 16 17 18 19) *0
ACPI: PCI Interrupt Link [LNK4] (IRQs 16 17 18 19) *0
ACPI: PCI Interrupt Link [LNK5] (IRQs 16 17 18 19) *0, disabled.
ACPI: PCI Interrupt Link [LSMB] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [LUS0] (IRQs 20 21 22 23) *0
ACPI: PCI Interrupt Link [LUS2] (IRQs 20 21 22 23) *0
ACPI: PCI Interrupt Link [LMAC] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [LACI] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [LMCI] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [LPID] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [LTID] (IRQs 20 21 22 23) *0
ACPI: PCI Interrupt Link [LSI1] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCP] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Root Bridge [PCI2] (00:18)
PCI: Probing PCI hardware (bus 18)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI2.G0PA._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI2.G0PB._PRT]
PCI: Probing PCI hardware
ACPI: PCI Interrupt Link [LSMB] enabled at IRQ 23
00:00:01[A] -> 4-23 -> IRQ 23 level high
ACPI: PCI Interrupt Link [LUS0] enabled at IRQ 22
00:00:02[A] -> 4-22 -> IRQ 22 level high
ACPI: PCI Interrupt Link [LUS2] enabled at IRQ 21
00:00:02[B] -> 4-21 -> IRQ 21 level high
ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 20
00:00:0a[A] -> 4-20 -> IRQ 20 level high
ACPI: PCI Interrupt Link [LACI] enabled at IRQ 23
ACPI: PCI Interrupt Link [LMCI] enabled at IRQ 22
ACPI: PCI Interrupt Link [LPID] enabled at IRQ 21
ACPI: PCI Interrupt Link [LTID] enabled at IRQ 20
ACPI: PCI Interrupt Link [LSI1] enabled at IRQ 23
ACPI: PCI Interrupt Link [LNK3] enabled at IRQ 19
00:01:06[A] -> 4-19 -> IRQ 19 level high
ACPI: PCI Interrupt Link [LNK1] enabled at IRQ 18
00:01:04[A] -> 4-18 -> IRQ 18 level high
ACPI: PCI Interrupt Link [LNK2] enabled at IRQ 17
00:01:04[B] -> 4-17 -> IRQ 17 level high
ACPI: PCI Interrupt Link [LNK4] enabled at IRQ 16
00:01:04[D] -> 4-16 -> IRQ 16 level high
00:19:02[A] -> 5-2 -> IRQ 26 level low
00:19:02[B] -> 5-3 -> IRQ 27 level low
00:19:02[C] -> 5-0 -> IRQ 24 level low
00:19:02[D] -> 5-1 -> IRQ 25 level low
00:1a:03[A] -> 6-2 -> IRQ 30 level low
00:1a:03[B] -> 6-3 -> IRQ 31 level low
00:1a:03[C] -> 6-0 -> IRQ 28 level low
00:1a:03[D] -> 6-1 -> IRQ 29 level low
number of MP IRQ sources: 16.
number of IO-APIC #4 registers: 24.
number of IO-APIC #5 registers: 4.
number of IO-APIC #6 registers: 4.
testing the IO APIC...
IO APIC #4..
 register #00: 0400
... : physical APIC id: 04
... : Delivery Type: 0
... : LTS : 0
 register #01: 00170011
... : max redirection entries: 0017
... : PRQ implemented: 0
... : IO APIC version: 0011
 register #02: 0400
... : arbitration: 04
 IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 00F 0F 0 0 0 0 0 1 1 31
01 00F 0F 0 0 0 0 0 1 1 39
02 00F 0F 0 0 0 0 0 1 1 41
03 00F 0F 0 0 0 0 0 1 1 49
04 00F 0F 0 0 0 0 0 1 1 51
05 00F 0F 0 0 0 0 0 

Re: [PATCH][RFC] Remove "obsolete" digiepca content.

[Jiri Slaby]

On 02/09/2008 10:45 PM, Robert P. J. Day wrote:

Remove the Digi Intl. epca driver for Linux, which is marked as
"obsolete."

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---
  this is a quick, first pass at a removal.  feel free to suggest
tweaks.


Was there any comments on this? I suggest reposting with Cc to akpm.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: getting uninterruptible sleep processes after upgrade from 2.6.20.20 to 2.6.24.2

[Jiri Slaby]

Ccing xfs team

On 02/21/2008 02:37 PM, Stefan Priebe - allied internet ag wrote:

Hello!

I'm using XFS. dmesg -s32000 does not help - no more output. In messages 
there is also no relevant output. Other than what I've posted here:

http://lkml.org/lkml/2008/2/21/76


http://lkml.org/lkml/2008/2/21/86

Some kind of borkage in readdir, probably either in xfs or vfs?

Sorry but i cannot recompile the kernel on all machines again - another 
downtime is not possible at the moment.


Stefan

Jiri Slaby schrieb:

Stefan Priebe - allied internet ag napsal(a):

Hello!

I've done the (echo t > /proc/sysrq-trigger) now but i'm not able to get
the whole output via dmesg.

Here is what i get:
# dmesg
3.432124]  [] do_select+0x390/0x46e
[272363.432226]  [] __pollwait+0x0/0xcf
[272363.432319]  [] default_wake_function+0x0/0x8


dmesg ring buffer is too small to fit this in. Please repeat it once 
again
with bigger ringbuffer (dmesg -s if you have this chosen in your 
kernel) or

post /var/log/meassages output of all processes. I see only waiters in
readdir, not seeing who could block them.

Which filesystem did you run du on?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] regulator: regulator core.

[Mark Brown]

On Sat, Feb 23, 2008 at 09:52:17AM +, Russell King - ARM Linux wrote:
> On Sat, Feb 23, 2008 at 12:05:38AM -0800, Andrew Morton wrote:

> > > +#undef current

> > err, no ;)  Please rename your stuff.

> Renaming is not an option - "current" is an electronic term for which
> there is no alternative.  The real problem is this __ATTR macro crap:

Indeed, and this is already being worked around by
drivers/power/power_supply_sysfs.c:

#define POWER_SUPPLY_ATTR(_name)\
{   \
.attr = { .name = #_name, .mode = 0444, .owner = THIS_MODULE }, \
.show = power_supply_show_property, \
.store = NULL,  \
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] USB: remove unnecessary type casting of urb->context

[Ming Lei]

urb->context code cleanup

Signed-off-by: Ming Lei <[EMAIL PROTECTED]>
---
 drivers/usb/atm/cxacru.c  |2 +-
 drivers/usb/class/cdc-acm.c   |2 +-
 drivers/usb/misc/auerswald.c  |   12 ++--
 drivers/usb/misc/ftdi-elan.c  |2 +-
 drivers/usb/misc/iowarrior.c  |4 ++--
 drivers/usb/misc/legousbtower.c   |4 ++--
 drivers/usb/misc/usblcd.c |2 +-
 drivers/usb/misc/usbtest.c|4 ++--
 drivers/usb/serial/belkin_sa.c|2 +-
 drivers/usb/serial/cyberjack.c|6 +++---
 drivers/usb/serial/cypress_m8.c   |4 ++--
 drivers/usb/serial/digi_acceleport.c  |8 
 drivers/usb/serial/empeg.c|2 +-
 drivers/usb/serial/ftdi_sio.c |4 ++--
 drivers/usb/serial/garmin_gps.c   |6 +++---
 drivers/usb/serial/generic.c  |4 ++--
 drivers/usb/serial/io_edgeport.c  |8 
 drivers/usb/serial/io_ti.c|6 +++---
 drivers/usb/serial/ipaq.c |4 ++--
 drivers/usb/serial/ir-usb.c   |4 ++--
 drivers/usb/serial/iuu_phoenix.c  |   16 
 drivers/usb/serial/keyspan.c  |   28 ++--
 drivers/usb/serial/keyspan_pda.c  |4 ++--
 drivers/usb/serial/kl5kusb105.c   |4 ++--
 drivers/usb/serial/mct_u232.c |2 +-
 drivers/usb/serial/mos7840.c  |8 
 drivers/usb/serial/omninet.c  |4 ++--
 drivers/usb/serial/option.c   |6 +++---
 drivers/usb/serial/oti6858.c  |6 +++---
 drivers/usb/serial/pl2303.c   |6 +++---
 drivers/usb/serial/safe_serial.c  |2 +-
 drivers/usb/serial/sierra.c   |4 ++--
 drivers/usb/serial/ti_usb_3410_5052.c |6 +++---
 drivers/usb/serial/visor.c|6 +++---
 drivers/usb/serial/whiteheat.c|6 +++---
 drivers/usb/storage/transport.c   |2 +-
 drivers/usb/usb-skeleton.c|2 +-
 37 files changed, 101 insertions(+), 101 deletions(-)

diff --git a/drivers/usb/atm/cxacru.c b/drivers/usb/atm/cxacru.c
index a51eeed..d470c72 100644
--- a/drivers/usb/atm/cxacru.c
+++ b/drivers/usb/atm/cxacru.c
@@ -444,7 +444,7 @@ CXACRU_ALL_FILES(INIT);
 /* the following three functions are stolen from drivers/usb/core/message.c */
 static void cxacru_blocking_completion(struct urb *urb)
 {
-   complete((struct completion *)urb->context);
+   complete(urb->context);
 }
 
 static void cxacru_timeout_kill(unsigned long data)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index bcc4213..705c471 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -450,7 +450,7 @@ urbs:
 /* data interface wrote those outgoing bytes */
 static void acm_write_bulk(struct urb *urb)
 {
-   struct acm *acm = (struct acm *)urb->context;
+   struct acm *acm = urb->context;
 
dbg("Entering acm_write_bulk with status %d", urb->status);
 
diff --git a/drivers/usb/misc/auerswald.c b/drivers/usb/misc/auerswald.c
index df7e1ec..920f561 100644
--- a/drivers/usb/misc/auerswald.c
+++ b/drivers/usb/misc/auerswald.c
@@ -283,7 +283,7 @@ static void auerchain_complete (struct urb * urb)
 int result;
 
 /* get pointer to element and to chain */
-pauerchainelement_t acep = (pauerchainelement_t) urb->context;
+pauerchainelement_t acep =  urb->context;
 pauerchain_t acp = acep->chain;
 
 /* restore original entries in urb */
@@ -593,7 +593,7 @@ ac_fail:/* free the elements */
 /* completion handler for synchronous chained URBs */
 static void auerchain_blocking_completion (struct urb *urb)
 {
-   pauerchain_chs_t pchs = (pauerchain_chs_t)urb->context;
+   pauerchain_chs_t pchs = urb->context;
pchs->done = 1;
wmb();
wake_up (&pchs->wqh);
@@ -846,7 +846,7 @@ static int auerswald_status_retry (int status)
 /* Completion of asynchronous write block */
 static void auerchar_ctrlwrite_complete (struct urb * urb)
 {
-   pauerbuf_t bp = (pauerbuf_t) urb->context;
+   pauerbuf_t bp =  urb->context;
pauerswald_t cp = ((pauerswald_t)((char *)(bp->list)-(unsigned 
long)(&((pauerswald_t)0)->bufctl)));
dbg ("auerchar_ctrlwrite_complete called");
 
@@ -859,7 +859,7 @@ static void auerchar_ctrlwrite_complete (struct urb * urb)
 /* Completion handler for dummy retry packet */
 static void auerswald_ctrlread_wretcomplete (struct urb * urb)
 {
-pauerbuf_t bp = (pauerbuf_t) urb->context;
+pauerbuf_t bp =  urb->context;
 pauerswald_t cp;
int ret;
int status = urb->status;
@@ -903,7 +903,7 @@ static void auerswald_ctrlread_complete (struct urb * urb)
 unsigned int  serviceid;
 pauerswald_t  cp;
 pauerscon_t   scp;
-pauerbuf_tbp  = (pauerbuf_t) urb->context;
+pauerbuf_tbp  =  urb->context;
int status = urb->status;
  

Re: [RFC 01/11] add generic versions of debugfs file operations

[Arnd Bergmann]

On Saturday 23 February 2008, Al Viro wrote:

> Ewww - caps, \n...  BTW, \0 is pointless here - simple_read_from_buffer() will
> not access it with these arguments)...

> ... 

> Please, check the length; sloppy input grammar is a bad idea.  Hell, at the
> very least you want -EINVAL if input is not recognized...

Ok, these two come straight from debugfs, but of course I can fix them
anyway. Should I do a fix for debugfs in 2.6.25 first, or rather do a
patch on top of the libfs rework?

I'd rather not have any semantic changes during the conversion, so
it would be better to keep that separate imho.

Arnd <><
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 02/11] introduce simple_fs_type

[Arnd Bergmann]

On Saturday 23 February 2008, Al Viro wrote:
> On Tue, Feb 19, 2008 at 05:04:37AM +0100, Arnd Bergmann wrote:
> > The most interesting function here is the new "struct dentry *
> > simple_register_filesystem(struct simple_fs_type *type)", which
> > returns the root directory of a new file system that can then
> > be passed to simple_create_file() and similar functions as a
> > parent.
> 
> Don't mix "split the file" with "add new stuff", please. 

Ok, I'll introduce it in libfs.c first then.

> And frankly, I'm not convinced that embedding file_system_type
> into another struct is a good idea.

Right, that has been one of the areas I've been thinking about
myself without coming to a good solution. One alternative I
thought about is to have the news members as part of file_system_type
itself, but that would cost a bit of memory for every single 
file system, and might lead to unintended misuse of these members
by non-simple file systems.

Do you think it would be better to dynamically allocate the
file_system_type and have a pointer in struct simple_fs_type to
it?

Arnd <><
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] x86: Coding Style fixes to arch/x86/power/cpu_32.c

[Paolo Ciarrocchi]

File is now error free.
Compile tested.
Patch is against x86#testing


Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]>
---
 arch/x86/power/cpu_32.c |   41 +++--
 1 files changed, 23 insertions(+), 18 deletions(-)

diff --git a/arch/x86/power/cpu_32.c b/arch/x86/power/cpu_32.c
index 7f9c6da..7dc5d5c 100644
--- a/arch/x86/power/cpu_32.c
+++ b/arch/x86/power/cpu_32.c
@@ -27,17 +27,17 @@ static void __save_processor_state(struct saved_context 
*ctxt)
/*
 * descriptor tables
 */
-   store_gdt(&ctxt->gdt);
-   store_idt(&ctxt->idt);
-   store_tr(ctxt->tr);
+   store_gdt(&ctxt->gdt);
+   store_idt(&ctxt->idt);
+   store_tr(ctxt->tr);
 
/*
 * segment registers
 */
-   savesegment(es, ctxt->es);
-   savesegment(fs, ctxt->fs);
-   savesegment(gs, ctxt->gs);
-   savesegment(ss, ctxt->ss);
+   savesegment(es, ctxt->es);
+   savesegment(fs, ctxt->fs);
+   savesegment(gs, ctxt->gs);
+   savesegment(ss, ctxt->ss);
 
/*
 * control registers
@@ -48,10 +48,12 @@ static void __save_processor_state(struct saved_context 
*ctxt)
ctxt->cr4 = read_cr4();
 }
 
+/* Needed by apm.c */
 void save_processor_state(void)
 {
__save_processor_state(&saved_context);
 }
+EXPORT_SYMBOL(save_processor_state);
 
 static void do_fpu_end(void)
 {
@@ -64,9 +66,14 @@ static void do_fpu_end(void)
 static void fix_processor_context(void)
 {
int cpu = smp_processor_id();
-   struct tss_struct * t = &per_cpu(init_tss, cpu);
+   struct tss_struct *t = &per_cpu(init_tss, cpu);
 
-   set_tss_desc(cpu,t);/* This just modifies memory; should not be 
necessary. But... This is necessary, because 386 hardware has concept of busy 
TSS or some similar stupidity. */
+   set_tss_desc(cpu, t);   /*
+* This just modifies memory; should not be
+* necessary. But... This is necessary, because
+* 386 hardware has concept of busy TSS or some
+* similar stupidity.
+*/
 
load_TR_desc(); /* This does ltr */
load_LDT(¤t->active_mm->context); /* This does lldt */
@@ -100,16 +107,16 @@ static void __restore_processor_state(struct 
saved_context *ctxt)
 * now restore the descriptor tables to their proper values
 * ltr is done i fix_processor_context().
 */
-   load_gdt(&ctxt->gdt);
-   load_idt(&ctxt->idt);
+   load_gdt(&ctxt->gdt);
+   load_idt(&ctxt->idt);
 
/*
 * segment registers
 */
-   loadsegment(es, ctxt->es);
-   loadsegment(fs, ctxt->fs);
-   loadsegment(gs, ctxt->gs);
-   loadsegment(ss, ctxt->ss);
+   loadsegment(es, ctxt->es);
+   loadsegment(fs, ctxt->fs);
+   loadsegment(gs, ctxt->gs);
+   loadsegment(ss, ctxt->ss);
 
/*
 * sysenter MSRs
@@ -123,11 +130,9 @@ static void __restore_processor_state(struct saved_context 
*ctxt)
mcheck_init(&boot_cpu_data);
 }
 
+/* Needed by apm.c */
 void restore_processor_state(void)
 {
__restore_processor_state(&saved_context);
 }
-
-/* Needed by apm.c */
-EXPORT_SYMBOL(save_processor_state);
 EXPORT_SYMBOL(restore_processor_state);
-- 
1.5.4.2.316.gf7a7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: jffs2: -ENOSPC when truncating file?!

[David Woodhouse]

On Sun, 2008-02-24 at 07:57 +0100, Jörn Engel wrote:
> Could a naïve implementation of this get exploited by doing a large
> number of truncates that just shave single bytes off various files?

Yeah, which is why _my_ naïve implementation would do it for
truncate-to-zero instead of just _any_ truncate (which could even be
truncate-to-larger).

A more complex version might allow _any_ transaction to eat into the
ALLOC_DELETION pool if it is ultimately going to reduce the amount of
space taken on the file system -- even overwriting 'real' data with
zeroes which compress better. That's going to be hard to calculate in
the general case though.

If allowing only truncate-to-zero isn't good enough, perhaps we could
allow truncation to use the ALLOC_DELETION pool when it's going to
obsolete at least one full data node. That's not so hard to check.

-- 
dwmw2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] x86: Coding Style fixes to arch/x86/kernel/cpu/common.c

[Paolo Ciarrocchi]

File is now error free.
Compile tested.


Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]>
---
 arch/x86/kernel/cpu/common.c |  105 ++---
 1 files changed, 56 insertions(+), 49 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 750456f..d0de972 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -62,9 +62,9 @@ __u32 cleared_cpu_caps[NCAPINTS] __cpuinitdata;
 static int cachesize_override __cpuinitdata = -1;
 static int disable_x86_serial_nr __cpuinitdata = 1;
 
-struct cpu_dev * cpu_devs[X86_VENDOR_NUM] = {};
+struct cpu_dev *cpu_devs[X86_VENDOR_NUM] = {};
 
-static void __cpuinit default_init(struct cpuinfo_x86 * c)
+static void __cpuinit default_init(struct cpuinfo_x86 *c)
 {
/* Not much we can do here... */
/* Check if at least it has cpuid */
@@ -81,11 +81,11 @@ static struct cpu_dev __cpuinitdata default_cpu = {
.c_init = default_init,
.c_vendor = "Unknown",
 };
-static struct cpu_dev * this_cpu __cpuinitdata = &default_cpu;
+static struct cpu_dev *this_cpu __cpuinitdata = &default_cpu;
 
 static int __init cachesize_setup(char *str)
 {
-   get_option (&str, &cachesize_override);
+   get_option(&str, &cachesize_override);
return 1;
 }
 __setup("cachesize=", cachesize_setup);
@@ -107,12 +107,12 @@ int __cpuinit get_model_name(struct cpuinfo_x86 *c)
/* Intel chips right-justify this string for some dumb reason;
   undo that brain damage */
p = q = &c->x86_model_id[0];
-   while ( *p == ' ' )
+   while (*p == ' ')
 p++;
-   if ( p != q ) {
-while ( *p )
+   if (p != q) {
+while (*p)
  *q++ = *p++;
-while ( q <= &c->x86_model_id[48] )
+while (q <= &c->x86_model_id[48])
  *q++ = '\0';  /* Zero-pad the rest */
}
 
@@ -130,7 +130,7 @@ void __cpuinit display_cacheinfo(struct cpuinfo_x86 *c)
cpuid(0x8005, &dummy, &dummy, &ecx, &edx);
printk(KERN_INFO "CPU: L1 I Cache: %dK (%d bytes/line), D cache 
%dK (%d bytes/line)\n",
edx>>24, edx&0xFF, ecx>>24, ecx&0xFF);
-   c->x86_cache_size=(ecx>>24)+(edx>>24);  
+   c->x86_cache_size = (ecx>>24)+(edx>>24);
}
 
if (n < 0x8006) /* Some chips just has a large L1. */
@@ -138,16 +138,16 @@ void __cpuinit display_cacheinfo(struct cpuinfo_x86 *c)
 
ecx = cpuid_ecx(0x8006);
l2size = ecx >> 16;
-   
+
/* do processor-specific cache resizing */
if (this_cpu->c_size_cache)
-   l2size = this_cpu->c_size_cache(c,l2size);
+   l2size = this_cpu->c_size_cache(c, l2size);
 
/* Allow user to override all this if necessary. */
if (cachesize_override != -1)
l2size = cachesize_override;
 
-   if ( l2size == 0 )
+   if (l2size == 0)
return; /* Again, no L2 cache is possible */
 
c->x86_cache_size = l2size;
@@ -156,16 +156,19 @@ void __cpuinit display_cacheinfo(struct cpuinfo_x86 *c)
   l2size, ecx & 0xFF);
 }
 
-/* Naming convention should be:  [()] */
-/* This table only is used unless init_() below doesn't set it; */
-/* in particular, if CPUID levels 0x8002..4 are supported, this isn't used 
*/
+/*
+ * Naming convention should be:  [()]
+ * This table only is used unless init_() below doesn't set it;
+ * in particular, if CPUID levels 0x8002..4 are supported, this isn't used
+ *
+ */
 
 /* Look up CPU names by table lookup. */
 static char __cpuinit *table_lookup_model(struct cpuinfo_x86 *c)
 {
struct cpu_model_info *info;
 
-   if ( c->x86_model >= 16 )
+   if (c->x86_model >= 16)
return NULL;/* Range check */
 
if (!this_cpu)
@@ -190,9 +193,9 @@ static void __cpuinit get_cpu_vendor(struct cpuinfo_x86 *c, 
int early)
 
for (i = 0; i < X86_VENDOR_NUM; i++) {
if (cpu_devs[i]) {
-   if (!strcmp(v,cpu_devs[i]->c_ident[0]) ||
-   (cpu_devs[i]->c_ident[1] && 
-!strcmp(v,cpu_devs[i]->c_ident[1]))) {
+   if (!strcmp(v, cpu_devs[i]->c_ident[0]) ||
+   (cpu_devs[i]->c_ident[1] &&
+!strcmp(v, cpu_devs[i]->c_ident[1]))) {
c->x86_vendor = i;
if (!early)
this_cpu = cpu_devs[i];
@@ -210,7 +213,7 @@ static void __cpuinit get_cpu_vendor(struct cpuinfo_x86 *c, 
int early)
 }
 
 
-static int __init x86_fxsr_setup(char * s)
+static int __init x86_fxsr_setup(char *s)
 {
setup_clear_cpu_cap(X86_FEATURE_FXSR);
setup_clear_cpu_cap(X86_FEATURE_XMM);
@@ -219,7 +222,7 @@ static int __init x86_fxsr_setup(char * s)
 __setup("nofxsr", x86_f

Re: [RFC 03/11] slim down debugfs

[Arnd Bergmann]

On Saturday 23 February 2008, Al Viro wrote:
> > +config LIBFS
> > + tristate
> > + default m
> > + help
> > +   libfs is a helper library used by many of the simpler file
> > +   systems. Parts of libfs can be modular when all of its users
> > +   are modules as well, and the users should select this symbol.
> 
> NAK.  For one thing, you need dependencies or selects and none of the
> patches later in the series introduces them.  For another, neither
> dependencies nor selects work well if you have non-modular users of
> that sucker.  Seriously, try to add those and do allmodconfig.  Then
> look what a mess it produces.

Sorry about that hunk, I didn't mean to keep that in there. In
my testing, I used the newly introduced parts as a loadable
module, and at one point the intention was to keep the existing
libfs functions as builtin and add a new Kconfig dependency in every
user of the new stuff whenever a file system gets converted.

I figured out later that hardly anyone could even try to build
without them as soon as all the trival file systems are moved
over, but forgot to make it always builtin.

Arnd <><
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[BUG] 2.6.25-rc2-git8 fails to boot on 486 due to TSC breakage

[Mikael Pettersson]

The kernel for this 486 has CONFIG_M486=y and CONFIG_M586TSC=n,
but the 2.6.25 kernels still try to access the TSC. Here's the
oops from 2.6.25-rc2-git8:

Pid: 0, comm: swapper Not tainted (2.6.25-rc2-git8 #1)
EIP: 0060:[] EFLAGS: 00010002 CPU: 0
EIP is at native_read_tsc+0x6/0x10
EAX: 8ce6 EBX: c19f8620 ECX: c19f8620 EDX: 00300100
ESI: 00300100 EDI: 0001 EBP: c19f7578 ESP: c02a7eec
 DS: 007b ES: 007b FS:  GS:  SS: 0068
Process swapper (pid: 0, ti=c02a6000 task=c028d300 task.ti=c02a6000)
Stack: c01b37e5  1000 8ce6  c19f7578  c019a2e7 
   c02e05cc c02e05cc c01da229 0016 c01da302 1000 0001 c029d4e0 
   c02e05cc 0050 c01dee35  c02e05cc c01dfc18 c02e0580 c1834ca0 
Call Trace:
 [] add_timer_randomness+0x115/0x170
 [] __blk_end_request+0x17/0x50
 [] __ide_end_request+0x39/0xe0
 [] ide_end_request+0x32/0x50
 [] task_end_request+0x25/0x70
 [] task_in_intr+0xd8/0xe0
 [] ide_intr+0x7a/0x1a0
 [] task_in_intr+0x0/0xe0
 [] run_timer_softirq+0x12/0x150
 [] handle_IRQ_event+0x30/0x70
 [] handle_level_irq+0x42/0x90
 [] do_IRQ+0x41/0x70
 [] common_interrupt+0x23/0x30
 [] arm_timer+0xa0/0x2b0
 [] default_idle+0x3d/0x60
 [] default_idle+0x0/0x60
 [] cpu_idle+0x20/0x70
 [] start_kernel+0x1e3/0x260
 ===
Code: 90 90 90 90 90 b8 8e 21 00 00 e9 a6 28 0a 00 8d b6 00 00 00 00 e6 ed c3 
90 90 90 90 90 90 90 90 9 
EIP: [] native_read_tsc+0x6/0x10 SS:ESP 0068:c02a7eec
Kernel panic - not syncing: Fatal exception in interrupt

This bug is also seen with 2.6.25-rc1.
Kernels up to and including 2.6.24 did not have this bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

strange behavior on multimedia eject button for cdrom

[Harald Dunkel]

Hi folks,

My laptop (Dell XPS M1330) has some multimedia keys added to the
keyboard, including an eject button for the cdrom drive, instead
of a "regular" eject button built into the drive itself.

When I press it to eject a CD, then Linux becomes pretty mad: The
audio device gets stuck somehow, playing the same tune over and
over again, the network connection is frozen, etc. Once the CD is
out it is back to normal, as it seems.

I would guess that the eject button triggers some bios functionality,
outside of the control of the kernel. But is it? How comes that
Linux seems to loose control in this case?

Kernel is 2.6.24.2 (amd64).

AFAICS this eject button has no keycode. The other multimedia keys
have.


Any helpful idea would be very welcome.


Regards

Harri

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: jffs2: -ENOSPC when truncating file?!

[Jörn Engel]

On Sun, 24 February 2008 18:57:32 +0800, David Woodhouse wrote:
> On Sun, 2008-02-24 at 07:57 +0100, Jörn Engel wrote:
> > Could a naïve implementation of this get exploited by doing a large
> > number of truncates that just shave single bytes off various files?
> 
> Yeah, which is why _my_ naïve implementation would do it for
> truncate-to-zero instead of just _any_ truncate (which could even be
> truncate-to-larger).

Truncate-to-larger is trivial to check.  Almost every filesystem does it
somewhere, including JFFS2. ;)

But yeah, truncate-to-zero should catch the common case.

> If allowing only truncate-to-zero isn't good enough, perhaps we could
> allow truncation to use the ALLOC_DELETION pool when it's going to
> obsolete at least one full data node. That's not so hard to check.

I would simply always write out a "full" replacement node, i.e. the
complete tail page for the file.  No need to check if an old node gets
obsoleted, we just made sure it does.  Anyway, it is your baby, so you
get to change the dirty diapers and pick your favorite pair of clean
ones.

Jörn

-- 
Joern's library part 3:
http://inst.eecs.berkeley.edu/~cs152/fa05/handouts/clark-test.pdf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PM: Introduce PM_EVENT_HIBERNATE (was: Re: i915 hibernation patch (was: Re: 2.6.25-rc2 System no longer ...))

[Rafael J. Wysocki]

On Sunday, 24 of February 2008, Mirco Tischler wrote:
> 
> On Sa, 2008-02-23 at 19:13 +0100, Rafael J. Wysocki wrote:
> > Index: linux-2.6/drivers/usb/host/u132-hcd.c
> > ===
> > --- linux-2.6.orig/drivers/usb/host/u132-hcd.c
> > +++ linux-2.6/drivers/usb/host/u132-hcd.c
> > @@ -3214,14 +3214,19 @@ static int u132_suspend(struct platform_
> >  return -ESHUTDOWN;
> >  } else {
> >  int retval = 0;
> > -if (state.event == PM_EVENT_FREEZE) {
> > +
> > +   switch (state.event) {
> > +   case PM_EVENT_FREEZE:
> >  retval = u132_bus_suspend(hcd);
> > -} else if (state.event == PM_EVENT_SUSPEND) {
> > +   break;
> > +   case PM_EVENT_SUSPEND:
> > +   case PM_EVENT_HIBERNATE:
> >  int ports = MAX_U132_PORTS;
> >  while (ports-- > 0) {
> >  port_power(u132, ports, 0);
> >  }
> > -}
> > +   break;
> > +   }
> >  if (retval == 0)
> >  pdev->dev.power.power_state = state;
> >  return retval;
> Hmm. Doesn't compile for me in 2.6.25-rc2-git7:
> 
>   CC [M]  drivers/usb/host/u132-hcd.o
> drivers/usb/host/u132-hcd.c: In function ‘u132_suspend’:
> drivers/usb/host/u132-hcd.c:3224: error: expected expression before
> ‘int’
> drivers/usb/host/u132-hcd.c:3225: error: ‘ports’ undeclared (first use
> in this function)
> drivers/usb/host/u132-hcd.c:3225: error: (Each undeclared identifier is
> reported only once
> drivers/usb/host/u132-hcd.c:3225: error: for each function it appears
> in.)
> make[3]: *** [drivers/usb/host/u132-hcd.o] Error 1
> make[2]: *** [drivers/usb/host] Error 2
> make[1]: *** [drivers/usb] Error 2
> make: *** [drivers] Error 2
> 
> This fixes it:
> 
> Thanks
> Mirco
> 
> ---
> From: Mirco Tischler <[EMAIL PROTECTED]>
> 
> Fixes the following compile error caused by commit
> 3a2d5b700132f35401f1d9e22fe3c2cab02c2549
> 
> ...
>   CC [M]  drivers/usb/host/u132-hcd.o
> drivers/usb/host/u132-hcd.c: In function ‘u132_suspend’:
> drivers/usb/host/u132-hcd.c:3224: error: expected expression before
> ‘int’
> drivers/usb/host/u132-hcd.c:3225: error: ‘ports’ undeclared (first use
> in this function)
> ...
> 
> Signed-off-by: Mirco Tischler <[EMAIL PROTECTED]>
> ---
>  drivers/usb/host/u132-hcd.c |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/usb/host/u132-hcd.c b/drivers/usb/host/u132-hcd.c
> index 6fca069..58830b2 100644
> --- a/drivers/usb/host/u132-hcd.c
> +++ b/drivers/usb/host/u132-hcd.c
> @@ -3214,6 +3214,7 @@ static int u132_suspend(struct platform_device
> *pdev, pm_message_t state)
>  return -ESHUTDOWN;
>  } else {
>  int retval = 0;
> + int ports = 0;

Hm, why not to do:

---
 drivers/usb/host/u132-hcd.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6/drivers/usb/host/u132-hcd.c
===
--- linux-2.6.orig/drivers/usb/host/u132-hcd.c
+++ linux-2.6/drivers/usb/host/u132-hcd.c
@@ -3214,6 +3214,7 @@ static int u132_suspend(struct platform_
 return -ESHUTDOWN;
 } else {
 int retval = 0;
+   int ports = MAX_U132_PORTS;
 
switch (state.event) {
case PM_EVENT_FREEZE:
@@ -3221,7 +3222,6 @@ static int u132_suspend(struct platform_
break;
case PM_EVENT_SUSPEND:
case PM_EVENT_HIBERNATE:
-int ports = MAX_U132_PORTS;
 while (ports-- > 0) {
 port_power(u132, ports, 0);
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] u132-hcd: add missing braces

[Rafael J. Wysocki]

On Sunday, 24 of February 2008, Stephen Rothwell wrote:
> 
> Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>

Thanks, this has been fixed already in the mainline.

> ---
>  drivers/usb/host/u132-hcd.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> Discovered while building Linus' tree for today's linux-next. Not the
> correct patch, but allowed compilation to succeed.
> 
> diff --git a/drivers/usb/host/u132-hcd.c b/drivers/usb/host/u132-hcd.c
> index 6fca069..648ad1a 100644
> --- a/drivers/usb/host/u132-hcd.c
> +++ b/drivers/usb/host/u132-hcd.c
> @@ -3221,11 +3221,13 @@ static int u132_suspend(struct platform_device *pdev, 
> pm_message_t state)
>   break;
>   case PM_EVENT_SUSPEND:
>   case PM_EVENT_HIBERNATE:
> + {
>  int ports = MAX_U132_PORTS;
>  while (ports-- > 0) {
>  port_power(u132, ports, 0);
>  }
>   break;
> + }
>   }
>  if (retval == 0)
>  pdev->dev.power.power_state = state;
> -- 
> 1.5.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.25 patch] fix drivers/usb/host/u132-hcd.c compilation

[Rafael J. Wysocki]

On Sunday, 24 of February 2008, Adrian Bunk wrote:
> This patch fixes the following compile error caused by
> commit 3a2d5b700132f35401f1d9e22fe3c2cab02c2549:

Thanks, it has already been fixed in the mainline.

> <--  snip  -->
> 
> ...
>   CC  drivers/usb/host/u132-hcd.o
> /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/usb/host/u132-hcd.c: 
> In function ‘u132_suspend’:
> /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/usb/host/u132-hcd.c:3224: 
> error: expected expression before ‘int’
> /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/usb/host/u132-hcd.c:3225: 
> error: ‘ports’ undeclared (first use in this function)
> /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/usb/host/u132-hcd.c:3225: 
> error: (Each undeclared identifier is reported only once
> /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/usb/host/u132-hcd.c:3225: 
> error: for each function it appears in.)
> make[4]: *** [drivers/usb/host/u132-hcd.o] Error 1
> 
> <--  snip  -->
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> 
> ---
> 69cf78da6371ad2aca30844858eeea318b37b3ec diff --git 
> a/drivers/usb/host/u132-hcd.c b/drivers/usb/host/u132-hcd.c
> index 6fca069..325c6c7 100644
> --- a/drivers/usb/host/u132-hcd.c
> +++ b/drivers/usb/host/u132-hcd.c
> @@ -3221,9 +3221,11 @@ static int u132_suspend(struct platform_device *pdev, 
> pm_message_t state)
>   break;
>   case PM_EVENT_SUSPEND:
>   case PM_EVENT_HIBERNATE:
> -int ports = MAX_U132_PORTS;
> -while (ports-- > 0) {
> -port_power(u132, ports, 0);
> + {
> + int ports = MAX_U132_PORTS;
> + while (ports-- > 0) {
> + port_power(u132, ports, 0);
> + }
>  }
>   break;
>   }
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] regulator: regulator core.

[Russell King - ARM Linux]

On Sun, Feb 24, 2008 at 10:23:49AM +, Mark Brown wrote:
> On Sat, Feb 23, 2008 at 09:52:17AM +, Russell King - ARM Linux wrote:
> > On Sat, Feb 23, 2008 at 12:05:38AM -0800, Andrew Morton wrote:
> 
> > > > +#undef current
> 
> > > err, no ;)  Please rename your stuff.
> 
> > Renaming is not an option - "current" is an electronic term for which
> > there is no alternative.  The real problem is this __ATTR macro crap:
> 
> Indeed, and this is already being worked around by
> drivers/power/power_supply_sysfs.c:
> 
> #define POWER_SUPPLY_ATTR(_name)\
> {   \
> .attr = { .name = #_name, .mode = 0444, .owner = THIS_MODULE }, \

My argument is - why bother with stuff like this, why not just pass
"_name" as the string itself, rather than using the preprocessor to
turn symbols into strings thereby suffering these nasty interactions.

It's not like "_name" is used for anything other than generating a
string.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.25-current-git hangs on boot

[Rafael J. Wysocki]

On Sunday, 24 of February 2008, Soeren Sonnenburg wrote:
> On Sat, 2008-02-23 at 20:00 +0100, Oliver Pinter wrote:
> > the pci=nommconf kernel parameter helped it?
> 
> yes indeed, this switch reliably helps to over come the hang at *this
> stage* (I tried booting with booth the switch and w/o).
> 
> however with 50% chance I still see a hang directly after
> 
> cpuidle: using governor ladder

Do you have CONFIG_CPU_IDLE set?  If you have, please try to unset it and
retest.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Hang on suspend

[Rafael J. Wysocki]

On Sunday, 24 of February 2008, Julian Blake Kongslie wrote:
> On Sat, 2008-02-23 at 21:43 +0100, Rafael J. Wysocki wrote:
> > Can you please apply the appened patch and retest?
> 
> Didn't apply cleanly to v2.6.25-rc2; I had to mangle one or two lines.
> The patch I applied follows at the end of this message.
> 
> Unfortunately, it's about the same as before. I got:
> 
> Freezing user space processes ... (elapsed 0.00 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
> ACPI: Preparing to enter system sleep state S3
> sd 0:0:0:0: [sda] Synchronizing SCSI cache
> sd 0:0:0:0: [sda] Stopping disk
> nsc-ircc 00:0b: disabled
> parport_pc 00:0a: disabled
> eth1: Going into suspend...
> ACPI: PCI interrupt for device :0b:02.0 disabled
> ACPI: PCI interrupt for device :00:1e.3 disabled
> ACPI: PCI interrupt for device :00:1e.2 disabled
> ACPI: PCI interrupt for device :00:1d.7 disabled
> ACPI: PCI interrupt for device :00:1d.3 disabled
> ACPI: PCI interrupt for device :00:1d.2 disabled
> ACPI: PCI interrupt for device :00:1d.1 disabled
> ACPI: PCI interrupt for device :00:1d.0 disabled
> BUG: unable to handle kernel NULL pointer dereference at 0090

Can you please check what's at the address platform_suspend_late+0x19?

You can used "gdb vmlinux" and then "l *platform_suspend_late+0x19" under the
gdb for this purpose.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PM: Introduce PM_EVENT_HIBERNATE (was: Re: i915 hibernation patch (was: Re: 2.6.25-rc2 System no longer ...))

[Rafael J. Wysocki]

On Sunday, 24 of February 2008, Rafael J. Wysocki wrote:
> On Sunday, 24 of February 2008, Mirco Tischler wrote:
> > 
> > On Sa, 2008-02-23 at 19:13 +0100, Rafael J. Wysocki wrote:
> > > Index: linux-2.6/drivers/usb/host/u132-hcd.c
> > > ===
> > > --- linux-2.6.orig/drivers/usb/host/u132-hcd.c
> > > +++ linux-2.6/drivers/usb/host/u132-hcd.c
> > > @@ -3214,14 +3214,19 @@ static int u132_suspend(struct platform_
> > >  return -ESHUTDOWN;
> > >  } else {
> > >  int retval = 0;
> > > -if (state.event == PM_EVENT_FREEZE) {
> > > +
> > > + switch (state.event) {
> > > + case PM_EVENT_FREEZE:
> > >  retval = u132_bus_suspend(hcd);
> > > -} else if (state.event == PM_EVENT_SUSPEND) {
> > > + break;
> > > + case PM_EVENT_SUSPEND:
> > > + case PM_EVENT_HIBERNATE:
> > >  int ports = MAX_U132_PORTS;
> > >  while (ports-- > 0) {
> > >  port_power(u132, ports, 0);
> > >  }
> > > -}
> > > + break;
> > > + }
> > >  if (retval == 0)
> > >  pdev->dev.power.power_state = state;
> > >  return retval;
> > Hmm. Doesn't compile for me in 2.6.25-rc2-git7:
> > 
> >   CC [M]  drivers/usb/host/u132-hcd.o
> > drivers/usb/host/u132-hcd.c: In function ‘u132_suspend’:
> > drivers/usb/host/u132-hcd.c:3224: error: expected expression before
> > ‘int’
> > drivers/usb/host/u132-hcd.c:3225: error: ‘ports’ undeclared (first use
> > in this function)
> > drivers/usb/host/u132-hcd.c:3225: error: (Each undeclared identifier is
> > reported only once
> > drivers/usb/host/u132-hcd.c:3225: error: for each function it appears
> > in.)
> > make[3]: *** [drivers/usb/host/u132-hcd.o] Error 1
> > make[2]: *** [drivers/usb/host] Error 2
> > make[1]: *** [drivers/usb] Error 2
> > make: *** [drivers] Error 2
> > 
> > This fixes it:
> > 
> > Thanks
> > Mirco
> > 
> > ---
> > From: Mirco Tischler <[EMAIL PROTECTED]>
> > 
> > Fixes the following compile error caused by commit
> > 3a2d5b700132f35401f1d9e22fe3c2cab02c2549

Ah, I see it's merged already.

Thanks for the fix, btw! :-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

lockdep warnings in ipv6

[Jan Engelhardt]

Hi,


when doing IPv6 (ping6, ssh otherhost, etc.), lockdep spews a warning in 
2.6.25-rc2 on the target. CONFIG_..._FRAME_POINTER is off,

CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
# CONFIG_FRAME_POINTER is not set

so I am not sure if the stack trace is worth something, is it?

[  449.168320] ===
[  449.168637] [ INFO: possible circular locking dependency detected ]
[  449.168851] 2.6.25-rc2 #67
[  449.168951] ---
[  449.169078] swapper/0 is trying to acquire lock:
[  449.169315]  (&tbl->lock){-+-+}, at: [] 
neigh_lookup+0x43/0xb0
[  449.170147] 
[  449.170150] but task is already holding lock:
[  449.170309]  (&n->lock){-+-+}, at: [] 
neigh_timer_handler+0x15/0x2a0
[  449.170512] 
[  449.170514] which lock already depends on the new lock.
[  449.170516] 
[  449.170736] 
[  449.170738] the existing dependency chain (in reverse order) is:
[  449.170926] 
[  449.170927] -> #1 (&n->lock){-+-+}:
[  449.171188][] add_lock_to_list+0x46/0xc0
[  449.171509][] __lock_acquire+0xb48/0xf90
[  449.171678][] neigh_periodic_timer+0x7a/0x170
[  449.171849][] lock_acquire+0x5f/0x80
[  449.172007][] neigh_periodic_timer+0x7a/0x170
[  449.172173][] _write_lock+0x29/0x40
[  449.172342][] neigh_periodic_timer+0x7a/0x170
[  449.172508][] neigh_periodic_timer+0x7a/0x170
[  449.172670][] run_timer_softirq+0x15f/0x1c0
[  449.172984][] neigh_periodic_timer+0x0/0x170
[  449.173180][] neigh_periodic_timer+0x0/0x170
[  449.173349][] __do_softirq+0x52/0xb0
[  449.173516][] do_softirq+0x45/0x50
[  449.173675][] irq_exit+0x55/0x70
[  449.173831][] do_IRQ+0x43/0x90
[  449.173987][] common_interrupt+0x24/0x40
[  449.174147][] common_interrupt+0x2e/0x40
[  449.174308][] 0x
[  449.174767] 
[  449.174769] -> #0 (&tbl->lock){-+-+}:
[  449.174939][] print_circular_bug_entry+0x40/0x50
[  449.175108][] __lock_acquire+0x971/0xf90
[  449.175268][] __lock_acquire+0x15e/0xf90
[  449.175468][] trace_hardirqs_on+0x66/0x110
[  449.175633][] lock_acquire+0x5f/0x80
[  449.175793][] neigh_lookup+0x43/0xb0
[  449.175973][] _read_lock_bh+0x2e/0x40
[  449.176139][] neigh_lookup+0x43/0xb0
[  449.176303][] neigh_lookup+0x43/0xb0
[  449.177821][] ndisc_dst_alloc+0x13c/0x1a0 [ipv6]
[  449.177821][] ndisc_dst_alloc+0x0/0x1a0 [ipv6]
[  449.177821][] __ndisc_send+0x95/0x4e0 [ipv6]
[  449.177821][] ip6_output+0x0/0xb00 [ipv6]
[  449.177821][] ndisc_send_ns+0x67/0xa0 [ipv6]
[  449.177821][] ipv6_chk_addr+0xa0/0xb0 [ipv6]
[  449.177821][] ndisc_solicit+0x9f/0x1b0 [ipv6]
[  449.177821][] mark_held_locks+0x38/0x70
[  449.177821][] _spin_unlock_irqrestore+0x45/0x60
[  449.177821][] trace_hardirqs_on+0x66/0x110
[  449.177821][] neigh_timer_handler+0x155/0x2a0
[  449.177821][] run_timer_softirq+0x15f/0x1c0
[  449.177821][] neigh_timer_handler+0x0/0x2a0
[  449.177821][] neigh_timer_handler+0x0/0x2a0
[  449.177821][] __do_softirq+0x52/0xb0
[  449.177821][] do_softirq+0x45/0x50
[  449.177821][] irq_exit+0x55/0x70
[  449.177821][] do_IRQ+0x43/0x90
[  449.177821][] common_interrupt+0x24/0x40
[  449.177821][] common_interrupt+0x2e/0x40
[  449.177821][] default_idle+0x5e/0x90
[  449.177821][] default_idle+0x0/0x90
[  449.177821][] cpu_idle+0x30/0x80
[  449.177821][] 0x
[  449.177821] 
[  449.177821] other info that might help us debug this:
[  449.177821] 
[  449.177821] 1 lock held by swapper/0:
[  449.177821]  #0:  (&n->lock){-+-+}, at: [] 
neigh_timer_handler+0x15/0x2a0
[  449.177821] 
[  449.177821] stack backtrace:
[  449.177821] Pid: 0, comm: swapper Not tainted 2.6.25-rc2 #67
[  449.177821]  [] print_circular_bug_tail+0x72/0x80
[  449.177821]  [] __lock_acquire+0x971/0xf90
[  449.177821]  [] __lock_acquire+0x15e/0xf90
[  449.177821]  [] trace_hardirqs_on+0x66/0x110
[  449.177821]  [] lock_acquire+0x5f/0x80
[  449.177821]  [] neigh_lookup+0x43/0xb0
[  449.177821]  [] _read_lock_bh+0x2e/0x40
[  449.177821]  [] neigh_lookup+0x43/0xb0
[  449.177821]  [] neigh_lookup+0x43/0xb0
[  449.177821]  [] ndisc_dst_alloc+0x13c/0x1a0 [ipv6]
[  449.177821]  [] ndisc_dst_alloc+0x0/0x1a0 [ipv6]
[  449.177821]  [] __ndisc_send+0x95/0x4e0 [ipv6]
[  449.177821]  [] ip6_output+0x0/0xb00 [ipv6]
[  449.177821]  [] ndisc_send_ns+0x67/0xa0 [ipv6]
[  449.177821]  [] ipv6_chk_addr+0xa0/0xb0 [ipv6]
[  449.177821]  [] ndisc_solicit+0x9f/0x1b0 [ipv6]
[  449.177821]  [] mark_held_locks+0x38/0x70
[  449.177821]  [] _spin_unlock_irqrestore+0x45/0x60
[  449.177821]  [] trace_hardirqs_on+0x66/0x110
[  449.177821]  [] neigh_timer_handler+0x155/0x2a0
[  449.177821]  [] run_timer_softirq+0x15f/0

Re: [patch 2/2] x86,fpu: lazy allocation of FPU area

[Andi Kleen]

On Sat, Feb 23, 2008 at 06:34:39PM -0800, Suresh Siddha wrote:
> Only allocate the FPU area when the application actually uses FPU, i.e., in 
> the
> first lazy FPU trap. This could save memory for non-fpu using apps.

Did you measure this making any difference? 

At least at some point glibc always touched the FPU once to initialize
it.

-andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Reducing debuginfo size by removing unneeded includes

[Andi Kleen]

> > Just FYI, newer gcc does this in theory automatically when you specify 
> > 
> > -feliminate-unused-debug-types -feliminate-unused-debug-symbols
> google did not turn up anything useful.
> Do you have a poiter to where these are described?

info gcc

> 
> 
> > There is also -feliminate-dwarf2-dups, but it seems to even increase
> > obj dir size. Also -feliminate-dwarf2-dups seems to generate a lot of 
> 
> Google only turned up a patch from Mark Mitchell removing this
> in ~2001 timeframe.
> So again a pointer would be nice.
> 
> I use FC8:
> gcc --version
> gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33)
> 
> So this is far behind trunk that you use - but I have not had any
> real incentive to upgrade.


It's in my info pages for SUSE gcc 4.1. I didn't think it was
a SUSE extension though.


I also checked and all options are in gcc head and in gcc 4.3

> 
> I would like to have a remote understanding of the options before
> enabling them.

Right now they are not useful to enable because they don't save
file size and in some cases make it even worse. I checked with some gcc 
developers and they explained why that is so. gcc would need to be fixed first.

-Andi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2

[Andi Kleen]

On Sat, Feb 23, 2008 at 09:48:42PM -0800, Yinghai Lu wrote:
> 
> quad core 8 socket system will have apic id lifting.the apic id range could
> be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters
> and that is large than 2. So it is treated as clustered_box.

Ok I see you chose the quick hack over doing it properly ...

> 
> and will get
> 
> Marking TSC unstable due to TSCs unsynchronized
> 
> even the CPUs have X86_FEATURE_CONSTANT_TSC set.

I doubt that will do the right thing on AMD based vSMP,
which also required the cluster check on AMD iirc.

Cc'ed Kiran/Shai. damage has already hit x86 tree I believe.

-Andi

diff --git a/arch/x86/kernel/apic_64.c b/arch/x86/kernel/apic_64.c
index d8d03e0..7d8ffda 100644
--- a/arch/x86/kernel/apic_64.c
+++ b/arch/x86/kernel/apic_64.c
@@ -1180,9 +1180,19 @@ __cpuinit int apic_is_clustered_box(void)
 {
int i, clusters, zeros;
unsigned id;
-   u16 *bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
+   u16 *bios_cpu_apicid;
DECLARE_BITMAP(clustermap, NUM_APIC_CLUSTERS);
+   /*
+* Some AMD box with quadcore cpu and 8 sockets apicid
+* will be [4, 0x23] or [8, 0x27] could be thought to
+* have three apic_clusters. So go out early.
+*/
+   if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+   return 0;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.25-current-git hangs on boot

[Soeren Sonnenburg]

On Sun, 2008-02-24 at 12:18 +0100, Rafael J. Wysocki wrote:
> On Sunday, 24 of February 2008, Soeren Sonnenburg wrote:
> > On Sat, 2008-02-23 at 20:00 +0100, Oliver Pinter wrote:
> > > the pci=nommconf kernel parameter helped it?
> > 
> > yes indeed, this switch reliably helps to over come the hang at *this
> > stage* (I tried booting with booth the switch and w/o).
> > 
> > however with 50% chance I still see a hang directly after
> > 
> > cpuidle: using governor ladder
> 
> Do you have CONFIG_CPU_IDLE set?  If you have, please try to unset it and
> retest.

Yes I had. When disabling that option booting 10 times in a row worked
without problems.

Soeren
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.25-rc2, 2.6.24-rc8] page allocation failure...

[Daniel J Blueman]

On Tue, Feb 19, 2008 at 5:37 PM, Kok, Auke <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
>  > On Sun, 17 Feb 2008 13:20:59 + "Daniel J Blueman" <[EMAIL PROTECTED]> 
> wrote:
>  >> I'm still hitting this with e1000e on 2.6.25-rc2, 10 times again.

>  are you sure? I don't think that's the case and you're seeing e1000 dumps 
> here...

Indeed so! I thought I moved to e1000e a time ago, but forgot that I
had moved back due to lack of support for 82566DC, added since.

I'm not seeing any related messages with e1000e after a few days'
uptime, so all looks well...

Thanks again,
  Daniel

>  >> It's clearly non-fatal, but then do we expect it to occur?
>  >>
>  >> Daniel
>  >>
>  >> --- [dmesg]
>  >>
>  >> [ 1250.822786] swapper: page allocation failure. order:3, mode:0x4020
>  >> [ 1250.822786] Pid: 0, comm: swapper Not tainted 2.6.25-rc2-119 #2
>  >> [ 1250.822786]
>  >> [ 1250.822786] Call Trace:
>  >> [ 1250.822786][] __alloc_pages+0x34e/0x3a0
>  >> [ 1250.822786]  [] ? __netdev_alloc_skb+0x1f/0x40
>  >> [ 1250.822786]  [] __slab_alloc+0x102/0x3d0
>  >> [ 1250.822786]  [] ? __netdev_alloc_skb+0x1f/0x40
>  >> [ 1250.822786]  [] __kmalloc_track_caller+0x7b/0xc0
>  >> [ 1250.822786]  [] __alloc_skb+0x6f/0x160
>  >> [ 1250.822786]  [] __netdev_alloc_skb+0x1f/0x40
>  >> [ 1250.822786]  [] e1000_alloc_rx_buffers+0x1ed/0x260
>  >> [ 1250.822786]  [] e1000_clean_rx_irq+0x22a/0x330
>  >> [ 1250.822786]  [] e1000_clean+0x1e1/0x540
>  >> [ 1250.822786]  [] ? tick_program_event+0x45/0x70
>  >> [ 1250.822786]  [] net_rx_action+0x9a/0x150
>  >> [ 1250.822786]  [] __do_softirq+0x74/0xf0
>  >> [ 1250.822786]  [] call_softirq+0x1c/0x30
>  >> [ 1250.822786]  [] do_softirq+0x3d/0x80
>  >> [ 1250.822786]  [] irq_exit+0x85/0x90
>  >> [ 1250.822786]  [] do_IRQ+0x85/0x100
>  >> [ 1250.822786]  [] ? mwait_idle+0x0/0x50
>  >> [ 1250.822786]  [] ret_from_intr+0x0/0xa
>  >> [ 1250.822786][] ? mwait_idle+0x45/0x50
>  >> [ 1250.822786]  [] ? enter_idle+0x22/0x30
>  >> [ 1250.822786]  [] ? cpu_idle+0x74/0xa0
>  >> [ 1250.822786]  [] ? rest_init+0x55/0x60
>  >
>  > They're regularly reported with e1000 too - I don't think aything really
>  > changed.
>  >
>  > e1000 has this crazy problem where because of a cascade of follies (mainly
>  > borked hardware) it has to do a 32kb allocation for a 9kb(?) packet.  It
>  > would be sad if that was carried over into e1000e?
>
>  can't be, I personally removed that code.
>
>  for MTU > 1500 e1000e uses a plain normal sized SKB. for anything bigger 
> e1000e
>  uses pages.
>
>  so I don't see how this bug could still be showing up for e1000e at all. The 
> large
>  skb receive code is all gone (literally, removed).
>
>  *please* rmmod e1000; modprobe e1000e and show the dumps again so we know 
> for sure
>  that we're not looking at e1000 dumps.
>
>  short fix: increase ring size for e1000 with `modprobe e1000 
> RxDescriptors=4096`
>  (or use ethtool) and `echo -n 8192 > /proc/sys/vm/min_free_kbytes` or 
> something
>  like that.
>
>  what nic hardware is this on? lspci?
>
>  Auke
>



-- 
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] More accessible usage of custom flags

[Nick Andrew]

On Sun, Feb 24, 2008 at 04:36:24AM -0500, Nicholas Marquez wrote:
> Yes, I would like to expand them.  If possibly, I'd like to take out
> the individual config options for gcc flags and integrate them into
> the help description.  I feel that the redundancy would not only be
> ugly, but possibly confusing.

If you allow CUSTOM_CFLAGS and friends (as an open-ended set of flags for
the compiler) then yes, having config options like CC_OPTIMIZE_FOR_SIZE
is redundant and should be removed.

Alternately, don't have a CUSTOM_CFLAGS and expand on the set of config
options which set individual compiler flags.  They could be in their
own menu, a bunch of checkboxes to tweak GCC's various optimisation
algorithms and/or warnings. That's certainly going to be friendlier
for the not-very-experienced kernel builder, if less flexible than
CUSTOM_CFLAGS.

> >  I'm hoping we don't need any stern warnings in the kernel configuration.
> >  Although I expect configuring bogus gcc flags is going to break the
> >  build far worse than selecting bad options otherwise. If the user
> >  makes a mistake in CUSTOM_CFLAGS is the build going to fail with
> >  a message "error in CUSTOM_CFLAGS" or is it going to spew out pages
> >  of gcc error messages?  It is nice if error messages can point back
> >  to the source of the error, so the user doesn't have to look through
> >  the entire kernel configuration for what they did wrong.
> 
> I hadn't thought of that.  It would certainly be more useful than a
> stern warning.  ^^;  Have you any ideas on how to implement such a
> thing?  I would imagine a configure-script-like test on the flags to
> make sure that gcc could take them correctly would be in order.  Then
> one could also capture any warnings or errors that gcc outputs (such
> as redundant flags, improper invocation, etc.), fail the build, and
> output the messages.  As far as capturing dangerous flags for the
> kernel (such as -ffast-math or -fmerge-all-constants), there could be
> a blacklist... but that would depend on the gcc version used... :/

I think that's a very interesting idea. Yes, you can test the flags by
compiling and linking a simple program. If it fails, your flags are
bad. You can stop the build right there and say "fix your flags".

The build could also capture the GCC warning/error output and
post-process it. Certain types of warnings might be suppressed,
or cause the build to fail (based on selected config options). My
kernel builds always show a handful of "may be used uninitialised" or
similar ... I just assume that those warnings are harmless. It is best
of course that these warnings don't occur at all, and I expect kernel
developers to fix them when they get a chance.  The idea in this
paragraph would be desirable to me, independent of how the CFLAGS are
specified.


> >  > Something else that could be included is a link to the manual for the
> >  > (currently used) gcc's command flags
> >  > (http://gcc.gnu.org/onlinedocs/gcc-4.2.3/gcc/index.html#toc_Invoking-GCC)
> >  > or at least to the online docs, considering that specifying one
> >  > specific gcc version's manual would yield various issues.
> >
> >  "info gcc" will give all that information in far more detail than I
> >  have time to read.
> 
> I believe you misunderstand.  I mean to include the link in the help
> message.  Like how the links to the appropriate sites for device
> drivers are included in their help messages.

No, I think I understood correctly. If you tell the user to go to that
long URL then you run the risk of pointing to the documentation for a
different version of GCC. On the other hand, if you tell them to type
"info gcc" then they will see the documentation for the version of GCC
which they have installed. And it's also a lot friendlier to write:
"Type 'info gcc' to see a full list of the compiler options".

> >  > I feel that perhaps it is a bit silly to put in such description, as
> >  > one using the flags should only do so in knowing specifically which
> >  > ones they wish to use and why ahead of time.  However, it cannot hurt
> >  > to put in more help documentation, so it's a fine suggestion.
> >
> >  Well, it can't be both silly and a fine suggestion. Does it dumb down
> >  the kernel configuration process too much?
> 
> No, I feel that both adjectives are perfectly reconcilable, at least
> in this case.  Again, more documentation couldn't hurt.  "Dumbing
> down" kernel configuration may be less aesthetically pleasing to
> purists, but that is a tiny price to pay for usability and a widening
> of kernel builders.

I'm looking to find a balance among the competing objectives. Time
will tell with any improvements. I'm also hoping for an aesthetically
pleasing config menu -- perhaps someone else can take on the challenge of
restructuring it to improve the ordering, structure and names of options.

> PS to Nick:  Sorry for the double-send. Didn't CC lkml;  a forward
> would be ugly.

No prob.

Nick.
-- 
PGP Key ID = 0x41

Re: Please, put 64-bit counter per task and incr.by.one each ctxt switch.

[J.C. Pizarro]

Good morning :)

On 2008/2/24, Rik van Riel <[EMAIL PROTECTED]> wrote:
> OK, one last reply on the (overly optimistic?) assumption that you are not a 
> troll.
>  > +++ linux-2.6_git-20080224/include/linux/sched.h2008-02-24
>  > 04:50:18.0 +0100
>  > @@ -1007,6 +1007,12 @@
>  > struct hlist_head preempt_notifiers;
>  >  #endif
>  >
>  > +   unsigned long long ctxt_switch_counts; /* 64-bit switches' count */
>  > +   /* ToDo:
>  > +*  To implement a poller/clock for CPU-scheduler that only reads
>  > +*   these counts of context switches of the runqueue's tasks.
>  > +*  No problem if this poller/clock is not implemented. */
>
> So you're introducing a statistic, but have not yet written any code
>  that uses it?

It's statistic, yes, but it's a very important parameter for the CPU-scheduler.
The CPU-scheduler will know the number of context switches of each task
 before of to take a blind decision into infinitum!.

Statistically, there are tasks X that have higher context switches and
tasks Y that have lower context switches in the last sized interval with the
 historical formula "(alpha-1)*prev + alpha*current" 0 < alpha < 1.
(measure this value V as a velocity of number of ctxt-switches/second too)

  Put more weight to X than to Y for more interactivity that X want.
  (X will have more higher V and Y more lower V).
  With an exception for avoid the eternal humble, to do sin(x) behaviour
   after of a long period of humble (later to modify the weights).

The missing code has to be implemented between everybodies because
1. Users wann't lose interactivity in overloaded CPU.
2. There are much code of CPU-schedulers bad organizated that i wann't
 touch it.

>  > +   p->ctxt_switch_counts = 0ULL; /* task's 64-bit counter inited 0 */
>
> Because we can all read C, there is no need to tell people in comments
>  what the code does.  Comments are there to explain why the code does
>  things, if an explanation is needed.

OK.

>  > >  > I will explain your later why of it.
>  > >
>  > > ... and explain exactly why the kernel needs this extra code.
>  >
>  > One reason: for the objective of gain interactivity, it's an issue that
>  >  CFS fair scheduler lacks it.

> Your patch does not actually help interactivity, because all it does
>  is add an irq spinlock in a hot path (bad idea) and a counter which
>  nothing reads.

Then remove the lock/unlock of the task that i'd put it,
i'm not sure if it's secure because i didn't read all the control of the road.

On 2008/2/24, Mike Galbraith <[EMAIL PROTECTED]> wrote:
>  > One reason: for the objective of gain interactivity, it's an issue that
>  >  CFS fair scheduler lacks it.
>
> A bug report would be a much better first step toward resolution of any
>  interactivity issues you're seeing than posts which do nothing but
>  suggest that there may be a problem.
>
>  First define the problem, _then_ fix it.

It's blind eternal problem in overloaded CPU scenario in the desktops.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: add the debugfs interface for the sysprof tool

[Theodore Tso]

On Sat, Feb 23, 2008 at 01:53:35PM +, John Levon wrote:
> On Sat, Feb 23, 2008 at 12:37:24PM +0100, Ingo Molnar wrote:
> 
> > It's 200 lines of pretty well isolated code for something that is 
> > already much more usable to me than 10 years of oprofile. Really, i'd 
> > much rather take 200 lines of poor kernel code written by a userspace 
> > developer for stuff that _already works better_, than to have ~2000 
> > lines of oprofile code and an unusable (to me) user-space tool written 
> > by kernel developers.

I think it's fair to say that oth oprofile and sysprof can use some
improvements.  There are a couple of questions that immediately come
to mind, including the most obvious one, *if* as you John clams, the
oprofile kernel had all of the functionality for the GUI, why wasn't
it used --- could it *perhaps* because the kernel interface for
oprofile wasn't documented well?  Heck, even if sysprof is 200 lines
of code versus 2000 lines of kernel code, most people don't write
extra code unless it's because the 2000 lines of pre-existing code
isn't well documented enough.

> Firstly, the distributions should have set this up automatically. That
> they don't is a distributor bug. The sheer madness of Linux not leaving
> a vmlinux file in a stable known location is hardly something oprofile
> can be blamed for.

Wrong Answer.  People who write userspace helpers *have* to do the
work of the distro's.  It's a bad, bad, bad, Bad, BAD idea to leave it
up to the distributions.  It means that some distributions won't get
it right; other distributions will do it in different ways, making it
harder for users to switch between distro's and making it harder for
people to write distribution-neutral HOWTO's.

There are plenty of things that can be done, including using search
paths to try to find vmlinuz; or maybe even proposing a new standard
such as say for example /lib/modules/`uname -r`/vmlinux being a
synlink to the location of vmlinux.  We already have
/lib/modules/`uname -r`/build and /lib/modules/`uname -r`/source, for
example.

The abdication of responsibility and the lack of trying to solve the
usability issues is one of the things that really worries me about
*all* of Linux's RAS tools.  We can and should do better!  And it's
really embarassing that the RAS maintainers seem (I assume you are one
of the oprofile maintainers), seem to be blaming this on the victims,
the people who are complaining about using *your* tool.  Yes, it's a
shame that Ingo didn't try to fix your tool; open source, and scratch
your own itch and all of that.  To be sure.  But at the *same* *time*
don't you have enough pride to take a look at a tools which so
obviously has massive lacks in the usability department, and tried to
fix it years ago?  There's more than enough blame to go around twenty
times over, I would think.

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: lockdep warnings in ipv6

[Kristof Provost]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2008-02-24 13:10:58 (+0100), Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> 
> when doing IPv6 (ping6, ssh otherhost, etc.), lockdep spews a warning in 
> 2.6.25-rc2 on the target. CONFIG_..._FRAME_POINTER is off,
I think that's the same bug I ran into. It was introduced in
69cc64d8d9 and reversed in 9ff56607468. I think Linus' tree has the
reversal by now.

Kristof
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHwW1CUEZ9DhGwDugRAkVJAKCFxUjwfQNTtAX0Z5OquJRyNimmCgCbBgio
0voGZL/B6iaz5kSLgTbV2EY=
=CPho
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

build #380 issue for v2.6.25-rc2-637-g4fa2b1c in ./drivers/media/video/vivi.c

[Toralf Förster]

Hello,

the build with the attached .config failed, make ends with:
...
  CC  arch/x86/lib/usercopy_32.o
  AR  arch/x86/lib/lib.a
  LD  vmlinux.o
  MODPOST vmlinux.o
  GEN .version
  CHK include/linux/compile.h
  UPD include/linux/compile.h
  CC  init/version.o
  LD  init/built-in.o
  LD  .tmp_vmlinux1
drivers/built-in.o: In function `vivi_release':
vivi.c:(.text+0x322f5): undefined reference to `video_unregister_device'
vivi.c:(.text+0x32337): undefined reference to `video_device_release'
drivers/built-in.o: In function `vivi_open':
vivi.c:(.text+0x32845): undefined reference to `v4l2_type_names'
drivers/built-in.o: In function `vivi_init':
vivi.c:(.init.text+0x1d20): undefined reference to `video_device_alloc'
vivi.c:(.init.text+0x1d48): undefined reference to `video_register_device'
drivers/built-in.o:(.rodata+0x1b40): undefined reference to `video_ioctl2'
drivers/built-in.o:(.data+0x140c): undefined reference to `video_device_release'
make: *** [.tmp_vmlinux1] Error 1


The build was made with :
$> make mrproper && make rndconfig &&  && make oldconfig && 
make

Here's the config:

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.25-rc2
# Sun Feb 24 13:01:51 2008
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
# CONFIG_GENERIC_LOCKBREAK is not set
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_FAST_CMPXCHG_LOCAL=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
# CONFIG_GENERIC_GPIO is not set
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
# CONFIG_GENERIC_TIME_VSYSCALL is not set
CONFIG_ARCH_HAS_CPU_RELAX=y
# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
# CONFIG_ZONE_DMA32 is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_AOUT=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_32_SMP=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_KTIME_SCALAR=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
# CONFIG_EXPERIMENTAL is not set
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_TASKSTATS=y
# CONFIG_TASK_DELAY_ACCT is not set
CONFIG_TASK_XACCT=y
# CONFIG_TASK_IO_ACCOUNTING is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_CGROUPS is not set
CONFIG_GROUP_SCHED=y
# CONFIG_FAIR_GROUP_SCHED is not set
CONFIG_USER_SCHED=y
# CONFIG_CGROUP_SCHED is not set
CONFIG_RELAY=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_EMBEDDED=y
# CONFIG_UID16 is not set
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
# CONFIG_HOTPLUG is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
# CONFIG_COMPAT_BRK is not set
CONFIG_BASE_FULL=y
# CONFIG_FUTEX is not set
CONFIG_ANON_INODES=y
# CONFIG_EPOLL is not set
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
# CONFIG_EVENTFD is not set
# CONFIG_SHMEM is not set
# CONFIG_VM_EVENT_COUNTERS is not set
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
CONFIG_MARKERS=y
# CONFIG_OPROFILE is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
CONFIG_HAVE_KPROBES=y
# CONFIG_PROC_PAGE_MONITOR is not set
CONFIG_SLABINFO=y
CONFIG_TINY_SHMEM=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
# CONFIG_BLOCK is not set
CONFIG_CLASSIC_RCU=y
# CONFIG_PREEMPT_RCU is not set

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_SMP=y
# CONFIG_X86_PC is not set
# CONFIG_X86_ELAN is not set
CONFIG_X86_VOYAGER=y
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_X86_RDC321X is not set
# CONFIG_X86_VSMP is not set
# CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER is not set
CONFIG_PARAVIRT_GUEST=y
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
CONFIG_MPENTIUMII=y
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not s

Re: [Bug 10030] Suspend doesn't work when SD card is inserted

[Rafael J. Wysocki]

On Sunday, 24 of February 2008, Alan Stern wrote:
> On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> 
> > On Sunday, 24 of February 2008, Alan Stern wrote:
> > > On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> > > 
> > > > Ultimately no, it's not.  However, we are now late in the -rc2 time 
> > > > frame and
> > > > the release of -rc3 seems to be imminent.  At this point, IMO, that's 
> > > > the
> > > > safest thing to do.  BTW, appended is the patch I'd like to get applied.
> > > 
> > > In the interest of having a safe release, I guess you're right.
> > 
> > That's what I'm concerned about at the moment.  I'm afraid there won't be
> > enough time to nail down all the issues (there may be some we're not even
> > aware of).
> 
> All right.  You'll need to enlarge your big reversal patch by reverting 
> commit 4145ed6dc597a9bea5f6ae8c574653b2de10620f.

Thanks for the hint.

In fact, I had to add a couple of fixes in device_power_down() and
dpm_suspend().  The entire patch is appended.

I'll comment your new patch in a separate message.

Thanks,
Rafael

---
 drivers/base/power/main.c |   97 +++---
 drivers/usb/core/usb.c|2 
 2 files changed, 8 insertions(+), 91 deletions(-)

Index: linux-2.6/drivers/base/power/main.c
===
--- linux-2.6.orig/drivers/base/power/main.c
+++ linux-2.6/drivers/base/power/main.c
@@ -48,7 +48,6 @@
  */
 
 LIST_HEAD(dpm_active);
-static LIST_HEAD(dpm_locked);
 static LIST_HEAD(dpm_off);
 static LIST_HEAD(dpm_off_irq);
 static LIST_HEAD(dpm_destroy);
@@ -81,28 +80,6 @@ void device_pm_add(struct device *dev)
  */
 void device_pm_remove(struct device *dev)
 {
-   /*
-* If this function is called during a suspend, it will be blocked,
-* because we're holding the device's semaphore at that time, which may
-* lead to a deadlock.  In that case we want to print a warning.
-* However, it may also be called by unregister_dropped_devices() with
-* the device's semaphore released, in which case the warning should
-* not be printed.
-*/
-   if (down_trylock(&dev->sem)) {
-   if (down_read_trylock(&pm_sleep_rwsem)) {
-   /* No suspend in progress, wait on dev->sem */
-   down(&dev->sem);
-   up_read(&pm_sleep_rwsem);
-   } else {
-   /* Suspend in progress, we may deadlock */
-   dev_warn(dev, "Suspicious %s during suspend\n",
-   __FUNCTION__);
-   dump_stack();
-   /* The user has been warned ... */
-   down(&dev->sem);
-   }
-   }
pr_debug("PM: Removing info for %s:%s\n",
 dev->bus ? dev->bus->name : "No Bus",
 kobject_name(&dev->kobj));
@@ -110,7 +87,6 @@ void device_pm_remove(struct device *dev
dpm_sysfs_remove(dev);
list_del_init(&dev->power.entry);
mutex_unlock(&dpm_list_mtx);
-   up(&dev->sem);
 }
 
 /**
@@ -266,7 +242,7 @@ static void dpm_resume(void)
struct list_head *entry = dpm_off.next;
struct device *dev = to_device(entry);
 
-   list_move_tail(entry, &dpm_locked);
+   list_move_tail(entry, &dpm_active);
mutex_unlock(&dpm_list_mtx);
resume_device(dev);
mutex_lock(&dpm_list_mtx);
@@ -275,25 +251,6 @@ static void dpm_resume(void)
 }
 
 /**
- * unlock_all_devices - Release each device's semaphore
- *
- * Go through the dpm_off list.  Put each device on the dpm_active
- * list and unlock it.
- */
-static void unlock_all_devices(void)
-{
-   mutex_lock(&dpm_list_mtx);
-   while (!list_empty(&dpm_locked)) {
-   struct list_head *entry = dpm_locked.prev;
-   struct device *dev = to_device(entry);
-
-   list_move(entry, &dpm_active);
-   up(&dev->sem);
-   }
-   mutex_unlock(&dpm_list_mtx);
-}
-
-/**
  * unregister_dropped_devices - Unregister devices scheduled for removal
  *
  * Unregister all devices on the dpm_destroy list.
@@ -305,7 +262,6 @@ static void unregister_dropped_devices(v
struct list_head *entry = dpm_destroy.next;
struct device *dev = to_device(entry);
 
-   up(&dev->sem);
mutex_unlock(&dpm_list_mtx);
/* This also removes the device from the list */
device_unregister(dev);
@@ -324,7 +280,6 @@ void device_resume(void)
 {
might_sleep();
dpm_resume();
-   unlock_all_devices();
unregister_dropped_devices();
up_write(&pm_sleep_rwsem);
 }
@@ -388,18 +343,15 @@ int device_power_down(pm_message_t state
struct list_head *entry = dpm_off.prev;
struct device *dev = to_device(entry);

Re: [PATCH] x86: add the debugfs interface for the sysprof tool

[Ingo Molnar]

* Theodore Tso <[EMAIL PROTECTED]> wrote:

> The abdication of responsibility and the lack of trying to solve the 
> usability issues is one of the things that really worries me about 
> *all* of Linux's RAS tools.  We can and should do better!  And it's 
> really embarassing that the RAS maintainers seem (I assume you are one 
> of the oprofile maintainers), seem to be blaming this on the victims, 
> the people who are complaining about using *your* tool.  Yes, it's a 
> shame that Ingo didn't try to fix your tool; open source, and scratch 
> your own itch and all of that.  To be sure.  But at the *same* *time* 
> don't you have enough pride to take a look at a tools which so 
> obviously has massive lacks in the usability department, and tried to 
> fix it years ago?  There's more than enough blame to go around twenty 
> times over, I would think.

i agree with most of your mail but i beg to differ with what you wrote 
about my role :-/ The specific bug/issue i discovered with oprofile i 
discovered on the very day i wrote about it to lkml.

In any case i'm not the one to fix oprofile - i cannot fix or report all 
itches that i have in ~1 billion lines of userspace - i would have to 
spend my whole life complaining ;-)

I'm the one to make sure that patches for useful userspace tools that 
get submitted to me eventually go upstream, one way or another. Sysprof 
has been around for years, had to rely on a (trivial) external module 
and AFAIK the feature even predates oprofile's stack-trace support. The 
API is butt-ugly and it's being fixed. So if then it should have been 
the oprofile folks porting over sysprof to their new API ... claiming 
otherwise would rewrite history i think.

a quick glance at oprofile's stack-trace/callgraph support shows it 
being rather buggy: it uses __copy_from_user_inatomic() from NMI 
context, which is bad because that can fault and re-enable NMIs, causing 
stack recursion/corruption. Fixing it is nontrivial. I'm not sure how 
much this feature has been tested - but with a sucky userspace kernel 
features _do not get tested_ - it's as simple as that! I'd be happier 
with sysprof's pure and simple "we only care about time events" initial 
approach and evolve this field via actual interest from users.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] input: support maple mouse on Dreamcast

[Adrian McMenamin]

input: support maple mouse on Dreamcast

Signed-off-by: Adrian McMenamin <[EMAIL PROTECTED]>
---

diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
index 7bbea09..d171336 100644
--- a/drivers/input/mouse/Kconfig
+++ b/drivers/input/mouse/Kconfig
@@ -232,4 +232,16 @@ config MOUSE_GPIO
  To compile this driver as a module, choose M here: the
  module will be called gpio_mouse.
 
+config MOUSE_MAPLE
+   tristate "Dreamcast mouse"
+   depends on SH_DREAMCAST
+   select MAPLE
+   help
+ This driver supports the Maple bus mouse on a SEGA Dreamcast.
+
+ Most Dreamcast users (with a mouse) will want to say Y here.
+
+ To compile this driver as a module, choose M here: the
+ module will be called maplemouse.
+
 endif

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] input: support maple mouse on Dreamcast

[Adrian McMenamin]

input: update Makefile to support maple mouse on Dreamcast

Signed-off-by: Adrian McMenamin <[EMAIL PROTECTED]>
---

diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile
index 9e6e363..5d35939 100644
--- a/drivers/input/mouse/Makefile
+++ b/drivers/input/mouse/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_MOUSE_SERIAL)+= sermouse.o
 obj-$(CONFIG_MOUSE_HIL)+= hil_ptr.o
 obj-$(CONFIG_MOUSE_VSXXXAA)+= vsxxxaa.o
 obj-$(CONFIG_MOUSE_GPIO)   += gpio_mouse.o
+obj-$(CONFIG_MOUSE_MAPLE)  += maplemouse.o
 
 psmouse-objs := psmouse-base.o synaptics.o

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[BUG] NMI watchdog alert with Linux 2.6.23.16

[Chris Rankin]

Hi,

This is a strange NMI lockup - I have no idea what triggered it and so cannot 
possibly reproduce
it. Requests to try (try "what"?) with 2.6.24.x would be similarly unhelpful.

But anyway, here it is. A perfectly normal boot of 2.6.23.16 on a dual P4 Xeon 
(HT enabled, to
give 4 logical CPUs) with 2 GB RAM, until it all goes horribly wrong:

...
scsi1 : ata_piix
ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001ffa0 irq 14
ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001ffa8 irq 15
ata1.00: ATA-6: IC35L090AVV207-0, V23OA66A, max UDMA/100
ata1.00: 15625 sectors, multi 8: LBA48 
usb 1-2: device not accepting address 2, error -71
ata1.00: configured for UDMA/100
usb 4-3: new high speed USB device using ehci_hcd and address 3
ata2.00: ATAPI: HL-DT-STDVD-ROM GDR8162B, 0015, max UDMA/33
ata2.01: ATAPI: SONYCD-RW  CRX216E, PD01, max UDMA/33
usb 4-3: configuration #1 chosen from 1 choice
hub 4-3:1.0: USB hub found
hub 4-3:1.0: 4 ports detected
ata2.00: configured for UDMA/33
ata2.01: configured for UDMA/33
scsi 0:0:0:0: Direct-Access ATA  IC35L090AVV207-0 V23O PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 15625 512-byte hardware sectors (8 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
sd 0:0:0:0: [sda] 15625 512-byte hardware sectors (8 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
 sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
sd 0:0:0:0: [sda] Attached SCSI disk
scsi 1:0:0:0: CD-ROMHL-DT-ST DVD-ROM GDR8162B 0015 PQ: 0 ANSI: 5
usb 1-2: new full speed USB device using uhci_hcd and address 4
scsi 1:0:1:0: CD-ROMSONY CD-RW  CRX216E   PD01 PQ: 0 ANSI: 5
usb 1-2: configuration #1 chosen from 1 choice
usb 4-3.4: new high speed USB device using ehci_hcd and address 4
usb 4-3.4: configuration #1 chosen from 1 choice
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: [EMAIL PROTECTED]
end_request: I/O error, dev fd0, sector 0
end_request: I/O error, dev fd0, sector 0
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Real Time Clock Driver v1.12ac

Fedora release 8 (Werewolf)
Kernel 2.6.23.16 on an i686

volcano.underworld login: BUG: NMI Watchdog detected LOCKUP on CPU1, eip 
c010df34, registers:
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 0046   (2.6.23.16 #1)
EIP is at ipi_handler+0x17/0x57
eax: f5c1ed98   ebx: f5c1ed98   ecx: 01cdb000   edx: c0340d00
esi: 0086   edi:    ebp: f6073c9c   esp: c0346dd8
ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
Process sendmail (pid: 2232, ti=c0346000 task=f6a02ff0 task.ti=f6be4000)
Stack: 000f f5c1ed98 c010df1d  f6073c9c c0112b52 f6371218 f7392480 
   f739256c c0104a04 f6371218 c0346000 0207 f7392480 f739256c f6073c9c 
   f6371218 007b 007b 00d8 ff04 c02777b5 0060 0207 
Call Trace:
 [] ipi_handler+0x0/0x57
 [] smp_call_function_interrupt+0x37/0x52
 [] call_function_interrupt+0x28/0x30
 [] _spin_unlock_irqrestore+0x5/0x23
 [] sock_def_readable+0x3c/0x66
 [] tcp_data_queue+0x502/0xa48
 [] tcp_rcv_established+0x5a4/0x645
 [] tcp_v4_do_rcv+0x28/0x342
 [] local_bh_enable+0x86/0xa2
 [] tcp_v4_rcv+0x828/0x884
 [] ip_local_deliver+0xd9/0x196
 [] ip_rcv+0x466/0x49c
 [] load_balance+0x6d/0x255
 [] _spin_unlock_irq+0xe/0x22
 [] ip_rcv+0x0/0x49c
 [] netif_receive_skb+0x1c9/0x255
 [] process_backlog+0x7f/0xe7
 [] net_rx_action+0x60/0xeb
 [] __do_softirq+0x58/0xba
 [] do_softirq+0x5c/0xb2
 [] loopback_xmit+0x5d/0x62
 [] local_bh_enable+0x7c/0xa2
 [] dev_queue_xmit+0x268/0x290
 [] ip_output+0x20d/0x245
 [] ip_queue_xmit+0x29d/0x2dd
 [] __getblk+0x14/0x1ea
 [] __inc_zone_state+0xc/0x4c
 [] __ext3_get_inode_loc+0x10a/0x2cd [ext3]
 [] tcp_transmit_skb+0x622/0x655
 [] _spin_lock+0xd/0x5a
 [] inotify_d_instantiate+0x44/0x72
 [] __tcp_push_pending_frames+0x709/0x7b9
 [] __alloc_skb+0x28/0xfb
 [] __alloc_skb+0x4d/0xfb
 [] tcp_sendmsg+0x921/0xa19
 [] mntput_no_expire+0x11/0x63
 [] sock_aio_write+0xbc/0xc8
 [] do_sync_write+0xc7/0x10a
 [] autoremove_wake_function+0x0/0x35
 [] __wake_up+0x32/0x43
 [] vfs_write+0x9e/0x10c
 [] unlock_kernel+0x2e/0x2f
 [] sys_write+0x41/0x67
 [] sysenter_past_esp+0x5f/0x85
 [] xfrm_hash_alloc+0x5e/0x76
 ===
Code: 78 04 01 75 0d 9c 5b fa a1 a4 68 35 c0 ff 50 0c 53 9d 5b c3 55 57 56 53 
83 ec 04 89 c3 9c 5e
fa f0 ff 08 eb 02 f3 90 83 7b 04 00 <74> f8 8b 7b 10 83 ff ff 8b 2d a4 68 35 c0 
74 14 8b 4b 0c 8b
53 



  __
Sent from Yahoo! Mail.
A Smarter Inbox. http://uk.docs.yahoo.com/nowyoucan.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.

Re: [Bug 10030] Suspend doesn't work when SD card is inserted

[Rafael J. Wysocki]

On Sunday, 24 of February 2008, Alan Stern wrote:
> On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> > On Sunday, 24 of February 2008, Alan Stern wrote:
> > > On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> 
> > > I still have no clear idea about what's going on with the ACPI bug in 
> > > #9874.
> > 
> > It seems that the ACPI code is not prepared to cope with a failing device
> > registration, in which case it'd need fixing.  Frankly, I'm afraid there may
> > be more issues like this throughout the tree.
> 
> The fact remains that it is unsafe to register a device during a sleep 
> transition, although if the device's driver doesn't have a suspend or 
> resume method you can probably get away with it.
> 
> > > However perhaps the bug wouldn't occur if we blocked device  
> > > registration until after the resume was finished, instead of failing it 
> > > outright.  Since the registration in this case was done in a workqueue 
> > > thread, blocking wouldn't cause an immediate deadlock.
> > 
> > No, it wouldn't, but the fact that it happens in the ACPI code makes me 
> > worry.
> 
> It happened in a workqueue.  There could be lots of similar cases: Some 
> interrupt-driven event causes a hotplug action.  Since the action can't 
> be carried out in interrupt context, the driver has no choice but to 
> defer it to a workqueue or kernel thread.  Blocking that workqueue or 
> kernel thread won't cause a problem _unless_ the driver's 
> suspend/resume methods try to synchronize with it.  That's the 
> difficult case.

Yes.

> > If we block that code and the things it's supposed to do turn out to be
> > necessary for suspending later on, we'll be in trouble.
> 
> Exactly.
> 
> > > @@ -94,14 +102,15 @@ void device_pm_remove(struct device *dev
> > >   /* No suspend in progress, wait on dev->sem */
> > >   down(&dev->sem);
> > >   up_read(&pm_sleep_rwsem);
> > > - } else {
> > > - /* Suspend in progress, we may deadlock */
> > > + } else if (!in_suspend_context()) {
> > > + /* Suspending in another task, we may deadlock */
> > 
> > Well, that shouldn't really deadlock.  If it does, there is a potential 
> > design
> > issue somewhere.  I think it might be better to set up a timer in here too.
> 
> At this point the driver core owns the device semaphore, so the 
> unregistration task will block until the sleep is over.  If the 
> driver's resume method has to synchronize with the unregistration task 
> then it will deadlock.  I agree, it would be a design issue.  In fact, 
> it's the same design issue described earlier in this email.
> 
> > Although IMO it would be even better to just set up a timer and remove the
> > warning altogehter.
> 
> That warning was just for debugging purposes.  A timer in the resume
> path could do the same thing with fewer false alarms, just like the 
> timer in the suspend path.  I have added it to the new patch.

OK

> > >   dev_warn(dev, "Suspicious %s during suspend\n",
> > >   __FUNCTION__);
> > >   dump_stack();
> > >   /* The user has been warned ... */
> > >   down(&dev->sem);
> > >   }
> > > + /* Otherwise we're okay */
> > >   }
> > >   pr_debug("PM: Removing info for %s:%s\n",
> > >dev->bus ? dev->bus->name : "No Bus",
> > 
> > There's a problem here, because we shouldn't release the semaphore if we're
> > in the suspend context.
> 
> Yes, you're right.  It's fixed in the new version.
> 
> > > +static void suspend_timeout(unsigned long _dev)
> > > +{
> > > + struct device *dev = (struct device *) _dev;
> > > +
> > > + dev_err(dev, "deadlock during suspend!\n");
> > > + show_state();
> > 
> > The show_state() seems to be overkill and won't really help if the user 
> > can't
> > collect the output on the fly using a serial console or something like this.
> > [The debug stuff printed here should fit a typical laptop screen, ideally.]
> 
> Changed.
> 
> > I'd prefer
> > 
> > if (in_suspend_context()) {
> > __device_release_driver(dev);
> > } else {
> > down(&dev->sem);
> > __device_release_driver(dev);
> > up(&dev->sem);
> > }
> 
> Okay.
> 
> You know, with this new patch we probably don't need 
> device_pm_schedule_removal() any more.

No, we don't.  However, because of that dpm_suspend() and device_power_down()
need to be changed not to assume that the removed devices will end up on
dpm_destroy.

> However I have left it in for now.

Well, it's used by the b43, leds and hwrng drivers as well as by some CPU
hotplug notifiers.  They all will have to be changed along with removing it.

> > Well, I'd really feel much more comfortable if we removed the troublesome 
> > code
> > for 2.6.25 and reintroduced it along with the above safeguards for 2.6.26.
> > 
> > Of course, this doesn't mean we can't send debug p

[PATCH 3/3] input: support maple mouse on Dreamcast

[Adrian McMenamin]

input: add support for maple mouse on Dreamcast

Signed-off-by: Adrian McMenamin <[EMAIL PROTECTED]>
---

diff --git a/drivers/input/mouse/maplemouse.c b/drivers/input/mouse/maplemouse.c
new file mode 100644
index 000..08cfb6f
--- /dev/null
+++ b/drivers/input/mouse/maplemouse.c
@@ -0,0 +1,148 @@
+/*
+ * SEGA Dreamcast mouse driver
+ * Based on drivers/usb/usbmouse.c
+ *
+ * Copyright Yaegashi Takeshi, 2001
+ * Porting to 2.6 and other fixes
+ * copyright, Adrian McMenamin, 2008
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+MODULE_AUTHOR("YAEGASHI Takeshi <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("SEGA Dreamcast mouse driver");
+MODULE_LICENSE("GPL");
+
+static void dc_mouse_callback(struct mapleq *mq)
+{
+   int buttons, relx, rely, relz;
+   struct maple_device *mapledev = mq->dev;
+   struct input_dev *dev = mapledev->private_data;
+   unsigned char *res = mq->recvbuf;
+
+   buttons = ~res[8];
+   relx = *(unsigned short *)(res + 12) - 512;
+   rely = *(unsigned short *)(res + 14) - 512;
+   relz = *(unsigned short *)(res + 16) - 512;
+
+   input_report_key(dev, BTN_LEFT,   buttons & 4);
+   input_report_key(dev, BTN_MIDDLE, buttons & 9);
+   input_report_key(dev, BTN_RIGHT,  buttons & 2);
+   input_report_rel(dev, REL_X,  relx);
+   input_report_rel(dev, REL_Y,  rely);
+   input_report_rel(dev, REL_WHEEL,  relz);
+   input_sync(dev);
+}
+
+static int dc_mouse_connect(struct maple_device *mdev)
+{
+   struct input_dev *input_dev;
+   int error;
+
+   input_dev = input_allocate_device();
+   if (!input_dev) {
+   error = ENOMEM;
+   goto fail_nomem;
+   }
+   mdev->private_data = input_dev;
+
+   input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REL);
+   input_dev->keybit[BIT_WORD(BTN_MOUSE)] = BIT_MASK(BTN_LEFT) | 
BIT_MASK(BTN_RIGHT) | BIT_MASK(BTN_MIDDLE);
+
+   input_dev->relbit[0] = BIT_MASK(REL_X) | BIT_MASK(REL_Y) | 
BIT_MASK(REL_WHEEL);
+
+   input_dev->name = mdev->product_name;
+   input_dev->id.bustype = BUS_HOST;
+
+   error = input_register_device(input_dev);
+   if (error)
+   goto fail_regdev;
+
+   maple_getcond_callback(mdev, dc_mouse_callback, HZ/50, 
MAPLE_FUNC_MOUSE);
+
+   return error;
+
+fail_regdev:
+   input_free_device(input_dev);
+fail_nomem:
+   return error;
+}
+
+static void dc_mouse_disconnect(struct maple_device *dev)
+{
+   struct input_dev *input_dev = dev->private_data;
+
+   input_unregister_device(input_dev);
+   kfree(input_dev);
+}
+
+/* allow the mouse to be used */
+static int probe_maple_mouse(struct device *dev)
+{
+   struct maple_device *mdev = to_maple_dev(dev);
+   struct maple_driver *mdrv = to_maple_driver(dev->driver);
+   int error;
+
+   error = dc_mouse_connect(mdev);
+   if (error)
+   return error;
+
+   mdev->driver = mdrv;
+
+   return 0;
+}
+
+
+static int remove_maple_mouse(struct device *dev)
+{
+   struct maple_device *mdev = to_maple_dev(dev);
+
+   dc_mouse_disconnect(mdev);
+   return 0;
+}
+
+static struct maple_driver dc_mouse_driver = {
+   .function = MAPLE_FUNC_MOUSE,
+   .connect =  dc_mouse_connect,
+   .disconnect =   dc_mouse_disconnect,
+   .drv = {
+   .name = "Dreamcast_mouse",
+   .probe = probe_maple_mouse,
+   .remove = remove_maple_mouse,
+   },
+};
+
+static int unplug_maple_mouse(struct device *dev, void *ignored)
+{
+   /* Please DO NOT really unplug your mouse */
+   struct maple_device *mdev;
+
+   mdev = to_maple_dev(dev);
+   if ((mdev->function & MAPLE_FUNC_MOUSE)
+   && (mdev->driver == &dc_mouse_driver))
+   remove_maple_mouse(dev);
+
+   return 0;
+}
+
+static int __init dc_mouse_init(void)
+{
+   maple_driver_register(&dc_mouse_driver.drv);
+   return 0;
+}
+
+static void __exit dc_mouse_exit(void)
+{
+   bus_for_each_dev(&maple_bus_type, NULL, NULL, unplug_maple_mouse);
+   driver_unregister(&dc_mouse_driver.drv);
+}
+
+module_init(dc_mouse_init);
+module_exit(dc_mouse_exit);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] 2.6.25-rc2-git8 fails to boot on 486 due to TSC breakage

[Ingo Molnar]

* Mikael Pettersson <[EMAIL PROTECTED]> wrote:

> The kernel for this 486 has CONFIG_M486=y and CONFIG_M586TSC=n, but 
> the 2.6.25 kernels still try to access the TSC. Here's the oops from 
> 2.6.25-rc2-git8:

hm, could you send me the full .config you used?

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-pm] [Bug 10030] Suspend doesn't work when SD card is inserted

[Rafael J. Wysocki]

On Sunday, 24 of February 2008, Alan Stern wrote:
> On Sat, 23 Feb 2008, Alan Stern wrote:
> 
> > It happened in a workqueue.  There could be lots of similar cases: Some 
> > interrupt-driven event causes a hotplug action.  Since the action can't 
> > be carried out in interrupt context, the driver has no choice but to 
> > defer it to a workqueue or kernel thread.  Blocking that workqueue or 
> > kernel thread won't cause a problem _unless_ the driver's 
> > suspend/resume methods try to synchronize with it.  That's the 
> > difficult case.
> 
> In fact this turns out to be exactly the problem with the MMC
> subsystem.  It uses a dedicated workqueue (kmmcd) to handle state
> changes, and mmc_suspend_host() does a flush_workqueue().  If the
> workqueue contains an entry to register or unregister a device, this is
> guaranteed to deadlock -- and that's exactly what happens when Zdenek 
> inserts or removes a card during the disk-drive spindown time of a 
> system sleep.
> 
> It looks like the best solution is for mmc_suspend_host() not to flush
> the workqueue; instead the workqueue should prevent itself from
> running during a suspend.  Right now the easiest way to accomplish this
> is for the workqueue routines (mmc_detect() and siblings) to acquire
> the mmc_host's device semaphore.  If in the future the MMC subsystem
> adds dynamic PM support then a more complicated arrangement will be 
> needed.
> 
> So the patch below, in combination with the previous patch, might just 
> fix the whole problem.

The patch looks sane and I think you're right.

Still, it depends on us holding the device semaphores (if I understand it
correctly).  For this reason, I'd prefer to include it into the patch that adds
device locking to the PM core.

I think we should first remove the device locking from
drivers/base/power/main.c (that's the patch I'd like to push upstream now) and
then create a patch that will add it back along with all of the necessary
additional changes we know of (BTW, I've just received a message from another
user affected by it).

but we need to be careful with
all the details.  IMO, it would be 

Thanks,
Rafael

 
> Index: usb-2.6/drivers/mmc/core/core.c
> ===
> --- usb-2.6.orig/drivers/mmc/core/core.c
> +++ usb-2.6/drivers/mmc/core/core.c
> @@ -731,8 +731,6 @@ void mmc_stop_host(struct mmc_host *host
>   */
>  int mmc_suspend_host(struct mmc_host *host, pm_message_t state)
>  {
> - mmc_flush_scheduled_work();
> -
>   mmc_bus_get(host);
>   if (host->bus_ops && !host->bus_dead) {
>   if (host->bus_ops->suspend)
> Index: usb-2.6/drivers/mmc/core/mmc.c
> ===
> --- usb-2.6.orig/drivers/mmc/core/mmc.c
> +++ usb-2.6/drivers/mmc/core/mmc.c
> @@ -441,6 +441,7 @@ static void mmc_detect(struct mmc_host *
>   BUG_ON(!host);
>   BUG_ON(!host->card);
>  
> + down(&mmc_classdev(host)->sem);
>   mmc_claim_host(host);
>  
>   /*
> @@ -449,6 +450,7 @@ static void mmc_detect(struct mmc_host *
>   err = mmc_send_status(host->card, NULL);
>  
>   mmc_release_host(host);
> + up(&mmc_classdev(host)->sem);
>  
>   if (err) {
>   mmc_remove(host);
> Index: usb-2.6/drivers/mmc/core/sd.c
> ===
> --- usb-2.6.orig/drivers/mmc/core/sd.c
> +++ usb-2.6/drivers/mmc/core/sd.c
> @@ -500,6 +500,7 @@ static void mmc_sd_detect(struct mmc_hos
>   BUG_ON(!host);
>   BUG_ON(!host->card);
>  
> + down(&mmc_classdev(host)->sem);
>   mmc_claim_host(host);
>  
>   /*
> @@ -508,6 +509,7 @@ static void mmc_sd_detect(struct mmc_hos
>   err = mmc_send_status(host->card, NULL);
>  
>   mmc_release_host(host);
> + up(&mmc_classdev(host)->sem);
>  
>   if (err) {
>   mmc_sd_remove(host);
> Index: usb-2.6/drivers/mmc/core/sdio.c
> ===
> --- usb-2.6.orig/drivers/mmc/core/sdio.c
> +++ usb-2.6/drivers/mmc/core/sdio.c
> @@ -195,6 +195,7 @@ static void mmc_sdio_detect(struct mmc_h
>   BUG_ON(!host);
>   BUG_ON(!host->card);
>  
> + down(&mmc_classdev(host)->sem);
>   mmc_claim_host(host);
>  
>   /*
> @@ -203,6 +204,7 @@ static void mmc_sdio_detect(struct mmc_h
>   err = mmc_select_card(host->card);
>  
>   mmc_release_host(host);
> + up(&mmc_classdev(host)->sem);
>  
>   if (err) {
>   mmc_sdio_remove(host);
> 
> 
> 



-- 
"Premature optimization is the root of all evil." - Donald Knuth
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] input: support maple controller on SEGA Dreamcast

[Adrian McMenamin]

This is a port of the old (never in mainline) 2.4 driver.

(It also fixes some issues with earlier patches which should be
discarded for this)


Signed-off-by: Adrian McMenamin <[EMAIL PROTECTED]>
---

diff -ruN ./a/drivers/input/joystick/Kconfig ./b/drivers/input/joystick/Kconfig
--- ./a/drivers/input/joystick/Kconfig  2008-02-21 20:42:07.0 +
+++ ./b/drivers/input/joystick/Kconfig  2008-02-24 13:59:04.0 +
@@ -282,4 +282,17 @@
  This option enables support for the LED which surrounds the Big X on
  XBox 360 controller.
 
+config JOYSTICK_MAPLE
+   tristate "Dreamcast control pad"
+   depends on SH_DREAMCAST
+   select MAPLE
+   help
+ Say Y here if you have a SEGA Dreamcast and want to use your
+ controller.
+
+ Most Dreamcast users will say Y.
+
+ To compile this as a module choose M here: the
+ module will be called maplecontrol.
+
 endif
diff -ruN ./a/drivers/input/joystick/Makefile 
./b/drivers/input/joystick/Makefile
--- ./a/drivers/input/joystick/Makefile 2008-02-21 20:42:07.0 +
+++ ./b/drivers/input/joystick/Makefile 2008-02-24 13:59:04.0 +
@@ -27,5 +27,6 @@
 obj-$(CONFIG_JOYSTICK_TWIDJOY) += twidjoy.o
 obj-$(CONFIG_JOYSTICK_WARRIOR) += warrior.o
 obj-$(CONFIG_JOYSTICK_XPAD)+= xpad.o
+obj-$(CONFIG_JOYSTICK_MAPLE)   += maplecontrol.o
 
 obj-$(CONFIG_JOYSTICK_IFORCE)  += iforce/
diff -ruN ./a/drivers/input/joystick/maplecontrol.c 
./b/drivers/input/joystick/maplecontrol.c
--- ./a/drivers/input/joystick/maplecontrol.c   1970-01-01 01:00:00.0 
+0100
+++ ./b/drivers/input/joystick/maplecontrol.c   2008-02-24 13:59:04.0 
+
@@ -0,0 +1,252 @@
+/*
+ * SEGA Dreamcast controller driver
+ * Based on drivers/usb/iforce.c
+ *
+ * Copyright Yaegashi Takeshi, 2001
+ * Porting to 2.6 by Adrian McMenamin, copyright 2008
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+MODULE_AUTHOR("YAEGASHI Takeshi <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("SEGA Dreamcast controller driver");
+MODULE_LICENSE("GPL");
+
+struct dc_pad {
+   struct input_dev *dev;
+   struct maple_device *mdev;
+   int open;
+};
+
+static void dc_pad_callback_idle(struct mapleq *mq)
+{
+}
+
+static void dc_pad_callback(struct mapleq *mq)
+{
+   unsigned short buttons;
+   struct maple_device *mapledev = mq->dev;
+   struct dc_pad *pad = mapledev->private_data;
+   struct input_dev *dev = pad->dev;
+   unsigned char *res = mq->recvbuf;
+
+   buttons = ~cpu_to_le16(*(unsigned short *)(res + 8));
+
+   input_report_abs(dev, ABS_HAT0Y,
+(buttons & 0x0010 ? -1:0) + (buttons & 0x0020 ? 1:0));
+   input_report_abs(dev, ABS_HAT0X,
+(buttons & 0x0040 ? -1:0) + (buttons & 0x0080 ? 1:0));
+   input_report_abs(dev, ABS_HAT1Y,
+(buttons & 0x1000 ? -1:0) + (buttons & 0x2000 ? 1:0));
+   input_report_abs(dev, ABS_HAT1X,
+(buttons & 0x4000 ? -1:0) + (buttons & 0x8000 ? 1:0));
+
+   input_report_key(dev, BTN_C,  buttons & 0x0001);
+   input_report_key(dev, BTN_B,  buttons & 0x0002);
+   input_report_key(dev, BTN_A,  buttons & 0x0004);
+   input_report_key(dev, BTN_START,  buttons & 0x0008);
+   input_report_key(dev, BTN_Z,  buttons & 0x0100);
+   input_report_key(dev, BTN_Y,  buttons & 0x0200);
+   input_report_key(dev, BTN_X,  buttons & 0x0400);
+   input_report_key(dev, BTN_SELECT, buttons & 0x0800);
+
+   input_report_abs(dev, ABS_GAS,   res[10]);
+   input_report_abs(dev, ABS_BRAKE, res[11]);
+   input_report_abs(dev, ABS_X, res[12]);
+   input_report_abs(dev, ABS_Y, res[13]);
+   input_report_abs(dev, ABS_RX,res[14]);
+   input_report_abs(dev, ABS_RY,res[15]);
+}
+
+static int dc_pad_open(struct input_dev *dev)
+{
+   struct dc_pad *pad = dev->private;
+   if (!pad->open)
+   maple_getcond_callback(pad->mdev, dc_pad_callback, HZ/50,
+   MAPLE_FUNC_CONTROLLER);
+   pad->open++;
+   return 0;
+
+}
+
+static void dc_pad_close(struct input_dev *dev)
+{
+   struct dc_pad *pad = dev->private;
+
+   pad->open--;
+   if (pad->open)
+   return;
+
+   /* Almost never call something that does nothing */
+   maple_getcond_callback(pad->mdev, dc_pad_callback_idle, 0x,
+   MAPLE_FUNC_CONTROLLER);
+}
+
+static int dc_pad_connect(struct maple_device *mdev)
+{
+   int i, error;
+   unsigned long data = be32_to_cpu(mdev->devinfo.function_data[0]);
+   struct dc_pad *pad;
+   struct input_dev *dev;
+
+   const short btn_bit[32] = {
+   BTN_C, BTN_B, BTN_A, BTN_START, -1, -1, -1, -1,
+   BTN_Z, BTN_Y, BTN_X, BTN_SELECT, -1, -1, -1, -1,
+   -1, -1

Re: bcm43xx regression in 2.6.24 (with patch)

[Michael Buesch]

On Saturday 23 February 2008 12:32:50 Alexey Zaytsev wrote:
> The problem is not with enabling both b43 and bcm43xx (will, whis won't work
> anyway, and there is no chance fixing it). The problem is with enabling the
> bcm43xx wifi driver and the b44 Ethernet driver. The ethernet driver then
> wrongly autosolects some config options that prevent the bcm43xx
> driver from loading, so I'm left with either no wifi or no ethenet.

Ok, so I just tested this on a machine and it is _not_ true.
It works just fine to run b44/ssb with bcm43xx in parallel.

Can you please stop fooling me and spreading this FUD?

-- 
Greetings Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] maple: fix device detection

[Adrian McMenamin]

The maple bus driver that went into the kernel mainline in September 2007 
contained some bugs which were revealed by the update of the kobj code for the 
current release series. Unfortunately those bugs also helped ensure maple 
devices were properly detected. This patch (against the current git) now 
ensures that devices are properly detected again.

(A previous attempt to fix this by delaying initialisation only partially fixed 
this - as became apparent when the bus was fully loaded)

Signed-off-by: Adrian McMenamin <[EMAIL PROTECTED]>
---



diff -ruN ./a/drivers/sh/maple/maple.c ./b/drivers/sh/maple/maple.c
--- ./a/drivers/sh/maple/maple.c2008-02-21 20:42:17.0 +
+++ ./b/drivers/sh/maple/maple.c2008-02-24 13:59:09.0 +
@@ -1,7 +1,7 @@
 /*
  * Core maple bus functionality
  *
- *  Copyright (C) 2007 Adrian McMenamin
+ *  Copyright (C) 2007, 2008 Adrian McMenamin
  *
  * Based on 2.4 code by:
  *
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -54,7 +53,7 @@
 static int subdevice_map[MAPLE_PORTS];
 static unsigned long *maple_sendbuf, *maple_sendptr, *maple_lastptr;
 static unsigned long maple_pnp_time;
-static int started, scanning, liststatus, realscan;
+static int started, scanning, liststatus, fullscan;
 static struct kmem_cache *maple_queue_cache;
 
 struct maple_device_specify {
@@ -62,6 +61,9 @@
int unit;
 };
 
+static bool checked[4];
+static struct maple_device *baseunits[4];
+
 /**
  *  maple_driver_register - register a device driver
  *  automatically makes the driver bus a maple bus
@@ -309,11 +311,9 @@
else
break;
 
-   if (realscan) {
-   printk(KERN_INFO "Maple device detected: %s\n",
-   mdev->product_name);
-   printk(KERN_INFO "Maple device: %s\n", mdev->product_licence);
-   }
+   printk(KERN_INFO "Maple device detected: %s\n",
+   mdev->product_name);
+   printk(KERN_INFO "Maple device: %s\n", mdev->product_licence);
 
function = be32_to_cpu(mdev->devinfo.function);
 
@@ -323,10 +323,9 @@
mdev->driver = &maple_dummy_driver;
sprintf(mdev->dev.bus_id, "%d:0.port", mdev->port);
} else {
-   if (realscan)
-   printk(KERN_INFO
-   "Maple bus at (%d, %d): Function 0x%lX\n",
-   mdev->port, mdev->unit, function);
+   printk(KERN_INFO
+   "Maple bus at (%d, %d): Function 0x%lX\n",
+   mdev->port, mdev->unit, function);
 
matched =
bus_for_each_drv(&maple_bus_type, NULL, mdev,
@@ -334,9 +333,8 @@
 
if (matched == 0) {
/* Driver does not exist yet */
-   if (realscan)
-   printk(KERN_INFO
-   "No maple driver found.\n");
+   printk(KERN_INFO
+   "No maple driver found.\n");
mdev->driver = &maple_dummy_driver;
}
sprintf(mdev->dev.bus_id, "%d:0%d.%lX", mdev->port,
@@ -472,9 +470,12 @@
maple_detach_driver(mdev);
return;
}
-   if (!started) {
-   printk(KERN_INFO "No maple devices attached to port %d\n",
-  mdev->port);
+   if (!started || !fullscan) {
+   if (checked[mdev->port] == false) {
+   checked[mdev->port] = true;
+   printk(KERN_INFO "No maple devices attached"
+   " to port %d\n", mdev->port);
+   }
return;
}
maple_clean_submap(mdev);
@@ -485,8 +486,14 @@
   char *recvbuf)
 {
char submask;
-   if ((!started) || (scanning == 2)) {
-   maple_attach_driver(mdev);
+   if (!started || (scanning == 2) || !fullscan) {
+   if ((mdev->unit == 0) && (checked[mdev->port] == false)) {
+   checked[mdev->port] = true;
+   maple_attach_driver(mdev);
+   } else {
+   if (mdev->unit != 0)
+   maple_attach_driver(mdev);
+   }
return;
}
if (mdev->unit == 0) {
@@ -505,6 +512,7 @@
struct maple_device *dev;
char *recvbuf;
enum maple_code code;
+   int i;
 
if (!maple_dma_done())
return;
@@ -557,6 +565,19 @@
} else
scanning = 0;
 
+   if (!fullscan) {
+   fullscan = 1;
+   for (i = 0; i < MAPLE_PORTS; i++) {
+   if (checked[i] == false) {
+   f

Re: [PATCH] x86: add the debugfs interface for the sysprof tool

[Ingo Molnar]

* Ingo Molnar <[EMAIL PROTECTED]> wrote:

> I'm the one to make sure that patches for useful userspace tools that 
> get submitted to me eventually go upstream, one way or another. 

just to make it clear: that "one way or another" very much includes the 
possibility that sysprof is modified to make use of the oprofile APIs - 
i.e. no kernel patch needed at all.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Merging of completely unreviewed drivers

[Krzysztof Halasa]

Jörn Engel <[EMAIL PROTECTED]> writes:

> I strongly disagree.  Machine-generated warnings are a great way of
> quickly locating a large amount of questionable code in an otherwise
> overwhelming haystack.  It doesn't even matter much, which warnings you
> look for.  Almost all code checkers find the same hotspots.

I think you misunderstood. Of course I'm not against warnings in
general. I'm rather talking about _authority_ of human vs machine,
in this specific ("measuring" code complexity) case.
-- 
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Page scan keeps touching kernel text pages

[Jörn Engel]

While tracking down some unrelated bug I noticed that shrink_page_list()
keeps testing very low page numbers (aka kernel text) until deciding
that the page lacks a mapping and cannot get freed.  Looks like a waste
of cpu and cachelines to me.

Is there a better reason for this behaviour than lack of a patch?

Jörn

-- 
Joern's library part 11:
http://www.unicom.com/pw/reply-to-harmful.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 00/38] 2.6.24-stable review

[Uli Luckas]

Hi stable-team,
Could you please include the attached patch [1] to the next stable release.
The patch fixes the otherwise unusable bluetooth uart on pxa25x . The patch is 
written by Russell King [1] who also gave his OK for stable inclusion [2].
The patch is also available as commit a0dd005d1d9f4c3beab52086f3844ef9342d1e67 
to Linus' tree.

Thanks,
Uli

[1] http://marc.info/?l=linux-arm-kernel&m=120298366510315
[2] http://marc.info/?l=linux-arm-kernel&m=120384388411097


diff --git a/arch/arm/mach-pxa/clock.c b/arch/arm/mach-pxa/clock.c
index 83ef5ec..df5ae27 100644
--- a/arch/arm/mach-pxa/clock.c
+++ b/arch/arm/mach-pxa/clock.c
@@ -23,18 +23,27 @@ static LIST_HEAD(clocks);
 static DEFINE_MUTEX(clocks_mutex);
 static DEFINE_SPINLOCK(clocks_lock);

+static struct clk *clk_lookup(struct device *dev, const char *id)
+{
+   struct clk *p;
+
+   list_for_each_entry(p, &clocks, node)
+   if (strcmp(id, p->name) == 0 && p->dev == dev)
+   return p;
+
+   return NULL;
+}
+
 struct clk *clk_get(struct device *dev, const char *id)
 {
struct clk *p, *clk = ERR_PTR(-ENOENT);

mutex_lock(&clocks_mutex);
-   list_for_each_entry(p, &clocks, node) {
-   if (strcmp(id, p->name) == 0 &&
-   (p->dev == NULL || p->dev == dev)) {
-   clk = p;
-   break;
-   }
-   }
+   p = clk_lookup(dev, id);
+   if (!p)
+   p = clk_lookup(NULL, id);
+   if (p)
+   clk = p;
mutex_unlock(&clocks_mutex);

return clk;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH][RFC] Remove "obsolete" digiepca content.

[Robert P. J. Day]

On Sun, 24 Feb 2008, Jiri Slaby wrote:

> On 02/09/2008 10:45 PM, Robert P. J. Day wrote:
> > Remove the Digi Intl. epca driver for Linux, which is marked as
> > "obsolete."
> >
> > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
> >
> > ---
> >   this is a quick, first pass at a removal.  feel free to suggest
> > tweaks.
>
> Was there any comments on this? I suggest reposting with Cc to akpm.

ok, i'll give it another shot but, given that this discussion has been
happening on and off for well over a year:

http://lkml.org/lkml/2006/10/26/231

i'm starting to wonder whether this is worth anyone's time anymore.
certainly, *i'm* losing interest in posting it every couple of months.

rday
--


Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.

http://crashcourse.ca  Waterloo, Ontario, CANADA

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] 2.6.25-rc2-git8 fails to boot on 486 due to TSC breakage

[Mikael Pettersson]

Ingo Molnar writes:
 > 
 > * Mikael Pettersson <[EMAIL PROTECTED]> wrote:
 > 
 > > The kernel for this 486 has CONFIG_M486=y and CONFIG_M586TSC=n, but 
 > > the 2.6.25 kernels still try to access the TSC. Here's the oops from 
 > > 2.6.25-rc2-git8:
 > 
 > hm, could you send me the full .config you used?

I've put it here:


Meanwhile, I've traced the breakage to 2.6.24-git8.

2.6.24-git8 changed include/asm-x86/tsc.h:get_cycles() to call
rdtscll() even if CONFIG_X86_TSC isn't set. The call is protected
by a cpu_has_tsc test, but starting with 2.6.24-git8 cpu_has_tsc
is non-zero on this machine, which is very very wrong.

Diffing dmesg between git7 and git8 doesn't sched any light since
git8 also removed the printouts of the x86 caps as they were being
initialised and updated. I'm currently adding those printouts back
in the hope of seeing where and when the caps get broken.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Change a WARN message in checkpatch

[Benny Halevy]

On Feb. 23, 2008, 5:38 -0800, "Paolo Ciarrocchi" <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 28, 2008 at 4:13 PM, Paolo Ciarrocchi
> <[EMAIL PROTECTED]> wrote:
>> On Jan 28, 2008 3:56 PM, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>>  > On Mon, Jan 14, 2008 at 11:29:13PM +0100, Paolo Ciarrocchi wrote:
>>  > > Hi Andy,
>>  > > When I started using checkpatch I was confused by the following WARN 
>> message:
>>  > >
>>  > >   no space between function name and open parenthesis
>>  > >
>>  > > I thought the problem was that a space was missing while the truth is 
>> the opposite.
>>  > >
>>  > > How about the following patch?
>>  >
>>  > I can see how that language would be confusing.  Your patch makes the
>>  > english clearer, but somehow seems clumsy.  There must be a better way
>>  > to say this.  I will think on it and see what I can come up with.
>>
>>  Fair enought, I'm not English mother tongue and I'm sure you can come
>>  up with a better
>>  sentence :-)
> 
> AFAICS the problem is still present.
> 
> Ciao,

How about:
-   WARN("no space between function name and open 
parenthesis '('\n" . $herecurr);
+   WARN("there should be no space between function 
name and open parenthesis '('\n" . $herecurr);

The original phrasing can be interpreted like "there is no space between ..." 
and the correct
interpretation should be "there should be no space between ..."

Benny
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Tabs, spaces, indent and 80 character lines

[Krzysztof Halasa]

Richard Knutsson <[EMAIL PROTECTED]> writes:

> Why hinder a developer who prefer
> 2, 4, 6 or any other != 8 width?

I guess we could use tabs only at the line start, for indentation
only. Rather hard to implement, most text editors can't do that yet.

> By only using tabs as indents, and
> changing the CodeStyle to be something like "maximum 80
> characters-wide lines, with a tab-setting of 8 spaces",

This changes nothing.

> that is
> possible + easier to write code-checkers [2].

I doubt it.

> Or are we really that concerned about the disk-space? ;)

Unpacked sources will be much bigger with not tabs, sure.
-- 
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv4 2.6.25] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers

[Jochen Friedrich]

Hi Olof,

>> 2. record the I2c name in the dts tree, either as seperate tag (like 
>> linux,i2c-name="")
>>or as additional compatible entry (like compatible="...", 
>> "linux,").
> 
> I have to say no on this one. The device tree is not supposed to know
> about how linux uses devices, there are firmwares out there that don't
> use DTS for thier device trees, etc.

I still believe this this could be done for embedded devices which are usually 
booted
via wrapper or U-Boot as those devices will most probably use the most exotic 
I2c devices
out there (e.g. home-grown devices used by stbs). However, I'm not an device 
tree expert.
 
>> 3. use a glue layer with a translation map.
> 
> In my opinion this is an OK solution since the same information has to
> be added somewhere already anyway -- eiither to the drivers or to this
> translation table. It should of course be an abstacted shared table,
> preferrably contained under the i2c source directories since several
> platforms and architectures might share them.

I could think of a mixture between 2. and 3.:

Using the compatible attribute with the manufacturer stripped off as I2c name 
by default
and using an exception table. For now, the struct i2c_driver_device would 
currently only
need one entry ("dallas,ds1374", "rtc-ds1374").

Thanks,
Jochen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] 2.6.25-rc2-git8 fails to boot on 486 due to TSC breakage

[Ingo Molnar]

* Mikael Pettersson <[EMAIL PROTECTED]> wrote:

> 2.6.24-git8 changed include/asm-x86/tsc.h:get_cycles() to call 
> rdtscll() even if CONFIG_X86_TSC isn't set. The call is protected by a 
> cpu_has_tsc test, but starting with 2.6.24-git8 cpu_has_tsc is 
> non-zero on this machine, which is very very wrong.

does reverting the commit below solve the problem?

Ingo

-->
commit 404ee5b14b68d3cba287c2596588b83790c49f7b
Author: Andi Kleen <[EMAIL PROTECTED]>
Date:   Wed Jan 30 13:33:20 2008 +0100

x86: convert TSC disabling to generic cpuid disable bitmap

Fix from: Ian Campbell <[EMAIL PROTECTED]>

Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index a96abd4..9b95edc 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -154,7 +154,7 @@ static void __init check_config(void)
  * If we configured ourselves for a TSC, we'd better have one!
  */
 #ifdef CONFIG_X86_TSC
-   if (!cpu_has_tsc && !tsc_disable)
+   if (!cpu_has_tsc)
panic("Kernel compiled for Pentium+, requires TSC feature!");
 #endif
 
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index c66991a..dfc9563 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -446,10 +446,6 @@ void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
 * we do "generic changes."
 */
 
-   /* TSC disabled? */
-   if ( tsc_disable )
-   clear_bit(X86_FEATURE_TSC, c->x86_capability);
-
/* If the model name is still unset, do table lookup. */
if ( !c->x86_model_id[0] ) {
char *p;
@@ -650,11 +646,6 @@ void __cpuinit cpu_init(void)
 
if (cpu_has_vme || cpu_has_tsc || cpu_has_de)
clear_in_cr4(X86_CR4_VME|X86_CR4_PVI|X86_CR4_TSD|X86_CR4_DE);
-   if (tsc_disable && cpu_has_tsc) {
-   printk(KERN_NOTICE "Disabling TSC...\n");
-   / FIX-HPA: DOES THIS REALLY BELONG HERE? /
-   clear_bit(X86_FEATURE_TSC, boot_cpu_data.x86_capability);
-   }
 
load_idt(&idt_descr);
switch_to_new_gdt();
diff --git a/arch/x86/kernel/numaq_32.c b/arch/x86/kernel/numaq_32.c
index 9000d82..e65281b 100644
--- a/arch/x86/kernel/numaq_32.c
+++ b/arch/x86/kernel/numaq_32.c
@@ -82,7 +82,7 @@ static int __init numaq_tsc_disable(void)
 {
if (num_online_nodes() > 1) {
printk(KERN_DEBUG "NUMAQ: disabling TSC\n");
-   tsc_disable = 1;
+   setup_clear_cpu_cap(X86_FEATURE_TSC);
}
return 0;
 }
diff --git a/arch/x86/kernel/tsc_32.c b/arch/x86/kernel/tsc_32.c
index 2a7b95b..43517e3 100644
--- a/arch/x86/kernel/tsc_32.c
+++ b/arch/x86/kernel/tsc_32.c
@@ -24,8 +24,6 @@ static int tsc_enabled;
 unsigned int tsc_khz;
 EXPORT_SYMBOL_GPL(tsc_khz);
 
-int tsc_disable;
-
 #ifdef CONFIG_X86_TSC
 static int __init tsc_setup(char *str)
 {
@@ -40,8 +38,7 @@ static int __init tsc_setup(char *str)
  */
 static int __init tsc_setup(char *str)
 {
-   tsc_disable = 1;
-
+   setup_clear_cpu_cap(X86_FEATURE_TSC);
return 1;
 }
 #endif
@@ -395,7 +392,7 @@ void __init tsc_init(void)
 {
int cpu;
 
-   if (!cpu_has_tsc || tsc_disable)
+   if (!cpu_has_tsc)
goto out_no_tsc;
 
cpu_khz = calculate_cpu_khz();
@@ -439,10 +436,5 @@ void __init tsc_init(void)
return;
 
 out_no_tsc:
-   /*
-* Set the tsc_disable flag if there's no TSC support, this
-* makes it a fast flag for the kernel to see whether it
-* should be using the TSC.
-*/
-   tsc_disable = 1;
+   setup_clear_cpu_cap(X86_FEATURE_TSC);
 }
diff --git a/arch/x86/mach-voyager/setup.c b/arch/x86/mach-voyager/setup.c
index 81257a8..5ae5466 100644
--- a/arch/x86/mach-voyager/setup.c
+++ b/arch/x86/mach-voyager/setup.c
@@ -37,7 +37,7 @@ void __init pre_setup_arch_hook(void)
 {
/* Voyagers run their CPUs from independent clocks, so disable
 * the TSC code because we can't sync them */
-   tsc_disable = 1;
+   setup_clear_cpu_cap(X86_FEATURE_TSC);
 }
 
 void __init trap_init_hook(void)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index d083ff5..b3721fd 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -592,7 +592,7 @@ __init void xen_time_init(void)
set_normalized_timespec(&wall_to_monotonic,
-xtime.tv_sec, -xtime.tv_nsec);
 
-   tsc_disable = 0;
+   setup_force_cpu_cap(X86_FEATURE_TSC);
 
xen_setup_timer(cpu);
xen_setup_cpu_clockevents();
diff --git a/include/asm-x86/cpufeature.h b/include/asm-x86/cpufeature.h
index b8f53f8..3fb7dfa 100644
--- a/include/asm-x86/cpufeature.h
+++ b/include/asm-x86/cpufeature.h
@@ -135,6 +135,10 @@
clear_cpu_cap(&boot_cpu_dat

Bugs in MMC [was: [Bug 10030] Suspend doesn't work when SD card is inserted]

[Alan Stern]

On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:

> > In fact this turns out to be exactly the problem with the MMC
> > subsystem.  It uses a dedicated workqueue (kmmcd) to handle state
> > changes, and mmc_suspend_host() does a flush_workqueue().  If the
> > workqueue contains an entry to register or unregister a device, this is
> > guaranteed to deadlock -- and that's exactly what happens when Zdenek 
> > inserts or removes a card during the disk-drive spindown time of a 
> > system sleep.
> > 
> > It looks like the best solution is for mmc_suspend_host() not to flush
> > the workqueue; instead the workqueue should prevent itself from
> > running during a suspend.  Right now the easiest way to accomplish this
> > is for the workqueue routines (mmc_detect() and siblings) to acquire
> > the mmc_host's device semaphore.  If in the future the MMC subsystem
> > adds dynamic PM support then a more complicated arrangement will be 
> > needed.
> > 
> > So the patch below, in combination with the previous patch, might just 
> > fix the whole problem.
> 
> The patch looks sane and I think you're right.

Well, the patch itself isn't really adequate; it was just a first pass 
intended to illustrate the nature of the problem.

The problems in the MMC subsystem go deeper.

The first is the way it uses flush_workqueue().  This is almost always 
a bad function to call, because it introduces unnecessary dependencies.  
cancel_delayed_work_sync() is much better.

But even changing that won't solve the second issue, which is a genuine
bug.  There is a race between detect events and suspend events.  The
mmc_suspend_host() routine starts out by flushing the kmmcd workqueue
before calling the host's suspend routine.  So what happens if another
detect event occurs in between?

This whole area of synchronization between card insertion, card
removal, suspend, and resume needs to be thought out better.  
Especially keeping in mind that device registration or unregistration
during a system sleep is likely to block until the sleep is over.

Lastly, there are some other questions about confusing aspects of the
subsystem.  What's the story with __mmc_claim_host()?  Is it really
nothing more than an abortable mutex_lock()?  Why does it ever need to
be aborted?  Why is its second argument an atomic_t instead of a normal
int?

Why are mmc_detect() and related routines described in comments as
"Card detection callback from host"?  They don't handle card
_detection_ -- they handle card _removal_.

What's the purpose of the card-counting loop in 
host/omap.c:mmc_omap_switch_handler()?  It looks like dead code.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Make v9fs uname and remotename parsing more robust

[Eric Van Hensbergen]

On Sat, Feb 23, 2008 at 2:07 AM, Andrew Morton
<[EMAIL PROTECTED]> wrote:
>
>  It would be better to present this as two patches.  One adds the new core
>  APIs and the other uses those APIs in v9fs.  The patches would take
>  separate routes into mainline.
>
>  I guess I can sneak this one in as-is, as long as the v9fs guys are OK with
>  that?
>

I'm fine with it.  Shall I pull it through the v9fs-devel patch line
or would you rather send it with your patches Andrew?

-eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.25-rc2 rcupreempt WARN after suspend to ram

[Karsten Wiese]

Am Samstag, 23. Februar 2008 schrieb Karsten Wiese:
> Am Samstag, 23. Februar 2008 schrieb Paul E. McKenney:
> > On Sat, Feb 23, 2008 at 01:41:02PM +0100, Karsten Wiese wrote:
> > > Hi,
> > > 
> > > This appeared in dmesg after
> > >   $ echo core > /sys/power/pm_test
> > > followed by 3 cycles of
> > >   $ echo mem > /sys/power/state
> > > . .config attached.
> > > 
> > > dmesg excerpt (, full ~1MByte available):
> > 
> > Does this tree have http://lkml.org/lkml/2008/1/29/208 applied?
> 
> Yes. This tree was linus' git head as of yesterday or the day before.

Updated to git-head of today, same test and .config, different symptoms
like in this thread: http://lkml.org/lkml/2008/2/23/260
Later in this thread, Alan Cox said it looked like irq problems.
Maybe also the rcupreemt related WARN_ON I saw are caused by irq problems.

Thanks,
  Karsten
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Tabs, spaces, indent and 80 character lines

[Richard Knutsson]

Krzysztof Halasa wrote:

Richard Knutsson <[EMAIL PROTECTED]> writes:

  

Why hinder a developer who prefer
2, 4, 6 or any other != 8 width?



I guess we could use tabs only at the line start, for indentation
only. Rather hard to implement, most text editors can't do that yet.
  
You mean for split lines? Hopefully there won't be that many, so there 
is just to delete the tabs it added and replace it with spaces.
  

By only using tabs as indents, and
changing the CodeStyle to be something like "maximum 80
characters-wide lines, with a tab-setting of 8 spaces",



This changes nothing.
  
Exactly! But then we can remove the "we use 8 wide tabs in the kernel" 
in CodeStyle.
  

that is
possible + easier to write code-checkers [2].



I doubt it.
  
Easier to write code-checkers? OK, maybe not. Just that I got hit by 
this problem at a time when I wrote a simple checker (don't remember its 
purpose).
  

Or are we really that concerned about the disk-space? ;)



Unpacked sources will be much bigger with not tabs, sure.
  
Without no tabs at all, you mean? Don't want to think about that 
scenario, but with this suggestion, I would estimate maybe 0,5 - 1% bigger.


Thanks for your input

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] invert the axes for HDAPS on Lenovo R61i ThinkPads

[Gabor Czigola]

--- /usr/src/linux-source-2.6.24/drivers/hwmon/hdaps.c  2008-02-08
02:20:38.0 +0100
+++ /tmp/hdaps.c2008-02-24 16:42:52.0 +0100
@@ -527,6 +527,7 @@
HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad X60"),
HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad Z60m"),
HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad T61P"),
+   HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad R61i"),
HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad R61"),
HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad T61"),
{ .ident = NULL }

-- 
Czigola, Gabor
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PM: Introduce PM_EVENT_HIBERNATE (was: Re: i915 hibernation patch (was: Re: 2.6.25-rc2 System no longer ...))

[Jeff Chua]

On Sun, Feb 24, 2008 at 2:43 AM, Linus Torvalds
<[EMAIL PROTECTED]> wrote:
>
>
>  On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
>  >
>
> > Thanks for testing.  Below is the final version of the patch with a 
> > changelog
>  > etc.
>
>  Thanks, applied.
>
>  With this, I also find that I dislike the use of suspend/resume for
>  freezing for STD a lot less. It's still too easy to get confused, but at
>  least now drivers always have total knowledge about what is really going
>  on. I'd not like this interface as a driver writer, but now it's not
>  fundamentally broken any more, just slightly confusing.

Tested and working.

Thanks again,
Jeff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.24.2: 4KSTACKS + pcdrw + dm + mount -> stack overflow: ide-cd related? dm-related?

[Nix]

On 24 Feb 2008, [EMAIL PROTECTED] outgrape:

> A loop mount/umounting a pcdrw or iso9660 (through the pktcdvd device)
> sees a stack overflow in four or five tries. Doing the same thing with
> the same CD in a normal non-pktcdvd-mounted drive doesn't cause a crash.

> (This may or may not be PREEMPT+PREEMPT_BKL-specific: I'll try turning
> them off tomorrow and repeating.)

It is not preempt-specific, nor dm-specific. Nor it is very easy to
capture tracebacks of: even netconsole generally gives up when faced
with a string of recursive tracebacks blurring past forever at blinding
speed.

But while I'd normally blame pktcdvd there's only one pktcdvd function
in these tracebacks (pkt_open) and it's not got a significant stack
footprint.

More notable is a great stack of mutual recursion between
dm_bio_destructor() and the CDROM code: it seems to burn most of the
stack on this sort of thrashing. Here's one of those tracebacks again:

do_IRQ: stack overflow: 480
id: 4645, comm: mount Not tainted 2.6.24.2-dirty #4
 [] do_IRQ+0x66/0xc5
 [] common_interrupt+0x23/0x28
 [] ide_outsl+0x5/0x9
 [] ata_output_data+0x4d/0x64
 [] atapi_output_bytes+0x19/0x3f
 [] cdrom_transfer_packet_command+0xb5/0xde
 [] cdrom_timer_expiry+0x0/0x51
 [] cdrom_start_packet_command+0x14f/0x157
 [] cdrom_do_pc_continuation+0x0/0x2c
 [] ide_do_request+0x70a/0x943
 [] schedule_timeout+0x13/0x8b
 [] elv_drain_elevator+0x15/0x58
 [] elv_insert+0xf6/0x1d9
 [] cdrom_transfer_packet_command+0xb5/0xde
 [] cdrom_timer_expiry+0x0/0x51
 [] ide_do_drive_cmd+0x99/0xe9
 [] cdrom_queue_packet_command+0x35/0xa9
 [] schedule+0x321/0x33e
 [] schedule_timeout+0x13/0x8b
 [] cdrom_read_tocentry+0x96/0xa1
 [] blk_end_sync_rq+0x0/0x23
 [] cdrom_read_toc+0x14b/0x42e
 [] blk_end_sync_rq+0x0/0x23
 [] ide_do_drive_cmd+0xdf/0xe9
 [] ide_cdrom_audio_ioctl+0x13c/0x1de
 [] dm_bio_destructor+0x0/0x8
 [] end_bio_bh_io_sync+0x0/0x27
 [] cdrom_check_status+0x55/0x60
 [] blk_end_sync_rq+0x0/0x23
 [] cdrom_count_tracks+0x64/0x16a
 [] clone_endio+0x0/0xa3
 [] dm_bio_destructor+0x0/0x8
 [] cdrom_open+0x190/0x8f8
 [] end_bio_bh_io_sync+0x0/0x27
 [] bio_fs_destructor+0x0/0xb
 [] end_bio_bh_io_sync+0x0/0x27
 [] bio_fs_destructor+0x0/0xb
 [] clone_endio+0x0/0xa3
 [] dm_bio_destructor+0x0/0x8
 [] end_bio_bh_io_sync+0x0/0x27
 [] bio_fs_destructor+0x0/0xb
 [] clone_endio+0x0/0xa3
 [] dm_bio_destructor+0x0/0x8
 [] get_disk+0x4e/0x65
 [] exact_lock+0x7/0xd
 [] kobj_lookup+0x104/0x12e
 [] idecd_open+0x72/0x86
 [] do_open+0x198/0x238
 [] clone_endio+0x0/0xa3
 [] __blkdev_get+0x69/0x74
 [] blkdev_get+0x12/0x14
 [] pkt_open+0x8d/0xc96
 [] end_bio_bh_io_sync+0x0/0x27
 [] bio_fs_destructor+0x0/0xb
 [] clone_endio+0x0/0xa3
 [] dm_bio_destructor+0x0/0x8
 [] clone_endio+0x0/0xa3
 [] dm_bio_destructor+0x0/0x8
 [] end_bio_bh_io_sync+0x0/0x27
 [] bio_fs_destructor+0x0/0xb
 [] end_bio_bh_io_sync+0x0/0x27
 [] bio_fs_destructor+0x0/0xb
 [] end_bio_bh_io_sync+0x0/0x27
 [] bio_fs_destructor+0x0/0xb
 [] end_bio_bh_io_sync+0x0/0x27
 [] bio_fs_destructor+0x0/0xb
 [] clone_endio+0x0/0xa3
 [] dm_bio_destructor+0x0/0x8
 [] kobject_get+0xf/0x13
 [] get_disk+0x4e/0x65
 [] exact_lock+0x7/0xd
 [] kobj_lookup+0x104/0x12e
 [] exact_match+0x0/0x4
 [] do_open+0x84/0x238
 [] 
EIP: 0060:[] EFLAGS: 00010093 CPU: 0
EIP is at dump_trace+0x52/0x8b
EAX: 082a EBX: 0046 ECX: 020a EDX: 
ESI:  EDI:  EBP: 0ffc ESP: eeede1c4
 DS: 007b ES: 007b FS:  GS: 0033 SS: 0068
rocess mount (pid: 4645, ti=eeede000 task=ee537320 task.ti=eeede000)vhttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Tabs, spaces, indent and 80 character lines

[Benny Halevy]

On Feb. 24, 2008, 7:40 -0800, Richard Knutsson <[EMAIL PROTECTED]> wrote:
> Krzysztof Halasa wrote:
>> Richard Knutsson <[EMAIL PROTECTED]> writes:
>>
>>   
>>> Why hinder a developer who prefer
>>> 2, 4, 6 or any other != 8 width?
>>> 
>> I guess we could use tabs only at the line start, for indentation
>> only. Rather hard to implement, most text editors can't do that yet.
>>   
> You mean for split lines? Hopefully there won't be that many, so there 
> is just to delete the tabs it added and replace it with spaces.

IMO, tabs SHOULD be used for syntactic indentation and spaces for
decoration purpose only.  I.e. a line should start with a number of tabs
equal to its nesting level and after that only spaces should be used.
for example, the following code

for (i = 0; i < n; i++) printk("a very long format string", some, parameters);

should be formatted like this:

for (i = 0; i < n; i++)
printk("a very long format string",
   some, parameters);

this will show exactly right regardless of your editor's tab expansion setting
as long as you use fixed-width fonts - where the screen width of the space 
character
is equal to all other characters.  Once you start using tabs instead of spaces
to push text right so it appears exactly below some other text on the line above
you make a dependency on *your* editor's tab expansion policy and that's not 
very
considerate for folks who prefer a different one.


>>   
>>> By only using tabs as indents, and
>>> changing the CodeStyle to be something like "maximum 80
>>> characters-wide lines, with a tab-setting of 8 spaces",
>>> 
>> This changes nothing.
>>   
> Exactly! But then we can remove the "we use 8 wide tabs in the kernel" 
> in CodeStyle.
>>   
>>> that is
>>> possible + easier to write code-checkers [2].
>>> 
>> I doubt it.
>>   
> Easier to write code-checkers? OK, maybe not. Just that I got hit by 
> this problem at a time when I wrote a simple checker (don't remember its 
> purpose).
>>   
>>> Or are we really that concerned about the disk-space? ;)
>>> 
>> Unpacked sources will be much bigger with not tabs, sure.
>>   
> Without no tabs at all, you mean? Don't want to think about that 
> scenario, but with this suggestion, I would estimate maybe 0,5 - 1% bigger.
> 
> Thanks for your input
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG + PATCH/Bugfix] x86/lguest: fix pgdir pmd index calculation

[Ingo Molnar]

* Ahmed S. Darwish <[EMAIL PROTECTED]> wrote:

> I am not sure why the division over four existed in the first place. 
> It seems bogus, maybe the Xen patch just made the problem appear ?

i think so - nice detective work and nice fix!

I've picked up your patch into x86.git#testing (until Rusty picks it 
up), you can track it the following way:

http://people.redhat.com/mingo/x86.git/README

it has other lguest fixes as well - could you double-check that 
x86.git#testing works fine for you as-is? (i've just updated the git 
tree so it includes your fix as well)

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[BUG + PATCH/Bugfix] x86/lguest: fix pgdir pmd index calculation

[Ahmed S. Darwish]

Hi all,

Beginning from commits close to v2.6.25-rc2, running lguest always oopses
the host kernel. Oops is at [1].

Bisection led to the following commit:

commit 37cc8d7f963ba2deec29c9b68716944516a3244f

x86/early_ioremap: don't assume we're using swapper_pg_dir

At the early stages of boot, before the kernel pagetable has been
fully initialized, a Xen kernel will still be running off the
Xen-provided pagetables rather than swapper_pg_dir[].  Therefore,
readback cr3 to determine the base of the pagetable rather than
assuming swapper_pg_dir[].

 static inline pmd_t * __init early_ioremap_pmd(unsigned long addr)
 {
-   pgd_t *pgd = &swapper_pg_dir[pgd_index(addr)];
+   /* Don't assume we're using swapper_pg_dir at this point */
+   pgd_t *base = __va(read_cr3());
+   pgd_t *pgd = &base[pgd_index(addr)];
pud_t *pud = pud_offset(pgd, addr);
pmd_t *pmd = pmd_offset(pud, addr);
 
Trying to analyze the problem, it seems on the guest side of lguest, 
%cr3 has a different value from &swapper_pg-dir (which
is AFAIK fine on a pravirt guest): 

Putting some debugging messages in early_ioremap_pmd:

/* Appears 3 times */
[0.00] ***
[0.00] __va(%cr3) = c000, &swapper_pg_dir = c02cc000
[0.00] ***

After 8 hours of debugging and staring on lguest code, I noticed something
strange in paravirt_ops->set_pmd hypercall invocation:

static void lguest_set_pmd(pmd_t *pmdp, pmd_t pmdval)
{
*pmdp = pmdval; 
lazy_hcall(LHCALL_SET_PMD, __pa(pmdp)&PAGE_MASK,
   (__pa(pmdp)&(PAGE_SIZE-1))/4, 0);
}

The first hcall parameter is global pgdir which looks fine. The second
parameter is the pmd index in the pgdir which is suspectful.

AFAIK, calculating the index of pmd does not need a divisoin over four. 
Removing the division made lguest work fine again . Patch is at [2].

I am not sure why the division over four existed in the first place. It
seems bogus, maybe the Xen patch just made the problem appear ?

[2]: The patch:

[PATCH] lguest: fix pgdir pmd index cacluation

Remove an error in index calculation which leads to removing
a not existing shadow page table (leading to a Null dereference).

Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c
index 5afdde4..6636750 100644
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -489,7 +489,7 @@ static void lguest_set_pmd(pmd_t *pmdp, pmd_t pmdval)
 {
*pmdp = pmdval;
lazy_hcall(LHCALL_SET_PMD, __pa(pmdp)&PAGE_MASK,
-  (__pa(pmdp)&(PAGE_SIZE-1))/4, 0);
+  (__pa(pmdp)&(PAGE_SIZE-1)), 0);
 }
 
 /* There are a couple of legacy places where the kernel sets a PTE, but we


[1]: The oops:

[9.936880] BUG: unable to handle kernel NULL pointer dereference at 0ff8
[9.938015] IP: [] release_pgd+0x6/0x60
[9.938379] *pde =  
[9.938618] Oops:  [#1] 
[9.938680] Modules linked in:
[9.938680] 
[9.938680] Pid: 173, comm: lguest Not tainted (2.6.25-rc2-dirty #59)
[9.938680] EIP: 0060:[] EFLAGS: 0202 CPU: 0
[9.938680] EIP is at release_pgd+0x6/0x60
[9.938680] EAX: c7cfe000 EBX: c7d06fb8 ECX:  EDX: 0ff8
[9.938680] ESI: c7cfe004 EDI: 0ff8 EBP:  ESP: c7cebe5c
[9.938680]  DS: 007b ES: 007b FS:  GS: 0033 SS: 0058
[9.938680] Process lguest (pid: 173, ti=c7cea000 task=c7c94ac0 
task.ti=c7cea000)
[9.938680] Stack: c7d06fb8 c7cfe004 c7cfe004  c0204a61  
0246 0246 
[9.938680]c7cbd528 c10ed500 b5d65000 0002 c02110f4 076a8067 
c0151ccc c7cc8668 
[9.938680]01d65000 c7cbd528 0007 c7cc8668  b5d65000 
c01531b8 0246 
[9.938680] Call Trace:
[9.938680]  [] do_hcall+0x1a1/0x230
[9.938680]  [] _spin_unlock+0x14/0x20
[9.938680]  [] follow_page+0x9c/0x190
[9.938680]  [] get_user_pages+0x108/0x2c0
[9.938680]  [] copy_to_user+0x3f/0x70
[9.938680]  [] read+0x0/0xb8
[9.938680]  [] do_hypercalls+0xb9/0x2a0
[9.938680]  [] lguest_arch_run_guest+0xfa/0x1d0
[9.938680]  [] run_guest+0xc1/0x110
[9.938680]  [] read+0x0/0xb8
[9.938680]  [] run_guest+0x2b/0x110
[9.938680]  [] vfs_read+0x8f/0xc0
[9.938680]  [] sys_pread64+0x76/0x80
[9.938680]  [] sysenter_past_esp+0x6d/0xc5
[9.938680]  ===
[9.938680] Code: 75 03 5b c3 90 89 d8 e8 39 dc f0 ff 90 8b 1d d8 44 4f c0 
c1 e8 0c c1 e0 05 01 d8 5b e9 24 81 f4 ff 8d 74 26 00 55 57 89 d7 56 53 <8b> 02 
e8 f3 db f0 ff 90 a8 01 74 3f 8b 07 e8 e7 db f0 ff 90 25 
[9.938680] EIP: [] release_pgd+0x6/0x60 SS:ESP 0058:c7cebe5c
[9.939759] ---[ end trace 0cda9e589a597173 ]---

Regards,

-- 

"Better to light a candle, than curse the darkness"

Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

--
To unsubscribe from

Re: [PATCHv4 2.6.25] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers

[Jon Smirl]

On 2/22/08, Jochen Friedrich <[EMAIL PROTECTED]> wrote:
> Hi Jean,
>
>
>  >> +/*
>  >> + * Wait for patch from Jon Smirl
>  >> + * #include "powerpc-common.h"
>  >> + */
>  >
>  > It doesn't make sense to merge this comment upstream.
>
>
> I know you don't like the patch from Jon Smirl and you also explained your 
> reasons.
>  Fortunately, I2c no longer uses numeric device IDs but names. So what are 
> the alternatives?
>
>  1. modify the I2c subsystem to accept OF names additionally to I2c names 
> (proposed by Jon smirl).

The correct statement is: modify the i2c subsystem to support the
standard kernel driver aliasing mechanism. Leaving powerpc and OF out
of the argument for the moment, i2c has a custom aliasing scheme on
the x86 too.

So as a first step, can we remove the custom i2c aliasing scheme and
change i2c to use standard module aliases on the x86? Patches for this
already exist.

On 2/23/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
> The problem I have with this is that it breaks compatibility. The chip
>  name is not only used for device/driver matching, it is also exported
>  to userspace as a sysfs attribute ("name"). Applications might rely on
>  it. At least libsensors does.

I think there is some confusion here. The OF aliases are only used by
the kernel to load the correct driver. Would doing something like this
help?

static struct i2c_device_id pcf8563_id[] = {
{"pcf8563", 0, "sysfs_legacy_name"},
{"rtc8564", 0, "sysfs_legacy_name"},
OF_ID("phillips,pcf8563", &pcf8563_id[0], 0)
OF_ID("epson,rtc8564", &pcf8563_id[1], 0)
{},
};
MODULE_DEVICE_TABLE(i2c, pcf8563_id);

Then in the probe function you can use the pointer to find the base id
entry and i2c never has to be aware that the OF alias exists.

>  2. record the I2c name in the dts tree, either as separate tag (like 
> linux,i2c-name="")

Not really practical for the millions of machines (all PowerPC Macs)
already shipped.

>or as additional compatible entry (like compatible="...", 
> "linux,").
>  3. use a glue layer with a translation map.

Audio codecs have exactly the same problem. There are probably other
devices that also need mapping.

This mapping table will need to contain a map from the OF names to the
kernel driver names.  It will need to stored permanently in RAM and
contain all possible mappings. This table will only grow in size.

The kernel has a widely used mechanism for mapping -- aliases in the
device drivers. Why do we want to build a new, parallel one?

What we are doing now is option 4.

4. Use kconfig to build custom kernels for each target system. Don't
load drivers automatically based on what the BIOS tells us.

-- 
Jon Smirl
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix the bcm43xx driver breakage in 2.6.24/25.

[Larry Finger]

Alexey Zaytsev wrote:


[resent with lkml added to cc, sorry]

Hello, gentlemen.

Theese two patches fix a problem instroduced in Linux 2.6.24, and
still present in the current Linus' 2.6.25 tree.

The bcm43xx Wifi driver won't work any more, if the b44 Ethernet
driver is enabled. This happens because the b44 driver
needlessly enables the b43_pci_bridge code, which claims
the same pci ids as the bcm43xx driver. The b43_pci_bridge
code is needed for the b43{legacy} drivers, but for the
b44, only the "ssb pci core" is needed.

The first patch separates the ssb b43 pci bridge and the ssb pci
core config options and enables only the needed ones.

A similar patch was once sent to Michael Buesch, but he rejected
it, fearing that changing the config autoselects cold introduce
some unexpected bugs.
If you are intrested, a rather emotional thread may be found
e.g. here:
http://thread.gmane.org/gmane.linux.kernel/644266

That said, I believe the patch may introduce no more bugs,
but fixes a critical regression, which left some users
without a working wifi driver on the 2.6.24 kernel.

If you doubt its correctness, I may write a longer description
on the changes introduced, but I hope they should be obvoius.

This patch is againts the current Linus' tree. I'd like it
to be added to both 2.6.25 and the 2.6.24-stable trees.

The second patch disables the bcm43xx driver if it can't
work due to the b43/b43legacy drivers inclusion, so no
users should be confused.


I have reviewed the above patches and tested them with what I believe to be most combinations. 
Everything worked and corrected the unintended consequence of breaking bcm43xx when b44 is included. 
I agree that these patches belong in 2.6.25 and stable (2.6.24). Of course, the problem goes away in 
2.6.26.


ACKED-by: [EMAIL PROTECTED]

Larry

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG + PATCH/Bugfix] x86/lguest: fix pgdir pmd index calculation

[Ahmed S. Darwish]

On Sun, Feb 24, 2008 at 05:18:14PM +0100, Ingo Molnar wrote:
> 
> * Ahmed S. Darwish <[EMAIL PROTECTED]> wrote:
> 
> > I am not sure why the division over four existed in the first place. 
> > It seems bogus, maybe the Xen patch just made the problem appear ?
> 
> i think so - nice detective work and nice fix!
> 

Thanks!. Your turn-around time is super, which is so nice too ;).

> I've picked up your patch into x86.git#testing (until Rusty picks it 
> up), you can track it the following way:
> 
> http://people.redhat.com/mingo/x86.git/README
> 
> it has other lguest fixes as well - could you double-check that 
> x86.git#testing works fine for you as-is? (i've just updated the git 
> tree so it includes your fix as well)
> 

Ofcourse. I'll send you the results by GMT night.

Regards,

-- 

"Better to light a candle, than curse the darkness"

Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/2] x86,fpu: split FPU state from task struct

[Siddha, Suresh B]

On Sun, Feb 24, 2008 at 08:27:30AM +0100, Roger While wrote:
> 
> On Sat, Feb 23, 2008 at 06:34:38PM -0800, Suresh Siddha wrote:
> > Split the FPU save area from the task struct. This allows easy migration
> > of FPU context, and it's generally cleaner. It also allows the following
> > two optimizations:
> >
> > 1) only allocate when the application actually uses FPU, so in the first
> > lazy FPU trap. This could save memory for non-fpu using apps. Next patch
> > does this lazy allocation.
> >
> > 2) allocate the right size for the actual cpu rather than 512 bytes 
> always.
> > Patches enabling xsave/xrstor support (coming shortly) will take advantage
> > of this.
> 
> > if (next_p->fpu_counter>5)
> > -   prefetch(&next->i387.fxsave);
> > +   prefetch(FXSAVE(next_p));
> 
> Shouldn't that be  prefetch(FXSAVE(next));  ?

No. 'next_p' which is the task_struct is what FXSAVE macro takes.

thanks,
suresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fixed PATCH] hpt366: fix section mismatch warnings

[Bartlomiej Zolnierkiewicz]

On Saturday 23 February 2008, Sam Ravnborg wrote:
> hpt366: fix section mismatch warnings
> 
> Fix following warnings:
> WARNING: o-sparc64/vmlinux.o(.data+0x195a38): Section mismatch in reference 
> from the variable hpt37x_info.0 to the variable .devinit.data:hpt370
> WARNING: o-sparc64/vmlinux.o(.data+0x195a40): Section mismatch in reference 
> from the variable hpt37x_info.0 to the variable .devinit.data:hpt370a
> WARNING: o-sparc64/vmlinux.o(.data+0x195a48): Section mismatch in reference 
> from the variable hpt37x_info.0 to the variable .devinit.data:hpt372
> WARNING: o-sparc64/vmlinux.o(.data+0x195a50): Section mismatch in reference 
> from the variable hpt37x_info.0 to the variable .devinit.data:hpt372n
> 
> Replace a static array with a small switch resulting in
> more readable code.
> Mark the pci table __devinitconst.
> 
> A lot of variables are const but annotated __devinitdata.
> Annotating them __devinitconst would cause a section type
> conflict error when build for 64 bit powerpc.
> 
> Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
> Cc: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
> Cc: Sergei Shtylyov <[EMAIL PROTECTED]>
> ---

thanks, applied

> The first patch I posted caused a section type conflict when
> build for 64 bit powerpc. The actual cause of this is know and unavoidable
> when we start to declare variables const.
> The patch attached is much simpler as the transition from __devinitdata
> to __devinitconst turned out to be bogus.

Weird, I thought that the main purpose of __devinitconst was to replace
const + __devinitdata?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/10] IDE: Coding Style Fixes

[Bartlomiej Zolnierkiewicz]

On Saturday 23 February 2008, Paolo Ciarrocchi wrote:
> Hi Bartlomiej,
> The following 10 patches remove a huge number of errors and warnings
> reported by checkpatch.pl from the IDE subsystem.

[...]

Thanks!

I applied everything (patch #8 with fixes based on comments from
Adrian & Cyrill + patches #1/2/4/5 also with some improvements)
and verified that md5sums for the resulting binary files remain
the same.

Bart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.25-rc1/2 CD/DVD burning broken

[Borislav Petkov]

On Sat, Feb 23, 2008 at 04:47:50PM +0100, Andreas Schwab wrote:
> Kiyoshi Ueda <[EMAIL PROTECTED]> writes:
> 
> > Could you try this patch?
> > I've only done a compile test, so this patch may not work.
> 
> Unfortunately, that is not enough to get DVD burning working again.
> This is the error that growisofs is getting:
> 
> ioctl(6, SG_IO, {'S', SG_DXFER_TO_DEV, cmd[10]=[2a, 00, 00, 00, 03, 10, 00, 
> 00, 10, 00], mx_sb_len=64, iovec_count=0, dxfer_len=32768, timeout=6, 
> flags=0x3, 
> data[32768]=["\360R\360\314Wt\277\241\36.\347\356L$\201]\210\372_~]I\213\366\253SV\2\372\356\312\257"...],
>  status=02, masked_status=01, sb[0]=[], host_status=0, driver_status=0, 
> resid=32768, duration=0, info=0x1}) = 0
> write(2, ":-( unable to [EMAIL PROTECTED]: ", 30) = 30
> 
> It looks like the sense buffer is not filled in.  In a successfully run
> of growisfs under 2.6.24.2 the sense code is "LONG WRITE IN PROGRESS".
> 
> I also see that resid always equals dxfer_len even when the transfer was
> successful, although growisofs does not seem to care.  With 2.6.24.2
> resid is only non-zero when a sense error occurred.

Hm, strange,

burning a dvd here with growisofs works just fine. However, my
strace -v won't dereference the struct pointer passed to the ioctl:

...
open("/dev/dvd", O_RDWR|O_NONBLOCK|O_LARGEFILE) = 5
...
ioctl(5, SG_IO, 0xbf804d14) = 0
...
-- 
Regards/Gruß,
Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] IDE: new series of Coding Style Fixes

[Bartlomiej Zolnierkiewicz]

On Saturday 23 February 2008, Paolo Ciarrocchi wrote:
> Bart,
> here is a new series of patches that remove some errors
> and warnings reported by checkpatch.pl from the IDE subsystem.
> 
> All the patches have been compile tested and are against this morning (CET 
> time :-)
> linux-next
> 
> Paolo Ciarrocchi (6):
>   IDE: Coding Style fixes to drivers/ide/pci/opti621.c
>   IDE: Coding Style fixes to drivers/ide/legacy/hd.c
>   IDE: Coding Style fixes to drivers/ide/legacy/ali14xx.c
>   IDE: Coding Style fixes to drivers/ide/pci/it8213.c

the above change (patch 4/6) seems to be m.i.a. ?

>   IDE: Coding Style fixes to drivers/ide/ide-floppy.c
>   IDE: Coding Style fixes to drivers/ide/pci/cmd640.c
> 
>  drivers/ide/ide-floppy.c |4 +-
>  drivers/ide/legacy/ali14xx.c |   11 +++--
>  drivers/ide/legacy/hd.c  |   79 ++--
>  drivers/ide/pci/cmd640.c |   90 
> +-
>  drivers/ide/pci/it8213.c |9 ++--
>  drivers/ide/pci/opti621.c|   50 
>  6 files changed, 122 insertions(+), 121 deletions(-)

I applied all the rest (some with minor fixes).

Thanks,
Bart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: add the debugfs interface for the sysprof tool

[John Levon]

On Sun, Feb 24, 2008 at 08:10:02AM -0500, Theodore Tso wrote:

> > Firstly, the distributions should have set this up automatically. That
> > they don't is a distributor bug. The sheer madness of Linux not leaving
> > a vmlinux file in a stable known location is hardly something oprofile
> > can be blamed for.
> 
> Wrong Answer.  People who write userspace helpers *have* to do the
> work of the distro's.  It's a bad, bad, bad, Bad, BAD idea to leave it
> up to the distributions.  It means that some distributions won't get
> it right; other distributions will do it in different ways, making it
> harder for users to switch between distro's and making it harder for
> people to write distribution-neutral HOWTO's.

Hi Ted. I would have loved to have fixed it myself, or had one of the
other oprofile contributors do so. Unfortunately I have no control over
what the distributions do. For example:

https://bugzilla.redhat.com/show_bug.cgi?id=139767

> There are plenty of things that can be done, including using search
> paths to try to find vmlinuz; or maybe even proposing a new standard
> such as say for example /lib/modules/`uname -r`/vmlinux being a

At the time when I was trying to fix this, I wasn't aware of any way to
propose a new standard and get distributions to follow it - is there
some way now? Informally I discussed this problem several times with
many people without any resolution. As regards searching informal paths,
this is extremely risky - get the wrong vmlinux and we end up with
inaccurate results, which is worse than no results.

> The abdication of responsibility and the lack of trying to solve the
> usability issues is one of the things that really worries me about
> *all* of Linux's RAS tools.  We can and should do better!  And it's
> really embarassing that the RAS maintainers seem (I assume you are one
> of the oprofile maintainers), seem to be blaming this on the victims,
> the people who are complaining about using *your* tool.  Yes, it's a

I'm not abdicating responsibility: I no longer maintain oprofile,
haven't for a long time, and the other contributors don't have any real
time to spend on it either.  I'm well aware there are improvements to be
made: when I (and others) had time, this stuff was improving massively
with each release. When Soren et al had a need for a simple tool + GUI,
they should have helped out with this: it's simply good engineering to
not duplicate efforts. I didn't even get a /single/ email.

regards,
john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/2] x86,fpu: split FPU state from task struct

[Siddha, Suresh B]

On Sun, Feb 24, 2008 at 08:22:02AM +0100, Ingo Molnar wrote:
> 
> * Suresh Siddha <[EMAIL PROTECTED]> wrote:
> 
> > Split the FPU save area from the task struct. This allows easy 
> > migration of FPU context, and it's generally cleaner. It also allows 
> > the following two optimizations:
> > 
> > 1) only allocate when the application actually uses FPU, so in the 
> > first lazy FPU trap. This could save memory for non-fpu using apps. 
> > Next patch does this lazy allocation.
> > 
> > 2) allocate the right size for the actual cpu rather than 512 bytes 
> > always. Patches enabling xsave/xrstor support (coming shortly) will 
> > take advantage of this.
> 
> i like the concept. Please clean up the issues found by Christoph and 
> please also base it against x86.git#testing [this is clear 2.6.26 
> material and there are already some changes in this area]:
> 
>http://people.redhat.com/mingo/x86.git/README

Sure. Will do that in a day.

thanks,
suresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: fix build on non-C locales.

[Priit Laes]

Ühel kenal päeval, P, 2008-02-24 kell 10:03, kirjutas Sam Ravnborg:
> Hi Prit.
> 
> Could we just use [[:alnum:]] and drop the setting of LC_ALL?
Yes, it works. Reverted the previous patch and did this:

diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
index f385a4b..b8bd0c4 100644
--- a/arch/x86/vdso/Makefile
+++ b/arch/x86/vdso/Makefile
@@ -48,7 +48,7 @@ obj-$(VDSO64-y)   += vdso-syms.lds
 # Match symbols in the DSO that look like VDSO*; produce a file of
constants.
 #
 sed-vdsosym := -e 's/^00*/0/' \
-   -e 's/^\([0-9a-fA-F]*\) . \(VDSO[a-zA-Z0-9_]*\)$$/\2 = 0x\1;/p'
+   -e 's/^\([[:xdigit:]]*\) . \(VDSO[[:alnum:]_]*\)$$/\2 = 0x\1;/p'
 quiet_cmd_vdsosym = VDSOSYM $@
   cmd_vdsosym = $(NM) $< | sed -n $(sed-vdsosym) | LC_ALL=C sort >
$@

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 2/2] x86,fpu: lazy allocation of FPU area

[Siddha, Suresh B]

On Sun, Feb 24, 2008 at 01:20:05PM +0100, Andi Kleen wrote:
> On Sat, Feb 23, 2008 at 06:34:39PM -0800, Suresh Siddha wrote:
> > Only allocate the FPU area when the application actually uses FPU, i.e., in 
> > the
> > first lazy FPU trap. This could save memory for non-fpu using apps.
> 
> Did you measure this making any difference? 
> 
> At least at some point glibc always touched the FPU once to initialize
> it.

Simple kernel boot showed that only 20 or so tasks using FPU, out of 
200 or so tasks running.

thanks,
suresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: bcm43xx regression in 2.6.24 (with patch)

[Alexey Zaytsev]

On Sun, Feb 24, 2008 at 5:29 PM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> On Saturday 23 February 2008 12:32:50 Alexey Zaytsev wrote:
>  > The problem is not with enabling both b43 and bcm43xx (will, whis won't 
> work
>  > anyway, and there is no chance fixing it). The problem is with enabling the
>  > bcm43xx wifi driver and the b44 Ethernet driver. The ethernet driver then
>  > wrongly autosolects some config options that prevent the bcm43xx
>  > driver from loading, so I'm left with either no wifi or no ethenet.
>
>  Ok, so I just tested this on a machine and it is _not_ true.
>  It works just fine to run b44/ssb with bcm43xx in parallel.
>
>  Can you please stop fooling me and spreading this FUD?
>

The ony way I see this was possible, you manually changed the
module loading order, so that the b43xx module was loaded prior
to the ssb and b44 modules. Right? Or the b43xx driver was built
statically and the b44 and the ssb as modules.

Looks like this, kind of, ruins my statement that is is impossible to get
working wifi in 2.6.24. Sorry, it was not intensinal. ;)

But there still are lots of valid combinations where the b43xx driver
silently won't work. E.g. when either the ssb or the b44 modules are
loaded prior to it, or when either of them are built statically (building
the b43xx driver staticaly won't help here). And my patch fixes them.

So, my statement goes, the bug stays. Agreed?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.25-rc1/2 CD/DVD burning broken

[Andreas Schwab]

Borislav Petkov <[EMAIL PROTECTED]> writes:

> burning a dvd here with growisofs works just fine.

You probably don't have a Pioneer.

> However, my strace -v won't dereference the struct pointer passed to
> the ioctl:

I use strace 4.5.16.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.24.2: 4KSTACKS + pcdrw + dm + mount -> stack overflow: ide-cd related? dm-related?

[Nix]

On 24 Feb 2008, Peter Osterlund told this:

> Nix <[EMAIL PROTECTED]> writes:
>> But while I'd normally blame pktcdvd there's only one pktcdvd function
>> in these tracebacks (pkt_open) and it's not got a significant stack
>> footprint.
>
> Did you verify that with "make checkstack" or just by looking at the
> source code? On my system, pkt_open() consumes 584 bytes because the
> compiler decides to inline lots of functions that would not normally
> be part of long call chains. The following patch fixes that problem on
> my system.

I just looked at the source; I forgot `make checkstack' existed.

On this system:

0xc0263e0f pkt_open [vmlinux]:  556

which is nearly as bad.

(As an aside, I'm surprised I didn't oops when packet-writing as well:

0xc021270d udf_process_sequence [vmlinux]:  692
0xc020f43d udf_add_entry [vmlinux]: 628

owch. I guess that's called via a shorter call chain...)


I'll try the patch after this series of backups is done :)

-- 
`The rest is a tale of post and counter-post.' --- Ian Rawlings
   describes USENET
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] mmiotrace full patch, preview 1

[Pekka Paalanen]

Hi all,

I have finally got kmmio.c into shape so that it is built in when mmiotrace
is built. I'd like to hear your comments on kmmio.c.

kmmio.c handles the list of mmio probes with callbacks, list of traced
pages, and attaching into the page fault handler and die notifier. It
arms, traps and disarms the given pages, this is the core of mmiotrace.

mmio-mod.c is a user interface, hooking into ioremap functions and
registering the mmio probes. It also decodes the required information
from trapped mmio accesses via the pre and post callbacks in each probe.
Currently, hooking into ioremap functions works by redefining the symbols
of the target (binary) kernel module, so that it calls the traced
versions of the functions.

The most notable changes done since the last discussion are:
- kmmio.c is a built-in, not part of the module
- direct call from fault.c to kmmio.c, removing all dynamic hooks
- prepare for unregistering probes at any time
- make kmmio re-initializable and accessible to more than one user
- rewrite kmmio locking to remove all spinlocks from page fault path

Can I abuse call_rcu() like I do in kmmio.c:unregister_kmmio_probe()
or is there a better way?

The function called via call_rcu() itself calls call_rcu() again,
will this work or break? There I need a second grace period for RCU
after the first grace period for page faults.

Mmiotrace itself (mmio-mod.c) is still a module, I am going to attack
that next. At some point I will start looking into how to make mmiotrace
a tracer component of ftrace (thanks for the hint, Ingo). Ftrace should
make the user space part of mmiotracing as simple as
'cat /debug/trace/mmio > dump.txt'.

Ftrace lives in sched-devel
http://people.redhat.com/mingo/sched-devel.git/README
and I have nothing for that yet.

This patch is against torvalds/linux-2.6.git master.

Home page of the out-of-tree version:
http://nouveau.freedesktop.org/wiki/MmioTrace


Thanks, Pekka.

 arch/x86/Kconfig.debug  |   33 +++
 arch/x86/mm/Makefile|5 +
 arch/x86/mm/fault.c |   13 +
 arch/x86/mm/kmmio.c |  541 +++
 arch/x86/mm/mmio-mod.c  |  541 +++
 arch/x86/mm/pageattr.c  |1 +
 arch/x86/mm/pf_in.c |  489 ++
 arch/x86/mm/pf_in.h |   39 +++
 arch/x86/mm/testmmiotrace.c |   76 ++
 include/linux/mmiotrace.h   |  104 +
 10 files changed, 1842 insertions(+), 0 deletions(-)

diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 702eb39..ef73cdd 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -134,6 +134,39 @@ config IOMMU_LEAK
  Add a simple leak tracer to the IOMMU code. This is useful when you
  are debugging a buggy device driver that leaks IOMMU mappings.
 
+config MMIOTRACE_HOOKS
+   bool
+   default n
+
+config MMIOTRACE
+   tristate "Memory mapped IO tracing"
+   depends on DEBUG_KERNEL && RELAY && DEBUG_FS
+   select MMIOTRACE_HOOKS
+   default n
+   help
+ This will build a kernel module called mmiotrace.
+ Making this a built-in is heavily discouraged.
+
+ Mmiotrace traces Memory Mapped I/O access and is meant for debugging
+ and reverse engineering. The kernel module offers wrapped
+ versions of the ioremap family of functions. The driver to be traced
+ must be modified to call these wrappers. A user space program is
+ required to collect the MMIO data.
+
+ See http://nouveau.freedesktop.org/wiki/MmioTrace
+ If you are not helping to develop drivers, say N.
+
+config MMIOTRACE_TEST
+   tristate "Test module for mmiotrace"
+   depends on MMIOTRACE && m
+   default n
+   help
+ This is a dumb module for testing mmiotrace. It is very dangerous
+ as it will write garbage to IO memory starting at a given address.
+ However, it should be safe to use on e.g. unused portion of VRAM.
+
+ Say N, unless you absolutely know what you are doing.
+
 #
 # IO delay types:
 #
diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile
index 9832910..e182f6d 100644
--- a/arch/x86/mm/Makefile
+++ b/arch/x86/mm/Makefile
@@ -3,3 +3,8 @@ include ${srctree}/arch/x86/mm/Makefile_32
 else
 include ${srctree}/arch/x86/mm/Makefile_64
 endif
+
+obj-$(CONFIG_MMIOTRACE_HOOKS)  += kmmio.o
+obj-$(CONFIG_MMIOTRACE)+= mmiotrace.o
+mmiotrace-objs := pf_in.o mmio-mod.o
+obj-$(CONFIG_MMIOTRACE_TEST)   += testmmiotrace.o
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index fdc6674..ba6d4c5 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -49,6 +50,16 @@
 #define PF_RSVD(1<<3)
 #define PF_INSTR   (1<<4)
 
+static inline int kmmio_fault(struct pt_regs *regs, unsigned long addr)
+{
+#ifdef CONFIG_MMIO

Re: [git patches] libata fixes

[Bartlomiej Zolnierkiewicz]

On Sunday 24 February 2008, Jeff Garzik wrote:

[...]

> Alan Cox (1):
>   pata_atiixp: Use 255 sector limit

AHCI needs sorting too but this deals with the old interface

Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>

[...]

>> diff --git a/drivers/ata/pata_atiixp.c b/drivers/ata/pata_atiixp.c
> index 9623f52..408bdc1 100644
> --- a/drivers/ata/pata_atiixp.c
> +++ b/drivers/ata/pata_atiixp.c
> @@ -227,7 +227,7 @@ static struct scsi_host_template atiixp_sht = {
>   .queuecommand   = ata_scsi_queuecmd,
>   .can_queue  = ATA_DEF_QUEUE,
>   .this_id= ATA_SHT_THIS_ID,
> - .sg_tablesize   = LIBATA_MAX_PRD,
> + .sg_tablesize   = LIBATA_DUMB_MAX_PRD,
>   .cmd_per_lun= ATA_SHT_CMD_PER_LUN,
>   .emulated   = ATA_SHT_EMULATED,
>   .use_clustering = ATA_SHT_USE_CLUSTERING,
> @@ -259,7 +259,7 @@ static struct ata_port_operations atiixp_port_ops = {
>   .bmdma_stop = atiixp_bmdma_stop,
>   .bmdma_status   = ata_bmdma_status,
>  
> - .qc_prep= ata_qc_prep,
> + .qc_prep= ata_dumb_qc_prep,
>   .qc_issue   = ata_qc_issue_prot,
>  
>   .data_xfer  = ata_data_xfer,

This patch doesn't enforce "255 sector limit" but instead:

- limits max PRD table size from 128 entries to 64

- enables quirk needed for some chipsets to split 64K PRD table entry
  on two 32K ones (these chipsets choke on size == 0x)

>From the patch description it can't be told whether the patch itself is
correct and only the patch description is bogus...

Alan/Jeff: please elaborate on what the patch is trying to achieve.

Thanks,
Bart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] DIGIEPCA: Remove long-obsolete digiepca driver.

[Alan Cox]

On Sun, 24 Feb 2008 10:12:41 -0500 (EST)
"Robert P. J. Day" <[EMAIL PROTECTED]> wrote:

> 
> Given that the removal of this driver has been under discussion for
> over a year:
> 
>   http://lkml.org/lkml/2006/10/26/231
> 
> it would seem time to get rid of it.

NAK - not until a replacement driver supporting the hardware is merged.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: bcm43xx regression in 2.6.24 (with patch)

[Michael Buesch]

On Sunday 24 February 2008, Alexey Zaytsev wrote:
> On Sun, Feb 24, 2008 at 5:29 PM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> > On Saturday 23 February 2008 12:32:50 Alexey Zaytsev wrote:
> >  > The problem is not with enabling both b43 and bcm43xx (will, whis won't 
> > work
> >  > anyway, and there is no chance fixing it). The problem is with enabling 
> > the
> >  > bcm43xx wifi driver and the b44 Ethernet driver. The ethernet driver then
> >  > wrongly autosolects some config options that prevent the bcm43xx
> >  > driver from loading, so I'm left with either no wifi or no ethenet.
> >
> >  Ok, so I just tested this on a machine and it is _not_ true.
> >  It works just fine to run b44/ssb with bcm43xx in parallel.
> >
> >  Can you please stop fooling me and spreading this FUD?
> >
> 
> The ony way I see this was possible, you manually changed the
> module loading order, so that the b43xx module was loaded prior
> to the ssb and b44 modules. Right?

Right. So "so I'm left with either no wifi or no ethenet" being wrong.

> Looks like this, kind of, ruins my statement that is is impossible to get
> working wifi in 2.6.24. Sorry, it was not intensinal. ;)

Ok, I see.

> But there still are lots of valid combinations where the b43xx driver
> silently won't work. E.g. when either the ssb or the b44 modules are
> loaded prior to it, or when either of them are built statically (building
> the b43xx driver staticaly won't help here). And my patch fixes them.

With your patch you can still artificially create situations that
something doesn't work.
My point being: It works just fine without the patch.
And as I'm not really sure about the implications of the patch, I
won't ack this. But it seems Larry acked it. So that's also fine, if
he takes over responsibility for that change then. So the next
"You broke my kernel!!11" round can go to his mail address and I won't
be bothered by this anymore. ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git patches] libata fixes

[Alan Cox]

> From the patch description it can't be told whether the patch itself is
> correct and only the patch description is bogus...

zero length PRD misparsing. If I remember rightly old IDE never generates
64K PRD slots because other hardware can't handle it either (CS5520/30
etc)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: fix build on non-C locales.

[Ingo Molnar]

* Priit Laes <[EMAIL PROTECTED]> wrote:

>  sed-vdsosym := -e 's/^00*/0/' \
> -   -e 's/^\([0-9a-fA-F]*\) . \(VDSO[a-zA-Z0-9_]*\)$$/\2 = 0x\1;/p'
> +   -e 's/^\([[:xdigit:]]*\) . \(VDSO[[:alnum:]_]*\)$$/\2 = 0x\1;/p'

thanks, i picked up this one instead of the first version.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git patches] libata fixes

[Bartlomiej Zolnierkiewicz]

On Sunday 24 February 2008, Alan Cox wrote:
> > From the patch description it can't be told whether the patch itself is
> > correct and only the patch description is bogus...
> 
> zero length PRD misparsing. If I remember rightly old IDE never generates
> 64K PRD slots because other hardware can't handle it either (CS5520/30
> etc)

OK, that would explain it.

Thanks,
Bart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] 2.6.25-rc2-git8 fails to boot on 486 due to TSC breakage

[Mikael Pettersson]

Mikael Pettersson writes:
 > Ingo Molnar writes:
 >  > 
 >  > * Mikael Pettersson <[EMAIL PROTECTED]> wrote:
 >  > 
 >  > > The kernel for this 486 has CONFIG_M486=y and CONFIG_M586TSC=n, but 
 >  > > the 2.6.25 kernels still try to access the TSC. Here's the oops from 
 >  > > 2.6.25-rc2-git8:
 >  > 
 >  > hm, could you send me the full .config you used?
 > 
 > I've put it here:
 > 
 > 
 > Meanwhile, I've traced the breakage to 2.6.24-git8.
 > 
 > 2.6.24-git8 changed include/asm-x86/tsc.h:get_cycles() to call
 > rdtscll() even if CONFIG_X86_TSC isn't set. The call is protected
 > by a cpu_has_tsc test, but starting with 2.6.24-git8 cpu_has_tsc
 > is non-zero on this machine, which is very very wrong.
 > 
 > Diffing dmesg between git7 and git8 doesn't sched any light since
 > git8 also removed the printouts of the x86 caps as they were being
 > initialised and updated. I'm currently adding those printouts back
 > in the hope of seeing where and when the caps get broken.

That turned out to be very illuminating:

--- dmesg-2.6.24-git7   2008-02-24 18:01:25.295851000 +0100
+++ dmesg-2.6.24-git8   2008-02-24 18:01:25.530358000 +0100
...
 CPU: After generic identify, caps: 0003    
   
 
 CPU: After all inits, caps: 0003     
  
+CPU: After applying cleared_cpu_caps, caps: 0013   
    

Notice how the TSC cap bit goes from Off to On.

(The first two lines are printout loops from -git7 forward-ported
to -git8, the third line is the same printout loop added just after
the xor-with-cleared_cpu_caps[] loop.)

Here's how the breakage occurs:
1. arch/x86/kernel/tsc_32.c:tsc_init() sees !cpu_has_tsc,
   so bails and calls setup_clear_cpu_cap(X86_FEATURE_TSC).
2. include/asm-x86/cpufeature.h:setup_clear_cpu_cap(bit) clears
   the bit in boot_cpu_data and sets it in cleared_cpu_caps
3. arch/x86/kernel/cpu/common.c:identify_cpu() XORs all caps
   in with cleared_cpu_caps
   HOWEVER, at this point c->x86_capability correctly has TSC
   Off, cleared_cpu_caps has TSC On, so the XOR incorrectly
   sets TSC to On in c->x86_capability, with disastrous results.

The real bug is that clearing bits with XOR only works if the
bits are known to be 1 prior to the XOR, and that's not true here.

A simple fix is to convert the XOR to AND-NOT instead. The following
patch does that, and allows my 486 to boot 2.6.25-rc kernels again.

Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
---
There's a similar XOR loop in arch/x86/kernel/setup_64.c.
I haven't seen it fail yet, but perhaps it should be changed
too, for robustness and symmetry.

--- linux-2.6.25-rc2-git8/arch/x86/kernel/cpu/common.c.~1~  2008-02-24 
17:42:56.0 +0100
+++ linux-2.6.25-rc2-git8/arch/x86/kernel/cpu/common.c  2008-02-24 
17:44:06.0 +0100
@@ -504,7 +504,7 @@ void __cpuinit identify_cpu(struct cpuin
 
/* Clear all flags overriden by options */
for (i = 0; i < NCAPINTS; i++)
-   c->x86_capability[i] ^= cleared_cpu_caps[i];
+   c->x86_capability[i] &= ~cleared_cpu_caps[i];
 
/* Init Machine Check Exception if available. */
mcheck_init(c);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Tabs, spaces, indent and 80 character lines

[Krzysztof Halasa]

Richard Knutsson <[EMAIL PROTECTED]> writes:

>> I guess we could use tabs only at the line start, for indentation
>> only. Rather hard to implement, most text editors can't do that yet.
>>   
> You mean for split lines?

Syntactic indentation vs alignment (including comments after
non-blank, values for struct initialization etc, split lines too).

> Hopefully there won't be that many, so there
> is just to delete the tabs it added and replace it with spaces.

Actually tabs "should" be used for indentation at start of the
line, then spaces. "Ideally" :-)

I.e., something like
   if (cond && (cond2 ||
   _cond3))
  do_something();

Underline = space.

Perhaps some day...

> Exactly! But then we can remove the "we use 8 wide tabs in the kernel"
> in CodeStyle.

I'm not sure it's practically possible now.

>> Unpacked sources will be much bigger with not tabs, sure.
>>   
> Without no tabs at all, you mean?

With spaces in place of all tabs.

All tabs converted to spaces = 20% more?
"Alignment" tabs converted to spaces? How cares how much more would it
take if it's the correct thing. Except that it's not very practical at
this point.
-- 
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Fix alignment of early reservation for EBDA

[Alexander van Heukelum]

Hi Andi,

My eyes fell on the following table in the boot messages:

early res: 0 [0-fff] BIOS data page
early res: 1 [6000-7fff] SMP_TRAMPOLINE
early res: 2 [20-374557] TEXT DATA BSS
early res: 3 [9fc00-a0bff] EBDA
early res: 4 [8000-afff] PGTABLE

The memory reserved for the EBDA overflows into the area normally
reserved for the VGA adaptor. It seems that you wanted to force
the allocation to cover whole pages, like:

early res: 3 [9f000-9] EBDA

This is what this patch implements.

Is it really necessary to force the allocation to a page boundary?


Signed-off-by: Alexander van Heukelum <[EMAIL PROTECTED]>

 arch/x86/kernel/head64.c |   12 +++-
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index ad24408..2c52543 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -53,7 +53,7 @@ static void __init copy_bootdata(char *real_mode_data)
 
 static __init void reserve_ebda(void)
 {
-   unsigned ebda_addr, ebda_size;
+   unsigned int ebda_addr, ebda_size, ebda_end;
 
/*
 * there is a real-mode segmented pointer pointing to the
@@ -70,12 +70,14 @@ static __init void reserve_ebda(void)
/* Round EBDA up to pages */
if (ebda_size == 0)
ebda_size = 1;
+   if (ebda_size > 64)
+   ebda_size = 64;
ebda_size <<= 10;
-   ebda_size = round_up(ebda_size + (ebda_addr & ~PAGE_MASK), PAGE_SIZE);
-   if (ebda_size > 64*1024)
-   ebda_size = 64*1024;
+   
+   ebda_end = ALIGN(ebda_addr + ebda_size, PAGE_SIZE);
+   ebda_addr = ALIGN(ebda_addr - PAGE_SIZE, PAGE_SIZE);
 
-   reserve_early(ebda_addr, ebda_addr + ebda_size, "EBDA");
+   reserve_early(ebda_addr, ebda_end, "EBDA");
 }
 
 void __init x86_64_start_kernel(char * real_mode_data)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 2.6.25-rc2-git 1/2] atmel_tc library

[Haavard Skinnemoen]

On Fri, 22 Feb 2008 17:23:23 -0800
David Brownell <[EMAIL PROTECTED]> wrote:

> Create  based on  and the
> at91sam9263 and at32ap7000 datasheets.  Most AT91 and AT32 SOCs have one
> or two of these TC blocks, which include three 16-bit timers that can be
> interconnected in various ways.
> 
> These TC blocks can be used for external interfacing (such as PWM and
> measurement), or used as somewhat quirky sixteen-bit timers.
> 
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>
> ---

Sorry for the delay...some late comments coming up.

> Note that this won't be usable until the AT91 and AT32 platforms
> incorporate patches to configure the relevant platform devices.
> Those changes are probably 2.6.26 material.

Right...and there are a few funny dependencies we need to watch out
for. AVR32 currently uses one of the TC blocks as a system timer. That
code needs to be ripped out, but that will cause a fourfold increase in
the power consumption of the AP7000 CPU. So I want to keep the window
between ripping out the old code and using the new code as small as
possible.

I see the following possibilities:
  * I switch avr32 over to use the new code after it has been merged
into mainline. This means the new code won't be tested on avr32
until near the end of the next merge window -- not good.
  * I forward the patches that switch avr32 over to Andrew so that they
can be included in -mm right after the tclib support. Not a bad
option, but I'm planning to do more AVR32 PM work before 2.6.26, so
there might be conflicts.
  * I take the whole thing through my avr32 git tree.
  * I (or someone else) set up a new git tree for tclib + AT91 and
AVR32 platform support and ask Stephen to pull it into the -next
tree. Or, once it's stable, rmk and I can both pull it into our
respective trees. But that obviously means no rebasing and funny
games from that point on...

I think the last option is the best one. What do you think?

> +#if defined(CONFIG_AVR32)
> +/* AVR32 has these divide PBB */
> +const u8 atmel_tc_divisors[5] = { 0, 4, 8, 16, 32, };
> +EXPORT_SYMBOL(atmel_tc_divisors);
> +
> +#elif defined(CONFIG_ARCH_AT91)
> +/* AT91 has these divide MCK */
> +const u8 atmel_tc_divisors[5] = { 2, 8, 32, 128, 0, };
> +EXPORT_SYMBOL(atmel_tc_divisors);
> +
> +#endif
> +
> +/* we "know" that there will be either one or two TC blocks */
> +static struct platform_device *blocks[2];

You seem to know more about future Atmel chips than I do :-P

I'm not a huge fan of such static limitations. Is there any way we can
turn it into a list? That probably means defining a struct atmel_tc
around each platform_device, but that might be nice to have for other
reasons too.

> +/**
> + * atmel_tc_alloc - allocate a specified TC block
> + * @block: which block to allocate
> + * @iomem: used to return its IO memory resource
> + *
> + * Caller allocates a block.  If it is available, its I/O space is requested
> + * and returned through the iomem pointer, and the device node for the block
> + * is returned.  When it is not available, NULL is returned.

Any reason why it can't ioremap() the registers as well? Most drivers
probably want that.

> + * On some platforms, each TC channel has its own clocks and IRQs.  Drivers
> + * should clk_get() and clk_enable() "t0_clk", "t1_clk, and "t2_clk".
> + * In the same vein, they should platform_get_irq() for irqs 0, 1, and 2.
> + * On other platforms, only irq 0 and "t0_clk" will be available; drivers
> + * should handle with both configurations.

Sounds complicated. I think it would be better if tclib did all the
clk_get() calls and stored each clock into the atmel_tc struct so that
the driver can simply clk_enable() each channel (which may point to the
same clock.)

> +struct platform_device *atmel_tc_alloc(unsigned block, struct resource 
> **iomem)
> +{
> + struct platform_device  *tc;
> + struct resource *r;
> +
> + if (block >= ARRAY_SIZE(blocks) || !iomem)
> + return NULL;
> +
> + tc = blocks[block];
> + if (tc) {
> + r = platform_get_resource(tc, IORESOURCE_MEM, 0);
> + if (r)
> + r = request_mem_region(r->start, 256, NULL);

Shouldn't you use the real resource size instead of some magic number?

> +static struct platform_driver tc_driver = {
> + .driver.name= "atmel_tcb",

Wow, I didn't know that was possible...

> +#define ATMEL_TC_BMR 0xc4/* TC Block Mode Register */
> +#define ATMEL_TC_TC0XC0S (3 << 0)/* external clock 0 source */
> +#defineATMEL_TC_TC0XC0S_TCLK0(0 << 0)

Hmm. Indentation using spaces? I didn't know you were into that sort of
thing ;-)

Anyway, my main issue is that I think we should add a data structure
with information about each device, similar to struct ssc_device in the
atmel-ssc driver. How about something like this?

struct atmel_tc_block {
void __iomem*regs;  /* non-NULL when busy */
  

Re: IDE cdrom problem with PLEXTOR DVDR PX-608AL

[Borislav Petkov]

On Sun, Feb 24, 2008 at 03:38:34PM +1000, Brad Rosser wrote:

[ Added Bart to CC: ]

Hi Brad,

> Borislav Petkov wrote:
> 
> > > Feb 14 00:18:18 kernel: hde: cdrom_pc_intr: The drive appears confused 
> > > (ireason = 0x01).
> > > Trying to recover by ending request.
> > > Feb 14 00:27:27 kernel: hdc: cdrom_pc_intr: The drive appears confused 
> > > (ireason = 0x01).
> > > Trying to recover by ending request.
> > >
> > > ~> uname -a
> > > Linux xrated 2.6.24.1-35-pae #1 SMP 2008/02/12 01:00:18 UTC i686 athlon 
> > > i386 GNU/Linux
> >
> > Actually the interrupt handler in ide-cd got rewritten and you're still 
> > using the
> > old one (cdrom_pc_intr vs cdrom_newpc_intr). Those changes went into 
> > mainline before
> > the 2.6.25-rc1 so we'll be able to test the new one only when you try out 
> > 2.6.25-rc1
> > or wait until 2.6.25 is released in case you don't want to try hazardous 
> > materials
> > such as an -rc kernel[*] :).
> 
> I have exactly the same problem.  I have a two-month old PC with a
> Gigabyte P35-DS4
> motherboard, which has the Intel P35 chipset with ICH10 south bridge and
> additional JMicron IDE/SATA controller.  I have two SATA-II hard disks
> and a sole
> IDE device, a Pioneer DVR-115D DVD-ROM, hooked up to the JMicron IDE port.
> The motherboard also has an embedded Realtek RTL8111/8168B gigabit
> ethernet controller.
> 
> The motherboard/bios assigns both the JMicron IDE controller and the Realtek
> controller to the same interrupt - typically '15'.  There's nothing in
> the bios that
> allows me to move one away from the other.  I can 'reserve' or block IRQs, but
> that only shifts them both to another interrupt.

well the driver probes the bios for that data and assigns the irq line it gets
from it.

> Similarly, no matter what I do with the Linux kernel, using boot parameters 
> such
> as 'acpi=off', 'noapic', 'nolapic' and the like, I can never get the
> kernel to use
> different interrupts for these two controllers.  A 'cat
> /proc/interrupts' always shows
> them sharing their IRQ:
> 
>   # grep ide /proc/interrupts
>   17:   58077   4   98999   129160   IO-APIC-fasteoi   ide0, eth0
> 
> With the IDE driver compiled into the kernel any access to the DVD is fine
> until I start using the network.  Upon any network activity I get the 
> 'confused'
> messages and more:
> 
> kernel: hda: cdrom_pc_intr: The drive appears confused (ireason =
> 0x01). Trying to recover by ending request.
> last message repeated 3 times
> kernel: ide: failed opcode was: unknown
> kernel: hda: drive not ready for command
> kernel: hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> 
> KDE even kindly pops up a window telling me that someone has inserted a 
> (ghost)
> DVD disc, would I care to play it?  :-(
> 
> I know nothing of modern/PCI hardware and their interrupt magic, but it seemed
> to me that the IDE driver was erroneously picking up the interrupts destined 
> for
> the Realtek NIC and thinking they were for it.  Unfortunately there seemed to 
> be
> no way for me to separate the two or get the IDE driver its own IRQ, either 
> via
> the PC's bios or linux kernel boot parameters.
> 
> When I saw the recent message from Hans-Peter Jansen about this exact
> problem, and Boris's comment that something in interrupt land for the
> CD driver had been fixed, I thought the latest version of the kernel would
> rectify matters.  I installed the 2.6.25-rc2 kernel from kernel.org
> but the problem
> is still there.

Can you please send me your whole boot log of 2.6.25-rc2? Thanks.

> 
> As a workaround I've disabled IDE entirely in my kernel build and am using
> sr_mod to present the DVD as /dev/sr0.
> 
> As a result of all this I've got several novice questions relating to
> this matter.
> I don't know if this mailing list is an appropriate place to ask them
> .. my apologies
> if not.  Any quick references to reference material would be appreciated.
> 
> Given all the kernel parameters to change IRQ routing and turn ACPI actions
> up, down and sideways, is there any way to tell it to assign an explicit
> IRQ to a device?  Or have it that the IDE driver doesn't share?  I thought
> CONFIG_IDEPCI_SHARE_IRQ might have something to do with it, but fiddling
> the value for that had no effect.  It 'feels' to me that all these IRQs seem 
> to
> be highly adjustable by the kernel, so I was hoping there'd be a way to
> let the IDE driver have one to itself.
> 
> Is there any way to leave the IDE driver compiled into the kernel but tell
> it to leave the DVD-ROM drive alone, so sr_mod can claim it rather than
> ide-cd?  I couldn't do it with my kernel, but I think Ubuntu (7.10) does
> manage it.  I tried various kernel boot parameters like 'hda=scsi' or
> 'hda=ide-scsi' but nothing seemed to work.  It would be nice to be able
> to use IDE hard disks while leaving the DVD-ROM to sr_mod until this
> problem is resolved.

since your cdrom seems to be hda from what i've seen above, try booting