date:20080103

* Matt Mackall <[EMAIL PROTECTED]> wrote:

> > Which means that SLOB could also trivially implement the same thing, 
> > with no new #ifdef'fery or other crud.
> 
> Except SLOB's emulation of slabs is so thin, it doesn't have the 
> relevant information. We have a very small struct kmem_cache, which I 
> suppose could contain a counter. But we don't have anything like the 
> kmalloc slabs, so you'd only be getting half the picture anyway. The 
> output of slabtop would simply be misleading because there are no 
> underlying "slabs" in the first place.

i think SLOB/embedded is sufficiently special that a "no /proc/slabinfo" 
restriction is perfectly supportable. (for instance it's only selectable 
if CONFIG_EMBEDDED=y) If a SLOB user has any memory allocation problems 
it's worth going to the bigger allocators anyway, to get all the 
debugging goodies.

btw., do you think it would be worth/possible to have build mode for 
SLUB that is acceptably close to the memory efficiency of SLOB? (and 
hence work towards unifying all the 3 allocators into SLUB in essence)

right now we are far away from it - SLUB has an order of magnitude 
larger .o than SLOB, even on UP. I'm wondering why that is so - SLUB's 
data structures _are_ quite compact and could in theory be used in a 
SLOB-alike way. Perhaps one problem is that much of SLUB's debugging 
code is always built in?

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: [PATCH] x86_64: not clear empty_zero_page again


* Yinghai Lu <[EMAIL PROTECTED]> wrote:

> [PATCH] x86_64: not clear empty_zero_page again
> 
> empty_zero_page is in .bss section, and it is cleared in clear_bss by 
> x86_64_start_kernel. So don't clear that again in mem_init

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/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

2008-01-03 Thread Mikael Pettersson

Linda Walsh writes:
 > Robert Hancock wrote:
 > > Linda Walsh wrote:
 > >> Alan Cox wrote:
 >  rate began falling; at 128k block-reads-at-a-time or larger, it 
 >  drops below
 >  20MB/s (only on buffered SATA).
 > >>> Try disabling NCQ - see if you've got a drive with the 'NCQ = no
 > >>> readahead' flaw.
 > > http://linux-ata.org/faq.html#ncq
 > ---
 > When drive initializes, dmesg says it has NCQ (depth 0/32)
 > Reading the queue_depth under /sys, shows a queuedepth of "1".
 > 
 > But more importantly -- I notice a chronic error message associate
 > with this drive that may be causing some or all of the problem:
 > ---
 > Jan  2 20:06:10 Ishtar kernel: ata1.00: exception Emask 0x0 SAct 0x0 
 > SErr 0x0 action 0x2
 > Jan  2 20:06:10 Ishtar kernel: ata1.00: port_status 0x2008
 > Jan  2 20:06:10 Ishtar kernel: ata1.00: cmd 
 > c8/00:10:30:06:03/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192 in
 > Jan  2 20:06:10 Ishtar kernel:  res 
 > 50/00:00:3f:06:03/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
 > Jan  2 20:06:13 Ishtar kernel: ata1: limiting SATA link speed to 1.5 Gbps
 > Jan  2 20:06:13 Ishtar kernel: ata1.00: exception Emask 0x0 SAct 0x0 
 > SErr 0x0 action 0x6
 > Jan  2 20:06:13 Ishtar kernel: ata1.00: port_status 0x2008
 > Jan  2 20:06:13 Ishtar kernel: ata1.00: cmd 
 > c8/00:10:00:8b:04/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192 in
 > Jan  2 20:06:13 Ishtar kernel:  res 
 > 50/00:00:0f:8b:04/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
 > Jan  2 20:06:14 Ishtar kernel: ata1: exception Emask 0x10 SAct 0x0 SErr 
 > 0x0 action 0x3
 > Jan  2 20:06:14 Ishtar kernel: ata1: hotplug_status 0x80
 > Jan  2 20:06:15 Ishtar kernel: ata1: exception Emask 0x10 SAct 0x0 SErr 
 > 0x0 action 0x3
 > Jan  2 20:06:15 Ishtar kernel: ata1: hotplug_status 0x80
 > ---
 > What da heck?

Looks like the Promise ASIC SG bug. Apply

and let us know if things improve.

/Mikael
--
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: Clean up k8topology.c


* Carlos R. Mafra <[EMAIL PROTECTED]> wrote:

> x86: Cleanup k8topology.c
> 
> This patch fixes all errors pointed out by checkpatch.pl.
> 
>   errors   lines of code   errors/KLOC
> arch/x86/mm/k8topology_64.c (before)  72 185 389.1
> arch/x86/mm/k8topology_64.c (after)0 185 0
> 
> No code changed.
> 
>textdata bss dec hex filename
>1506   0   01506 5e2 k8topology_64.o.after
>1506   0   01506 5e2 k8topology_64.o.before
>
> md5sum:
> 
>f9f48331a7eca4fc60d2a03369dc5f53  k8topology_64.o.after
>f9f48331a7eca4fc60d2a03369dc5f53  k8topology_64.o.before
>
> Signed-off-by: Carlos R. Mafra <[EMAIL PROTECTED]>

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/

Re: [PATCH 0/3 -mm] kexec jump -v8

2008-01-03 Thread Huang, Ying

On Mon, 2007-12-31 at 14:26 -0500, Vivek Goyal wrote:
[...]
> Ok. But If I copy the /proc/vmcore to disk. Then I reboot the system 
> and boot back into a kernel which is supposed to resume the hibernated
> image. This kernel will not have any command line option jump_back_entry.
> I  need to resume using krestore tool. How will a krestore tool decide that
> image one wants to restore is a core file or a hibernated image?
> 
> In this context I thought an PT_NOTE might be useful.

In current implementation, when saving the memory image of hibernated
kernel in hibernating kernel, the jump back entry from kernel command
line should be saved at the same time, or the jump back entry from
kernel command line can be saved as entry point of ELF hibernated image
file by a modified makedumpfile. That is, 

- method 1:

jbe=`cat /proc/cmdline | tr -d ' ' '\n' | grep kexec_jump_back_entry | cut -d 
'=' -f 2`
cp /proc/vmcore .
echo $jbe > kexec_jump_back_entry

- method 2:

jbe=`cat /proc/cmdline | tr -d ' ' '\n' | grep kexec_jump_back_entry | cut -d 
'=' -f 2`
makedumpfile  -j $jbe /proc/vmcore 

Method 2 is better, because "jump back entry" is the very entry point of
the hibernated image. The vmcore implementation can be changed to set
entry point of /proc/vmcore if "kexec_jump_back_entry" kernel command
line option is present. I did not add this to kernel because it can be
done by user space tool "makedumpfile", and one of the guideline is to
keep kernel part as simple as possible.

With method 2, the ordinary "core file" and "hibernated image" can be
distinguished by the "entry point".

The "jump back entry" can be saved with PT_NOTE too. And more
information can be saved with PT_NOTE. I have ever defined another
mechanism to pass information between two kernels too. I will describe
it later in this mail.

> > As for ELF NOTE, in fact, the ELF NOTE does not work for resumable
> > kernel. Because the contents of source page and destination page is
> > swapped during kexec, and the kernel access the destination page
> > directly during parsing ELF NOTE. All memory that is swapped need to be
> > accessed via the backup pages map (image->head). I think these
> > information can be exchanged between two kernels via kernel command line
> > or /proc/kimgcore.
> > 
> 
> Why should we exchange backup page map information between two kernels?
> What data has been swapped and how to restore it back should be known
> to the kernel who did it. I think the memory info and address of ELF
> headers we can still pass to second kernel the same way we do for
> /proc/vmcore. The only difference is that purgatory shall have to modify 
> the command line to reflect the new address of ELF headers just before
> jumping to new kernel (because of swapping).
> 
> We can also modify the actual ELF headers in purgatory to reflect the
> right data (because of swapping) and new kernel will not have to know
> anything about swapping.
> 
> So I thought of following sequence.
> 
> Lets say there is production kernel A and there is helper kernel B (B
> will save the hibernated image of A).
> 
> - Boot into A.
> - Load kernel B using --load-preserve-context.
> - This load operation can also create the Elf headers.   
> - Kexec -e will start hibernation of A. Pages shall be swapped. Control
>   will be transferred to purgatory.
> - Purgatory will readjust the ELF headers and command line based on 
>   the swapping done and jump to new kernel.
> - New kernel will retrieve the elf headers and export the memory of
>   hibernated kernel through /proc/vmcore.
> 
> Hence there is no need to communicate swapped pages map between two
> kernels.

One original page will map to one backup page (the contents of original
page and backup page will be swapped). It is possible that the entries
number of map equals the number of backup pages.

If the helper kernel B uses 16M memory, there will be 4096 backup pages.
One PT_LOAD header is needed for each backup page to record the map
between the original page to the backup page. So, the memory needed for
PT_LOAD headers will be 32 * 4k = 128k.

If the size of PT_LOAD headers and the "readability" of headers
information of /proc/vmcore is not a big issue, I think this is a good
idea.

In addition to revising the ELF headers in purgatory, the /proc/kimgcore
interface can also be used to revise the ELF headers in kernel A. But
this needs to export backup pages map information to user space (another
sysfs/procfs file?).

[...]
> > The image of B is made as you said. And it can be restored as
> follow:
> > 
> > /sbin/kexec -l --args-none --flags=0x2 
> > /sbin/kexec -e
> > 
> > That is, the image of B is loaded as a ordinary ELF file. A option
> > to /sbin/kexec named --flags are added to specify the
> > KEXEC_PRESERVE_CONTEXT flags for sys_kexec_load. This has been tested.
> 
> Shouldn't we be able to load this image using --load-preseve-context? Why
> to create another otion --flags.

Yes. This seems better. I will

Re: [PATCH] x86: clean up apic_32/64.c


* Hiroshi Shimamoto <[EMAIL PROTECTED]> wrote:

> From: Hiroshi Shimamoto <[EMAIL PROTECTED]>
> Subject: [PATCH] x86: clean up apic_32.c
> 
> White space and coding style clean up.

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/

Re: [RFC PATCH 01/11] Add basic support for gcc profiler instrumentation

Hi Steven.

On Thu, Jan 03, 2008 at 02:16:10AM -0500, Steven Rostedt wrote:
> If CONFIG_MCOUNT is selected and /proc/sys/kernel/mcount_enabled is set to a
> non-zero value the mcount routine will be called everytime we enter a kernel
> function that is not marked with the "notrace" attribute.
> 
> The mcount routine will then call a registered function if a function
> happens to be registered.
> 
> [This code has been highly hacked by Steven Rostedt, so don't
>  blame Arnaldo for all of this ;-) ]
> 
> Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
> Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
> ---
> 
> Index: linux-compile.git/Documentation/stable_api_nonsense.txt
> ===
> --- linux-compile.git.orig/Documentation/stable_api_nonsense.txt  
> 2008-01-03 01:02:28.0 -0500
> +++ linux-compile.git/Documentation/stable_api_nonsense.txt   2008-01-03 
> 01:02:33.0 -0500
> @@ -62,6 +62,9 @@ consider the following facts about the L
>- different structures can contain different fields
>- Some functions may not be implemented at all, (i.e. some locks
>   compile away to nothing for non-SMP builds.)
> +  - Parameter passing of variables from function to function can be
> + done in different ways (the CONFIG_REGPARM option controls
> + this.)

As CONFIG_REGPARM affects calling convention we should add it to the
list of symbols checked when loading modules (vermagic.h).


>- Memory within the kernel can be aligned in different ways,
>   depending on the build options.
>- Linux runs on a wide range of different processor architectures.
> Index: linux-compile.git/Makefile
> ===
> --- linux-compile.git.orig/Makefile   2008-01-03 01:02:28.0 -0500
> +++ linux-compile.git/Makefile2008-01-03 01:02:39.0 -0500
> @@ -509,11 +509,15 @@ endif
>  
>  include $(srctree)/arch/$(SRCARCH)/Makefile
>  
> +ifdef CONFIG_MCOUNT
> +KBUILD_CFLAGS+= -pg -fno-omit-frame-pointer 
> -fno-optimize-sibling-calls
> +else
>  ifdef CONFIG_FRAME_POINTER
>  KBUILD_CFLAGS+= -fno-omit-frame-pointer -fno-optimize-sibling-calls
>  else
>  KBUILD_CFLAGS+= -fomit-frame-pointer
>  endif
> +endif
Could we please move these relations to Kconfig. So we do not end up in a 
situation
where CONFIG_FRAME_POINTER is set but the flag is not added.



>  
>  ifdef CONFIG_DEBUG_INFO
>  KBUILD_CFLAGS+= -g
> Index: linux-compile.git/arch/x86/Kconfig
> ===
> --- linux-compile.git.orig/arch/x86/Kconfig   2008-01-03 01:02:28.0 
> -0500
> +++ linux-compile.git/arch/x86/Kconfig2008-01-03 01:02:33.0 
> -0500
> @@ -28,6 +28,12 @@ config GENERIC_CMOS_UPDATE
>   bool
>   default y
>  
> +# function tracing might turn this off:
> +config REGPARM
> + bool
> + depends on !MCOUNT
> + default y
> +

Could we please define config REGPARM in _one_ Kconfig file
and let those who want it select it.
If you consider this x86 spacific this should be included in the naming
as in CONFIG_X86_REGPARM - and then the above is OK.

Defining the same config variable in several files is not good (but done too 
often these days).

> Index: linux-compile.git/lib/mcount/Makefile
> ===
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++ linux-compile.git/lib/mcount/Makefile 2008-01-03 01:02:33.0 
> -0500
> @@ -0,0 +1,3 @@
> +obj-$(CONFIG_MCOUNT) += libmcount.o
> +
> +libmcount-objs := mcount.o

Preferred syntax is now:
libmcount-y := mcount.o

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: list corruption on ib_srp load in v2.6.24-rc5

2008-01-03 Thread FUJITA Tomonori

On Wed, 02 Jan 2008 09:51:38 -0800
Roland Dreier <[EMAIL PROTECTED]> wrote:

>  > > Can you try this?
>  > 
>  > That patched oopsed in scsi_remove_host(), but reversing the order has
>  > survived over 500 insert/probe/remove cycles.
>  > 
>  > Tested-by: David Dillow <[EMAIL PROTECTED]>
>  > ---
>  > diff --git a/drivers/infiniband/ulp/srp/ib_srp.c 
> b/drivers/infiniband/ulp/srp/ib_srp.c
>  > index 950228f..77e8b90 100644
>  > --- a/drivers/infiniband/ulp/srp/ib_srp.c
>  > +++ b/drivers/infiniband/ulp/srp/ib_srp.c
>  > @@ -2054,6 +2054,7 @@ static void srp_remove_one(struct ib_device *device)
>  >list_for_each_entry_safe(target, tmp_target,
>  > >target_list, list) {
>  >scsi_remove_host(target->scsi_host);
>  > +  srp_remove_host(target->scsi_host);
>  >srp_disconnect_target(target);
> 
> Where do we stand on this?  What is the right place to put the
> srp_remove_host?  Is there a bug somewhere else?

{sas|fc}_remove_host is called before scsi_remove_host. And in
srp_remove_work(), we call srp_remove_host and then
scsi_remove_host. ibmvscsi also calls them in that order.

I thought that I messed up something in srp_transport_class. But I
can't figure out what's wrong. The above patch works and is unlikely
to lead to critical problems so I'm fine with it for now.


> I'd like to get this fixed before 2.6.24 final comes out...

Yeah, it should be fixed.
--
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: Why is deleting (or reading) files not counted as IO-Wait in top?

2008-01-03 Thread Matthias Schniedermeyer

On 03.01.2008 02:16, Maxim Levitsky wrote:
> On Wednesday, 2 January 2008 21:35:03 Matthias Schniedermeyer wrote:
> > Hi
> > 
> > 
> > Currently i'm deleting about 500.000 files on a XFS-filesystem which 
> > takes a few minutes, as i had a top open i saw that 'wa' is shown as 
> > 0.0% (Nothing else running currently) and everything except 'id' is near 
> > the bottom too. Kernel is 2.6.23.11.
> > 
> > So, as 'rm -rf' is essentially a IO (or seek, to be more correct)-bound 
> > task, shouldn't that count as "Waiting for IO"?
> > 
> > The man-page of top says:
> > 'Amount of time the CPU has been waiting for I/O to complete.'
> > 
> > But AFAICT wa only seams to be (ac)counted for writing and not for 
> > reading. I come to that conclusion because, when i fire 'sync' i can see 
> > some percent wa for a few seconds.
> 
> The IOWAIT time is the IDLE time that was spent waiting
> for I/O. (meaning that there were no tasks running, but some were waiting on 
> I/O)
> 
> Thus if you have another task that is not I/O bound, it can run in that time,
> and ideally, you shouldn't notice any I/O slowdown, but the iowait time will 
> decrease.
> 
> It wasn't the case before CFS introduction. I did few tests that showed 
> almost 50% slowdown 
> when running another task in that iowait time.
> It is not longer a problem with CFS.

I can understand that, but in my case nothing else was running, so i 
would expect about 46%-50% wa (Dual Core Processor).




Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

--
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/

Linux 2.6 KBUILD Help Required.

2008-01-03 Thread murtuja bharmal

Hello,

  I have a one question.
  If I have to add  additional external flag on my external kernel 
module source during compilation with KBUILD.
  lest say I have one kernel module file hello.c
  and I want to add one flag -D testdebug.
 
suppose this is my makefile.

obj-m += hello.o
all:
 make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
 make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

where I can add this flag.

Any help will be appreciated.

Thanks and Regards

- Original Message 
From: murtuja bharmal <[EMAIL PROTECTED]>
To: Sam Ravnborg <[EMAIL PROTECTED]>
Sent: Wednesday, 28 November, 2007 11:30:59 PM
Subject: Re: Linux 2.6 kernel module compilation without using KBUILD


> Try disabling Module version support - then you do
> not
> see the .tmp_.o
> When you have understood this simpler case you can
> move
> on and try enabling module versioning.
> 
> But again - you really do not need to understand all
> this
> kernel internal stuff to build a module.
> If your real goal is to build a module without
> use of kbuild you are on the wrong track.
> 
> Please enligthing us why you need all this deep
> internal
> knowledge to build your module and we may be able to
> tell
> you how to use kbuild top do so.
> 
> What you are heading at now looks like waste of time
> for all parties.
> 
> Sam
>

Hello sam,

Thanks for your time.
Any way, we already had a lot discussion.
It just matter of interest nothing else.
Actually it is just a curiosity to know little bit 
Internals of KBUILD and module versioning.
You can say, it is my bad habit when I start work on
something.
I want to understand it from base.
Unfortunately this time I didn’t get much information
from google.
Neither from kernel documentation.
I don’t have any issue on using KBUILD.

Sorry again.
Thanks for your suggestion and view.

Murtuja Bharmal






  

Get easy, one-click access to your favorites. 
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs


  Save all your chat conversations. Find them online at 
http://in.messenger.yahoo.com/webmessengerpromo.php
--
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 2.6 KBUILD Help Required.

On Thu, Jan 03, 2008 at 01:45:32PM +0530, murtuja bharmal wrote:
> Hello,
> 
>   I have a one question.
>   If I have to add  additional external flag on my external kernel 
> module source during compilation with KBUILD.
>   lest say I have one kernel module file hello.c
>   and I want to add one flag -D testdebug.
>  
> suppose this is my makefile.
> 
> obj-m += hello.o
> all:
>  make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
> clean:
>  make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
> 
> where I can add this flag.

>From Documentation/kbuild/makefile.txt:
--- 3.7 Compilation flags

ccflags-y, asflags-y and ldflags-y
The three flags listed above applies only to the kbuild makefile
where they are assigned. They are used for all the normal
cc, as and ld invocation happenign during a recursive build.
Note: Flags with the same behaviour were previously named:
EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS.
They are yet supported but their use are deprecated.

ccflags-y specifies options for compiling C files with $(CC).

Example:
# drivers/sound/emu10k1/Makefile
ccflags-y += -I$(obj)
ccflags-$(DEBUG) += -DEMU10K1_DEBUG

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: git-x86 broken on 32bit


* Ingo Molnar <[EMAIL PROTECTED]> wrote:

> * Andi Kleen <[EMAIL PROTECTED]> wrote:
> 
> > Current git-x86 seems to be totally broken on i386
> > 
> > commit a6f08929f0566f9d309ef5f6651371d8e20fc833
> > Author: Russell Leidich <[EMAIL PROTECTED]>
> > Date:   Wed Jan 2 22:46:22 2008 +0100
> 
> that patch was not included in x86.git anymore at the time you wrote 
> your email. You probably picked up an interim version of the queue 
> that had the breakage - i noticed it and pulled it a few minutes 
> later.

correction: i had fixed it but did not push it out - pushed it out now. 
Please check that it works for you.

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-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

2008-01-03 Thread Bryan Wu

On Jan 3, 2008 3:36 PM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 02 January 2008, Bryan Wu wrote:
> > B.T.W, 2 questions about the MUSB driver:
> > 1. What's the plan for mainline merge of the whole MUSB driver? maybe
> > I can cleanup current Blackfin ports to you guys.
>
> It might as well merge in 2.6.25-early.  It'll be easier to integrate
> patches that way.  Including your Blackfin port.  When I asked before,
> nobody hugely objected to "one big patch".
>
>
> > 2. Do you remember the PING issue I reported in OMAP list? How do you
> > think of that?
>
> Yes, something needs to be done.  EHCI might benefit from the same
> kind of patch, to cope with ill-behaved usb thumb drives.
>
>
> > > I have an idea: the USB_NAKLIMIT0 should be set to some value, when we
> > > got NAK timeout interrupt, we can disable PING. When enumerating normal
> > > USB stick, there is no NAK timeout, because PING is efficient for
> > > handshaking. While problem USB stick will generate NAK timeout
> > > interrupt, we disable PING for this kind of USB device enumeration.
>
> That sounds much better than your original patch, which disabled it
> always.  It might even be worth allocating a flag somewhere in the
> usb_device structure to record when ep0 pings seem to misbehave.
>

OK, I will work on it and send out a patch for that fix.

Thanks
-Bryan Wu
--
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-x86 broken on 32bit

* Andi Kleen <[EMAIL PROTECTED]> wrote:

> Current git-x86 seems to be totally broken on i386 
> 
> commit a6f08929f0566f9d309ef5f6651371d8e20fc833
> Author: Russell Leidich <[EMAIL PROTECTED]>
> Date:   Wed Jan 2 22:46:22 2008 +0100

that patch was not included in x86.git anymore at the time you wrote 
your email. You probably picked up an interim version of the queue that 
had the breakage - i noticed it and pulled it a few minutes later.

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-x86 broken on 32bit


* Andi Kleen [EMAIL PROTECTED] wrote:

 Current git-x86 seems to be totally broken on i386 
 
 commit a6f08929f0566f9d309ef5f6651371d8e20fc833
 Author: Russell Leidich [EMAIL PROTECTED]
 Date:   Wed Jan 2 22:46:22 2008 +0100

that patch was not included in x86.git anymore at the time you wrote 
your email. You probably picked up an interim version of the queue that 
had the breakage - i noticed it and pulled it a few minutes later.

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-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

2008-01-03 Thread Bryan Wu

On Jan 3, 2008 3:36 PM, David Brownell [EMAIL PROTECTED] wrote:
 On Wednesday 02 January 2008, Bryan Wu wrote:
  B.T.W, 2 questions about the MUSB driver:
  1. What's the plan for mainline merge of the whole MUSB driver? maybe
  I can cleanup current Blackfin ports to you guys.

 It might as well merge in 2.6.25-early.  It'll be easier to integrate
 patches that way.  Including your Blackfin port.  When I asked before,
 nobody hugely objected to one big patch.


  2. Do you remember the PING issue I reported in OMAP list? How do you
  think of that?

 Yes, something needs to be done.  EHCI might benefit from the same
 kind of patch, to cope with ill-behaved usb thumb drives.


   I have an idea: the USB_NAKLIMIT0 should be set to some value, when we
   got NAK timeout interrupt, we can disable PING. When enumerating normal
   USB stick, there is no NAK timeout, because PING is efficient for
   handshaking. While problem USB stick will generate NAK timeout
   interrupt, we disable PING for this kind of USB device enumeration.

 That sounds much better than your original patch, which disabled it
 always.  It might even be worth allocating a flag somewhere in the
 usb_device structure to record when ep0 pings seem to misbehave.


OK, I will work on it and send out a patch for that fix.

Thanks
-Bryan Wu
--
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-x86 broken on 32bit


* Ingo Molnar [EMAIL PROTECTED] wrote:

 * Andi Kleen [EMAIL PROTECTED] wrote:
 
  Current git-x86 seems to be totally broken on i386
  
  commit a6f08929f0566f9d309ef5f6651371d8e20fc833
  Author: Russell Leidich [EMAIL PROTECTED]
  Date:   Wed Jan 2 22:46:22 2008 +0100
 
 that patch was not included in x86.git anymore at the time you wrote 
 your email. You probably picked up an interim version of the queue 
 that had the breakage - i noticed it and pulled it a few minutes 
 later.

correction: i had fixed it but did not push it out - pushed it out now. 
Please check that it works for you.

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 2.6 KBUILD Help Required.

On Thu, Jan 03, 2008 at 01:45:32PM +0530, murtuja bharmal wrote:
 Hello,
 
   I have a one question.
   If I have to add  additional external flag on my external kernel 
 module source during compilation with KBUILD.
   lest say I have one kernel module file hello.c
   and I want to add one flag -D testdebug.
  
 suppose this is my makefile.
 
 obj-m += hello.o
 all:
  make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
 clean:
  make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
 
 where I can add this flag.

From Documentation/kbuild/makefile.txt:
--- 3.7 Compilation flags

ccflags-y, asflags-y and ldflags-y
The three flags listed above applies only to the kbuild makefile
where they are assigned. They are used for all the normal
cc, as and ld invocation happenign during a recursive build.
Note: Flags with the same behaviour were previously named:
EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS.
They are yet supported but their use are deprecated.

ccflags-y specifies options for compiling C files with $(CC).

Example:
# drivers/sound/emu10k1/Makefile
ccflags-y += -I$(obj)
ccflags-$(DEBUG) += -DEMU10K1_DEBUG


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/

Linux 2.6 KBUILD Help Required.

2008-01-03 Thread murtuja bharmal

Hello,

  I have a one question.
  If I have to add  additional external flag on my external kernel 
module source during compilation with KBUILD.
  lest say I have one kernel module file hello.c
  and I want to add one flag -D testdebug.
 
suppose this is my makefile.

obj-m += hello.o
all:
 make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
 make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

where I can add this flag.

Any help will be appreciated.

Thanks and Regards

- Original Message 
From: murtuja bharmal [EMAIL PROTECTED]
To: Sam Ravnborg [EMAIL PROTECTED]
Sent: Wednesday, 28 November, 2007 11:30:59 PM
Subject: Re: Linux 2.6 kernel module compilation without using KBUILD


 Try disabling Module version support - then you do
 not
 see the .tmp_modulename.o
 When you have understood this simpler case you can
 move
 on and try enabling module versioning.
 
 But again - you really do not need to understand all
 this
 kernel internal stuff to build a module.
 If your real goal is to build a module without
 use of kbuild you are on the wrong track.
 
 Please enligthing us why you need all this deep
 internal
 knowledge to build your module and we may be able to
 tell
 you how to use kbuild top do so.
 
 What you are heading at now looks like waste of time
 for all parties.
 
 Sam


Hello sam,

Thanks for your time.
Any way, we already had a lot discussion.
It just matter of interest nothing else.
Actually it is just a curiosity to know little bit 
Internals of KBUILD and module versioning.
You can say, it is my bad habit when I start work on
something.
I want to understand it from base.
Unfortunately this time I didn’t get much information
from google.
Neither from kernel documentation.
I don’t have any issue on using KBUILD.

Sorry again.
Thanks for your suggestion and view.

Murtuja Bharmal






  

Get easy, one-click access to your favorites. 
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs


  Save all your chat conversations. Find them online at 
http://in.messenger.yahoo.com/webmessengerpromo.php
--
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: Why is deleting (or reading) files not counted as IO-Wait in top?

2008-01-03 Thread Matthias Schniedermeyer

On 03.01.2008 02:16, Maxim Levitsky wrote:
 On Wednesday, 2 January 2008 21:35:03 Matthias Schniedermeyer wrote:
  Hi
  
  
  Currently i'm deleting about 500.000 files on a XFS-filesystem which 
  takes a few minutes, as i had a top open i saw that 'wa' is shown as 
  0.0% (Nothing else running currently) and everything except 'id' is near 
  the bottom too. Kernel is 2.6.23.11.
  
  So, as 'rm -rf' is essentially a IO (or seek, to be more correct)-bound 
  task, shouldn't that count as Waiting for IO?
  
  The man-page of top says:
  'Amount of time the CPU has been waiting for I/O to complete.'
  
  But AFAICT wa only seams to be (ac)counted for writing and not for 
  reading. I come to that conclusion because, when i fire 'sync' i can see 
  some percent wa for a few seconds.
 
 The IOWAIT time is the IDLE time that was spent waiting
 for I/O. (meaning that there were no tasks running, but some were waiting on 
 I/O)
 
 Thus if you have another task that is not I/O bound, it can run in that time,
 and ideally, you shouldn't notice any I/O slowdown, but the iowait time will 
 decrease.
 
 It wasn't the case before CFS introduction. I did few tests that showed 
 almost 50% slowdown 
 when running another task in that iowait time.
 It is not longer a problem with CFS.

I can understand that, but in my case nothing else was running, so i 
would expect about 46%-50% wa (Dual Core Processor).




Bis denn

-- 
Real Programmers consider what you see is what you get to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a you asked for it, you got it text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

--
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: list corruption on ib_srp load in v2.6.24-rc5

2008-01-03 Thread FUJITA Tomonori

On Wed, 02 Jan 2008 09:51:38 -0800
Roland Dreier [EMAIL PROTECTED] wrote:

Can you try this?
   
   That patched oopsed in scsi_remove_host(), but reversing the order has
   survived over 500 insert/probe/remove cycles.
   
   Tested-by: David Dillow [EMAIL PROTECTED]
   ---
   diff --git a/drivers/infiniband/ulp/srp/ib_srp.c 
 b/drivers/infiniband/ulp/srp/ib_srp.c
   index 950228f..77e8b90 100644
   --- a/drivers/infiniband/ulp/srp/ib_srp.c
   +++ b/drivers/infiniband/ulp/srp/ib_srp.c
   @@ -2054,6 +2054,7 @@ static void srp_remove_one(struct ib_device *device)
  list_for_each_entry_safe(target, tmp_target,
   host-target_list, list) {
  scsi_remove_host(target-scsi_host);
   +  srp_remove_host(target-scsi_host);
  srp_disconnect_target(target);
 
 Where do we stand on this?  What is the right place to put the
 srp_remove_host?  Is there a bug somewhere else?

{sas|fc}_remove_host is called before scsi_remove_host. And in
srp_remove_work(), we call srp_remove_host and then
scsi_remove_host. ibmvscsi also calls them in that order.

I thought that I messed up something in srp_transport_class. But I
can't figure out what's wrong. The above patch works and is unlikely
to lead to critical problems so I'm fine with it for now.


 I'd like to get this fixed before 2.6.24 final comes out...

Yeah, it should be fixed.
--
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 PATCH 01/11] Add basic support for gcc profiler instrumentation

Hi Steven.

On Thu, Jan 03, 2008 at 02:16:10AM -0500, Steven Rostedt wrote:
 If CONFIG_MCOUNT is selected and /proc/sys/kernel/mcount_enabled is set to a
 non-zero value the mcount routine will be called everytime we enter a kernel
 function that is not marked with the notrace attribute.
 
 The mcount routine will then call a registered function if a function
 happens to be registered.
 
 [This code has been highly hacked by Steven Rostedt, so don't
  blame Arnaldo for all of this ;-) ]
 
 Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
 Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
 ---
 
 Index: linux-compile.git/Documentation/stable_api_nonsense.txt
 ===
 --- linux-compile.git.orig/Documentation/stable_api_nonsense.txt  
 2008-01-03 01:02:28.0 -0500
 +++ linux-compile.git/Documentation/stable_api_nonsense.txt   2008-01-03 
 01:02:33.0 -0500
 @@ -62,6 +62,9 @@ consider the following facts about the L
- different structures can contain different fields
- Some functions may not be implemented at all, (i.e. some locks
   compile away to nothing for non-SMP builds.)
 +  - Parameter passing of variables from function to function can be
 + done in different ways (the CONFIG_REGPARM option controls
 + this.)

As CONFIG_REGPARM affects calling convention we should add it to the
list of symbols checked when loading modules (vermagic.h).


- Memory within the kernel can be aligned in different ways,
   depending on the build options.
- Linux runs on a wide range of different processor architectures.
 Index: linux-compile.git/Makefile
 ===
 --- linux-compile.git.orig/Makefile   2008-01-03 01:02:28.0 -0500
 +++ linux-compile.git/Makefile2008-01-03 01:02:39.0 -0500
 @@ -509,11 +509,15 @@ endif
  
  include $(srctree)/arch/$(SRCARCH)/Makefile
  
 +ifdef CONFIG_MCOUNT
 +KBUILD_CFLAGS+= -pg -fno-omit-frame-pointer 
 -fno-optimize-sibling-calls
 +else
  ifdef CONFIG_FRAME_POINTER
  KBUILD_CFLAGS+= -fno-omit-frame-pointer -fno-optimize-sibling-calls
  else
  KBUILD_CFLAGS+= -fomit-frame-pointer
  endif
 +endif
Could we please move these relations to Kconfig. So we do not end up in a 
situation
where CONFIG_FRAME_POINTER is set but the flag is not added.



  
  ifdef CONFIG_DEBUG_INFO
  KBUILD_CFLAGS+= -g
 Index: linux-compile.git/arch/x86/Kconfig
 ===
 --- linux-compile.git.orig/arch/x86/Kconfig   2008-01-03 01:02:28.0 
 -0500
 +++ linux-compile.git/arch/x86/Kconfig2008-01-03 01:02:33.0 
 -0500
 @@ -28,6 +28,12 @@ config GENERIC_CMOS_UPDATE
   bool
   default y
  
 +# function tracing might turn this off:
 +config REGPARM
 + bool
 + depends on !MCOUNT
 + default y
 +

Could we please define config REGPARM in _one_ Kconfig file
and let those who want it select it.
If you consider this x86 spacific this should be included in the naming
as in CONFIG_X86_REGPARM - and then the above is OK.

Defining the same config variable in several files is not good (but done too 
often these days).

 Index: linux-compile.git/lib/mcount/Makefile
 ===
 --- /dev/null 1970-01-01 00:00:00.0 +
 +++ linux-compile.git/lib/mcount/Makefile 2008-01-03 01:02:33.0 
 -0500
 @@ -0,0 +1,3 @@
 +obj-$(CONFIG_MCOUNT) += libmcount.o
 +
 +libmcount-objs := mcount.o

Preferred syntax is now:
libmcount-y := mcount.o

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: [PATCH 0/3 -mm] kexec jump -v8

2008-01-03 Thread Huang, Ying

On Mon, 2007-12-31 at 14:26 -0500, Vivek Goyal wrote:
[...]
 Ok. But If I copy the /proc/vmcore to disk. Then I reboot the system 
 and boot back into a kernel which is supposed to resume the hibernated
 image. This kernel will not have any command line option jump_back_entry.
 I  need to resume using krestore tool. How will a krestore tool decide that
 image one wants to restore is a core file or a hibernated image?
 
 In this context I thought an PT_NOTE might be useful.

In current implementation, when saving the memory image of hibernated
kernel in hibernating kernel, the jump back entry from kernel command
line should be saved at the same time, or the jump back entry from
kernel command line can be saved as entry point of ELF hibernated image
file by a modified makedumpfile. That is, 

- method 1:

jbe=`cat /proc/cmdline | tr -d ' ' '\n' | grep kexec_jump_back_entry | cut -d 
'=' -f 2`
cp /proc/vmcore .
echo $jbe  kexec_jump_back_entry

- method 2:

jbe=`cat /proc/cmdline | tr -d ' ' '\n' | grep kexec_jump_back_entry | cut -d 
'=' -f 2`
makedumpfile other options -j $jbe /proc/vmcore image file


Method 2 is better, because jump back entry is the very entry point of
the hibernated image. The vmcore implementation can be changed to set
entry point of /proc/vmcore if kexec_jump_back_entry kernel command
line option is present. I did not add this to kernel because it can be
done by user space tool makedumpfile, and one of the guideline is to
keep kernel part as simple as possible.

With method 2, the ordinary core file and hibernated image can be
distinguished by the entry point.


The jump back entry can be saved with PT_NOTE too. And more
information can be saved with PT_NOTE. I have ever defined another
mechanism to pass information between two kernels too. I will describe
it later in this mail.

  As for ELF NOTE, in fact, the ELF NOTE does not work for resumable
  kernel. Because the contents of source page and destination page is
  swapped during kexec, and the kernel access the destination page
  directly during parsing ELF NOTE. All memory that is swapped need to be
  accessed via the backup pages map (image-head). I think these
  information can be exchanged between two kernels via kernel command line
  or /proc/kimgcore.
  
 
 Why should we exchange backup page map information between two kernels?
 What data has been swapped and how to restore it back should be known
 to the kernel who did it. I think the memory info and address of ELF
 headers we can still pass to second kernel the same way we do for
 /proc/vmcore. The only difference is that purgatory shall have to modify 
 the command line to reflect the new address of ELF headers just before
 jumping to new kernel (because of swapping).
 
 We can also modify the actual ELF headers in purgatory to reflect the
 right data (because of swapping) and new kernel will not have to know
 anything about swapping.
 
 So I thought of following sequence.
 
 Lets say there is production kernel A and there is helper kernel B (B
 will save the hibernated image of A).
 
 - Boot into A.
 - Load kernel B using --load-preserve-context.
 - This load operation can also create the Elf headers.   
 - Kexec -e will start hibernation of A. Pages shall be swapped. Control
   will be transferred to purgatory.
 - Purgatory will readjust the ELF headers and command line based on 
   the swapping done and jump to new kernel.
 - New kernel will retrieve the elf headers and export the memory of
   hibernated kernel through /proc/vmcore.
 
 Hence there is no need to communicate swapped pages map between two
 kernels.

One original page will map to one backup page (the contents of original
page and backup page will be swapped). It is possible that the entries
number of map equals the number of backup pages.

If the helper kernel B uses 16M memory, there will be 4096 backup pages.
One PT_LOAD header is needed for each backup page to record the map
between the original page to the backup page. So, the memory needed for
PT_LOAD headers will be 32 * 4k = 128k.

If the size of PT_LOAD headers and the readability of headers
information of /proc/vmcore is not a big issue, I think this is a good
idea.

In addition to revising the ELF headers in purgatory, the /proc/kimgcore
interface can also be used to revise the ELF headers in kernel A. But
this needs to export backup pages map information to user space (another
sysfs/procfs file?).

[...]
  The image of B is made as you said. And it can be restored as
 follow:
  
  /sbin/kexec -l --args-none --flags=0x2 kimgecore
  /sbin/kexec -e
  
  That is, the image of B is loaded as a ordinary ELF file. A option
  to /sbin/kexec named --flags are added to specify the
  KEXEC_PRESERVE_CONTEXT flags for sys_kexec_load. This has been tested.
 
 Shouldn't we be able to load this image using --load-preseve-context? Why
 to create another otion --flags.

Yes. This seems better. I will change it.

 So there seems to be two different kind of load

Re: [PATCH] x86: Clean up k8topology.c


* Carlos R. Mafra [EMAIL PROTECTED] wrote:

 x86: Cleanup k8topology.c
 
 This patch fixes all errors pointed out by checkpatch.pl.
 
   errors   lines of code   errors/KLOC
 arch/x86/mm/k8topology_64.c (before)  72 185 389.1
 arch/x86/mm/k8topology_64.c (after)0 185 0
 
 No code changed.
 
textdata bss dec hex filename
1506   0   01506 5e2 k8topology_64.o.after
1506   0   01506 5e2 k8topology_64.o.before

 md5sum:
 
f9f48331a7eca4fc60d2a03369dc5f53  k8topology_64.o.after
f9f48331a7eca4fc60d2a03369dc5f53  k8topology_64.o.before

 Signed-off-by: Carlos R. Mafra [EMAIL PROTECTED]

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/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

2008-01-03 Thread Mikael Pettersson

Linda Walsh writes:
  Robert Hancock wrote:
   Linda Walsh wrote:
   Alan Cox wrote:
   rate began falling; at 128k block-reads-at-a-time or larger, it 
   drops below
   20MB/s (only on buffered SATA).
   Try disabling NCQ - see if you've got a drive with the 'NCQ = no
   readahead' flaw.
   http://linux-ata.org/faq.html#ncq
  ---
  When drive initializes, dmesg says it has NCQ (depth 0/32)
  Reading the queue_depth under /sys, shows a queuedepth of 1.
  
  But more importantly -- I notice a chronic error message associate
  with this drive that may be causing some or all of the problem:
  ---
  Jan  2 20:06:10 Ishtar kernel: ata1.00: exception Emask 0x0 SAct 0x0 
  SErr 0x0 action 0x2
  Jan  2 20:06:10 Ishtar kernel: ata1.00: port_status 0x2008
  Jan  2 20:06:10 Ishtar kernel: ata1.00: cmd 
  c8/00:10:30:06:03/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192 in
  Jan  2 20:06:10 Ishtar kernel:  res 
  50/00:00:3f:06:03/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
  Jan  2 20:06:13 Ishtar kernel: ata1: limiting SATA link speed to 1.5 Gbps
  Jan  2 20:06:13 Ishtar kernel: ata1.00: exception Emask 0x0 SAct 0x0 
  SErr 0x0 action 0x6
  Jan  2 20:06:13 Ishtar kernel: ata1.00: port_status 0x2008
  Jan  2 20:06:13 Ishtar kernel: ata1.00: cmd 
  c8/00:10:00:8b:04/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192 in
  Jan  2 20:06:13 Ishtar kernel:  res 
  50/00:00:0f:8b:04/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
  Jan  2 20:06:14 Ishtar kernel: ata1: exception Emask 0x10 SAct 0x0 SErr 
  0x0 action 0x3
  Jan  2 20:06:14 Ishtar kernel: ata1: hotplug_status 0x80
  Jan  2 20:06:15 Ishtar kernel: ata1: exception Emask 0x10 SAct 0x0 SErr 
  0x0 action 0x3
  Jan  2 20:06:15 Ishtar kernel: ata1: hotplug_status 0x80
  ---
  What da heck?

Looks like the Promise ASIC SG bug. Apply
http://user.it.uu.se/~mikpe/linux/patches/sata_promise/patch-sata_promise-1-asic-sg-bug-fix-v3-2.6.23
and let us know if things improve.

/Mikael
--
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: not clear empty_zero_page again


* Yinghai Lu [EMAIL PROTECTED] wrote:

 [PATCH] x86_64: not clear empty_zero_page again
 
 empty_zero_page is in .bss section, and it is cleared in clear_bss by 
 x86_64_start_kernel. So don't clear that again in mem_init

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/

Re: [patch 02/20] make the inode i_mmap_lock a reader/writer lock


* Nick Piggin [EMAIL PROTECTED] wrote:

  Have you done anything more with allowing  256 CPUS in this 
  spinlock patch?  We've been testing with 1k cpus and to verify with 
  -mm kernel, we need to unpatch these spinlock changes.
 
 Hi Mike,
 
 Actually I had it in my mind that 64 bit used single-byte locking like 
 i386, so I didn't think I'd caused a regression there.
 
 I'll take a look at fixing that up now.

thanks - this is a serious showstopper for the ticket spinlock patch. 

( which has otherwise been performing very well in x86.git so far - it 
  has passed a few thousand bootup tests on 64-bit and 32-bit as well, 
  so we are close to it being in a mergable state. Would be a pity to
  lose it due to the 256 cpus limit. )

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: [PATCH] x86: clean up apic_32/64.c


* Hiroshi Shimamoto [EMAIL PROTECTED] wrote:

 From: Hiroshi Shimamoto [EMAIL PROTECTED]
 Subject: [PATCH] x86: clean up apic_32.c
 
 White space and coding style clean up.

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] aio: partial write should not return error code.

2008-01-03 Thread Rusty Russell

When an AIO write gets an error after writing some data (eg. ENOSPC),
it should return the amount written already, not the error.  Just like
write() is supposed to.

This was found by the libaio test suite.

Signed-off-by: Rusty Russell [EMAIL PROTECTED]

diff -r 18802689361a fs/aio.c
--- a/fs/aio.c  Thu Jan 03 15:22:24 2008 +1100
+++ b/fs/aio.c  Thu Jan 03 18:05:25 2008 +1100
@@ -1346,6 +1350,13 @@ static ssize_t aio_rw_vect_retry(struct 
/* This means we must have transferred all that we could */
/* No need to retry anymore */
if ((ret == 0) || (iocb-ki_left == 0))
+   ret = iocb-ki_nbytes - iocb-ki_left;
+
+   /* If we managed to write some out we return that, rather than
+* the eventual error. */
+   if (opcode == IOCB_CMD_PWRITEV
+ret  0
+iocb-ki_nbytes - iocb-ki_left)
ret = iocb-ki_nbytes - iocb-ki_left;
 
return ret;
--
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] aio: negative offset should return -EINVAL

2008-01-03 Thread Rusty Russell

An AIO read or write should return -EINVAL if the offset is negative.
This check matches the one in pread and pwrite.

This was found by the libaio test suite.

Signed-off-by: Rusty Russell [EMAIL PROTECTED]

diff -r 18802689361a fs/aio.c
--- a/fs/aio.c  Thu Jan 03 15:22:24 2008 +1100
+++ b/fs/aio.c  Thu Jan 03 18:05:25 2008 +1100
@@ -1330,6 +1330,10 @@ static ssize_t aio_rw_vect_retry(struct 
opcode = IOCB_CMD_PWRITEV;
}
 
+   /* This matches the pread()/pwrite() logic */
+   if (iocb-ki_pos  0)
+   return -EINVAL;
+
do {
ret = rw_op(iocb, iocb-ki_iovec[iocb-ki_cur_seg],
iocb-ki_nr_segs - iocb-ki_cur_seg,
--
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: freeze vs freezer

2008-01-03 Thread Nigel Cunningham

Hi.

Rafael J. Wysocki wrote:
 On Wednesday, 2 of January 2008, Nigel Cunningham wrote:
 Pavel Machek wrote:
 So how do you handle threads that are blocked on I/O or a lock  
 during the system freeze process, then?
 We wait until they can continue.
 So if I have a process blocked on an unavilable NFS mount, I can't
 suspend?
 That's correct, you can't.

 [And I know what you're going to say. ;-)]
 Why exactly does suspend/hibernation depend on TASK_INTERRUPTIBLE  
 instead of a zero preempt_count()?  Really what we should do is just  
 iterate over all of the actual physical devices and tell each one  
 Block new IO requests preemptably, finish pending DMA, put the  
 hardware in low-power mode, and prepare for suspend/hibernate.  As  
 long as each driver knows how to do those simple things we can have  
 an entirely consistent kernel image for both suspend and for  
 hibernation.
 each driver means this is a lot of work. But yes, that is probably
 way to go, and patch would be welcome.
 Yes, that does work. It's what I've done in my (preliminary) support for
 fuse.
 
 Hmm, can you please elaborate a bit?

Sorry. I wasn't very unambiguous, was I? And I'm not sure now whether
you're meaning How does fuse support relate to freezing block devices?
or What's this about fuse support?. Let me therefore seek to answer
both questions:

Higher level, I know (filesystems rather than block devices), but I was
meaning the general concept of blocking new requests and completing
existing ones worked fine for the supposedly impossible fuse support.

Re fuse support, let me start by saying I know this doesn't handle all
situations, but I think it's a good enough proof-of-concept implementation.

I added some simple hooks to the code for submitting new work to fuse
threads.

#define FUSE_MIGHT_FREEZE(superblock, desc) \
do { \
   int printed = 0; \
   while(superblock-s_frozen != SB_UNFROZEN) { \
   if (!printed) { \
   printk(%d frozen in  desc .\n, current-pid); \
   printed = 1; \
   } \
   try_to_freeze(); \
   yield(); \
   } \
} while (0)

On top of this, I made a (too simple at the moment) freeze_filesystems
function which iterates through super_blocks in reverse order, freezing
fuse filesystems or ordinary ones. I say 'too simple' because it doesn't
currently allow for the possibility of someone mounting (say) ext3 on
fuse, but that would just be an extension of what's already done.

The end result is:

int freeze_processes(void)
{
int error;

printk(KERN_INFO Stopping fuse filesystems.\n);
freeze_filesystems(FS_FREEZER_FUSE);
freezer_state = FREEZER_FILESYSTEMS_FROZEN;
printk(KERN_INFO Freezing user space processes ... );
error = try_to_freeze_tasks(FREEZER_USER_SPACE);
if (error)
goto Exit;
printk(KERN_INFO done.\n);

sys_sync();
printk(KERN_INFO Stopping normal filesystems.\n);
freeze_filesystems(FS_FREEZER_NORMAL);
freezer_state = FREEZER_USERSPACE_FROZEN;
printk(KERN_INFO Freezing remaining freezable tasks ... );
error = try_to_freeze_tasks(FREEZER_KERNEL_THREADS);
if (error)
goto Exit;
printk(KERN_INFO done.);
freezer_state = FREEZER_FULLY_ON;
 Exit:
BUG_ON(in_atomic());
printk(\n);
return error;
}

Sorry if that's more info than you wanted.

Nigel
--
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 PATCH 01/11] Add basic support for gcc profiler instrumentation


* Steven Rostedt [EMAIL PROTECTED] wrote:

 +# function tracing might turn this off:
 +config REGPARM
 + bool
 + depends on !MCOUNT
 + default y

are you sure -pg really needs this? I just carried this along the years 
and went the path of least resistence, but we should not be 
reintroducing the !REGPARM build mode for the kernel. I'd not be 
surprised if there were a few issues with REGPARM + mcount, but we have 
to figure it out before merging ...

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: neigh: timer !nud_in_timer

2008-01-03 Thread John Sigler


John Sigler wrote:


I noticed the following message in my kernel log.
kernel: neigh: timer  !nud_in_timer
(Might be due to a race condition.)

I'm running a UP Linux version 2.6.22.1-rt9
( http://rt.wiki.kernel.org/index.php )

The following /proc entries might be relevant.

/proc/sys/net/ipv4/conf/all/arp_accept
0
/proc/sys/net/ipv4/conf/all/arp_announce
2
/proc/sys/net/ipv4/conf/all/arp_filter
0
/proc/sys/net/ipv4/conf/all/arp_ignore
1

I also lowered the priority of softirq-timer/0 to 10 which means
it can be interrupted by other IRQ handlers.


Comments or musings?
--
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/3] move WARN_ON() out of line


* Arjan van de Ven [EMAIL PROTECTED] wrote:

 +#define WARN_ON(condition) do_warn_on((unsigned long)(condition), __FILE__, \
 +  __LINE__, __FUNCTION__)

hm. This passes in 4 arguments to do_warn_on().

i think we could get away with no arguments (!), by using section 
tricks. Firstly, we can get rid of __FUNCTION__ and replace it with a 
ksyms lookup - that is fine enough. Secondly, we could put __FILE__ and 
__LINE__ into a text section and key it up to the return address from 
do_warn_on().

the condition code should not be passed in at all i think - it creates 
extra function calls to do_warn_on() all the time.

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] More NFS client fixes for 2.6.24-rc6


* Trond Myklebust [EMAIL PROTECTED] wrote:

 commit 53478daff2c8b494d2af1ede6611f166f81bc393
 Author: Trond Myklebust [EMAIL PROTECTED]
 Date:   Wed Jan 2 13:28:57 2008 -0500
 
 NFS: Fix a possible Oops in fs/nfs/super.c
 
 Sigh... commit 4584f520e1f773082ef44ff4f8969a5d992b16ec (NFS: Fix NFS
 mountpoint crossing...) had a slight flaw: server can be NULL if sget()
 returned an existing superblock.
 
 Fix the fix by dereferencing s-s_fs_info.
 
 Also add in the same namespace Oops fix for NFSv4 in both the mountpoint
 crossing case, and the referral case.
 
 Signed-off-by: Trond Myklebust [EMAIL PROTECTED]

shouldnt this commit have included the full credit of the bugfix:

  http://bugzilla.kernel.org/show_bug.cgi?id=9647

  
  Description From Adrian Bunk 2007-12-27 12:36

  The Coverity checker spotted that commit
  4584f520e1f773082ef44ff4f8969a5d992b16ec introduced the following NULL
  dereference in 2.6.24-rc6:

  --  snip  --
 if (s-s_fs_info != server) {
 nfs_free_server(server);
 server = NULL; ---
 }

  --- Comment #1 From Adrian Bunk 2007-12-27 12:37:42 ---
  The NULL dereference is at the 
  server-nfs_client-rpc_ops-dir_inode_ops.
  --

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: [PATCH 2/2] Kprobes: Move kprobes examples to samples/


* Ananth N Mavinakayanahalli [EMAIL PROTECTED] wrote:

 From: Ananth N Mavinakayanahalli [EMAIL PROTECTED]
 
 Move kprobes examples from Documentation/kprobes.txt to under 
 samples/. Patch originally by Randy Dunlap.

nice!

 +config SAMPLE_KPROBES
 + tristate Build kprobes examples -- loadable modules only
 + depends on KPROBES  m
 + help
 +   This build several kprobes example modules.

feature request: please make this work in the !modular case as well - if 
built-in then it should just run sometime during bootup and run the 
tests and report success/failure. This way automated testing can pick up 
any regressions much easier.

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: [PATCH] x86: Use is_kprobe_fault to better match usage


* Harvey Harrison [EMAIL PROTECTED] wrote:

 Currently the notify_page_fault helper is used to test it the page 
 fault was caused by a kprobe causing an early return from 
 do_page_fault.
 
 Change the name of the helper to is_kprobe_fault to match the usage 
 and remove the preempt_disable/enable pair around kprobe_running() 
 with an explicit test for preemption.  The idea for this comes from a 
 patch by Quentin Barnes to kprobes.c
 
 Signed-off-by: Harvey Harrison [EMAIL PROTECTED]

hm, this doesnt apply:

 Hunk #3 FAILED at 426.
 Hunk #4 succeeded at 413 (offset -22 lines).
 1 out of 4 hunks FAILED -- rejects in file arch/x86/mm/fault_32.c
 patching file arch/x86/mm/fault_64.c
 Hunk #3 FAILED at 476.
 Hunk #4 succeeded at 475 (offset -10 lines).
 1 out of 4 hunks FAILED -- rejects in file arch/x86/mm/fault_64.c

could you double-check x86.git#mm, perhaps we are out of sync with a 
patch somewhere?

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: freeze vs freezer

2008-01-03 Thread Oliver Neukum

Am Donnerstag 03 Januar 2008 schrieb Nigel Cunningham:
 On top of this, I made a (too simple at the moment) freeze_filesystems
 function which iterates through super_blocks in reverse order, freezing
 fuse filesystems or ordinary ones. I say 'too simple' because it doesn't
 currently allow for the possibility of someone mounting (say) ext3 on
 fuse, but that would just be an extension of what's already done.

How do you deal with fuse server tasks using other fuse filesystems?
How does freeze_filesystems() look?

Regards
Oliver

--
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: freeze vs freezer

2008-01-03 Thread Nigel Cunningham

Hi.

Oliver Neukum wrote:
 Am Donnerstag 03 Januar 2008 schrieb Nigel Cunningham:
 On top of this, I made a (too simple at the moment) freeze_filesystems
 function which iterates through super_blocks in reverse order, freezing
 fuse filesystems or ordinary ones. I say 'too simple' because it doesn't
 currently allow for the possibility of someone mounting (say) ext3 on
 fuse, but that would just be an extension of what's already done.
 
 How do you deal with fuse server tasks using other fuse filesystems?

Since they're frozen in reverse order, the dependant one would be frozen
first.

 How does freeze_filesystems() look?

Removing my ugly debugging statements, it's currently:

/**
 * freeze_filesystems - lock all filesystems and force them into a
consistent
 * state
 */
void freeze_filesystems(int which)
{
struct super_block *sb;

lockdep_off();

/*
 * Freeze in reverse order so filesystems dependant upon others are
 * frozen in the right order (eg. loopback on ext3).
 */
list_for_each_entry_reverse(sb, super_blocks, s_list) {
if (sb-s_type-fs_flags  FS_IS_FUSE 
sb-s_frozen == SB_UNFROZEN 
which  FS_FREEZER_FUSE) {
sb-s_frozen = SB_FREEZE_TRANS;
sb-s_flags |= MS_FROZEN;
continue;
}

if (!sb-s_root || !sb-s_bdev ||
(sb-s_frozen == SB_FREEZE_TRANS) ||
(sb-s_flags  MS_RDONLY) ||
(sb-s_flags  MS_FROZEN) ||
!(which  FS_FREEZER_NORMAL))
continue;
freeze_bdev(sb-s_bdev);
sb-s_flags |= MS_FROZEN;
}

lockdep_on();
}

Nigel
--
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/20] x86: Make ptrace.h safe to include from assembler code


* Andi Kleen [EMAIL PROTECTED] wrote:

 Index: linux/include/asm-x86/ptrace-abi.h
 ===
 --- linux.orig/include/asm-x86/ptrace-abi.h
 +++ linux/include/asm-x86/ptrace-abi.h
 @@ -80,6 +80,7 @@
  
  #define PTRACE_SINGLEBLOCK   33  /* resume execution until next branch */
  
 +#ifndef __ASSEMBLY__

hm, this patch misses a rationale - what assembly code includes 
ptrace-abi.h directly or indirectly? Did you see any build breakage with 
x86.git that requires this? (if yes then please send me the .config)

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: Kernel BUG in 2.6.23.9

2008-01-03 Thread Tarkan Erimer

Arjan van de Ven wrote:

On Sun, 09 Dec 2007 14:49:16 -0500
Jerry Geis [EMAIL PROTECTED] wrote:

I am using centos 5.1, 2.6.23.9 kernel. Machine works great all day.
Then sometime through the night the kernel dies, the trace is below.

is this when a 3D screensaver is active?
Probably worth running without the proprietary nvidia driver it
also tends to get more people to pay attention :)

In addition to this suspicion; you're the first one to report this oops
since at least a year as shown in
http://www.kerneloops.org/guilty.php?guilty=journal_dirty_dataversion=2.6.23-releasestart=1540096end=1572863

so it might well be something weird on your side (like the binary
driver or some heat problem created by having a 3D screensaver)

Hi,

For a while, I have the same behavior. I tested under 2.6.23.9,
2.6.24-rc3 and rc4. So all of these kernels have the same issue. Also, I
don't use any proprietary driver. My video card is Intel-945 and I use
the intel driver. I use 3D screensavers as well. These kernels die
after some long idles like 1 or 2 days after. My distribution is Kubuntu
7.10 and with Kubuntu kernel this behavior did not happened. So, how to
track this interesting problem ? Any ideas welcomed :-)

Cheers,

Tarkan Erimer

--
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] Kprobes: Move kprobes examples to samples/

2008-01-03 Thread Ananth N Mavinakayanahalli

On Thu, Jan 03, 2008 at 10:33:03AM +0100, Ingo Molnar wrote:
 
 * Ananth N Mavinakayanahalli [EMAIL PROTECTED] wrote:
 
  From: Ananth N Mavinakayanahalli [EMAIL PROTECTED]
  
  Move kprobes examples from Documentation/kprobes.txt to under 
  samples/. Patch originally by Randy Dunlap.
 
 nice!
 
  +config SAMPLE_KPROBES
  +   tristate Build kprobes examples -- loadable modules only
  +   depends on KPROBES  m
  +   help
  + This build several kprobes example modules.
 
 feature request: please make this work in the !modular case as well - if 
 built-in then it should just run sometime during bootup and run the 
 tests and report success/failure. This way automated testing can pick up 
 any regressions much easier.

Will try cook up something along those lines. It'll be easy to verify if
the probes inserted and removed properly, but verifying handlers run
correctly will need some work.

We have a sort of regression test bucket that uses expect to parse the
dmesg to verify handlers did run correctly; that isn't a totally
in-kernel solution anyway. I have a couple of ideas in mind to make it
easier.

Ananth
--
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/

mconf and help texts

2008-01-03 Thread Ph. Marek

Hello everybody!

[[ Please keep me CC'ed. Thank you. ]]


I just tried looking at NF_CONNTRACK_MARK (menuconfig, in 2.6.23.12), and 
found it disallowed.

So I took a look at Help, and saw that blob:

  Selected by: NETFILTER_XT_TARGET_CONNMARK  NET  INET  NETFILTER 
 NETFILTER_XTABLES  (IP_NF_MANGLE || IP6_NF_MANGLE)  NF_CONNTRACK ||
 NETFILTER_XT_MATCH_CONNMARK  NET  INET  NETFILTER 
 NETFILTER_XTABLES  NF_CONNTRACK || IP_NF_TARGET_CLUSTERIP  NET 
 INET  NETFILTER  IP_NF_MANGLE  EXPERIMENTAL  NF_CONNTRACK_IPV4

That is a _bit_ unreadable.


Now breaking that into multiple lines would show me this:
  NETFILTER_XT_TARGET_CONNMARK  NET  INET  NETFILTER 
 NETFILTER_XTABLES  (IP_NF_MANGLE || IP6_NF_MANGLE)  NF_CONNTRACK ||
  NETFILTER_XT_MATCH_CONNMARK  NET  INET  NETFILTER 
 NETFILTER_XTABLES  NF_CONNTRACK || 
  IP_NF_TARGET_CLUSTERIP  NET  INET  NETFILTER  IP_NF_MANGLE 
 EXPERIMENTAL  NF_CONNTRACK_IPV4

Is that correct? If yes, how about putting such line-breaks in the shown text?

Furthermore ... how about removing duplicate symbols from there?
A bit of editing shows me

  1 EXPERIMENTAL
  3 INET
  1 IP6_NF_MANGLE
  2 IP_NF_MANGLE
  1 IP_NF_TARGET_CLUSTERIP
  3 NET
  3 NETFILTER
  2 NETFILTER_XTABLES
  1 NETFILTER_XT_MATCH_CONNMARK
  1 NETFILTER_XT_TARGET_CONNMARK
  2 NF_CONNTRACK
  1 NF_CONNTRACK_IPV4

Now I wonder ... complete reductions of this might be a bit awful, but 
repeated 
INET  ... ||
INET  ... ||
INET  ...
could surely be made shorter.

It would be nice (depending on your value of nice, of course :-))
to see 
  NET  INET  NETFILTER 
NETFILTER_XT_TARGET_CONNMARK  NETFILTER_XTABLES  
  (IP_NF_MANGLE || IP6_NF_MANGLE)  NF_CONNTRACK ||
  NETFILTER_XT_MATCH_CONNMARK  NETFILTER_XTABLES  NF_CONNTRACK || 
  IP_NF_TARGET_CLUSTERIP  IP_NF_MANGLE  EXPERIMENTAL  NF_CONNTRACK_IPV4

I'm not sure whether it would be worth the additional work to get
  NET  INET  NETFILTER 
( NETFILTER_XTABLES  NF_CONNTRACK 
  ( NETFILTER_XT_MATCH_CONNMARK  NETFILTER_XTABLES ) ||
  ( NETFILTER_XT_TARGET_CONNMARK  NF_CONNTRACK 
(IP_NF_MANGLE || IP6_NF_MANGLE) ) ||
IP_NF_TARGET_CLUSTERIP  IP_NF_MANGLE  EXPERIMENTAL 
  NF_CONNTRACK_IPV4

(if I translated that correctly, manually)


Would there be interest if I supplied some script (perl would be easiest for 
me) that tried to simplify such strings? Calling that from C wouldn't be 
nice, but acceptable for the occasional help text showing.

There has to be some expression parser for that ... could that be used? Where 
gets this string built?


As a side-node - I cannot get xconfig to work (pkg-config); is there some way 
in menuconfig to see why some config option is disallowed? The location tree 
shows some data (- Networking support (NET [=y])), but not for all 
dependencies. [Does xconfig allow enabling them while seeing this option?]



Regards,

Phil
--
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] [9/20] x86: Don't use oops_begin in 64bit mce code


* Andi Kleen [EMAIL PROTECTED] wrote:

 It is not really useful to lock machine checks against oopses. And 
 machine checks normally don't nest, so they don't need their own 
 locking. Just call bust_spinlock/console_verbose directly.

is this in response to any particular incident you've seen?

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: [RFC][PATCH 2/7] ACPI: Separate invocations of _GTS and _BFS from _PTS and _WAK

On Thu 2007-12-27 19:15:16, Rafael J. Wysocki wrote:
 From: Rafael J. Wysocki [EMAIL PROTECTED]
 
 The execution of ACPI global control methods _GTS and _BFS is
 currently tied to the preparation to enter a sleep state and to the
 leaving of the sleep state, respectively.  However, these functions
 are called before disabling the nonboot CPUs and after enabling
 them, respectively (in fact, on ACPI 1.0x systems the first of them
 ought to be called before suspending devices), while according to the
 ACPI specification, _GTS is to be executed right prior to entering
 the system sleep state and _BFS is to be executed right after the
 platfor firmware has returned control to the OS on wake up.
 
 Move the execution of _GTS and _BFS to the right places.
 
 Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]

Seems ok to me, but it is 2.6.25 material earliest, right?

-- 
(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: [PATCH] [10/20] i386: Move MWAIT idle check to generic CPU initialization


* Andi Kleen [EMAIL PROTECTED] wrote:

 Previously it was only run for Intel CPUs, but AMD Fam10h implements 
 MWAIT too.
 
 This matches 64bit behaviour.
 
 Signed-off-by: Andi Kleen [EMAIL PROTECTED]

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/

Re: [RFC][PATCH 3/7] ACPI: Separate disabling of GPEs from _PTS

Hi!

 From: Rafael J. Wysocki [EMAIL PROTECTED]
 
 The preparation to enter an ACPI system sleep state is now tied to
 the disabling of GPEs, but the GPEs should not be disabled before
 suspending devices.  Since on ACPI 1.0x systems the _PTS global
 control method should be executed before suspending devices, we
 need to disable GPEs separately.
 
 Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]

Looks ok to me... as does rest of the series.

-- 
(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: [PATCH] [11/20] x86: Use the correct cpuid method to detect MWAIT support for C states


* Andi Kleen [EMAIL PROTECTED] wrote:

 +static int mwait_usable(const struct cpuinfo_x86 *c)
 +{
 + if (force_mwait)
 + return 1;
 + /* Any C1 states supported? */
 + return c-cpuid_level = 5  ((cpuid_edx(5)  4)  0xf)  0;
 +}
 +
  void __cpuinit select_idle_routine(const struct cpuinfo_x86 *c)
  {
 - if (cpu_has(c, X86_FEATURE_MWAIT)) {
 + if (cpu_has(c, X86_FEATURE_MWAIT)  mwait_usable(c)) {
   printk(monitor/mwait feature present.\n);

hm, why not clear FEATURE_MWAIT if it's not usable? That's the 
standard approach we do for CPU features that do not work.

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: [PATCH] [5/20] x86: Introduce nsec_barrier()


* Andi Kleen [EMAIL PROTECTED] wrote:

 nsec_barrier() is a new barrier primitive that stops RDTSC speculation 
 to avoid races with timer interrupts on other CPUs.
 
 Add it to all architectures. Except for x86 it is a nop right now. I 
 only tested x86, but it's a very simple change.
 
 On x86 it expands either to LFENCE (for Intel CPUs) or MFENCE (for AMD 
 CPUs) which stops RDTSC on all currently known microarchitectures that 
 implement SSE. On CPUs without SSE there is generally no RDTSC 
 speculation.

i've picked up your rdtsc patches into x86.git but have simplified it: 
there's no nsec_barrier() anymore - rdtsc() is always synchronous. 
MFENCE/LFENCE is fast enough. Open-coding such barriers almost always 
leads to needless trouble. Please check the next x86.git tree.

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: [PATCH] [12/20] x86: Use a per cpu timer for correctable machine check checking


* Andi Kleen [EMAIL PROTECTED] wrote:

 Previously the code used a single timer that then used 
 smp_call_function to interrupt all CPUs while the original CPU was 
 waiting for them.
 
 But it is better / more real time and more power friendly to simply 
 run individual timers on each CPU so they all do this independently.
 
 This way no single CPU has to wait for all others.

i think we should unify this code first and provide it on 32-bit 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/

Re: [PATCH 0/4] PM: Do not destroy/create devices while suspended (rev. 2)

Hi!

That way any suspend breakage would be detectable (and bisectable) 
in automated testing - if the resume does not come back after 10-20 
seconds then the test failed.
   
   Yes, but please note that some systems require user space 
   manipulations of the graphics adapter for suspend to work and to 
   detect a breakage of such a system you need to boot it into X and use 
   s2ram to suspend.
  
  yeah, i wouldnt expect graphics mode to come back without quirks. But it 
  should still work fine over the network, right? (which is my main mode 
  of testing anyway)
 
 Well, if the graphics is sufficiently broken, it won't resume at
 all.

Actually, no. Unless you try to boot the bios, it should come up
without graphics. 

Hmm... first framebuffer access may kill the machine at that
point... so disable framebuffer...? ;-). 

vga=1 and no acpi_sleep options usually does the trick for me. That
should work everywhere, independend of graphics options, AFAICT.
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: [PATCH] [19/20] x86: Use shorter addresses in i386 segfault printks


* Andi Kleen [EMAIL PROTECTED] wrote:

 x86: Use shorter addresses in i386 segfault printks

hm, why? It's pretty well-established that we print addresses 8 char 
wide on 32-bit.

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: [PATCH] [20/20] x86: Print which shared library/executable faulted in segfault etc. messages


* Andi Kleen [EMAIL PROTECTED] wrote:

 They now look like
 
 hal-resmgr[13791]: segfault at 3c rip 2b9c8caec182 rsp 7fff1e825d30 
 error 4 in libacl.so.1.1.0[2b9c8caea000+6000]
 
 This makes it easier to pinpoint bugs to specific libraries.

yep, that's really useful.

I think the patch needs one more iteration though:

 And printing the offset into a mapping also always allows to find the 
 correct fault point in a library even with randomized mappings. Previously
 there was no way to actually find the correct code address inside
 the randomized mapping.
 
 Relies on earlier patch to shorten the printk formats.
 
 They are often now longer than 80 characters, but I think that's worth 
 it.

why not make it multi-line? that way the %lx hack wouldnt be needed 
either.

 +void print_vma_addr(char *prefix, unsigned long ip)
 +{
 + struct mm_struct *mm = current-mm;
 + struct vm_area_struct *vma;
 + down_read(mm-mmap_sem);
 + vma = find_vma(mm, ip);

grumble. Proper CodingStyle please.

 + if (buf) {
 + char *p, *s;
 + p = d_path(f-f_dentry, f-f_vfsmnt, buf, PAGE_SIZE);

this one too.

 + if (show_unhandled_signals  printk_ratelimit()) {
 + printk(%s[%d] bad frame in %s frame:%p ip:%lx sp:%lx orax:%lx,
  me-comm,me-pid,where,frame,regs-ip,regs-sp,regs-orig_ax);

and this.

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/

struct should not be named same way as function in sony-laptop

Naming struct and function by same name is evil. Rename the struct.

Signed-off-by: Pavel Machek [EMAIL PROTECTED]

diff --git a/drivers/misc/sony-laptop.c b/drivers/misc/sony-laptop.c
index b0f6803..31ce39d 100644
--- a/drivers/misc/sony-laptop.c
+++ b/drivers/misc/sony-laptop.c
@@ -1180,7 +1180,7 @@ struct sony_pic_ioport {
struct list_headlist;
 };
 
-struct sony_pic_irq {
+struct sony_pic_irqdesc {
struct acpi_resource_irqirq;
struct list_headlist;
 };
@@ -1192,7 +1192,7 @@ struct sony_pic_dev {
u8  bluetooth_power;
u8  wwan_power;
struct acpi_device  *acpi_dev;
-   struct sony_pic_irq *cur_irq;
+   struct sony_pic_irqdesc *cur_irq;
struct sony_pic_ioport  *cur_ioport;
struct list_headinterrupts;
struct list_headioports;
@@ -2094,7 +2094,7 @@ sony_pic_read_possible_resource(struct a
case ACPI_RESOURCE_TYPE_IRQ:
{
struct acpi_resource_irq *p = resource-data.irq;
-   struct sony_pic_irq *interrupt = NULL;
+   struct sony_pic_irqdesc *interrupt = NULL;
if (!p || !p-interrupt_count) {
/*
 * IRQ descriptors may have no IRQ# bits set,
@@ -2218,7 +2218,7 @@ static int sony_pic_disable(struct acpi_
  *  Call _SRS to set current resources
  */
 static int sony_pic_enable(struct acpi_device *device,
-   struct sony_pic_ioport *ioport, struct sony_pic_irq *irq)
+   struct sony_pic_ioport *ioport, struct sony_pic_irqdesc *irq)
 {
acpi_status status;
int result = 0;
@@ -2381,7 +2381,7 @@ found:
 static int sony_pic_remove(struct acpi_device *device, int type)
 {
struct sony_pic_ioport *io, *tmp_io;
-   struct sony_pic_irq *irq, *tmp_irq;
+   struct sony_pic_irqdesc *irq, *tmp_irq;
 
if (sony_pic_disable(device)) {
printk(KERN_ERR DRV_PFX Couldn't disable device.\n);
@@ -2422,7 +2422,7 @@ static int sony_pic_add(struct acpi_devi
 {
int result;
struct sony_pic_ioport *io, *tmp_io;
-   struct sony_pic_irq *irq, *tmp_irq;
+   struct sony_pic_irqdesc *irq, *tmp_irq;
 
printk(KERN_INFO DRV_PFX %s v%s.\n,
SONY_PIC_DRIVER_NAME, SONY_LAPTOP_DRIVER_VERSION);

-- 
(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: [PATCH] [15/20] x86: Move X86_FEATURE_CONSTANT_TSC into early cpu feature detection


* Andi Kleen [EMAIL PROTECTED] wrote:

 Need this in the next patch in time_init and that happens early.
 
 This includes a minor fix on i386 where early_intel_workarounds() 
 [which is now called early_init_intel] really executes early as the 
 comments say.

thanks, applied. I'll wait for Thomas to comment on the TSC bits though. 
(but as long as we carry this patch in x86.git it should make your 
future patching efforts easier.)

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: [PATCH 2/2] Kprobes: Move kprobes examples to samples/


* Ananth N Mavinakayanahalli [EMAIL PROTECTED] wrote:

  feature request: please make this work in the !modular case as well 
  - if built-in then it should just run sometime during bootup and run 
  the tests and report success/failure. This way automated testing can 
  pick up any regressions much easier.
 
 Will try cook up something along those lines. It'll be easy to verify 
 if the probes inserted and removed properly, but verifying handlers 
 run correctly will need some work.
 
 We have a sort of regression test bucket that uses expect to parse the 
 dmesg to verify handlers did run correctly; that isn't a totally 
 in-kernel solution anyway. I have a couple of ideas in mind to make it 
 easier.

Great. Would be really nice to have something along the lines of 
CONFIG_DEBUG_LOCKING_API_SELFTESTS. Those unit tests took time to 
develop, but they caught more than 90% (!) of the internal lockdep 
engine bugs before they ever hit mainline.

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/

don't #error on higher HZ values


For some crazy reason (trying to work around hw problem in i810) I
wanted to use HZ around 4000.


Signed-off-by: Pavel Machek [EMAIL PROTECTED]
Pavel

diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
index 8b08002..7ba9e47 100644
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -29,6 +29,12 @@ #elif HZ = 384  HZ  768
 # define SHIFT_HZ  9
 #elif HZ = 768  HZ  1536
 # define SHIFT_HZ  10
+#elif HZ = 1536  HZ  3072
+# define SHIFT_HZ  11
+#elif HZ = 3072  HZ  6144
+# define SHIFT_HZ  12
+#elif HZ = 6144  HZ  12288
+# define SHIFT_HZ  13
 #else
 # error You lose.
 #endif
 

-- 
(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: [PATCH] teach checkpatch.pl about list_for_each

2008-01-03 Thread Andy Whitcroft

On Sun, Dec 02, 2007 at 01:03:35PM +0100, Christer Weinigel wrote:
 Hi Andy,
 
 you seem to be the last person messing around with checkpatch.pl so I'm
 addressing this to you. :-)
 
 checkpatch complains about the following:
 
 WARNING: no space between function name and open parenthesis '('
 #520: FILE: drivers/spi/spi_s3c24xx_dma.c:478:
 +   list_for_each_entry (transfer, message-transfers, transfer_list) {
 
 which I think is a bit bogus since it actually is a for statement in
 disguise.  The following patch adds list_for_each to the list of things
 that look like functions that it shouldn't complain about.

We have had some stabs at changing this, but no consensus was reached on
whether it was a for or a function.  My memory is of there being
slightly more without a space tenders than the other and so it has not
been changed.  This thread also seems so far to have not really
generated a concensus.  So I would tend to leave things as they are.  

A third option might be to accept either on *for_each* constructs.
That might tend to lead to divergance.  Difficult.  However, also see my
later comments on style guide.

 
 By the way, what is the consensus on lines over 80 characters?
 checkpatch complains about the following:
 
 WARNING: line over 80 characters
 #762: FILE: drivers/spi/spi_s3c24xx_dma.c:720:
 +   printk(KERN_INFO S3C24xx SPI DMA driver (c) 2007 Nordnav 
 Technologies AB\n);
 
 I can of course break this into:
 
 printk(KERN_INFO S3C24xx SPI DMA driver (c) 2007 Nordnav 
  Technologies AB\n);
 
 but in my opinion that becomes more even unreadable.  Would it be
 possible to add a special case so that checkpatch ignores long strings
 that go beyond 80 characters?  Do you think it is a good idea?

I think you are miss-understanding the point of checkpatch here.  It has
flagged this line as suspect.  You are happy it is better as it is.  You
should therefore leave it as it is as you are happy to justify that
checkpatch failure.  Checkpatch is a style guide, if it complains you
should think about its complaint and act as you see fit in response.
Sometimes you will ignore it, that is fine.

-apw
--
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: struct should not be named same way as function in sony-laptop

2008-01-03 Thread Al Viro

On Thu, Jan 03, 2008 at 12:01:54PM +0100, Pavel Machek wrote:
 Naming struct and function by same name is evil. Rename the struct.

Um... why?  It's not even particulary bad style per se...  Occurs less
frequently than things like
struct foo *foo;
but nothing inherently terrible and not likely to cause any kind of
confusion.
--
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/

[x86] kernel/audit.c cleanup according to checkpatch.pl

2008-01-03 Thread Cyrill Gorcunov

This patch eliminates code-style errors according
to checkpatch.pl

Signed-off-by: Cyrill Gorcunov [EMAIL PROTECTED]
---

Ingo, David, md5sums will be different for old and patched
asm listings due to:

- zero initialized static vars take off
- assignments moved out from 'if' conditions
- EXPORT_SYMBOL's set at appropriate places

anyway the changes are trivial, so even a glance review
would be enough to ensure that it doesn't bring errors
into the kernel

before:
total: 20 errors, 17 warnings, 1473 lines checked
after:
total: 2 errors, 12 warnings, 1480 lines checked

Any comments are welcome.

 kernel/audit.c |   69 ++-
 1 files changed, 38 insertions(+), 31 deletions(-)

diff --git a/kernel/audit.c b/kernel/audit.c
index f93c271..4e71602 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -89,7 +89,7 @@ static intaudit_rate_limit;
 /* Number of outstanding audit_buffers allowed. */
 static int audit_backlog_limit = 64;
 static int audit_backlog_wait_time = 60 * HZ;
-static int audit_backlog_wait_overflow = 0;
+static int audit_backlog_wait_overflow;
 
 /* The identity of the user shutting down the audit system. */
 uid_t  audit_sig_uid = -1;
@@ -158,8 +158,7 @@ static void audit_set_pid(struct audit_buffer *ab, pid_t 
pid)
 
 void audit_panic(const char *message)
 {
-   switch (audit_failure)
-   {
+   switch (audit_failure) {
case AUDIT_FAIL_SILENT:
break;
case AUDIT_FAIL_PRINTK:
@@ -173,15 +172,16 @@ void audit_panic(const char *message)
 
 static inline int audit_rate_check(void)
 {
-   static unsigned longlast_check = 0;
-   static int  messages   = 0;
+   static unsigned longlast_check;
+   static int  messages;
static DEFINE_SPINLOCK(lock);
unsigned long   flags;
unsigned long   now;
unsigned long   elapsed;
int retval = 0;
 
-   if (!audit_rate_limit) return 1;
+   if (!audit_rate_limit)
+   return 1;
 
spin_lock_irqsave(lock, flags);
if (++messages  audit_rate_limit) {
@@ -210,7 +210,7 @@ static inline int audit_rate_check(void)
 */
 void audit_log_lost(const char *message)
 {
-   static unsigned longlast_msg = 0;
+   static unsigned longlast_msg;
static DEFINE_SPINLOCK(lock);
unsigned long   flags;
unsigned long   now;
@@ -232,7 +232,8 @@ void audit_log_lost(const char *message)
 
if (print) {
printk(KERN_WARNING
-  audit: audit_lost=%d audit_rate_limit=%d 
audit_backlog_limit=%d\n,
+  audit: audit_lost=%d audit_rate_limit=%d 
+  audit_backlog_limit=%d\n,
   atomic_read(audit_lost),
   audit_rate_limit,
   audit_backlog_limit);
@@ -253,7 +254,8 @@ static int audit_set_rate_limit(int limit, uid_t loginuid, 
u32 sid)
if (sid) {
char *ctx = NULL;
u32 len;
-   if ((rc = selinux_sid_to_string(sid, ctx, len)) == 0) {
+   rc = selinux_sid_to_string(sid, ctx, len);
+   if (rc == 0) {
audit_log(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE,
audit_rate_limit=%d old=%d by auid=%u
 subj=%s res=%d,
@@ -288,7 +290,8 @@ static int audit_set_backlog_limit(int limit, uid_t 
loginuid, u32 sid)
if (sid) {
char *ctx = NULL;
u32 len;
-   if ((rc = selinux_sid_to_string(sid, ctx, len)) == 0) {
+   rc = selinux_sid_to_string(sid, ctx, len);
+   if (rc == 0) {
audit_log(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE,
audit_backlog_limit=%d old=%d by auid=%u
 subj=%s res=%d,
@@ -326,7 +329,8 @@ static int audit_set_enabled(int state, uid_t loginuid, u32 
sid)
if (sid) {
char *ctx = NULL;
u32 len;
-   if ((rc = selinux_sid_to_string(sid, ctx, len)) == 0) {
+   rc = selinux_sid_to_string(sid, ctx, len);
+   if (rc == 0) {
audit_log(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE,
audit_enabled=%d old=%d by auid=%u
 subj=%s res=%d,
@@ -366,7 +370,8 @@ static int audit_set_failure(int state, uid_t loginuid, u32 
sid)
if (sid) {
char *ctx = NULL;
u32 len;
-   if ((rc = selinux_sid_to_string(sid, ctx, len)) == 0) {
+   rc = selinux_sid_to_string(sid, ctx, len);
+   if (rc == 0) {
audit_log(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE,

Re: [patch 1/3] move WARN_ON() out of line

2008-01-03 Thread Pekka Enberg

Hi Arjan,

On Jan 3, 2008 2:56 AM, Arjan van de Ven [EMAIL PROTECTED] wrote:
 +int do_warn_on(const unsigned long condition, const char *file,
 +   const int line, const char *function)
 +{
 +   if (unlikely(condition)) {
 +   printk(KERN_WARNING WARNING: at %s:%d %s()\n,
 +   __FILE__, __LINE__, __FUNCTION__);

I don't think you want to use __FILE__ and friends here...
--
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] teach checkpatch.pl about list_for_each

2008-01-03 Thread pHilipp Zabel

On Dec 2, 2007 1:03 PM, Christer Weinigel [EMAIL PROTECTED] wrote:
 Hi Andy,

 you seem to be the last person messing around with checkpatch.pl so I'm
 addressing this to you. :-)

 checkpatch complains about the following:

 WARNING: no space between function name and open parenthesis '('
 #520: FILE: drivers/spi/spi_s3c24xx_dma.c:478:
 +   list_for_each_entry (transfer, message-transfers, transfer_list) {

 which I think is a bit bogus since it actually is a for statement in
 disguise.  The following patch adds list_for_each to the list of things
 that look like functions that it shouldn't complain about.

 By the way, what is the consensus on lines over 80 characters?
 checkpatch complains about the following:

 WARNING: line over 80 characters
 #762: FILE: drivers/spi/spi_s3c24xx_dma.c:720:
 +   printk(KERN_INFO S3C24xx SPI DMA driver (c) 2007 Nordnav 
 Technologies AB\n);

 I can of course break this into:

 printk(KERN_INFO S3C24xx SPI DMA driver (c) 2007 Nordnav 
Technologies AB\n);

I'd not split it in the middle of a name or phrase if possible.
printk(KERN_INFO S3C24xx SPI DMA driver
(c) 2007 Nordnav Technologies AB\n);
but ...

 but in my opinion that becomes more even unreadable.  Would it be
 possible to add a special case so that checkpatch ignores long strings
 that go beyond 80 characters?  Do you think it is a good idea?

... in this case
   pr_info(S3C24xx SPI DMA driver (c) 2007 Nordnav Technologies AB\n);
might just push it under the limit.

cheers
Philipp
--
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: [x86] kernel/audit.c cleanup according to checkpatch.pl

2008-01-03 Thread Jörn Engel

On Thu, 3 January 2008 14:19:25 +0300, Cyrill Gorcunov wrote:
 @@ -232,7 +232,8 @@ void audit_log_lost(const char *message)
  
   if (print) {
   printk(KERN_WARNING
 -audit: audit_lost=%d audit_rate_limit=%d 
 audit_backlog_limit=%d\n,
 +audit: audit_lost=%d audit_rate_limit=%d 
 +audit_backlog_limit=%d\n,
  atomic_read(audit_lost),
  audit_rate_limit,
  audit_backlog_limit);

This hunk is a bit questionable.  It can easily deceive a reader to
assume two seperate lines printed out and sometimes defeats grepping
for printk output to find the code generating the message.

Rest looks good to me.

Jörn

-- 
He that composes himself is wiser than he that composes a book.
-- B. Franklin
--
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: [PATCHv3] powerpc: DBox2 Board Support

2008-01-03 Thread Jochen Friedrich


Hi David,


+/ {
+   model = unknown,dbox2; // boot wrapper fills in correct manufacturer


Probably better just to leave model out of the dts and let the
bootwrapper add it.


Unfortunately, dtc requires a model:

$ dtc arch/powerpc/boot/dts/dbox2.dts
DTC: dts-dts  on file arch/powerpc/boot/dts/dbox2.dts
ERROR: Missing model property in /


+   [EMAIL PROTECTED],0 {
+   compatible = cfi-flash;
+   reg = 0 0 80;
+   bank-width = 4;
+   device-width = 1;
+   #address-cells = 1;
+   #size-cells = 1;
+   [EMAIL PROTECTED] {
+   label = BR bootloader;
+   reg = 0 2;
+   read-only;
+   };
+   [EMAIL PROTECTED] {
+   label = FLFS (U-Boot);
+   reg = 2 2;
+   };
+   [EMAIL PROTECTED] {
+   label = rootfs;
+   reg = 4 7c;
+   };
+   [EMAIL PROTECTED] {


Uh.. I really don't know what the MTD driver will handle these
overlapping partitions.  I suspect it will not be pretty...


+   label = Flash without bootloader;
+   reg = 2 7e;
+   };
+   [EMAIL PROTECTED] {
+   label = Complete Flash;
+   reg = 0 80;
+   read-only;
+   };
+   };
+   };


MTD handles this correctly. dbox2 uses Flash without bootloader for flashing image 
updates and Complete Flash for creating a backup of everything.
OpenWRT also uses overlapping partitions BTW (and also for flashing updates).

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: freeze vs freezer

2008-01-03 Thread Oliver Neukum

Am Donnerstag, 3. Januar 2008 10:52:53 schrieb Nigel Cunningham:
 Hi.
 
 Oliver Neukum wrote:
  Am Donnerstag 03 Januar 2008 schrieb Nigel Cunningham:
  On top of this, I made a (too simple at the moment) freeze_filesystems
  function which iterates through super_blocks in reverse order, freezing
  fuse filesystems or ordinary ones. I say 'too simple' because it doesn't
  currently allow for the possibility of someone mounting (say) ext3 on
  fuse, but that would just be an extension of what's already done.
  
  How do you deal with fuse server tasks using other fuse filesystems?
 
 Since they're frozen in reverse order, the dependant one would be frozen
 first.

Say I do:

a) mount fuse on /tmp/first
b) mount fuse on /tmp/second

Then the server task for (a) does ls /tmp/second. So it will be frozen,
right? How do you then freeze (a)? And keep in mind that the server task
may have forked.

Regards
Oliver
--
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: [x86] kernel/audit.c cleanup according to checkpatch.pl

2008-01-03 Thread Cyrill Gorcunov

[=?ISO-8859-1?Q?J=F6rn_Engel_ - Thu, Jan 03, 2008 at 12:29:57PM +0100]
| On Thu, 3 January 2008 14:19:25 +0300, Cyrill Gorcunov wrote:
|  @@ -232,7 +232,8 @@ void audit_log_lost(const char *message)
|   
|  if (print) {
|  printk(KERN_WARNING
|  -  audit: audit_lost=%d audit_rate_limit=%d 
audit_backlog_limit=%d\n,
|  +  audit: audit_lost=%d audit_rate_limit=%d 
|  +  audit_backlog_limit=%d\n,
| atomic_read(audit_lost),
| audit_rate_limit,
| audit_backlog_limit);
| 
| This hunk is a bit questionable.  It can easily deceive a reader to
| assume two seperate lines printed out and sometimes defeats grepping
| for printk output to find the code generating the message.
| 
| Rest looks good to me.
| 
| Jörn
| 
| -- 
| He that composes himself is wiser than he that composes a book.
| -- B. Franklin
| 

indeed.

here is updated one (with these part removed)

---

 kernel/audit.c |   66 ++-
 1 files changed, 36 insertions(+), 30 deletions(-)

diff --git a/kernel/audit.c b/kernel/audit.c
index f93c271..22b951e 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -89,7 +89,7 @@ static intaudit_rate_limit;
 /* Number of outstanding audit_buffers allowed. */
 static int audit_backlog_limit = 64;
 static int audit_backlog_wait_time = 60 * HZ;
-static int audit_backlog_wait_overflow = 0;
+static int audit_backlog_wait_overflow;
 
 /* The identity of the user shutting down the audit system. */
 uid_t  audit_sig_uid = -1;
@@ -158,8 +158,7 @@ static void audit_set_pid(struct audit_buffer *ab, pid_t 
pid)
 
 void audit_panic(const char *message)
 {
-   switch (audit_failure)
-   {
+   switch (audit_failure) {
case AUDIT_FAIL_SILENT:
break;
case AUDIT_FAIL_PRINTK:
@@ -173,15 +172,16 @@ void audit_panic(const char *message)
 
 static inline int audit_rate_check(void)
 {
-   static unsigned longlast_check = 0;
-   static int  messages   = 0;
+   static unsigned longlast_check;
+   static int  messages;
static DEFINE_SPINLOCK(lock);
unsigned long   flags;
unsigned long   now;
unsigned long   elapsed;
int retval = 0;
 
-   if (!audit_rate_limit) return 1;
+   if (!audit_rate_limit)
+   return 1;
 
spin_lock_irqsave(lock, flags);
if (++messages  audit_rate_limit) {
@@ -210,7 +210,7 @@ static inline int audit_rate_check(void)
 */
 void audit_log_lost(const char *message)
 {
-   static unsigned longlast_msg = 0;
+   static unsigned longlast_msg;
static DEFINE_SPINLOCK(lock);
unsigned long   flags;
unsigned long   now;
@@ -253,7 +253,8 @@ static int audit_set_rate_limit(int limit, uid_t loginuid, 
u32 sid)
if (sid) {
char *ctx = NULL;
u32 len;
-   if ((rc = selinux_sid_to_string(sid, ctx, len)) == 0) {
+   rc = selinux_sid_to_string(sid, ctx, len);
+   if (rc == 0) {
audit_log(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE,
audit_rate_limit=%d old=%d by auid=%u
 subj=%s res=%d,
@@ -288,7 +289,8 @@ static int audit_set_backlog_limit(int limit, uid_t 
loginuid, u32 sid)
if (sid) {
char *ctx = NULL;
u32 len;
-   if ((rc = selinux_sid_to_string(sid, ctx, len)) == 0) {
+   rc = selinux_sid_to_string(sid, ctx, len);
+   if (rc == 0) {
audit_log(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE,
audit_backlog_limit=%d old=%d by auid=%u
 subj=%s res=%d,
@@ -326,7 +328,8 @@ static int audit_set_enabled(int state, uid_t loginuid, u32 
sid)
if (sid) {
char *ctx = NULL;
u32 len;
-   if ((rc = selinux_sid_to_string(sid, ctx, len)) == 0) {
+   rc = selinux_sid_to_string(sid, ctx, len);
+   if (rc == 0) {
audit_log(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE,
audit_enabled=%d old=%d by auid=%u
 subj=%s res=%d,
@@ -366,7 +369,8 @@ static int audit_set_failure(int state, uid_t loginuid, u32 
sid)
if (sid) {
char *ctx = NULL;
u32 len;
-   if ((rc = selinux_sid_to_string(sid, ctx, len)) == 0) {
+   rc = selinux_sid_to_string(sid, ctx, len);
+   if (rc == 0) {
audit_log(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE,
audit_failure=%d old=%d by auid=%u
 subj=%s res=%d,
@@ -626,18

[Patch] xfrm_policy_destroy: rename and relative fixes

2008-01-03 Thread WANG Cong


Since __xfrm_policy_destroy is used to destory the resources
allocated by xfrm_policy_alloc. So using the name
__xfrm_policy_destroy is not correspond with xfrm_policy_alloc.
Rename it to xfrm_policy_destroy.

And along with some instances that call xfrm_policy_alloc
but not using xfrm_policy_destroy to destroy the resource,
fix them.

Cc: David Miller [EMAIL PROTECTED]
Cc: Herbert Xu [EMAIL PROTECTED]
Signed-off-by: WANG Cong [EMAIL PROTECTED]

---

diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 58dfa82..6eff085 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -505,12 +505,12 @@ static inline void xfrm_pol_hold(struct xfrm_policy 
*policy)
atomic_inc(policy-refcnt);
 }
 
-extern void __xfrm_policy_destroy(struct xfrm_policy *policy);
+extern void xfrm_policy_destroy(struct xfrm_policy *policy);
 
 static inline void xfrm_pol_put(struct xfrm_policy *policy)
 {
if (atomic_dec_and_test(policy-refcnt))
-   __xfrm_policy_destroy(policy);
+   xfrm_policy_destroy(policy);
 }
 
 #ifdef CONFIG_XFRM_SUB_POLICY
diff --git a/net/key/af_key.c b/net/key/af_key.c
index 26d5e63..3667f44 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -2291,8 +2291,7 @@ static int pfkey_spdadd(struct sock *sk, struct sk_buff 
*skb, struct sadb_msg *h
return 0;
 
 out:
-   security_xfrm_policy_free(xp);
-   kfree(xp);
+   xfrm_policy_destroy(xp);
return err;
 }
 
@@ -3236,8 +3235,7 @@ static struct xfrm_policy *pfkey_compile_policy(struct 
sock *sk, int opt,
return xp;
 
 out:
-   security_xfrm_policy_free(xp);
-   kfree(xp);
+   xfrm_policy_destroy(xp);
return NULL;
 }
 
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 26b846e..087484e 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -206,7 +206,7 @@ EXPORT_SYMBOL(xfrm_policy_alloc);
 
 /* Destroy xfrm_policy: descendant resources must be released to this moment. 
*/
 
-void __xfrm_policy_destroy(struct xfrm_policy *policy)
+void xfrm_policy_destroy(struct xfrm_policy *policy)
 {
BUG_ON(!policy-dead);
 
@@ -218,7 +218,7 @@ void __xfrm_policy_destroy(struct xfrm_policy *policy)
security_xfrm_policy_free(policy);
kfree(policy);
 }
-EXPORT_SYMBOL(__xfrm_policy_destroy);
+EXPORT_SYMBOL(xfrm_policy_destroy);
 
 static void xfrm_policy_gc_kill(struct xfrm_policy *policy)
 {
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index e75dbdc..73cc755 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1048,7 +1048,7 @@ static struct xfrm_policy *xfrm_policy_construct(struct 
xfrm_userpolicy_info *p,
return xp;
  error:
*errp = err;
-   kfree(xp);
+   xfrm_policy_destroy(xp);
return 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/

Re: [x86] kernel/audit.c cleanup according to checkpatch.pl

2008-01-03 Thread Cyrill Gorcunov

[Tomas Carnecky - Thu, Jan 03, 2008 at 01:10:28PM +0100]
 Cyrill Gorcunov wrote:
 [=?ISO-8859-1?Q?J=F6rn_Engel_ - Thu, Jan 03, 2008 at 12:29:57PM +0100]
 | On Thu, 3 January 2008 14:19:25 +0300, Cyrill Gorcunov wrote:
 |  @@ -232,7 +232,8 @@ void audit_log_lost(const char *message)
 |   |  if (print) {
 |   printk(KERN_WARNING
 |  -   audit: audit_lost=%d audit_rate_limit=%d 
 audit_backlog_limit=%d\n,
 |  +   audit: audit_lost=%d audit_rate_limit=%d 
 |  +   audit_backlog_limit=%d\n,
 |  atomic_read(audit_lost),
 |  audit_rate_limit,
 |  audit_backlog_limit);
 | | This hunk is a bit questionable.  It can easily deceive a reader to
 | assume two seperate lines printed out and sometimes defeats grepping
 | for printk output to find the code generating the message.
 | | Rest looks good to me.
 | | Jörn
 | | -- | He that composes himself is wiser than he that composes a book.
 | -- B. Franklin
 | indeed.
 here is updated one (with these part removed)

 Instead of removing that part completely, why not print this:
 audit: lost=%d rate_limit=%d backlog_limit=%d\n

 In that line there were too many 'audit's IMHO, and if someone wants to 
 grep 'audit_lost=' he still can, 'audit:.*lost=' or something like that..

 tom


Well, it seems David is a mainteiner of this code,
so if he would not argue against this the we could.

- Cyrill -
--
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] teach checkpatch.pl about list_for_each

2008-01-03 Thread Christoph Hellwig

On Thu, Jan 03, 2008 at 11:10:58AM +, Andy Whitcroft wrote:
 We have had some stabs at changing this, but no consensus was reached on
 whether it was a for or a function.  My memory is of there being
 slightly more without a space tenders than the other and so it has not
 been changed.  This thread also seems so far to have not really
 generated a concensus.  So I would tend to leave things as they are.  
 
 A third option might be to accept either on *for_each* constructs.
 That might tend to lead to divergance.  Difficult.  However, also see my
 later comments on style guide.

Pretty much all core code uses list_for_each_entry( so new code should
follow that example.

--
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: [x86] kernel/audit.c cleanup according to checkpatch.pl

2008-01-03 Thread Tomas Carnecky


Cyrill Gorcunov wrote:

[=?ISO-8859-1?Q?J=F6rn_Engel_ - Thu, Jan 03, 2008 at 12:29:57PM +0100]
| On Thu, 3 January 2008 14:19:25 +0300, Cyrill Gorcunov wrote:
|  @@ -232,7 +232,8 @@ void audit_log_lost(const char *message)
|   
|   	if (print) {

|   printk(KERN_WARNING
|  -   audit: audit_lost=%d audit_rate_limit=%d 
audit_backlog_limit=%d\n,
|  +   audit: audit_lost=%d audit_rate_limit=%d 
|  +   audit_backlog_limit=%d\n,
|  atomic_read(audit_lost),
|  audit_rate_limit,
|  audit_backlog_limit);
| 
| This hunk is a bit questionable.  It can easily deceive a reader to

| assume two seperate lines printed out and sometimes defeats grepping
| for printk output to find the code generating the message.
| 
| Rest looks good to me.
| 
| Jörn
| 
| -- 
| He that composes himself is wiser than he that composes a book.

| -- B. Franklin
| 


indeed.

here is updated one (with these part removed)


Instead of removing that part completely, why not print this:
audit: lost=%d rate_limit=%d backlog_limit=%d\n

In that line there were too many 'audit's IMHO, and if someone wants to 
grep 'audit_lost=' he still can, 'audit:.*lost=' or something like that..


tom
--
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] teach checkpatch.pl about list_for_each

2008-01-03 Thread Arnaldo Carvalho de Melo

Em Thu, Jan 03, 2008 at 12:26:10PM +, Christoph Hellwig escreveu:
 On Thu, Jan 03, 2008 at 11:10:58AM +, Andy Whitcroft wrote:
  We have had some stabs at changing this, but no consensus was reached on
  whether it was a for or a function.  My memory is of there being
  slightly more without a space tenders than the other and so it has not
  been changed.  This thread also seems so far to have not really
  generated a concensus.  So I would tend to leave things as they are.  
  
  A third option might be to accept either on *for_each* constructs.
  That might tend to lead to divergance.  Difficult.  However, also see my
  later comments on style guide.
 
 Pretty much all core code uses list_for_each_entry( so new code should
 follow that example.

Agreed, CodingStyle is not about mindless consistency such as for ( is
the right thing, so list_for_each ( is consistent with it, it is about
codifying practice contributors got used to over the years.

- Arnaldo
--
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] teach checkpatch.pl about list_for_each

2008-01-03 Thread Tomas Carnecky


Christer Weinigel wrote:

By the way, what is the consensus on lines over 80 characters?
checkpatch complains about the following:

WARNING: line over 80 characters
#762: FILE: drivers/spi/spi_s3c24xx_dma.c:720:
+   printk(KERN_INFO S3C24xx SPI DMA driver (c) 2007 Nordnav Technologies 
AB\n);

I can of course break this into:

printk(KERN_INFO S3C24xx SPI DMA driver (c) 2007 Nordnav 
   Technologies AB\n);

but in my opinion that becomes more even unreadable.  Would it be
possible to add a special case so that checkpatch ignores long strings
that go beyond 80 characters?  Do you think it is a good idea?


At the top of the file add a #define and use that in the code? Some 
drivers define their version/author etc that way and then just

printk(DRIVER_VERSION DRIVER_AUTHOR);

tom
--
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: serial console _after_ boot ? - was: Redirect kernel console

2008-01-03 Thread devzero

hi !

i was wondering how to make kernel messages appear on /dev/ttyS0 without a 
reboot, i.e. kernelparam console=ttyS0

after playing for a while with setconsole, setterm and klogconsole i didn`t 
find a way to make that happen.

i can do setconsole /dev/tty1 /dev/console and then echo test 
/dev/console and see test on tty1

setterm -msg on -msglevel 8 /dev/console  (or /dev/tty1), modprobe 
loop;rmmod loop - and i see the kernel message there
   
i can do setconsole /dev/ttyS0 /dev/console and then echo test 
/dev/console and see test on ttyS0

BUT :

setterm -msg on -msglevel 8 /dev/console  (or /dev/ttyS0), modprobe 
loop;rmmod loop  ..  nothing!

since i came across jan`s posting from 2005, which didn`t get a reply i think 
it`s not that stupid to ask again...

any clue how to do that at runtime or what`s the issue here ? (see excerpts 
below) 

i can set 
regards
roland



List:   linux-kernel
Subject:Redirect kernel console
From:   Jan Engelhardt jengelh () linux01 ! gwdg ! de
Date:   2005-08-13 12:48:22
Message-ID: Pine.LNX.4.61.0508131447220.4457 () yvahk01 ! tjqt ! qr
[Download message RAW]

Hi,


there is a klogconsole utiltity that allows to change the console to which 
kernel messages are printed. However, is it possible to redirect to ttyS0 
without a reboot?


Jan Engelhardt
--- 





 Subject: Re: serial console _after_ boot ?

  Setterm outputs the correct escape sequences to stdout. You can 
  configure another tty using 'setterm -msglevel 8 -msg on  /dev/ttyS0'. 
  I tested this on the standard kernel consoles (/dev/tty1-9), and it 
  worked. You obviously need root access to write the escape sequences to 
  the tty's.
 
 oh - yes, this works! but with tty1-9 only.
 not with ttyS0 :(

.as the docs tell.

 Some options  however  (marked  virtual  consoles  only below)  do  not  
 correspond to a terminfo(5) capability.

  -msg [on|off] (virtual consoles only)
  Enables or disables the sending of kernel printk() messages to 
 the console.

   -msglevel 1-8 (virtual consoles only)
  Sets the console logging level for kernel printk() messages.  
 All messages strictly more important than  this
  will  be  printed, so a logging level of 0 has the same effect 
 as -msg on and a logging level of 8 will print
  all kernel messages.  klogd(8) may be a more convenient 
 interface to the logging of kernel messages.


   but i don`t have change_console. 
   searched the net and found that this eventually should be part of 
   sysvinit package.
   but mine doesn`t provide that tool.
   
   found setconsole which looks like something similar, but setconsole 
   /dev/ttyS0  /dev/console
   doesn`t have any effect
  
  What distribution do you use? I have change_console on gentoo, yet I 
  cannot find the tool on a debian etch. But that's a vserver, so it's 
  probably not a reference.
 
 i have opensuse 10.3

_
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071distributionid=0066

--
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: [uml-devel] UML woes in 2.6.24-rc6-mm1

2008-01-03 Thread Miklos Szeredi

  32bit UML, 64bit host, config attached.
 
 Hadn't tried that, but that works here too.
 
 I'll see if your config reproduces it.
 
  Can't reproduce with plain -rc6.
 
 Feel like bisecting -mm1?

This is the one: uml-runtime-detection-of-host-vmsplit-on-i386.patch

The relevant log line (both for successful and failed boots):

Locating the top of the address space ... 0xffc0

Miklos

--
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/20] x86: Make ptrace.h safe to include from assembler code

On Thursday 03 January 2008 10:54:52 Ingo Molnar wrote:
 
 * Andi Kleen [EMAIL PROTECTED] wrote:
 
  Index: linux/include/asm-x86/ptrace-abi.h
  ===
  --- linux.orig/include/asm-x86/ptrace-abi.h
  +++ linux/include/asm-x86/ptrace-abi.h
  @@ -80,6 +80,7 @@
   
   #define PTRACE_SINGLEBLOCK 33  /* resume execution until next branch */
   
  +#ifndef __ASSEMBLY__
 
 hm, this patch misses a rationale - what assembly code includes 
 ptrace-abi.h directly or indirectly? Did you see any build breakage with 
 x86.git that requires this? (if yes then please send me the .config)

It's needed for the dwarf2 unwinder, but imho useful on its own.

-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] [19/20] x86: Use shorter addresses in i386 segfault printks

On Thursday 03 January 2008 11:56:14 Ingo Molnar wrote:
 
 * Andi Kleen [EMAIL PROTECTED] wrote:
 
  x86: Use shorter addresses in i386 segfault printks
 
 hm, why? It's pretty well-established that we print addresses 8 char 
 wide on 32-bit.

It's useless. What purpose does it have?

-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: Make checkpatch.pl's quiet option not print the summary on no errors

2008-01-03 Thread Andy Whitcroft

On Thu, Jan 03, 2008 at 01:54:42AM +0100, Arjan van de Ven wrote:
 Subject: Make checkpatch.pl's quiet option not print the summary on no 
 errors
 From: Arjan van de Ven [EMAIL PROTECTED]
 CC: [EMAIL PROTECTED]

 Right now, in quiet mode, checkpatch.pl still prints a summary line even
 if the patch is 100% clean. IMO, quiet mode should mean no output if 
 clean,
 the patch below makes that so. (This also makes the quilt integration
 on my system work nicer :)

 Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]

I think that sounds reasonable.  Should people want the summary
regardless it makes more sense to provice an option for that, perhaps a
doubling of the --summary flag.

Will be in 0.13.

-apw
--
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-x86 broken on 32bit

On Thursday 03 January 2008 09:10:25 Ingo Molnar wrote:
 
 * Ingo Molnar [EMAIL PROTECTED] wrote:
 
  * Andi Kleen [EMAIL PROTECTED] wrote:
  
   Current git-x86 seems to be totally broken on i386
   
   commit a6f08929f0566f9d309ef5f6651371d8e20fc833
   Author: Russell Leidich [EMAIL PROTECTED]
   Date:   Wed Jan 2 22:46:22 2008 +0100
  
  that patch was not included in x86.git anymore at the time you wrote 
  your email. You probably picked up an interim version of the queue 
  that had the breakage - i noticed it and pulled it a few minutes 
  later.
 
 correction: i had fixed it but did not push it out - pushed it out now. 
 Please check that it works for you.

I'll check once git.kernel.org unbreaks itself

% git pull -u
fatal: The remote end hung up unexpectedly
Cannot get the repository state from 
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git

-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 2/3] CONFIG_HIGHPTE vs. sub-page page tables.


 Can we please just nuke CONFIG_HIGHPTE?  There's only been a small
 amount of 32bit machines 

It's unfortunately a larger amount :/ And for unknown reasons a lot of
people still install 32bit kernels on new perfectly capable 64bit systems
even if they have a lot of memory.

I don't think removing CONFIG_HIGHPTE will be an option any time soon.

-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] [20/20] x86: Print which shared library/executable faulted in segfault etc. messages


  And printing the offset into a mapping also always allows to find the 
  correct fault point in a library even with randomized mappings. Previously
  there was no way to actually find the correct code address inside
  the randomized mapping.
  
  Relies on earlier patch to shorten the printk formats.
  
  They are often now longer than 80 characters, but I think that's worth 
  it.
 
 why not make it multi-line? that way the %lx hack wouldnt be needed 
 either.

I prefer it single-line. I also disagree on %lx being a hack.

 
  +void print_vma_addr(char *prefix, unsigned long ip)
  +{
  +   struct mm_struct *mm = current-mm;
  +   struct vm_area_struct *vma;
  +   down_read(mm-mmap_sem);
  +   vma = find_vma(mm, ip);
 
 grumble. Proper CodingStyle please.


Looks fine to me. If you mean the new line after variables -- that was always 
optional.

Anyways I'll repost with the error check.

Also it seems like you did apply only parts of the patchkit. If you do that can
you send a list of what patches you didn't add, otherwise it'll be messy to 
figure
this out from here.

-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: [Bluez-devel] Oops involving RFCOMM and sysfs

2008-01-03 Thread Gabor Gombas

On Wed, Jan 02, 2008 at 04:16:42PM +0100, Gabor Gombas wrote:

 So the patch referenced above does not help. But I've found a very easy
 way to trigger the bug:
 
 - do a cat /dev/zero  /dev/rfcomm0
 - switch the phone off
 - switch the phone on, and the kernel oopses

FYI I also remember having oopses with 2.6.22.something but I do not
have those logs anymore. Also I now booted 2.6.20.7 and it did not oops.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -
--
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/

[RESEND PATCH 0/10] ide-floppy redux p1


Hi Bart,

here's the unfinished redux of ide-floppy which i'm REsending now so that we 
could
sinchronize trees. The original send got busted in vger's filters due to syntax
error in the Message-ID tag.

 Documentation/ide/ChangeLog.ide-floppy.1996-2002 |   64 ++
 drivers/ide/ide-floppy.c | 1248 +++---
 drivers/ide/ide-floppy.h |  351 ++
 include/linux/cdrom.h|1 +
 4 files changed, 819 insertions(+), 845 deletions(-)

--
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/

[RESEND PATCH 05/10] ide-floppy: factor out ioctl handlers from idefloppy_ioctl()

There should be no functional change resulting from this patch.

Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
---
 drivers/ide/ide-floppy.c |   90 +-
 1 files changed, 57 insertions(+), 33 deletions(-)

diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 196a697..7823447 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -1600,6 +1600,58 @@ static int idefloppy_getgeo(struct block_device *bdev, 
struct hd_geometry *geo)
return 0;
 }
 
+static int idefloppy_lockdoor(struct inode *inode, idefloppy_pc_t *pc,
+   int event, unsigned int cmd)
+{
+   struct block_device *bdev = inode-i_bdev;
+   struct ide_floppy_obj *floppy = ide_floppy_g(bdev-bd_disk);
+   ide_drive_t *drive = floppy-drive;
+
+   if (floppy-openers  1)
+   return -EBUSY;
+
+   /* The IOMEGA Clik! Drive doesn't support this command -
+* no room for an eject mechanism */
+   if (!test_bit(IDEFLOPPY_CLIK_DRIVE, floppy-flags)) {
+   idefloppy_create_prevent_cmd(pc, event);
+   (void) idefloppy_queue_pc_tail(drive, pc);
+   }
+
+   if (cmd == CDROMEJECT) {
+   idefloppy_create_start_stop_cmd(pc, 2);
+   (void) idefloppy_queue_pc_tail(drive, pc);
+   }
+
+   return 0;
+}
+
+static
+int idefloppy_format_start(struct file *file, struct inode *inode,
+   void __user *argp)
+{
+   struct block_device *bdev = inode-i_bdev;
+   struct ide_floppy_obj *floppy = ide_floppy_g(bdev-bd_disk);
+   ide_drive_t *drive = floppy-drive;
+   int err;
+
+   if (!(file-f_mode  2))
+   return -EPERM;
+
+   if (floppy-openers  1) {
+   /* Don't format if someone is using the disk */
+   clear_bit(IDEFLOPPY_FORMAT_IN_PROGRESS, floppy-flags);
+   return -EBUSY;
+   }
+
+   set_bit(IDEFLOPPY_FORMAT_IN_PROGRESS, floppy-flags);
+
+   err = idefloppy_begin_format(drive, argp);
+   if (err)
+   clear_bit(IDEFLOPPY_FORMAT_IN_PROGRESS, floppy-flags);
+
+   return err;
+}
+
 static int idefloppy_ioctl(struct inode *inode, struct file *file,
unsigned int cmd, unsigned long arg)
 {
@@ -1612,47 +1664,19 @@ static int idefloppy_ioctl(struct inode *inode, struct 
file *file,
idefloppy_pc_t pc;
 
switch (cmd) {
+
case CDROMEJECT:
prevent = 0;
/* fall through */
-   case CDROM_LOCKDOOR:
-   if (floppy-openers  1)
-   return -EBUSY;
 
-   /* The IOMEGA Clik! Drive doesn't support this command -
-* no room for an eject mechanism */
-if (!test_bit(IDEFLOPPY_CLIK_DRIVE, floppy-flags)) {
-   idefloppy_create_prevent_cmd(pc, prevent);
-   (void) idefloppy_queue_pc_tail(drive, pc);
-   }
-   if (cmd == CDROMEJECT) {
-   idefloppy_create_start_stop_cmd(pc, 2);
-   (void) idefloppy_queue_pc_tail(drive, pc);
-   }
-   return 0;
+   case CDROM_LOCKDOOR:
+   return idefloppy_lockdoor(inode, pc, prevent, cmd);
case IDEFLOPPY_IOCTL_FORMAT_SUPPORTED:
return 0;
case IDEFLOPPY_IOCTL_FORMAT_GET_CAPACITY:
return idefloppy_get_format_capacities(drive, argp);
case IDEFLOPPY_IOCTL_FORMAT_START:
-
-   if (!(file-f_mode  2))
-   return -EPERM;
-
-   if (floppy-openers  1) {
-
-   /* Don't format if someone is using the disk */
-   clear_bit(IDEFLOPPY_FORMAT_IN_PROGRESS,
- floppy-flags);
-   return -EBUSY;
-   }
-
-   set_bit(IDEFLOPPY_FORMAT_IN_PROGRESS, floppy-flags);
-
-   err = idefloppy_begin_format(drive, argp);
-   if (err)
-   clear_bit(IDEFLOPPY_FORMAT_IN_PROGRESS, floppy-flags);
-   return err;
+   return idefloppy_format_start(file, inode, argp);
/*
 * Note, the bit will be cleared when the device is
 * closed.  This is the cleanest way to handle the
@@ -1669,7 +1693,7 @@ static int idefloppy_ioctl(struct inode *inode, struct 
file *file,
 */
if (cmd != CDROM_SEND_PACKET  cmd != SCSI_IOCTL_SEND_COMMAND)
err = scsi_cmd_ioctl(file, bdev-bd_disk-queue,
-   bdev-bd_disk, cmd, argp);
+   bdev-bd_disk, cmd, argp);
else
err = -ENOTTY;
 
-- 
1.5.3.7

--
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

[RESEND PATCH 03/10] ide-floppy: convert to generic packet commands

Replace the ide-floppy packet commands opcode defines with the generic ones.
Add a missing GPCMD_WRITE_12 (opcode 0xaa) to the generic ones in cdrom.h. The
last one can be found in the current version of INF-8090, p.905.

CC: Jens Axboe [EMAIL PROTECTED]
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
---
 drivers/ide/ide-floppy.c |   26 +-
 drivers/ide/ide-floppy.h |   21 -
 include/linux/cdrom.h|1 +
 3 files changed, 14 insertions(+), 34 deletions(-)

diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 52d09c1..4fb6128 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -313,7 +313,7 @@ static void idefloppy_init_pc (idefloppy_pc_t *pc)
 static void idefloppy_create_request_sense_cmd (idefloppy_pc_t *pc)
 {
idefloppy_init_pc(pc);
-   pc-c[0] = IDEFLOPPY_REQUEST_SENSE_CMD;
+   pc-c[0] = GPCMD_REQUEST_SENSE;
pc-c[4] = 255;
pc-request_transfer = 18;
pc-callback = idefloppy_request_sense_callback;
@@ -379,7 +379,7 @@ static ide_startstop_t idefloppy_pc_intr (ide_drive_t 
*drive)
debug_log(KERN_INFO ide-floppy: %s: I/O error\n,
drive-name);
rq-errors++;
-   if (pc-c[0] == IDEFLOPPY_REQUEST_SENSE_CMD) {
+   if (pc-c[0] == GPCMD_REQUEST_SENSE) {
printk(KERN_ERR ide-floppy: I/O error in 
request sense command\n);
return ide_do_reset(drive);
@@ -586,8 +586,8 @@ static ide_startstop_t idefloppy_issue_pc (ide_drive_t 
*drive, idefloppy_pc_t *p
  and have lived on another thread's stack; that stack may have become
  unmapped meanwhile (CONFIG_DEBUG_PAGEALLOC). */
 #if IDEFLOPPY_DEBUG_BUGS
-   if (floppy-pc-c[0] == IDEFLOPPY_REQUEST_SENSE_CMD 
-   pc-c[0] == IDEFLOPPY_REQUEST_SENSE_CMD) {
+   if (floppy-pc-c[0] == GPCMD_REQUEST_SENSE 
+   pc-c[0] == GPCMD_REQUEST_SENSE) {
printk(KERN_ERR ide-floppy: possible ide-floppy.c bug - 
Two request sense in serial were issued\n);
}
@@ -595,7 +595,7 @@ static ide_startstop_t idefloppy_issue_pc (ide_drive_t 
*drive, idefloppy_pc_t *p
 #endif
 
if (floppy-failed_pc == NULL 
-   pc-c[0] != IDEFLOPPY_REQUEST_SENSE_CMD)
+   pc-c[0] != GPCMD_REQUEST_SENSE)
floppy-failed_pc = pc;
/* Set the current packet command */
floppy-pc = pc;
@@ -690,14 +690,14 @@ static void idefloppy_create_prevent_cmd (idefloppy_pc_t 
*pc, int prevent)
prevent = %d\n, prevent);
 
idefloppy_init_pc(pc);
-   pc-c[0] = IDEFLOPPY_PREVENT_REMOVAL_CMD;
+   pc-c[0] = GPCMD_PREVENT_ALLOW_MEDIUM_REMOVAL;
pc-c[4] = prevent;
 }
 
 static void idefloppy_create_read_capacity_cmd (idefloppy_pc_t *pc)
 {
idefloppy_init_pc(pc);
-   pc-c[0] = IDEFLOPPY_READ_CAPACITY_CMD;
+   pc-c[0] = GPCMD_READ_FORMAT_CAPACITIES;
pc-c[7] = 255;
pc-c[8] = 255;
pc-request_transfer = 255;
@@ -707,7 +707,7 @@ static void idefloppy_create_format_unit_cmd 
(idefloppy_pc_t *pc, int b, int l,
  int flags)
 {
idefloppy_init_pc(pc);
-   pc-c[0] = IDEFLOPPY_FORMAT_UNIT_CMD;
+   pc-c[0] = GPCMD_FORMAT_UNIT;
pc-c[1] = 0x17;
 
memset(pc-buffer, 0, 12);
@@ -733,7 +733,7 @@ static void idefloppy_create_mode_sense_cmd (idefloppy_pc_t 
*pc, u8 page_code,
u16 length = sizeof(idefloppy_mode_par_hdr_t);
 
idefloppy_init_pc(pc);
-   pc-c[0] = IDEFLOPPY_MODE_SENSE_CMD;
+   pc-c[0] = GPCMD_MODE_SENSE_10;
pc-c[1] = 0;
pc-c[2] = page_code + (type  6);
 
@@ -755,14 +755,14 @@ static void idefloppy_create_mode_sense_cmd 
(idefloppy_pc_t *pc, u8 page_code,
 static void idefloppy_create_start_stop_cmd (idefloppy_pc_t *pc, int start)
 {
idefloppy_init_pc(pc);
-   pc-c[0] = IDEFLOPPY_START_STOP_CMD;
+   pc-c[0] = GPCMD_START_STOP_UNIT;
pc-c[4] = start;
 }
 
 static void idefloppy_create_test_unit_ready_cmd(idefloppy_pc_t *pc)
 {
idefloppy_init_pc(pc);
-   pc-c[0] = IDEFLOPPY_TEST_UNIT_READY_CMD;
+   pc-c[0] = GPCMD_TEST_UNIT_READY;
 }
 
 static void idefloppy_create_rw_cmd (idefloppy_t *floppy, idefloppy_pc_t *pc,
@@ -778,10 +778,10 @@ static void idefloppy_create_rw_cmd (idefloppy_t *floppy, 
idefloppy_pc_t *pc,
 
idefloppy_init_pc(pc);
if (test_bit(IDEFLOPPY_USE_READ12, floppy-flags)) {
-   pc-c[0] = cmd == READ ? IDEFLOPPY_READ12_CMD : 
IDEFLOPPY_WRITE12_CMD;
+   pc-c[0] = cmd == READ ? GPCMD_READ_12 : GPCMD_WRITE_12;
put_unaligned(htonl(blocks), (unsigned int *) pc-c[6]);
} else {
-   pc-c[0] = cmd == READ ? IDEFLOPPY_READ10_CMD : 
IDEFLOPPY_WRITE10_CMD;
+

[RESEND PATCH 01/10] move ide-floppy historical changelog to Documentation/ide/ChangeLog.ide-floppy.1996-2002;

Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
---
 Documentation/ide/ChangeLog.ide-floppy.1996-2002 |   64 
 drivers/ide/ide-floppy.c |   69 +-
 2 files changed, 67 insertions(+), 66 deletions(-)

diff --git a/Documentation/ide/ChangeLog.ide-floppy.1996-2002 
b/Documentation/ide/ChangeLog.ide-floppy.1996-2002
new file mode 100644
index 000..70166f3
--- /dev/null
+++ b/Documentation/ide/ChangeLog.ide-floppy.1996-2002
@@ -0,0 +1,64 @@
+/*
+ * Many thanks to Lode Leroy [EMAIL PROTECTED], who tested so many
+ * ALPHA patches to this driver on an EASYSTOR LS-120 ATAPI floppy drive.
+ *
+ * Ver 0.1   Oct 17 96   Initial test version, mostly based on ide-tape.c.
+ * Ver 0.2   Oct 31 96   Minor changes.
+ * Ver 0.3   Dec  2 96   Fixed error recovery bug.
+ * Ver 0.4   Jan 26 97   Add support for the HDIO_GETGEO ioctl.
+ * Ver 0.5   Feb 21 97   Add partitions support.
+ *   Use the minimum of the LBA and CHS capacities.
+ *   Avoid hwgroup-rq == NULL on the last irq.
+ *   Fix potential null dereferencing with DEBUG_LOG.
+ * Ver 0.8   Dec  7 97   Increase irq timeout from 10 to 50 seconds.
+ *   Add media write-protect detection.
+ *   Issue START command only if TEST UNIT READY fails.
+ *   Add work-around for IOMEGA ZIP revision 21.D.
+ *   Remove idefloppy_get_capabilities().
+ * Ver 0.9   Jul  4 99   Fix a bug which might have caused the number of
+ *bytes requested on each interrupt to be zero.
+ *Thanks to [EMAIL PROTECTED] for pointing this out.
+ * Ver 0.9.sv Jan 6 01   Sam Varshavchik [EMAIL PROTECTED]
+ *   Implement low level formatting.  Reimplemented
+ *   IDEFLOPPY_CAPABILITIES_PAGE, since we need the srfp
+ *   bit.  My LS-120 drive barfs on
+ *   IDEFLOPPY_CAPABILITIES_PAGE, but maybe it's just me.
+ *   Compromise by not reporting a failure to get this
+ *   mode page.  Implemented four IOCTLs in order to
+ *   implement formatting.  IOCTls begin with 0x4600,
+ *   0x46 is 'F' as in Format.
+ *Jan 9 01   Userland option to select format verify.
+ *   Added PC_SUPPRESS_ERROR flag - some idefloppy drives
+ *   do not implement IDEFLOPPY_CAPABILITIES_PAGE, and
+ *   return a sense error.  Suppress error reporting in
+ *   this particular case in order to avoid spurious
+ *   errors in syslog.  The culprit is
+ *   idefloppy_get_capability_page(), so move it to
+ *   idefloppy_begin_format() so that it's not used
+ *   unless absolutely necessary.
+ *   If drive does not support format progress indication
+ *   monitor the dsc bit in the status register.
+ *   Also, O_NDELAY on open will allow the device to be
+ *   opened without a disk available.  This can be used to
+ *   open an unformatted disk, or get the device capacity.
+ * Ver 0.91  Dec 11 99   Added IOMEGA Clik! drive support by 
+ *[EMAIL PROTECTED]
+ * Ver 0.92  Oct 22 00   Paul Bristow became official maintainer for this 
+ *driver.  Included Powerbook internal zip kludge.
+ * Ver 0.93  Oct 24 00   Fixed bugs for Clik! drive
+ *no disk on insert and disk change now works
+ * Ver 0.94  Oct 27 00   Tidied up to remove strstr(Clik) everywhere
+ * Ver 0.95  Nov  7 00   Brought across to kernel 2.4
+ * Ver 0.96  Jan  7 01   Actually in line with release version of 2.4.0
+ *   including set_bit patch from Rusty Russell
+ * Ver 0.97  Jul 22 01   Merge 0.91-0.96 onto 0.9.sv for ac series
+ * Ver 0.97.sv Aug 3 01  Backported from 2.4.7-ac3
+ * Ver 0.98  Oct 26 01   Split idefloppy_transfer_pc into two pieces to
+ *fix a lost interrupt problem. It appears the busy
+ *bit was being deasserted by my IOMEGA ATAPI ZIP 100
+ *drive before the drive was actually ready.
+ * Ver 0.98a Oct 29 01   Expose delay value so we can play.
+ * Ver 0.99  Feb 24 02   Remove duplicate code, modify clik! detection code 
+ *to support new PocketZip drives 
+ */
+
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 04a3578..785fbde 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -1,12 +1,8 @@
 /*
- * linux/drivers/ide/ide-floppy.c  Version 0.99Feb 24 2002
+ * IDE ATAPI floppy driver.
  *
  * Copyright (C) 1996 - 1999 Gadi Oxman [EMAIL PROTECTED]
  * Copyright

[RESEND PATCH 02/10] ide-floppy: move ide-floppy struct and macro defs into its own header. While at it

- do a white-space cleanup
- remove old crufty code untouched since at least 2005
- shorten lines longer than 80ish columns
- shorten some LAAARGE typenames.

There should be no functional changes resulting from this patch.

Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
---
 drivers/ide/ide-floppy.c |  763 --
 drivers/ide/ide-floppy.h |  382 +++
 2 files changed, 581 insertions(+), 564 deletions(-)

diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 785fbde..52d09c1 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -44,418 +44,7 @@
 #include asm/io.h
 #include asm/unaligned.h
 
-/*
- * The following are used to debug the driver.
- */
-#define IDEFLOPPY_DEBUG_LOG0
-#define IDEFLOPPY_DEBUG_INFO   0
-#define IDEFLOPPY_DEBUG_BUGS   1
-
-/* #define IDEFLOPPY_DEBUG(fmt, args...) printk(KERN_INFO fmt, ## args) */
-#define IDEFLOPPY_DEBUG( fmt, args... )
-
-#if IDEFLOPPY_DEBUG_LOG
-#define debug_log printk
-#else
-#define debug_log(fmt, args... ) do {} while(0)
-#endif
-
-
-/*
- * Some drives require a longer irq timeout.
- */
-#define IDEFLOPPY_WAIT_CMD (5 * WAIT_CMD)
-
-/*
- * After each failed packet command we issue a request sense command
- * and retry the packet command IDEFLOPPY_MAX_PC_RETRIES times.
- */
-#define IDEFLOPPY_MAX_PC_RETRIES   3
-
-/*
- * With each packet command, we allocate a buffer of
- * IDEFLOPPY_PC_BUFFER_SIZE bytes.
- */
-#define IDEFLOPPY_PC_BUFFER_SIZE   256
-
-/*
- * In various places in the driver, we need to allocate storage
- * for packet commands and requests, which will remain valid while
- * we leave the driver to wait for an interrupt or a timeout event.
- */
-#define IDEFLOPPY_PC_STACK (10 + IDEFLOPPY_MAX_PC_RETRIES)
-
-/*
- * Our view of a packet command.
- */
-typedef struct idefloppy_packet_command_s {
-   u8 c[12];   /* Actual packet bytes */
-   int retries;/* On each retry, we increment 
retries */
-   int error;  /* Error code */
-   int request_transfer;   /* Bytes to transfer */
-   int actually_transferred;   /* Bytes actually transferred */
-   int buffer_size;/* Size of our data buffer */
-   int b_count;/* Missing/Available data on 
the current buffer */
-   struct request *rq; /* The corresponding request */
-   u8 *buffer; /* Data buffer */
-   u8 *current_position;   /* Pointer into the above 
buffer */
-   void (*callback) (ide_drive_t *);   /* Called when this packet 
command is completed */
-   u8 pc_buffer[IDEFLOPPY_PC_BUFFER_SIZE]; /* Temporary buffer */
-   unsigned long flags;/* Status/Action bit flags: 
long for set_bit */
-} idefloppy_pc_t;
-
-/*
- * Packet command flag bits.
- */
-#definePC_ABORT0   /* Set when an error is 
considered normal - We won't retry */
-#define PC_DMA_RECOMMENDED 2   /* 1 when we prefer to use DMA 
if possible */
-#definePC_DMA_IN_PROGRESS  3   /* 1 while DMA in 
progress */
-#definePC_DMA_ERROR4   /* 1 when encountered 
problem during DMA */
-#definePC_WRITING  5   /* Data direction */
-
-#definePC_SUPPRESS_ERROR   6   /* Suppress error 
reporting */
-
-/*
- * Removable Block Access Capabilities Page
- */
-typedef struct {
-#if defined(__LITTLE_ENDIAN_BITFIELD)
-   unsignedpage_code   :6; /* Page code - Should be 0x1b */
-   unsignedreserved1_6 :1; /* Reserved */
-   unsignedps  :1; /* Should be 0 */
-#elif defined(__BIG_ENDIAN_BITFIELD)
-   unsignedps  :1; /* Should be 0 */
-   unsignedreserved1_6 :1; /* Reserved */
-   unsignedpage_code   :6; /* Page code - Should be 0x1b */
-#else
-#error Bitfield endianness not defined! Check your byteorder.h
-#endif
-   u8  page_length;/* Page Length - Should be 0xa 
*/
-#if defined(__LITTLE_ENDIAN_BITFIELD)
-   unsignedreserved2   :6;
-   unsignedsrfp:1; /* Supports reporting progress 
of format */
-   unsignedsflp:1; /* System floppy type device */
-   unsignedtlun:3; /* Total logical units 
supported by the device */
-   unsignedreserved3   :3;
-   unsignedsml :1; /* Single / Multiple lun 
supported */
-   unsignedncd :1; /* Non cd optical device */
-#elif

[RESEND PATCH 08/10] ide-floppy: mv idefloppy_{should_,}report_error

Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
---
 drivers/ide/ide-floppy.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 2c139e7..fd5fe7b 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -544,7 +544,7 @@ static ide_startstop_t idefloppy_transfer_pc1(ide_drive_t 
*drive)
 }
 
 /* Supresses error messages resulting from Medium not present */
-static inline int idefloppy_should_report_error(idefloppy_t *floppy)
+static inline int idefloppy_report_error(idefloppy_t *floppy)
 {
if (floppy-sense_key == 0x02 
floppy-asc   == 0x3a 
@@ -587,7 +587,7 @@ static ide_startstop_t idefloppy_issue_pc(ide_drive_t 
*drive, idefloppy_pc_t *pc
 */
if (!test_bit(PC_ABORT, pc-flags)) {
if (!test_bit(PC_SUPPRESS_ERROR, pc-flags)) {
-   if (idefloppy_should_report_error(floppy))
+   if (idefloppy_report_error(floppy))
printk(KERN_ERR ide-floppy: %s: I/O 
error, 
   pc = %2x, key = %2x, 
   asc = %2x, ascq = %2x\n,
@@ -809,7 +809,7 @@ static ide_startstop_t idefloppy_do_request(ide_drive_t 
*drive,
 
if (rq-errors = ERROR_MAX) {
if (floppy-failed_pc != NULL) {
-   if (idefloppy_should_report_error(floppy))
+   if (idefloppy_report_error(floppy))
printk(KERN_ERR ide-floppy: %s: I/O error,
 pc = %2x, key = %2x, asc = %2x,
 ascq = %2x\n,
-- 
1.5.3.7

--
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] [12/20] x86: Use a per cpu timer for correctable machine check checking

On Thursday 03 January 2008 11:49:56 Ingo Molnar wrote:
 
 * Andi Kleen [EMAIL PROTECTED] wrote:
 
  Previously the code used a single timer that then used 
  smp_call_function to interrupt all CPUs while the original CPU was 
  waiting for them.
  
  But it is better / more real time and more power friendly to simply 
  run individual timers on each CPU so they all do this independently.
  
  This way no single CPU has to wait for all others.
 
 i think we should unify this code first and provide it on 32-bit as 
 well.

That's done in another patch that hasn't been posted yet.

-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] [9/20] x86: Don't use oops_begin in 64bit mce code

On Thursday 03 January 2008 11:39:12 Ingo Molnar wrote:
 
 * Andi Kleen [EMAIL PROTECTED] wrote:
 
  It is not really useful to lock machine checks against oopses. And 
  machine checks normally don't nest, so they don't need their own 
  locking. Just call bust_spinlock/console_verbose directly.
 
 is this in response to any particular incident you've seen?


No, that was a preparatory patch for the use 64bit machine check code
for 32bit kernels because 32bit doesn't have oops_begin(), but it is
useful on its own.

-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] [11/20] x86: Use the correct cpuid method to detect MWAIT support for C states

On Thursday 03 January 2008 11:45:26 Ingo Molnar wrote:
 
 * Andi Kleen [EMAIL PROTECTED] wrote:
 
  +static int mwait_usable(const struct cpuinfo_x86 *c)
  +{
  +   if (force_mwait)
  +   return 1;
  +   /* Any C1 states supported? */
  +   return c-cpuid_level = 5  ((cpuid_edx(5)  4)  0xf)  0;
  +}
  +
   void __cpuinit select_idle_routine(const struct cpuinfo_x86 *c)
   {
  -   if (cpu_has(c, X86_FEATURE_MWAIT)) {
  +   if (cpu_has(c, X86_FEATURE_MWAIT)  mwait_usable(c)) {
  printk(monitor/mwait feature present.\n);
 
 hm, why not clear FEATURE_MWAIT if it's not usable? That's the 
 standard approach we do for CPU features that do not work.

Well it works, just in a unexpected way not useful to the kernel.

At least on AMD there is a bit to enable it for ring 3 too, so 
in theory someone could use it anyways.

-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] [5/20] x86: Introduce nsec_barrier()

On Thursday 03 January 2008 11:47:54 Ingo Molnar wrote:
 
 * Andi Kleen [EMAIL PROTECTED] wrote:
 
  nsec_barrier() is a new barrier primitive that stops RDTSC speculation 
  to avoid races with timer interrupts on other CPUs.
  
  Add it to all architectures. Except for x86 it is a nop right now. I 
  only tested x86, but it's a very simple change.
  
  On x86 it expands either to LFENCE (for Intel CPUs) or MFENCE (for AMD 
  CPUs) which stops RDTSC on all currently known microarchitectures that 
  implement SSE. On CPUs without SSE there is generally no RDTSC 
  speculation.
 
 i've picked up your rdtsc patches into x86.git but have simplified it: 
 there's no nsec_barrier() anymore - rdtsc() is always synchronous. 
 MFENCE/LFENCE is fast enough. Open-coding such barriers almost always 
 leads to needless trouble. Please check the next x86.git tree.

That's most likely wrong unless you added two barriers -- the barriers
are strictly need to be before and after RDTSC.

I still think having the open barrier is the better approach here.

It's also useful for performance measurements because it allows
a cheap way to measure a specific region with RDTSC

-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/

[RESEND PATCH 07/10] ide-floppy: remove unnecessary -handler != NULL check

This BUG_ON is unneeded since the -handler != NULL check is performed in
ide_set_handler().

Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
---
 drivers/ide/ide-floppy.c |8 +++-
 1 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 5d0fd1f..2c139e7 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -421,7 +421,7 @@ static ide_startstop_t idefloppy_pc_intr(ide_drive_t *drive)
to send us more data than expected 
- discarding data\n);
idefloppy_discard_data(drive,bcount.all);
-   BUG_ON(HWGROUP(drive)-handler != NULL);
+
ide_set_handler(drive,
idefloppy_pc_intr,
IDEFLOPPY_WAIT_CMD,
@@ -453,8 +453,6 @@ static ide_startstop_t idefloppy_pc_intr(ide_drive_t *drive)
pc-actually_transferred += bcount.all;
pc-current_position += bcount.all;
 
-   BUG_ON(HWGROUP(drive)-handler != NULL);
-
/* And set the interrupt handler again */
ide_set_handler(drive, idefloppy_pc_intr, IDEFLOPPY_WAIT_CMD, NULL);
return ide_started;
@@ -482,7 +480,7 @@ static ide_startstop_t idefloppy_transfer_pc(ide_drive_t 
*drive)
issuing a packet command\n);
return ide_do_reset(drive);
}
-   BUG_ON(HWGROUP(drive)-handler != NULL);
+
/* Set the interrupt routine */
ide_set_handler(drive, idefloppy_pc_intr, IDEFLOPPY_WAIT_CMD, NULL);
/* Send the actual packet */
@@ -537,7 +535,7 @@ static ide_startstop_t idefloppy_transfer_pc1(ide_drive_t 
*drive)
 * 40 and 50msec work well. idefloppy_pc_intr will not be actually
 * used until after the packet is moved in about 50 msec.
 */
-   BUG_ON(HWGROUP(drive)-handler != NULL);
+
ide_set_handler(drive,
  idefloppy_pc_intr,   /* service routine for packet command */
  floppy-ticks,/* wait this long before failing */
-- 
1.5.3.7

--
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/

[RESEND PATCH 09/10] ide-floppy: use test_bit wrappers for testing flags

also, fix header comments and remove superfluous ones. There should be no
functionality change resulting from this patch.

Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
---
 drivers/ide/ide-floppy.c |   45 -
 drivers/ide/ide-floppy.h |  127 +-
 2 files changed, 79 insertions(+), 93 deletions(-)

diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index fd5fe7b..6c29b5f 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -337,7 +337,7 @@ static ide_startstop_t idefloppy_pc_intr(ide_drive_t *drive)
 
debug_log(Reached %s interrupt handler\n, __FUNCTION__);
 
-   if (test_bit(PC_DMA_IN_PROGRESS, pc-flags)) {
+   if (idefl_dma_ongoing(pc)) {
 
dma_error = HWIF(drive)-ide_dma_end(drive);
if (dma_error) {
@@ -365,7 +365,7 @@ static ide_startstop_t idefloppy_pc_intr(ide_drive_t *drive)
 
local_irq_enable_in_hardirq();
 
-   if (status.b.check || test_bit(PC_DMA_ERROR, pc-flags)) {
+   if (status.b.check || idefl_dma_err(pc)) {
/* Error detected */
debug_log(%s: I/O error\n, drive-name);
rq-errors++;
@@ -404,7 +404,7 @@ static ide_startstop_t idefloppy_pc_intr(ide_drive_t *drive)
printk(KERN_ERR ide-floppy: CoD != 0 in idefloppy_pc_intr\n);
return ide_do_reset(drive);
}
-   if (ireason.b.io == test_bit(PC_WRITING, pc-flags)) {
+   if (ireason.b.io == idefl_data_dir(pc)) {
/* Hopefully, we will never get here */
printk(KERN_ERR ide-floppy: We wanted to %s, ,
ireason.b.io ? Write:Read);
@@ -412,7 +412,7 @@ static ide_startstop_t idefloppy_pc_intr(ide_drive_t *drive)
ireason.b.io ? Read:Write);
return ide_do_reset(drive);
}
-   if (!test_bit(PC_WRITING, pc-flags)) {
+   if (!idefl_data_dir(pc)) {
/* Reading - Check that we have enough space */
temp = pc-actually_transferred + bcount.all;
if (temp  pc-request_transfer) {
@@ -432,7 +432,7 @@ static ide_startstop_t idefloppy_pc_intr(ide_drive_t *drive)
expected - allowing transfer\n);
}
}
-   if (test_bit(PC_WRITING, pc-flags)) {
+   if (idefl_data_dir(pc)) {
if (pc-buffer != NULL)
/* Write the current buffer */
HWIF(drive)-atapi_output_bytes(drive,
@@ -579,14 +579,13 @@ static ide_startstop_t idefloppy_issue_pc(ide_drive_t 
*drive, idefloppy_pc_t *pc
/* Set the current packet command */
floppy-pc = pc;
 
-   if (pc-retries  IDEFLOPPY_MAX_PC_RETRIES ||
-   test_bit(PC_ABORT, pc-flags)) {
+   if (pc-retries  IDEFLOPPY_MAX_PC_RETRIES || idefl_abort(pc)) {
/*
-*  We will abort retrying a packet command in case
-*  a legitimate error code was received.
+* We will abort retrying a packet command in case a
+* legitimate error code was received.
 */
-   if (!test_bit(PC_ABORT, pc-flags)) {
-   if (!test_bit(PC_SUPPRESS_ERROR, pc-flags)) {
+   if (!idefl_abort(pc)) {
+   if (!idefl_supp_err(pc)) {
if (idefloppy_report_error(floppy))
printk(KERN_ERR ide-floppy: %s: I/O 
error, 
   pc = %2x, key = %2x, 
@@ -616,7 +615,7 @@ static ide_startstop_t idefloppy_issue_pc(ide_drive_t 
*drive, idefloppy_pc_t *pc
 
feature.all = 0;
 
-   if (test_bit(PC_DMA_RECOMMENDED, pc-flags)  drive-using_dma)
+   if (idefl_dma_prefd(pc)  drive-using_dma)
feature.b.dma = !hwif-dma_setup(drive);
 
if (IDE_CONTROL_REG)
@@ -633,7 +632,7 @@ static ide_startstop_t idefloppy_issue_pc(ide_drive_t 
*drive, idefloppy_pc_t *pc
}
 
/* Can we transfer the packet when we get the interrupt or wait? */
-   if (test_bit(IDEFLOPPY_ZIP_DRIVE, floppy-flags)) {
+   if (idefl_zip_drive(floppy)) {
/* wait */
pkt_xfer_routine = idefloppy_transfer_pc1;
} else {
@@ -641,7 +640,7 @@ static ide_startstop_t idefloppy_issue_pc(ide_drive_t 
*drive, idefloppy_pc_t *pc
pkt_xfer_routine = idefloppy_transfer_pc;
}
 
-   if (test_bit(IDEFLOPPY_DRQ_INTERRUPT, floppy-flags)) {
+   if (idefl_drq_intr(floppy)) {
/* Issue the packet command */
ide_execute_command(drive, WIN_PACKETCMD,
pkt_xfer_routine,
@@ -749,11 +748,10 @@ static void idefloppy_create_rw_cmd(idefloppy_t *floppy, 
idefloppy_pc_t *pc,
int cmd = rq_data_dir(rq);

[RESEND PATCH 04/10] ide-floppy: cleanup debugging macros

There should be no functional change resulting from this patch.

Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
---
 drivers/ide/ide-floppy.c |   58 +
 drivers/ide/ide-floppy.h |3 +-
 2 files changed, 29 insertions(+), 32 deletions(-)

diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 4fb6128..196a697 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -105,7 +105,7 @@ static int idefloppy_do_end_request(ide_drive_t *drive, int 
uptodate, int nsecs)
struct request *rq = HWGROUP(drive)-rq;
int error;
 
-   debug_log(KERN_INFO Reached idefloppy_end_request\n);
+   debug_log(Reached %s\n, __FUNCTION__);
 
switch (uptodate) {
case 0: error = IDEFLOPPY_ERROR_GENERAL; break;
@@ -257,13 +257,12 @@ static void idefloppy_analyze_error (ide_drive_t *drive,
floppy-progress_indication = result-sksv[0]  0x80 ?
(u16)get_unaligned((u16 *)(result-sksv+1)):0x1;
if (floppy-failed_pc)
-   debug_log(KERN_INFO ide-floppy: pc = %x, sense key = %x, 
-   asc = %x, ascq = %x\n, floppy-failed_pc-c[0],
-   result-sense_key, result-asc, result-ascq);
+   debug_log(pc = %x, sense key = %x, asc = %x, ascq = %x\n,
+   floppy-failed_pc-c[0], result-sense_key,
+   result-asc, result-ascq);
else
-   debug_log(KERN_INFO ide-floppy: sense key = %x, asc = %x, 
-   ascq = %x\n, result-sense_key,
-   result-asc, result-ascq);
+   debug_log(sense key = %x, asc = %x, ascq = %x\n,
+   result-sense_key, result-asc, result-ascq);
 }
 
 static void idefloppy_request_sense_callback (ide_drive_t *drive)
@@ -271,7 +270,7 @@ static void idefloppy_request_sense_callback (ide_drive_t 
*drive)
idefloppy_t *floppy = drive-driver_data;
u8 *buf = floppy-pc-buffer;
 
-   debug_log(KERN_INFO ide-floppy: Reached %s\n, __FUNCTION__);
+   debug_log(Reached %s\n, __FUNCTION__);
 
if (!floppy-pc-error) {
idefloppy_analyze_error(drive, (rq_sense_res_t *) buf);
@@ -291,7 +290,7 @@ static void idefloppy_pc_callback (ide_drive_t *drive)
 {
idefloppy_t *floppy = drive-driver_data;
 
-   debug_log(KERN_INFO ide-floppy: Reached %s\n, __FUNCTION__);
+   debug_log(Reached %s\n, __FUNCTION__);
 
idefloppy_do_end_request(drive, floppy-pc-error ? 0 : 1, 0);
 }
@@ -351,8 +350,7 @@ static ide_startstop_t idefloppy_pc_intr (ide_drive_t 
*drive)
struct request *rq = pc-rq;
unsigned int temp;
 
-   debug_log(KERN_INFO ide-floppy: Reached %s interrupt handler\n,
-   __FUNCTION__);
+   debug_log(Reached %s interrupt handler\n, __FUNCTION__);
 
if (test_bit(PC_DMA_IN_PROGRESS, pc-flags)) {
if (HWIF(drive)-ide_dma_end(drive)) {
@@ -361,23 +359,23 @@ static ide_startstop_t idefloppy_pc_intr (ide_drive_t 
*drive)
pc-actually_transferred = pc-request_transfer;
idefloppy_update_buffers(drive, pc);
}
-   debug_log(KERN_INFO ide-floppy: DMA finished\n);
+   debug_log(%s: DMA finished\n, __FUNCTION__);
}
 
/* Clear the interrupt */
status.all = HWIF(drive)-INB(IDE_STATUS_REG);
 
if (!status.b.drq) {/* No more interrupts */
-   debug_log(KERN_INFO Packet command completed, %d bytes 
-   transferred\n, pc-actually_transferred);
+   debug_log(Packet command completed, %d bytes transferred\n,
+   pc-actually_transferred);
+
clear_bit(PC_DMA_IN_PROGRESS, pc-flags);
 
local_irq_enable_in_hardirq();
 
if (status.b.check || test_bit(PC_DMA_ERROR, pc-flags)) {
/* Error detected */
-   debug_log(KERN_INFO ide-floppy: %s: I/O error\n,
-   drive-name);
+   debug_log(%s: I/O error\n, drive-name);
rq-errors++;
if (pc-c[0] == GPCMD_REQUEST_SENSE) {
printk(KERN_ERR ide-floppy: I/O error in 
@@ -438,9 +436,8 @@ static ide_startstop_t idefloppy_pc_intr (ide_drive_t 
*drive)
NULL);
return ide_started;
}
-   debug_log(KERN_NOTICE ide-floppy: The floppy wants to 
-   send us more data than expected - 
-   allowing transfer\n);
+   debug_log(The floppy wants to send us more data than
+   expected - allowing transfer\n);
}

[RESEND PATCH 10/10] ide-floppy: replace ntoh{s,l} and hton{s,l} calls with the generic byteorder macros

Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
---
 drivers/ide/ide-floppy.c |   28 ++--
 1 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 6c29b5f..ddab66c 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -695,8 +695,8 @@ static void idefloppy_create_format_unit_cmd(idefloppy_pc_t 
*pc, int b, int l,
pc-buffer[1] ^= 0x20;  /* ... turn off DCRT bit */
pc-buffer[3] = 8;
 
-   put_unaligned(htonl(b), (unsigned int *)(pc-buffer[4]));
-   put_unaligned(htonl(l), (unsigned int *)(pc-buffer[8]));
+   put_unaligned(cpu_to_be32(b), (unsigned int *)(pc-buffer[4]));
+   put_unaligned(cpu_to_be32(l), (unsigned int *)(pc-buffer[8]));
pc-buffer_size=12;
set_bit(PC_WRITING, pc-flags);
 }
@@ -723,7 +723,7 @@ static void idefloppy_create_mode_sense_cmd(idefloppy_pc_t 
*pc, u8 page_code,
printk(KERN_ERR ide-floppy: unsupported page code 
in create_mode_sense_cmd\n);
}
-   put_unaligned(htons(length), (u16 *) pc-c[7]);
+   put_unaligned(cpu_to_be16(length), (u16 *) pc-c[7]);
pc-request_transfer = length;
 }
 
@@ -753,12 +753,12 @@ static void idefloppy_create_rw_cmd(idefloppy_t *floppy, 
idefloppy_pc_t *pc,
idefloppy_init_pc(pc);
if (idefl_use_rw(floppy)) {
pc-c[0] = cmd == READ ? GPCMD_READ_12 : GPCMD_WRITE_12;
-   put_unaligned(htonl(blocks), (unsigned int *) pc-c[6]);
+   put_unaligned(cpu_to_be32(blocks), (unsigned int *) pc-c[6]);
} else {
pc-c[0] = cmd == READ ? GPCMD_READ_10 : GPCMD_WRITE_10;
-   put_unaligned(htons(blocks), (unsigned short *) pc-c[7]);
+   put_unaligned(cpu_to_be16(blocks), (unsigned short *) 
pc-c[7]);
}
-   put_unaligned(htonl(block), (unsigned int *) pc-c[2]);
+   put_unaligned(cpu_to_be32(block), (unsigned int *) pc-c[2]);
pc-callback = idefloppy_rw_callback;
pc-rq = rq;
pc-b_count = cmd == READ ? 0 : rq-bio-bi_size;
@@ -890,10 +890,10 @@ static int idefloppy_get_flexible_disk_page(ide_drive_t 
*drive)
set_disk_ro(floppy-disk, floppy-wp);
page = (idefloppy_flex_disk_page_t *) (header + 1);
 
-   page-transfer_rate = ntohs(page-transfer_rate);
-   page-sector_size = ntohs(page-sector_size);
-   page-cyls = ntohs(page-cyls);
-   page-rpm = ntohs(page-rpm);
+   page-transfer_rate = be16_to_cpu(page-transfer_rate);
+   page-sector_size = be16_to_cpu(page-sector_size);
+   page-cyls = be16_to_cpu(page-cyls);
+   page-rpm = be16_to_cpu(page-rpm);
capacity = page-cyls * page-heads * page-sectors * page-sector_size;
 
if (memcmp (page, floppy-flex_disk_page,
@@ -972,8 +972,8 @@ static int idefloppy_get_capacity(ide_drive_t *drive)
descriptor = (idefloppy_cap_desc_t *) (header + 1);
 
for (i = 0; i  descriptors; i++, descriptor++) {
-   blocks = descriptor-blocks = ntohl(descriptor-blocks);
-   length = descriptor-length = ntohs(descriptor-length);
+   blocks = descriptor-blocks = be32_to_cpu(descriptor-blocks);
+   length = descriptor-length = be16_to_cpu(descriptor-length);
 
if (!i)
{
@@ -1100,8 +1100,8 @@ static int idefloppy_get_format_capacities(ide_drive_t 
*drive, int __user *arg)
if (i == 0)
continue;   /* Skip the first descriptor */
 
-   blocks = ntohl(descriptor-blocks);
-   length = ntohs(descriptor-length);
+   blocks = be32_to_cpu(descriptor-blocks);
+   length = be16_to_cpu(descriptor-length);
 
if (put_user(blocks, argp))
return(-EFAULT);
-- 
1.5.3.7

--
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/

[RESEND PATCH 06/10] ide-floppy: report DMA handling in idefloppy_pc_intr() properly