Re: Linux header change breaks linux-atm userspace build

[Andrew Walrond]

On Friday 09 February 2007 00:01, David Miller wrote:
> From: Andrew Walrond <[EMAIL PROTECTED]>
> Date: Thu, 8 Feb 2007 21:31:25 +
>
> > Sometime between 2.6.18.3 and 2.6.20, this change...
> >
> > --- /include/linux/atmarp.h 2007-01-10 16:32:05.0 +
> > +++ pkg/linux/include/linux/atmarp.h2007-02-08 20:02:08.0
> > + @@ -34,7 +34,7 @@
> >  struct atmarp_ctrl {
> > enum atmarp_ctrl_type   type;   /* message type */
> > int itf_num;/* interface number (if present)
> > */ -   uint32_tip; /* IP address (act_need only)
> > */ +   __be32  ip; /* IP address (act_need only)
> > */ };
> >
> >  #endif
> >
> > was introduced, but __be32 is undefined, so atmarp.h should include
> > linux/types.h
>
> I'll fix this, thanks for reporting.

Actually, it seems that several other atm headers are also missing 
linux/types.h. I guess you can tell which ones have changed recently using 
git (I just patched linux-atm with liberal #include ). But let 
me know if you want a full list.

Andrew Walrond
-
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] i386/x86_64: smp_call_function locking inconsistency

[Andi Kleen]

On Thursday 08 February 2007 21:32, Heiko Carstens wrote:
> On i386/x86_64 smp_call_function_single() takes call_lock with
> spin_lock_bh(). To me this would imply that it is legal to call
> smp_call_function_single() from softirq context.
> It's not since smp_call_function() takes call_lock with just
> spin_lock(). We can easily deadlock:
> 
> -> [process context]
> -> smp_call_function()
> -> spin_lock(&call_lock)
> -> IRQ -> do_softirq -> tasklet
> -> [softirq context]
> -> smp_call_function_single()
> -> spin_lock_bh(&call_lock)
> -> dead
> 
> So either all spin_lock_bh's should be converted to spin_lock,
> which would limit smp_call_function()/smp_call_function_single()
> to process context & irqs enabled.
> Or the spin_lock's could be converted to spin_lock_bh which would
> make it possible to call these two functions even if in softirq
> context. AFAICS this should be safe.

I'm not so sure. Perhaps drop _bh in both and stick a WARN_ON_ONCE in
to catch the cases? 

-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: genirq: Add a set_irq_handler_locked() function

[Russell King]

On Fri, Feb 09, 2007 at 02:48:42PM +1100, David Gibson wrote:
> At present set_irq_handler() and all the existing variants take the
> desc->lock for the irq in question before adjusting the irq's flow
> handler.  This can cause problems for irq chips for which a given
> interrupt can be either level or edge depending on what's attached.

Are you sure you need to change the flow handler depending on how
you program the device?

Since the outset of this design, I've had what are essentially edge
based interrupt sources using the "level" handlers because they haven't
had a "broken" edge implementation.  By that, I mean that the masking
is done in such a way that you miss edges when the source is masked.

If you do not miss edges while the source is masked, there's no point
in having the complexity of the "edge" based handler in the path - it
buys you nothing.  Just use the "level" handler instead.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
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] remove sb->s_files and file_list_lock usage in dquot.c

[hui]

On Thu, Feb 08, 2007 at 11:14:04PM -0800, Bill Huey wrote:
> I have an adaptive lock implementation in my tree that eliminates
> the contention between what looks like the IDE layer, work queues and
> the anticipatory scheduler, but that's not a real problem unlike what
> I've mentioned above. I can get you and others more specifics on the
> problem if folks working on the lower layers want it.

Correction, it eliminates all of the "live" contentions where the
mutex owner isn't asleep already.

bill

-
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] Convert pci_module_init() to pci_register_driver()

[Richard Knutsson]

Convert pci_module_init() to pci_register_driver().

Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with "allyes", "allmod" & "allno" on i386
Diff'ed against the unpatched object-files, no difference
Has previously been sent to the maintainers, without respons

 crypto/geode-aes.c |2 +-
 scsi/megaraid.c|2 +-
 scsi/tmscsim.c |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)


diff --git a/drivers/crypto/geode-aes.c b/drivers/crypto/geode-aes.c
index 43a6839..31ea405 100644
--- a/drivers/crypto/geode-aes.c
+++ b/drivers/crypto/geode-aes.c
@@ -457,7 +457,7 @@ static struct pci_driver geode_aes_driver = {
 static int __init
 geode_aes_init(void)
 {
-   return pci_module_init(&geode_aes_driver);
+   return pci_register_driver(&geode_aes_driver);
 }
 
 static void __exit
diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c
index 77d9d38..4fd4960 100644
--- a/drivers/scsi/megaraid.c
+++ b/drivers/scsi/megaraid.c
@@ -5072,7 +5072,7 @@ static int __init megaraid_init(void)
"megaraid: failed to create megaraid root\n");
}
 #endif
-   error = pci_module_init(&megaraid_pci_driver);
+   error = pci_register_driver(&megaraid_pci_driver);
if (error) {
 #ifdef CONFIG_PROC_FS
remove_proc_entry("megaraid", &proc_root);
diff --git a/drivers/scsi/tmscsim.c b/drivers/scsi/tmscsim.c
index fa5382e..ce8845e 100644
--- a/drivers/scsi/tmscsim.c
+++ b/drivers/scsi/tmscsim.c
@@ -2681,7 +2681,7 @@ static int __init dc390_module_init(void)
printk (KERN_INFO "DC390: Using safe settings.\n");
}
 
-   return pci_module_init(&dc390_driver);
+   return pci_register_driver(&dc390_driver);
 }
 
 static void __exit dc390_module_exit(void)
-
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: Direct IO for fat

[Jan Kara]

On Fri 09-02-07 04:53:02, OGAWA Hirofumi wrote:
> Jan Kara <[EMAIL PROTECTED]> writes:
> 
> >> > -> blockdev_direct_IO()
> >> >   -> direct_io_worker()
> >> > -> do_direct_IO()
> >> >   -> get_more_blocks()
> >> > 
> >> >  create = dio->rw & WRITE;
> >>   Here, create == 1.
> >> 
> >> >  if (dio->lock_type == DIO_LOCKING) {
> >> >  if (dio->block_in_file < (i_size_read(dio->inode) >>
> >> >  dio->blkbits))
> >> >  create = 0;
> >>   But here create was reset back to 0 - exactly because
> >> dio->block_in_file > i_size...
> >   Obviously, I'm blind and you're right ;) This test is not satisfied
> > and so create == 1.
> >   But still it would seem better to me to return 0 from fat_direct_IO()
> > instead of EINVAL so that write falls back to a buffered one, instead
> > returning the error...
> 
> I see. When I wrote this, I thought kernel should use DIO to write if
> user sets O_DIRECT. Because the wrong alignment request isn't fallback
> to buffered-write, and it's also returns EINVAL.
  I understand. It's just that I've got some surprised users who could not
track why the hell does write() return EINVAL to them when they have
everything alligned and the same code works for EXT3 :). Of course, nothing
guarantees that FAT should behave the same way as EXT3 but I can understand
they were surprised (I had to look in the code too).
  I also don't have a strong opinion whether we should fallback to buffered
write automagically or whether we should return EINVAL and let the user fall
back to the buffered write himself. But I'd slightly prefer the first
option.

Honza

-- 
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
-
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: [md] RAID6: clean up CPUID and FPU enter/exit code

[H. Peter Anvin]

My apologies for the screwed-up 'To:' line in the previous email... I 
did -s `head -1 file` instead of -s "`head -1 file`" by mistake [:^O


-hpa (who is going to bed now...)
-
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] remove sb->s_files and file_list_lock usage in dquot.c

[hui]

On Thu, Feb 08, 2007 at 01:01:21AM -0800, Bill Huey wrote:
> Christoph,
> 
> The i_mutex lock the inode structure is also a source of contention
> heavy when running a lot of parallel "find"s. I'm sure that folks
> would be open to hearing suggestions regarding how to fix that.

Christoph,

And while you're at it, you should also know that dcache_lock is next
in line to be nixed out of existence if possible.

i_mutex is a bitch and I'm not even going to think about how to get
rid of it since it's so widely used in many places (file systems aren't
my think as well). Maybe some more precise tracking of contention paths
would be useful to see if there's a pathological case creating a
cascade of contention events so that can be nixed, don't know.

About 1/10th of the lock stat events I've logged report that the owner
of the rtmutex is the "current" on a runqueue some where. An adaptive
lock would help with those contention events (spin for it while owner
is running for the mutex release) but really, the contention should be
avoided in the first place since they have a kind of (I think) polynomial
increase in contention time as you add more processors to the mix.

I have an adaptive lock implementation in my tree that eliminates
the contention between what looks like the IDE layer, work queues and
the anticipatory scheduler, but that's not a real problem unlike what
I've mentioned above. I can get you and others more specifics on the
problem if folks working on the lower layers want it.

Other than that the -rt patch does quite well with instrumenting all
sort of kernel behaviors that include contention and latency issues.

So I don't need to tell you how valuable the -rt patch is for these
issues since it's obvious, and I'm sure that you'll agree, that it's
been instrumental at discovering many problems with the stock kernel.

bill

-
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] aio: fix kernel bug when page is temporally busy

[Suparna Bhattacharya]

On Fri, Feb 09, 2007 at 08:41:41AM +0300, Ananiev, Leonid I wrote:
> > invalidate_inode_pages2() has other callers.  I suspect with this
> change
> > we'll end up leaking EIOCBRETRY back to userspace.
>  
> EIOCBRETRY is used and caught already in do_sync_read() and
> do_sync_readv_writev().
>  
> Below fixed patch against kernel 2.6.20.

I agree with Andrew, this doesn't look like the right solution.

EIOCBRETRY isn't the same as EAGAIN or "try again later". EIOCBRETRY means
"I have queued up an action to notify (wakeup) the callback to retry the
operation once data is ready".

Regards
Suparna

>  
> >From Leonid Ananiev
>  
> Fix kernel bug when IO page is temporally busy:
> invalidate_inode_pages2() returns EIOCBRETRY but not  EIO..
>  
> Signed-off-by: Leonid Ananiev <[EMAIL PROTECTED]>
> ---
> --- linux-2.6.20/mm/truncate.c2007-02-04 10:44:54.0 -0800
> +++ linux-2.6.20p/mm/truncate.c   2007-02-08 11:38:11.0 -0800
> @@ -366,7 +366,7 @@ static int do_launder_page(struct addres
>   * Any pages which are found to be mapped into pagetables are unmapped
> prior to
>   * invalidation.
>   *
> - * Returns -EIO if any pages could not be invalidated.
> + * Returns -EIOCBRETRY if any pages could not be invalidated.
>   */
>  int invalidate_inode_pages2_range(struct address_space *mapping,
> pgoff_t start, pgoff_t end)
> @@ -423,7 +423,7 @@ int invalidate_inode_pages2_range(struct
>   }
>   ret = do_launder_page(mapping, page);
>   if (ret == 0 &&
> !invalidate_complete_page2(mapping, page))
> - ret = -EIO;
> + ret = -EIOCBRETRY;
>   unlock_page(page);
>   }
>   pagevec_release(&pvec);
> @@ -440,7 +440,7 @@ EXPORT_SYMBOL_GPL(invalidate_inode_pages
>   * Any pages which are found to be mapped into pagetables are unmapped
> prior to
>   * invalidation.
>   *
> - * Returns -EIO if any pages could not be invalidated.
> + * Returns -EIOCBRETRY if any pages could not be invalidated.
>   */
>  int invalidate_inode_pages2(struct address_space *mapping)
>  {
>  
> --
> To unsubscribe, send a message with 'unsubscribe linux-aio' in
> the body to [EMAIL PROTECTED]  For more info on Linux AIO,
> see: http://www.kvack.org/aio/
> Don't email: mailto:"[EMAIL PROTECTED]">[EMAIL PROTECTED]

-- 
Suparna Bhattacharya ([EMAIL PROTECTED])
Linux Technology Center
IBM Software Lab, India

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

Re: [PATCH 2/2] x86_64 irq: Handle irqs pending in IRR during irq migration.

[Eric W. Biederman]

>
> The version I would up testing is below, and it doesn't work.
> I still get "No irq handler for vector" warnings as well as
> a couple of complaints from lock/irq debugging.The debugging
> doesn't worry me.  The fact that I don't have a good way to ensure
> I have no more irqs in flight does.
>
> So unless someone can find a sure way to drain the irqs in flight,
> I can't migrate an irq from process context, and looking at irr and
> handling a pending irq appears required.  '

Bah.  I had not taken into account that the local apic despite
being tightly coupled with the cpu is for programming purposes
an asynchronous device.  If I want to give it time to react to something
I need to read from it.

The routine below actually works. 

My remaining practical question is can this been done cleanly.

Ingo's lock debugging dislikes this routine.  
By using raw_local_irq_enable I have avoided all but a message on
the irq return path, I haven't quite worked out where.

But at least this version feels like it could be done better
(less inline? different helpers?) someone.

For interrupts coming through a sane interrupt controller moving
this into process context would certainly simplify things.  For edge
triggered interrupts coming through an io_apic I'm not at all certain
what makes sense.

When the routine below is used to ack an edge triggered interrupt
it runs before the edge triggered interrupt handler so losing an
edge shouldn't happen (we haven't acknowledged the hardware yet)
and even if we do the device driver gets to run at least once.

So doing migration in the irq handler still looks like the best
solution even if it is ugly.  As long as the little bit of
stack overhead isn't a problem I think enabling interrupts to
clear out any pending irqs certainly looks simpler. 

In another vein.  I went and looked through all of Intel's and
AMD's public errata that I could find and there weren't any associated
with irr or isr, so I think my previous version of the code is still
sane, and not likely to break.

I can improve it a little by getting the vector as:
"vector = ~ get_irq_regs()->orig_rax;" instead of reading
ISR.  That still leaves reading the pending bit in ISR and the
other funny tricks.

I'm conflicted between the two approaches a little because playing
games with enabling interrupts in an interrupt handler seems to
have some weird corner cases.

static void ack_apic(unsigned int irq)
{
#if defined(CONFIG_GENERIC_PENDING_IRQ) || defined(CONFIG_IRQBALANCE)
struct irq_desc *desc;
desc = irq_desc + irq;
if (likely(!(desc->status & IRQ_MOVE_PENDING)))
goto simple;

if (hardirq_count() != HARDIRQ_OFFSET)
goto simple;

desc->chip->mask(irq);
ack_APIC_irq();

/* Ensure all of the irq handlers for this irq have completed
 * before we migrate it.
 */
spin_unlock(&desc->lock);
raw_local_irq_enable();
apic_read(APIC_ID);
raw_local_irq_disable();
spin_lock(&desc->lock);

move_masked_irq(irq);
desc->chip->unmask(irq);
return;
simple:
#endif
ack_APIC_irq();
}


BUG: at /home/eric/projects/linux/linux-2.6-devel/kernel/lockdep.c:1860 
trace_hardirqs_on()

Call Trace:
   [] trace_hardirqs_on_thunk+0x35/0x37
 [] generic_delete_inode+0x0/0x13e
 [] restore_args+0x0/0x30
 [] generic_delete_inode+0x0/0x13e
 [] ack_apic+0x63/0x99
 [] ack_apic+0x5b/0x99
 [] handle_fasteoi_irq+0xc1/0xd1
 [] generic_delete_inode+0x0/0x13e
 [] do_IRQ+0x89/0xf3
 [] default_idle+0x35/0x51
 [] default_idle+0x0/0x51
 [] ret_from_intr+0x0/0xf
   [] generic_delete_inode+0x0/0x13e
 [] default_idle+0x0/0x51
 [] default_idle+0x35/0x51
 [] default_idle+0x37/0x51
 [] default_idle+0x35/0x51
 [] cpu_idle+0x56/0x75
 [] start_secondary+0x481/0x490

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

[BUG] at drivers/char/vt.c:3332 do_blank_screen() on resume

[S.Çağlar Onur]

Hi;

With 2.6.20, resuming from disk sometimes cannot returns on vt7 where X runs 
but everything seems working, so just changing to vt1 and returning to vt7 
solves the problem. But dmesg shows some BUG() output like [1] whenever this 
problem occurs

I'm using 20070207 snapshot of suspend, s2disk is used to suspend2disk, 
machine is a Sony Vaio FS-215B which is in the whitelist and works well with 
2.6.16/17/18 (all have fbsplash and vesafb-tng patches [from gentoo] 
applied).

[1] http://cekirdek.pardus.org.tr/~caglar/dmesg.2.6.20

Cheers
-- 
S.Çağlar Onur <[EMAIL PROTECTED]>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!


pgpOFZaDCPLaz.pgp
Description: PGP signature

[no subject]

[Priyanka Sharma]

unsubscribe linux-kernel

--
Priyanka
202.141.151.80/~priyanka
-
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: Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3

[Vivek Goyal]

On Thu, Feb 08, 2007 at 01:10:58PM +, Etienne Lorrain wrote:
> > >  I assume you care about this ELF header because you are also a user of
> > > the ELF file vmlinux, aren't you?
> >
> > Yes I am. I use kexec boot loader which has capability to load ELF kernel
> > images (vmlinux). That's why I am concerned about linking real mode code
> > in vmlinux as for kdump case I shall have to be aware that kernel vmlinux
> > might contain a special PT_LOAD type program header which will contain
> > real mode code and it does not have to be loaded. Then I will run into
> > guessing business which one is that real mode PT_LOAD  program header and
> > my assumption might very well break in next few kernel release.
> 
>  So is kexec able to relocate this vmlinux? If kexec and Gujin do 
> approximately
> the same thing they should do it the same way.

No, as of today, kexec does not relocate vmlinux. At compilation time,
vmlinux is compiled for a fixed address and vmlinux is loaded at that
address. This compile address can be controlled with CONFIG_PHYSICAL_START,
as you already mentioned in your patchset.

So in the case of kdump, if one wishes to use vmlinux instead of a relocatable
bzImage, he will re-compile the kernel for a different address and then use
that vmlinux.

OTOH, boot loader can possibly relocate vmlinux because all the relocation
information is retained in vmlinux (Using ld option --emit-relocs). But
probably self relocating image should be a better option as all the
boot-loaders out there don't have to be modifed.

> If you cannot get a PT_LOAD
> section, maybe we can put a simple system in NOTE, or just create a
> PT_LOAD16 if the linker accepts other values.

My guess is that PT_LOAD16 is not an acceptable value. Putting information
in PT_NOTE seems interesting (As Eric already mentioned).

>  I do not really like to relocate after vmlinux has been linked at a fixed 
> address,
> because I am not sure you can guess each address to relocate or not:
> you can define permanent address in the linker file by simply "symbol = 
> address"
> and those should never be relocated. For instance the very high addresses
> on ia32 may point to registers or FPU instead of memory, so may or may not
> have to be relocated. I also would better like you not to relocate the 
> real-mode
> addresses.
>  

I think there will have to be an upper limit on the address where you can
relocate your image to. Anyway, given i386 virtual memory address space
constraint, I think you can not load kernel image in high memory (896MB).
It has to run anywhere below that.

I think you are referring to defining absolute symbols. Already there are
some absolute symbols generated when kernel is compiled and these are
not relocated while image is being loaded at a non-compiled address. So if
a boot loader decides to relocate a vmlinux image, it will have to skip
relocations present w.r.t absolute symbols. (Unfortunately, ld does generate
relocation entries even for absolute symbols).
 
> > >  And you do not want to write protect the kernel code (if the CPU write 
> > > protection
> > > is not working, the hardware is not working so debug will be difficult, 
> > > and a simple
> > > CRC32 can tell kernel memory failure) and use twice the same code memory
> > > (with different data area or saving kernel data elsewhere before reload).
> > >  Is that related to module loading or instruction set detection/patch or 
> > > multiprocessor?
> >
> > If I understand it right, you seem to be suggesting that I don't have to 
> > reload the kernel text and I can only reload the data for second kernel?
> > 
> > We run the whole of the kernel from a mutually execlusive location from
> > first kernel to mitigate the concerns that first kernel's ongoing DMA might
> > corrupt second kernel. That's why first kernel's text can't be reused.
> 
>   So in some exception handler, you detect something is wrong and then
>  jump to a new kernel.

In a nutshell, Yes.

>  Maybe this class of bug (DMA or hardware bit flipped)
>  should be detected even without this double kernel environment, by running a
>  CRC32 on the kernel text section in this exception handler, displayed that in
>  the crash dump.

We already do checksum verification to make sure newly loaded kernel has
not been corrupted before we jump to it. What's the point in doing the
verification existing kernel text. Because even that is intact, and you
reload your data section, that data section will have to be reloaded at
the same place where previous data section was. Now after you re-loaded 
the data section, some DMA might corrupt it now (Because we never stopped
DMAs). So loading a fresh copy of text and data section at a reserved 
memory location seems safer. 

> 
> > Secondly, it gives flexibility to user that either he can choose to use 
> > the production kernel as capture kernel or an entirely different custom
> > kernel can be used as capture kernel.
> 
>   IHMO if it is just capturing the memo

Re: [PATCH] aio: fix kernel bug when page is temporally busy

[Andrew Morton]

On Fri, 9 Feb 2007 08:41:41 +0300 "Ananiev, Leonid I" <[EMAIL PROTECTED]> wrote:

> 
> > invalidate_inode_pages2() has other callers.  I suspect with this
> change
> > we'll end up leaking EIOCBRETRY back to userspace.
> 
> EIOCBRETRY is used and caught already in do_sync_read() and
> do_sync_readv_writev().

To pick one example:

nfs_follow_link
->nfs_revalidate_mapping_nolock
  ->nfs_invalidate_mapping_nolock
->invalidate_inode_pages2

so that, I assume, affects open(), unlink(), etc.


> Below fixed patch against kernel 2.6.20.

The tab->spaces issue is fixed, but it's still all wordwrapped.

-
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] aio: fix kernel bug when page is temporally busy

[Ananiev, Leonid I]

> invalidate_inode_pages2() has other callers.  I suspect with this
change
> we'll end up leaking EIOCBRETRY back to userspace.

EIOCBRETRY is used and caught already in do_sync_read() and
do_sync_readv_writev().

Below fixed patch against kernel 2.6.20.

>From Leonid Ananiev

Fix kernel bug when IO page is temporally busy:
invalidate_inode_pages2() returns EIOCBRETRY but not  EIO..

Signed-off-by: Leonid Ananiev <[EMAIL PROTECTED]>
---
--- linux-2.6.20/mm/truncate.c  2007-02-04 10:44:54.0 -0800
+++ linux-2.6.20p/mm/truncate.c 2007-02-08 11:38:11.0 -0800
@@ -366,7 +366,7 @@ static int do_launder_page(struct addres
  * Any pages which are found to be mapped into pagetables are unmapped
prior to
  * invalidation.
  *
- * Returns -EIO if any pages could not be invalidated.
+ * Returns -EIOCBRETRY if any pages could not be invalidated.
  */
 int invalidate_inode_pages2_range(struct address_space *mapping,
  pgoff_t start, pgoff_t end)
@@ -423,7 +423,7 @@ int invalidate_inode_pages2_range(struct
}
ret = do_launder_page(mapping, page);
if (ret == 0 &&
!invalidate_complete_page2(mapping, page))
-   ret = -EIO;
+   ret = -EIOCBRETRY;
unlock_page(page);
}
pagevec_release(&pvec);
@@ -440,7 +440,7 @@ EXPORT_SYMBOL_GPL(invalidate_inode_pages
  * Any pages which are found to be mapped into pagetables are unmapped
prior to
  * invalidation.
  *
- * Returns -EIO if any pages could not be invalidated.
+ * Returns -EIOCBRETRY if any pages could not be invalidated.
  */
 int invalidate_inode_pages2(struct address_space *mapping)
 {
-
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: -mm merge plans for 2.6.21

[Bharata B Rao]

Andrew,

On 2/9/07, Andrew Morton <[EMAIL PROTECTED]> wrote:

fsaio-add-a-wait-queue-arg-to-the-wait_bit-action-routine.patch
fsaio-add-a-wait-queue-arg-to-the-wait_bit-action-routine-gfs2-fix.patch
fsaio-rename-__lock_page-to-lock_page_blocking.patch
fsaio-interfaces-to-initialize-and-to-test-a-wait-bit-key.patch
fsaio-add-a-default-io-wait-bit-field-in-task-struct.patch
fsaio-enable-wait-bit-based-filtered-wakeups-to-work-for-aio.patch
fsaio-enable-wait-bit-based-filtered-wakeups-to-work-for-aio-fix.patch
fsaio-enable-wait-bit-based-filtered-wakeups-to-work-for-aio-fix-sparse-fix.patch
fsaio-enable-asynchronous-wait-page-and-lock-page.patch
fsaio-filesystem-aio-read.patch
fsaio-aio-o_sync-filesystem-write.patch

 Will wait to see what happens with febrils.

aio-is-unlikely.patch

 Will merge.

rework-compat_sys_io_submit.patch
fix-aioh-includes.patch
fix-access_ok-checks.patch
make-good_sigevent-non-static.patch
make-good_sigevent-non-static-fix.patch
make-__sigqueue_free-and.patch
aio-completion-signal-notification.patch
aio-completion-signal-notification-fix.patch
aio-completion-signal-notification-fixes-and-cleanups.patch
aio-completion-signal-notification-small-cleanup.patch
add-listio-syscall-support.patch

 I guess these are dependent upon fsaio.


No. AIO completion signal notification patches and listio patch work
independently of fsaio patches. Just that for buffered AIO case, the
fsaio patches will make the behaviour truly asynchronous.

Regards,
Bharata.
-
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: The who needs reviews anyways [PATCH]

[Oleg Verych]

On Thu, Feb 08, 2007 at 10:48:51PM +0100, Roman Zippel wrote:
[]
> - printf has other side effects, instead stop pretending we support 
>   something else than bash

More on printf, `sh', tmpfiles.

As we know original problem is: something from binutils is removing
output files on failure. 

> -   else if [ -x /bin/bash ]; then echo /bin/bash; \
> -   else echo sh; fi ; fi)
> +   else if [ -x /bin/bash ]; then echo /bin/bash; fi; fi)
> +ifeq ($(CONFIG_SHELL),)
> +$(error bash is required to build the kernel)
> +endif
> +SHELL := $(CONFIG_SHELL)

here is policy to have `bash' introduced, so due to original
issue, where `root' users ended with removed /dev/null, may policy to have
`non root' user to build kernel be added? Thus

this:
> +# output directory for tests below
> +TMPOUT := $(if $(KBUILD_EXTMOD),$(firstword $(KBUILD_EXTMOD))/)
[]
> +# try-run
> +# Usage: option = $(call try-run, $(CC)...-o "$$TMP",option-ok,otherwise)
> +# Exit code chooses option. "$$TMP" is can be used as temporary file and
> +# is automatically cleaned up.
> +try-run = $(shell set -e;\
this:
> + TMP="$(TMPOUT)..tmp";   \
[]
> + if ($(1)) >/dev/null 2>&1;  \
> + then echo "$(2)";   \
> + else echo "$(3)";   \
> + fi; \
this:
> + rm -f "$$TMP")

may be removed, and to make TMP=/dev/null? And to forget currently about
my silly symlinks, and this crappy sets of output files?

As for `printf', as i've wrote, only in case of % and quotes in
arguments, something else must be added to handle that. But i think, it's
paranoia.

> -as-instr = $(call checker-shell,\
> -   printf "$(1)" | $(CC) $(AFLAGS) -c -xassembler -o $$OUT -,$(2),$(3))

`printf $(1)' is pretty enough.


-
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: forcedeth problems on 2.6.20-rc6-mm3

[Ayaz Abdulla]

David Ford wrote:
On 2/5/07, *Andrew Morton* <[EMAIL PROTECTED] 
> wrote:


On Sun, 04 Feb 2007 23:48:33 -0600 Robert Hancock <[EMAIL PROTECTED]
> wrote:

 > Andrew Morton wrote:
 > > On Sun, 04 Feb 2007 23:13:09 -0600 Robert Hancock <
[EMAIL PROTECTED] > wrote:
 > >
 > >> Something's busted with forcedeth in 2.6.20-rc6-mm3 for me
relative to
 > >> 2.6.20-rc6. There's no errors in dmesg, but it seems no
packets ever get
 > >> received and so the machine can't get an IP address. I tried
reverting
 > >> all the -mm changes to drivers/net/forcedeth.c, which didn't
help. The
 > >> network controller shares an IRQ with the USB OHCI controller
which is
 > >> receiving interrupts, so it doesn't seem like an interrupt routing
 > >> problem, though I suppose something wierd could be happening
there.
 > >>
 > >> This is on an Asus A8N-SLI Deluxe (CK804 chipset) on x86_64.
 > >>
 > >> Any suggestions on how to debug/what to try reverting to see
what's
 > >> causing this?
 > >
 > > There are many forcedeth changes in git-netdev-all.patch.  Can you
 > > try reverting drivers/net/forcedeth.c back to the unpatched version
 > > from 2.6.20-rc6?
 > >
 > > Thanks.
 > >
 >
 > That's essentially what I did, it didn't appear to help. I assume
the
 > problem must lie elsewhere..
 >

doh, I missed that.

It's presumably not the driver and nobody else seems to be hitting
this, so
it must be something peculiar to your setup.  But I don't know what it
might be, sorry.



Actually it has been reported by several other people here including 
myself but it seems to have been overlooked here ;)


See the messages with forcedeth in the subject line over the past few 
weeks.


I put 2.6.20-gentoo on my machine this weekend with debug printks 
enabled and right now I have yet to lose connectivity -- going on ~20 
hours worth.


Previously I would lose connectivity within minutes of booting up.  I 
had a script set up that detected the ping loss of a gateway and would 
restart both interfaces (dual onboard nics).


Tonight I will disable the debug printks and see if the system remains 
online.  There was a big patch applied to forcedeth for 2.6.20, 
previously I was having these issues for several of the -19 series.


David


For all those who are having issues, please try out the attached patch.

Ayaz


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--- orig/drivers/net/forcedeth.c2007-02-08 21:41:59.0 -0500
+++ new/drivers/net/forcedeth.c 2007-02-08 21:44:53.0 -0500
@@ -3104,13 +3104,17 @@
struct fe_priv *np = netdev_priv(dev);
u8 __iomem *base = get_hwbase(dev);
unsigned long flags;
+   u32 retcode;
 
-   if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2)
+   if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) {
pkts = nv_rx_process(dev, limit);
-   else
+   retcode = nv_alloc_rx(dev);
+   } else {
pkts = nv_rx_process_optimized(dev, limit);
+   retcode = nv_alloc_rx_optimized(dev);
+   }
 
-   if (nv_alloc_rx(dev)) {
+   if (retcode) {
spin_lock_irqsave(&np->lock, flags);
if (!np->in_shutdown)
mod_timer(&np->oom_kick, jiffies + OOM_REFILL);

Re: [PATCH] aio: fix kernel bug when page is temporally busy

[Andrew Morton]

On Fri, 9 Feb 2007 07:29:31 +0300 "Ananiev, Leonid I" <[EMAIL PROTECTED]> wrote:

> >From Leonid Ananiev
> 
> Fix "Kernel BUG at fs/aio.c:509". Return EIOCBRETRY but not  EIO if page
> is busy.
> 
> Signed-off-by: Leonid Ananiev <[EMAIL PROTECTED]>
> 
> "Kernel BUG at fs/aio.c:509"
> http://marc.theaimsgroup.com/?l=linux-kernel&m=117031052517746&w=2 
> is present in 2.6.20 as well as 2.6.19.
> The investigation shows that the bug's panic occurs when aio_complete()
> is called with argument ret=EIO which is returned from
> invalidate_inode_pages2_range() because the page is temporally busy.
> Call Trace:
>  [] invalidate_inode_pages2_range+0x236/0x26b
>  [] ext3_direct_IO+0x16c/0x19e
>  [] ext3_get_block+0x0/0xe2
>  [] generic_file_direct_IO+0xb9/0xcf
>  [] generic_file_direct_write+0x67/0x10e
>  [] __generic_file_aio_write_nolock+0x2d6/0x3fe
>  [] __switch_to+0x26f/0x27e
>  [] thread_return+0x0/0xd8
>  [] generic_file_aio_write+0x67/0xc7
>  [] ext3_file_write+0x0/0x8f
>  [] ext3_file_write+0x16/0x8f
>  [] ext3_file_write+0x0/0x8f
>  [] aio_rw_vect_retry+0x72/0x14f
>  [] aio_run_iocb+0xe6/0x187
>  [] io_submit_one+0x296/0x2e3
>  [] sys_io_submit+0x9b/0x108
>  [] default_wake_function+0x0/0xe
>  [] system_call+0x7e/0x83
> 
> As a result aio_complete() is called while it should not be.
> When IO is finished  aio_complete() is called once more
> and iocb->ki_users becomes negative.
> 
> Taking into account aio.c lines in aio_run_iocb()
> if (ret != -EIOCBRETRY && ret != -EIOCBQUEUED) {
> aio_complete(iocb, ret, 0);
> 
> proposed patch makes function invalidate_inode_pages2_range()
> to return EIOCBRETRY but not  EIO if page is busy.
> The patch is tested on 2.6.20.
> 
> --- linux-2.6.20/mm/truncate.c  2007-02-04 10:44:54.0 -0800
> +++ linux-2.6.20p/mm/truncate.c 2007-02-08 11:38:11.0 -0800
> @@ -366,7 +366,7 @@ static int do_launder_page(struct addres
>   * Any pages which are found to be mapped into pagetables are unmapped
> prior to
>   * invalidation.
>   *
> - * Returns -EIO if any pages could not be invalidated.
> + * Returns -EIOCBRETRY if any pages could not be invalidated.
>   */
>  int invalidate_inode_pages2_range(struct address_space *mapping,
>   pgoff_t start, pgoff_t end)
> @@ -423,7 +423,7 @@ int invalidate_inode_pages2_range(struct
> }
> ret = do_launder_page(mapping, page);
> if (ret == 0 &&
> !invalidate_complete_page2(mapping, page))
> -   ret = -EIO;
> +   ret = -EIOCBRETRY;
> unlock_page(page);
> }
> pagevec_release(&pvec);
> @@ -440,7 +440,7 @@ EXPORT_SYMBOL_GPL(invalidate_inode_pages
>   * Any pages which are found to be mapped into pagetables are unmapped
> prior to
>   * invalidation.
>   *
> - * Returns -EIO if any pages could not be invalidated.
> + * Returns -EIOCBRETRY if any pages could not be invalidated.
>   */
>  int invalidate_inode_pages2(struct address_space *mapping)
>  {

The patch is wildly wordwrapped and has had it tabs replaced with spaces.

invalidate_inode_pages2() has other callers.  I suspect with this change
we'll end up leaking EIOCBRETRY back to userspace.

-
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: Network: convert network devices to use struct device instead of class_device

[Dmitry Torokhov]

On Thursday 08 February 2007 19:56, Greg KH wrote:
> On Thu, Feb 08, 2007 at 12:29:12PM -0500, Dmitry Torokhov wrote:
> > On 2/8/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> > >On Thu, 08 Feb 2007 07:43:18 -0500
> > >Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > >
> > >> Linux Kernel Mailing List wrote:
> > >> > Gitweb: 
> > >http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=43cb76d91ee85f579a69d42bc8efc08bac560278
> > >> > Commit: 43cb76d91ee85f579a69d42bc8efc08bac560278
> > >> > Parent: 2943ecf2ed32632473c06f1975db47a7aa98c10f
> > >> > Author: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> > >> > AuthorDate: Tue Apr 9 12:14:34 2002 -0700
> > >> > Committer:  Greg Kroah-Hartman <[EMAIL PROTECTED]>
> > >> > CommitDate: Wed Feb 7 10:37:11 2007 -0800
> > >> >
> > >> > Network: convert network devices to use struct device instead of 
> > >class_device
> > >> >
> > >> > This lets the network core have the ability to handle 
> > >suspend/resume
> > >> > issues, if it wants to.
> > >
> > >It fixes a non-problem. I would like to see the network core suspend/resume
> > >proposal as well. Last time I examined doing network core suspend help,
> > >the problem was that the physical device suspend was called before the
> > >class device. It is not clear how this change would help.
> > 
> > If physical devices are registered before class devices then when
> > suspending class devices are naturally suspended first. It is still
> > not clear to me why we need to convert everythign to struct device, I
> > believe I've shown (with patches) that it is possible to integrate
> > struct class_device into PM framework and avoid reshuffling half of
> > the kernel code.
> 
> I don't want to have two separate device trees in the kernel (well, one
> big device tree and a bunch of little class_device trees.)  The code
> duplication in the class_device code is just too much, and I get
> questions all the time as to what the differences are.
>

While duplication of code is a real concern my worry is constant fattening
of struct device. For example most physical devices do not interface
directly with userspace but every single one of them now has dev_t.
Former class_devices do not need suspend/resume early framework either.
And so on, and so forth.
 
> With these slow and gradual changes, we are getting a true, unified,
> device tree, and it will reduce the amount of code and complexity we
> need to maintain and fix in the driver core itself.
> 
> And it should also alow for proper power management functionality, using
> the changes that Linus put into the driver core about 8 months ago.
> 
> Don't worry, I have input patches queued up next for you Dmitry :)
> 

;)

-- 
Dmitry
-
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: fix kernel bug when page is temporally busy

[Ananiev, Leonid I]

>From Leonid Ananiev

Fix "Kernel BUG at fs/aio.c:509". Return EIOCBRETRY but not  EIO if page
is busy.

Signed-off-by: Leonid Ananiev <[EMAIL PROTECTED]>

"Kernel BUG at fs/aio.c:509"
http://marc.theaimsgroup.com/?l=linux-kernel&m=117031052517746&w=2 
is present in 2.6.20 as well as 2.6.19.
The investigation shows that the bug's panic occurs when aio_complete()
is called with argument ret=EIO which is returned from
invalidate_inode_pages2_range() because the page is temporally busy.
Call Trace:
 [] invalidate_inode_pages2_range+0x236/0x26b
 [] ext3_direct_IO+0x16c/0x19e
 [] ext3_get_block+0x0/0xe2
 [] generic_file_direct_IO+0xb9/0xcf
 [] generic_file_direct_write+0x67/0x10e
 [] __generic_file_aio_write_nolock+0x2d6/0x3fe
 [] __switch_to+0x26f/0x27e
 [] thread_return+0x0/0xd8
 [] generic_file_aio_write+0x67/0xc7
 [] ext3_file_write+0x0/0x8f
 [] ext3_file_write+0x16/0x8f
 [] ext3_file_write+0x0/0x8f
 [] aio_rw_vect_retry+0x72/0x14f
 [] aio_run_iocb+0xe6/0x187
 [] io_submit_one+0x296/0x2e3
 [] sys_io_submit+0x9b/0x108
 [] default_wake_function+0x0/0xe
 [] system_call+0x7e/0x83

As a result aio_complete() is called while it should not be.
When IO is finished  aio_complete() is called once more
and iocb->ki_users becomes negative.

Taking into account aio.c lines in aio_run_iocb()
if (ret != -EIOCBRETRY && ret != -EIOCBQUEUED) {
aio_complete(iocb, ret, 0);

proposed patch makes function invalidate_inode_pages2_range()
to return EIOCBRETRY but not  EIO if page is busy.
The patch is tested on 2.6.20.

--- linux-2.6.20/mm/truncate.c  2007-02-04 10:44:54.0 -0800
+++ linux-2.6.20p/mm/truncate.c 2007-02-08 11:38:11.0 -0800
@@ -366,7 +366,7 @@ static int do_launder_page(struct addres
  * Any pages which are found to be mapped into pagetables are unmapped
prior to
  * invalidation.
  *
- * Returns -EIO if any pages could not be invalidated.
+ * Returns -EIOCBRETRY if any pages could not be invalidated.
  */
 int invalidate_inode_pages2_range(struct address_space *mapping,
  pgoff_t start, pgoff_t end)
@@ -423,7 +423,7 @@ int invalidate_inode_pages2_range(struct
}
ret = do_launder_page(mapping, page);
if (ret == 0 &&
!invalidate_complete_page2(mapping, page))
-   ret = -EIO;
+   ret = -EIOCBRETRY;
unlock_page(page);
}
pagevec_release(&pvec);
@@ -440,7 +440,7 @@ EXPORT_SYMBOL_GPL(invalidate_inode_pages
  * Any pages which are found to be mapped into pagetables are unmapped
prior to
  * invalidation.
  *
- * Returns -EIO if any pages could not be invalidated.
+ * Returns -EIOCBRETRY if any pages could not be invalidated.
  */
 int invalidate_inode_pages2(struct address_space *mapping)
 {
-
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/

genirq: Add a set_irq_handler_locked() function

[David Gibson]

Thomas, as discussed previously over IRC and private email.  Please
apply.

At present set_irq_handler() and all the existing variants take the
desc->lock for the irq in question before adjusting the irq's flow
handler.  This can cause problems for irq chips for which a given
interrupt can be either level or edge depending on what's attached.
The chip->set_type() callback, which is used to switch the interrupt
type in this case may need to alter the flow handler - but it is
called with the desc->lock already held, so it cannot safely call
set_irq_handler().

This patch pulls the core logic out of set_irq_handler() into a new
set_irq_handler_locked() which assumes the desc->lock is already held.
It can safely be used from the chip->set_type() callback.

Signed-off-by: David Gibson <[EMAIL PROTECTED]>

Index: working-2.6/kernel/irq/chip.c
===
--- working-2.6.orig/kernel/irq/chip.c  2007-01-24 12:01:21.0 +1100
+++ working-2.6/kernel/irq/chip.c   2007-02-09 14:28:55.0 +1100
@@ -500,6 +500,43 @@ handle_percpu_irq(unsigned int irq, stru
 
 #endif /* CONFIG_SMP */
 
+/**
+ * set_irq_handler_locked - Set irq flow handler. *
+ * @irq:   the interrupt number
+ * @handle:the flow handler function
+ * @is_chained:is this a chained handler (used for cascade interrupts)
+ * @name:  name for this handler, usually "level" or "edge"
+ *
+ * This version of set_irq_handler() assumes that desc->lock for
+ * the interrupt in question is already taken.  In particular,
+ * this means it is safe to call from a chip->set_type() callback
+ * function.
+ */
+void set_irq_handler_locked(unsigned int irq, irq_flow_handler_t handle,
+   int is_chained, const char *name)
+{
+   struct irq_desc *desc = irq_desc + irq;
+
+   /* Uninstall? */
+   if (handle == handle_bad_irq) {
+   if (desc->chip != &no_irq_chip) {
+   desc->chip->mask(irq);
+   desc->chip->ack(irq);
+   }
+   desc->status |= IRQ_DISABLED;
+   desc->depth = 1;
+   }
+   desc->handle_irq = handle;
+   desc->name = name;
+
+   if (handle != handle_bad_irq && is_chained) {
+   desc->status &= ~IRQ_DISABLED;
+   desc->status |= IRQ_NOREQUEST | IRQ_NOPROBE;
+   desc->depth = 0;
+   desc->chip->unmask(irq);
+   }
+}
+
 void
 __set_irq_handler(unsigned int irq, irq_flow_handler_t handle, int is_chained,
  const char *name)
@@ -531,25 +568,7 @@ __set_irq_handler(unsigned int irq, irq_
}
 
spin_lock_irqsave(&desc->lock, flags);
-
-   /* Uninstall? */
-   if (handle == handle_bad_irq) {
-   if (desc->chip != &no_irq_chip) {
-   desc->chip->mask(irq);
-   desc->chip->ack(irq);
-   }
-   desc->status |= IRQ_DISABLED;
-   desc->depth = 1;
-   }
-   desc->handle_irq = handle;
-   desc->name = name;
-
-   if (handle != handle_bad_irq && is_chained) {
-   desc->status &= ~IRQ_DISABLED;
-   desc->status |= IRQ_NOREQUEST | IRQ_NOPROBE;
-   desc->depth = 0;
-   desc->chip->unmask(irq);
-   }
+   set_irq_handler_locked(irq, handle, is_chained, name);
spin_unlock_irqrestore(&desc->lock, flags);
 }
 
Index: working-2.6/include/linux/irq.h
===
--- working-2.6.orig/include/linux/irq.h2007-01-24 12:01:21.0 
+1100
+++ working-2.6/include/linux/irq.h 2007-02-09 14:04:12.0 +1100
@@ -329,6 +329,9 @@ set_irq_chip_and_handler_name(unsigned i
  irq_flow_handler_t handle, const char *name);
 
 extern void
+set_irq_handler_locked(unsigned int irq, irq_flow_handler_t handle,
+  int is_chained, const char *name);
+extern void
 __set_irq_handler(unsigned int irq, irq_flow_handler_t handle, int is_chained,
  const char *name);
 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
-
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: somebody dropped a (warning) bomb

[D. Hazelton]

On Thursday 08 February 2007 19:42, Linus Torvalds wrote:

> Most C types don't, and some you can't even tell (do pointers generate
> "signed" or "unsigned" comparisons? I'll argue that a compiler that
> generates signed comparisons for them is broken, but it tends to be
> something you can only see with a standards- conforming proghram if you
> can allocate memory across the sign boundary, which may or may not be
> true..)

And this is, because as Dennis Ritchie says in "The Development of the C 
Language" (http://cm.bell-labs.com/cm/cs/who/dmr/chist.html) C evolved from a 
typeless language, B - which, in turn, had originated as a stripped down 
version of BCPL. B and BCPL  used a "cell addressing" scheme, but because of 
the move off the PDP-7, and the difficulties run into by Ken Thompson in 
rewriting the code for Unix in B (the original Unix was written in assembler) 
types were added - 'char' and 'int'. These represented the byte and word 
addressing modes of the PDP-11, and were needed because Ritchie was in the 
process of having the compiler generate assembler instead of "threaded code". 
This "NB" language, after also having data structures added and the rules for 
defining pointers finalized, was renamed "C" by Ritchie.

So almost all the rules around the signs of types are because of a single, 
historical machine. Hence the rules about "char" being unsigned by default 
and "int" being signed by default are because of the nature of the PDP-11. 
The implementation defined nature of bitfields is because Dennis Ritchie had 
freedom there - the PDP-11 didn't have anything like them in the hardware and 
they were being stuffed in to make Thompsons life easier.

Now: There is no reason for the behavior that came from the nature of the 
PDP11 to have survived, but because it was in "The White Book" it made it 
through the ANSI standardization process.

Now that this history lesson is over...

DRH
-
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] fs: add an iovec iterator

[Nick Piggin]

On Thu, Feb 08, 2007 at 06:03:50PM -0800, Nate Diller wrote:
> On 2/8/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
> >On Thu, Feb 08, 2007 at 07:49:53PM +, Christoph Hellwig wrote:
> >> On Thu, Feb 08, 2007 at 02:07:24PM +0100, Nick Piggin wrote:
> >> > Add an iterator data structure to operate over an iovec. Add usercopy
> >> > operators needed by generic_file_buffered_write, and convert that 
> >function
> >> > over.
> >>
> >> iovec_iterator is an awfully long and not very descriptive name.
> >> In past discussions we named this thingy iodesc and wanted to pass it
> >> down all the I/O path, including the file operations.
> >
> >Hi Christoph,
> >
> >Sure I think it would be a good idea to shorten the name. And yes, although
> >I just construct the iterator to pass into perform_write, I think it should
> >make sense to go much further up the call stack instead of passing all 
> >those
> >args around. iodesc seems like a fine name, so I'll use that unless
> >anyone objects.
> 
> i had a patch integrating the iodesc idea, but after some thought, had
> decided to call it struct file_io.  That name reflects the fact that
> it's doing I/O in arbitrary lengths with byte offsets, and struct
> file_io *fio contrasts well with struct bio (block_io).  I also had
> used the field ->nbytes instead of ->count, to clarify the difference
> between segment iterators, segment offsets, and absolute bytecount.

The field name is a good suggestion.

What I have there is not actually a full-blown file io descriptor, because
there is no file or offset. It is just an iovec iterator (so maybe I should
rename it to iov_iter, rather than iodesc). 

I think it might be a nice idea to keep this iov_iter as a standalone
structure, and it could be embedded into a struct file_io?

Thanks,
Nick
-
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] ATA convert GSI to irq on ia64

[Zhang, Yanmin]

On Thu, 2007-02-08 at 20:19 -0500, Jeff Garzik wrote:
> Zhang, Yanmin wrote:
> > If an ATA drive uses legacy mode, ata driver will choose 14 and 15 as the
> > fixed irq number. On ia64 platform, such numbers are GSI and should be 
> > converted
> > to irq vector.
> > 
> > Below patch against kernel 2.6.20 fixes it.
> > 
> > Signed-off-by: Zhang Yanmin <[EMAIL PROTECTED]>
> 
> IA64 should create its own libata-portmap.h, rather than modifying the 
> one in asm-generic with arch-specific choices.
> 
> powerpc is a current example of this (and currently the only 
> non-asm-generic user) found in kernel 2.6.20.
Thank Jeff. I worked out a new patch.

If an ATA drive uses legacy mode, ata driver will choose 14 and 15 as the fixed
irq number. On ia64 platform, such numbers are GSI and should be converted to 
irq
vector.

Below patch against kernel 2.6.20 fixes it.
 
Signed-off-by: Zhang Yanmin <[EMAIL PROTECTED]>

---

diff -Nraup linux-2.6.20/arch/ia64/Kconfig linux-2.6.20_fix/arch/ia64/Kconfig
--- linux-2.6.20/arch/ia64/Kconfig  2007-02-08 15:13:41.0 +0800
+++ linux-2.6.20_fix/arch/ia64/Kconfig  2007-02-09 11:19:35.0 +0800
@@ -11,6 +11,7 @@ menu "Processor type and features"
 
 config IA64
bool
+   select ATA_NONSTANDARD if ATA
default y
help
  The Itanium Processor Family is Intel's 64-bit successor to
diff -Nraup linux-2.6.20/include/asm-ia64/libata-portmap.h 
linux-2.6.20_fix/include/asm-ia64/libata-portmap.h
--- linux-2.6.20/include/asm-ia64/libata-portmap.h  1970-01-01 
08:00:00.0 +0800
+++ linux-2.6.20_fix/include/asm-ia64/libata-portmap.h  2007-02-09 
11:19:55.0 +0800
@@ -0,0 +1,12 @@
+#ifndef __ASM_IA64_LIBATA_PORTMAP_H
+#define __ASM_IA64_LIBATA_PORTMAP_H
+
+#define ATA_PRIMARY_CMD0x1F0
+#define ATA_PRIMARY_CTL0x3F6
+#define ATA_PRIMARY_IRQ(dev)   isa_irq_to_vector(14)
+
+#define ATA_SECONDARY_CMD  0x170
+#define ATA_SECONDARY_CTL  0x376
+#define ATA_SECONDARY_IRQ(dev) isa_irq_to_vector(15)
+
+#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: -mm merge plans for 2.6.21

[Andrew Morton]

On Thu, 8 Feb 2007 21:57:50 -0500 "Parag Warudkar" <[EMAIL PROTECTED]> wrote:

> >x86-fix-vdso-mapping-for-aout-executables.patch
> >a.out executables are presently non-functional.  This patch needs more work.
> 
> I have a patch for x86 ready and tested and I should be able to get
> the full thing (x86, ppc, sh and x86_64) out over the weekend. (This
> time around I got rid of the CONFIG stuff used __attribute__((weak))
> as Andi suggested. Hopefully that's what you meant by more work?)
> 

Sounds good, thanks.
-
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/

-mm merge plans for 2.6.21

[Parag Warudkar]

x86-fix-vdso-mapping-for-aout-executables.patch
a.out executables are presently non-functional.  This patch needs more work.


I have a patch for x86 ready and tested and I should be able to get
the full thing (x86, ppc, sh and x86_64) out over the weekend. (This
time around I got rid of the CONFIG stuff used __attribute__((weak))
as Andi suggested. Hopefully that's what you meant by more work?)

Parag
-
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: [Cbe-oss-dev] [RFC, PATCH] CELL Oprofile SPU profiling updated patch

[Milton Miller]

On Feb 8, 2007, at 4:51 PM, Carl Love wrote:


On Thu, 2007-02-08 at 18:21 +0100, Arnd Bergmann wrote:

On Thursday 08 February 2007 15:18, Milton Miller wrote:


1) sample rate setup

In the current patch, the user specifies a sample rate as a time
interval.
The kernel is (a) calling cpufreq to get the current cpu 
frequency,

(b)
converting the rate to a cycle count, (c) converting this to a 
24 bit

LFSR count, an iterative algorithm (in this patch, starting from
one of 256 values so a max of 2^16 or 64k iterations), (d)
calculating
an trace unload interval.   In addition, a cpufreq notifier is
registered
to recalculate on frequency changes.


No.  The user issues the command opcontrol --event:N  where N is the
number of events (cycles, l2 cache misses, instructions retired etc)
that are to elapse between collecting the samples.


So you are saying that b and c are primary, and a is used to calculate
a safe value for d.   All of the above work is dont, just from a
different starting point?



The OProfile passes
the value N to the kernel via the variable ctr[i].count.  Where i is 
the

performance counter entry for that event.


Ok I haven't looked a the api closely.


Specifically with SPU
profiling, we do not use performance counters because the CELL HW does
not allow the normal the PPU to read the SPU PC when a performance
counter interrupt occurs.  We are using some additional hw support in
the chip that allows us to periodically capture the SPU PC.  There is 
an

LFSR hardware counter that can be started at an arbitrary LFSR value.
When the last LFSR value in the sequence is reached, a sample is taken
and stored in the trace buffer.  Hence, the value of N specified by the
user must get converted to the LFSR value that is N from the end of the
sequence.


Ok so its arbitray load count to max vs count and compare.   A critical
detail when computing the value to load, but the net result is the
same; the value for the count it hard to determine.


The same clock that the processor is running at is used to
control the LFSR count.  Hence the LFSR counter increments once per CPU
clock cycle regardless of the CPU frequency or changes in the 
frequency.

There is no calculation for the LFSR value that is a function of the
processor frequency.  There is no need to adjust the LFSR when the
processor frequency changes.




Oh, so the lfsr doesn't have to be recomputed, only the time
between unloads.



Milton had a comment about the code

 if (ctr[0].event == SPU_CYCLES_EVENT_NUM) {

+ spu_cycle_reset = ctr[0].count;
+ return;
+ }


Well, given the above description, it is clear that if you are doing 
SPU

event profiling, the value N is put into the cntr[0].cnt entry since
there is only one event.  Thus in cell_global_start_spu() you use
spu_cycle_reset as the argument to the lfsr calculation routine to get
the LFSR value that is N from the end of the sequence.


I was looking at the patch and the context was not very good.   You
might consider adding -p to your diff command, it provides the function
name after the @@.

However, in this case, I think I just need to see the final result.





The obvious problem is step (c), running a loop potentially 64
thousand
times in kernel space will have a noticeable impact on other 
threads.


I propose instead that user space perform the above 4 steps, and
provide
the kernel with two inputs: (1) the value to load in the LFSR 
and (2)
the periodic frequency / time interval at which to empty the 
hardware

trace buffer, perform sample analysis, and send the data to the
oprofile
subsystem.

There should be no security issues with this approach.   If the 
LFSR

value
is calculated incorrectly, either it will be too short, causing 
the

trace
array to overfill and data to be dropped, or it will be too 
long, and

there will be fewer samples.   Likewise, the kernel periodic poll
can be
too long, again causing overflow, or too frequent, causing only 
timer

execution overhead.

Various data is collected by the kernel while processing the
periodic timer,
this approach would also allow the profiling tools to control the
frequency of this collection.   More frequent collection results 
in

more
accurate sample data, with the linear cost of poll execution
overhead.

Frequency changes can be handled either by the profile code 
setting
collection at a higher than necessary rate, or by interacting 
with

the
governor to limit the speeds.

Optionally, the kernel can add a record indicating that some 
data was

likely dropped if it is able to read all 256 entries without
underflowing
the array.  This can be used as hint to user space that the 
kernel

time
was too long for the collection rate.


Moving the sample rate computation to user space sounds like the right
idea, but why not have a more drastic version of it:


No, I do not 

Strange oops in iret_exc with my own module

[Grzegorz Kulewski]

Hi,

I written really simple and stupid module (the design wasn't mine). One 
tester of this module provided me the following oops it caused quite often 
(on many automated tests):


[17179765.492000] BUG: unable to handle kernel NULL pointer dereference at 
virtual address 

[17179765.492000]  printing eip:
[17179765.492000] c02c4845
[17179765.492000] *pde = 
[17179765.492000] Oops: 0002 [#1]
[17179765.492000] Modules linked in: altpinfo rfcomm l2cap bluetooth ppdev 
cpufreq_userspace cpufreq_stats freq_table
cpufreq_powersave cpufreq_ondemand cpufreq_conservative video button 
battery container ac af_packet dm_mod md_mod ipv6
lp snd_seq_dummy snd_seq_oss snd_seq_midi snd_seq_midi_event snd_seq 
snd_via82xx gameport snd_ac97_codec snd_ac97_bus
via686a snd_pcm_oss snd_mixer_oss tsdev i2c_isa i2c_viapro usbhid snd_pcm 
snd_timer snd_page_alloc snd_mpu401_uart
snd_rawmidi snd_seq_device i2c_core snd soundcore psmouse 8139too mii 
pcspkr floppy serio_raw parport_pc rtc via_agp
agpgart parport shpchp pci_hotplug evdev ext3 jbd mbcache ide_generic 
uhci_hcd usbcore ide_cd cdrom ide_disk via82cxxx
generic thermal processor fan vga16fb cfbcopyarea vgastate cfbimgblt 
cfbfillrect

[17179765.492000] CPU:0
[17179765.492000] EIP:0060:[]Not tainted VLI
[17179765.492000] EFLAGS: 00210246   (2.6.17.13nopreempt #3)
[17179765.492000] EIP is at iret_exc+0x4fd/0x75d
[17179765.492000] eax:    ebx:    ecx: 2b646970   edx: 
336e3094
[17179765.492000] esi: 0809c724   edi:    ebp: 0003   esp: 
c32b3f34

[17179765.492000] ds: 007b   es: 007b   ss: 0068
[17179765.492000] Process so6-3-test (pid: 7227, threadinfo=c32b2000 
task=c620e550)
[17179765.492000] Stack:  2b646970  2b646970 d0833913 
 0809c724 2b646970
[17179765.492000]0809c720 c47c8d40 40040c01 0809c720 c016a5f2 
cadb0624 c47c8d40 40040c01
[17179765.492000]0809c720 c47c8d40  c016a654 c015845a 
cffefa80 c47c8d40 c016a90d

[17179765.492000] Call Trace:
[17179765.492000]   altpinfo_ioctl+0x103/0x170 [altpinfo] 
 do_ioctl+0x52/0x60
[17179765.492000]   vfs_ioctl+0x54/0x2b0   
do_sys_open+0x9a/0xd0
[17179765.492000]   sys_ioctl+0x5d/0x90   
syscall_call+0x7/0xb
[17179765.492000] Code: 5c 24 28 c7 03 f2 ff ff ff e9 12 be f0 ff ba f2 ff 
ff ff e9 6d c0 f0 ff 8d 0c 8a e9 8f c0 f0 ff
01 c1 eb 03 8d 0c 88 51 50 31 c0  aa 58 59 e9 ca c0 f0 ff 8d 0c 88 51 
50 31 c0 f3 aa 58 59 e9
[17179765.492000] EIP: [] iret_exc+0x4fd/0x75d SS:ESP 
0068:c32b3f34

[17179765.492000]  <6>altpinfo: unloaded


The function altpinfo_ioctl looks like this:

static int altpinfo_ioctl(struct inode *inode, struct file *f, unsigned 
int cmd, unsigned long arg)

{
int ret = 0;

switch (cmd) {

case API_GET_FMT:
ret = put_fmt((char __user *)arg);
break;

case API_SET_FMT:
if (!capable(CAP_SYS_ADMIN)) {
return -EPERM;
}

ret = get_fmt((char __user *)arg);
break;

case API_GET_CURLEN:
ret = put_curlen(f, (int __user *)arg);
break;

default:
ret = -ENOTTY;
break;

}

return ret;
}


Helper functions look like this:

static int put_curlen(struct file *f, int __user *arg)
{
int left;
struct private_data *p = (struct private_data *) f->private_data;

if (down_interruptible(&p->sem) != 0) {
return -ERESTARTSYS;
}

left = p->buffer_size - f->f_pos;

up(&p->sem);

return put_user(left, arg);
}

static int put_fmt(char __user *arg)
{
char *fmt;
int ret;

ret = get_format_string(&fmt);

if (ret != 0) {
return ret;
}

if (copy_to_user(arg, fmt, strlen(fmt)) != 0) {
return -EIO;
}

kfree(fmt);

return 0;
}

/* Better make arg buffer at least 4 bytes alligned in userspace! */
static int get_fmt(char __user *arg)
{
int ret;
int len;
char *buf;

ret = get_user(len, (int __user *)arg);

if (ret != 0) {
return ret;
}

buf = kcalloc(len, sizeof(char), GFP_KERNEL);

if (copy_from_user(buf, arg + 4, len) != 0) {
kfree(buf);
return -EIO;
}

buf[len] = '\0';

ret = parse_format(buf);

if (ret != 0) {
kfree(buf);
return ret;
}

return 0;
}


I wonder what does this oops mean and what that function iret_exc really 
does and why? It looks like some automagical exception handler but I am 
not sure about it.


I can't reproduce this oops for now on my machine. Could anybody tell me 
why that code is wrong and why is this oops in iret_exc? (At the same time 
I am waiting for further info from the tester but I am not sure when and 
how

Re: The who needs reviews anyways [PATCH]

[Valdis . Kletnieks]

On Fri, 09 Feb 2007 00:20:49 +0100, Roman Zippel said:
> > The point is, neither $BASH nor /bin/bash may be set.
> 
> Is that really a problem? I think any system that has bash without 
> /bin/bash is simply broken.

If you're trying to bootstrap a Linux box onto a new platform from some
non-Linux Unixoid, it's possible that bash lives in $TOOLCHAIN/bin/bash.

But I see that even Solaris 9 has a bash 2.05 in /bin/bash, so I might be
talking out some odd orifice here.




pgpA6X9IC9WHY.pgp
Description: PGP signature

Re: [patch 1/3 take2] smaps: extract pte walker from smaps code

[David Rientjes]

On Thu, 8 Feb 2007, Matt Mackall wrote:

> I've been looking at a similar refactoring of other code and I think
> the way to go is a callback per block-of-PTEs with start and end
> pointers. That gets rid of most of the call indirection overhead.
> 

Yes, but only in a limited number of cases (including smaps).  It is not 
always sufficient to do it on the block-of-ptes level.  Many of the the 
pte iterators in the code right now are slightly different on each level: 
the ioremap code, for example, allocates the various directories as it 
progresses in depth.

To have one library pte iterator would only be possible with callback 
functions on each pgd, pud, and pmd level that (at least) ioremap would 
require to be implemented on top of.  That isn't very appealing.

The PTI patchset from July moved these iterators into .h files but did not 
implement a single pte iterator to build on.  It just turned out nicely in 
the smaps case that there was no difference on the pgd, pud, or pmd level 
between the two required iterators.  I added a void *private to carry the 
struct for statistics accumulating in the smaps case but this is worthless 
in the clear_refs case.

David
-
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-cifs-client] Re: SMB support still missing?

[Jan Engelhardt]

On Feb 8 2007 18:53, Christopher R. Hertel wrote:
>>>
>>> It does seem to me that it is some sort of name resolution issue, but it may
>>> have more to do with the multi-homed nature of your setup.
>>>
>>> Did you try:
>>>
>>>  mount.cifs //CL0/c /mnt
>> 
>> Yes, that one _fails_ with "mount error 112 = Host is down" (though tcpdump
>> _does_ show that cifs connects to port 139 and then disconnects using FIN)
>
>It would be interesting to see that capture.

01:39:02.089070 IP 192.168.222.94.2019 > 192.168.222.33.445: S 
870214128:870214128(0) win 5840 
0x:  4500 003c ca4d 4000 4006 329d c0a8 de5e  E..<[EMAIL 
PROTECTED]@.2^
0x0010:  c0a8 de21 07e3 01bd 33de 69f0    ...!3.i.
0x0020:  a002 16d0 a82c  0204 05b4 0402 080a  .,..
0x0030:  000c a3bd   0103 0301
01:39:02.092572 IP 192.168.222.33.445 > 192.168.222.94.2019: R 0:0(0) ack 
870214129 win 0
0x:  4500 0028 f300  8006 09fe c0a8 de21  E..(...!
0x0010:  c0a8 de5e 01bd 07e3   33de 69f1  ...^3.i.
0x0020:  5014  ca8f       P.
01:39:02.096738 IP 192.168.222.94.1343 > 192.168.222.33.139: S 
870214131:870214131(0) win 5840 
0x:  4500 003c ca33 4000 4006 32b7 c0a8 de5e  E..<[EMAIL 
PROTECTED]@.2^
0x0010:  c0a8 de21 053f 008b 33de 69f3    ...!.?..3.i.
0x0020:  a002 16d0 abfc  0204 05b4 0402 080a  
0x0030:  000c a3c0   0103 0301
01:39:02.102544 IP 192.168.222.33.139 > 192.168.222.94.1343: S 
4435509:4435509(0) ack 870214132 win 8760 
0x:  4500 0030 f400 4000 8006 c8f5 c0a8 de21  [EMAIL PROTECTED]
0x0010:  c0a8 de5e 008b 053f 0043 ae35 33de 69f4  ...^...?.C.53.i.
0x0020:  7012 2238 d0f0  0204 05b4 0101 0402  p."8
01:39:02.104880 IP 192.168.222.94.1343 > 192.168.222.33.139: . ack 1 win 5840
0x:  4500 0028 ca34 4000 4006 32ca c0a8 de5e  E..([EMAIL 
PROTECTED]@.2^
0x0010:  c0a8 de21 053f 008b 33de 69f4 0043 ae36  ...!.?..3.i..C.6
0x0020:  5010 16d0 091d   P...
01:39:02.117326 IP 192.168.222.94.1343 > 192.168.222.33.139: P 1:73(72) ack 1 
win 5840 NBT Session Packet: Session Request
0x:  4500 0070 ca35 4000 4006 3281 c0a8 de5e  [EMAIL 
PROTECTED]@.2^
0x0010:  c0a8 de21 053f 008b 33de 69f4 0043 ae36  ...!.?..3.i..C.6
0x0020:  5018 16d0 3e34  8100 0044 2043 4b46  P...>4.D.CKF
0x0030:  4445 4e45 4346 4445 4646 4346 4745 4646  DENECFDEFFCFGEFF
0x0040:  4343 4143 4143 4143 4143 4143 4100 2046  CCACACACACACA..F
0x0050:  4445 4c44 4143 4143 4143 4143 4143 4143  DELDACACACACACAC
0x0060:  4143 4143 4143 4143 4143 4143 4141 4100  ACACACACACACAAA.
01:39:02.121140 IP 192.168.222.33.139 > 192.168.222.94.1343: FP 1:6(5) ack 73 
win 8688 NBT Session Packet: [|SMB]
0x:  4500 002d f500 4000 8006 c7f8 c0a8 de21  [EMAIL PROTECTED]
0x0010:  c0a8 de5e 008b 053f 0043 ae36 33de 6a3c  ...^...?.C.63.j<
0x0020:  5019 21f0 f8a4  8300 0001 8253   P.!..S
01:39:02.162638 IP 192.168.222.94.1343 > 192.168.222.33.139: . ack 7 win 5840
0x:  4500 0028 ca36 4000 4006 32c8 c0a8 de5e  E..([EMAIL 
PROTECTED]@.2^
0x0010:  c0a8 de21 053f 008b 33de 6a3c 0043 ae3c  ...!.?..3.j<.C.<
0x0020:  5010 16d0 08cf   P...
01:39:02.173013 IP 192.168.222.94.1343 > 192.168.222.33.139: P 73:155(82) ack 7 
win 5840 NBT Session Packet: Session Message
0x:  4500 007a ca37 4000 4006 3275 c0a8 de5e  [EMAIL 
PROTECTED]@.2u...^
0x0010:  c0a8 de21 053f 008b 33de 6a3c 0043 ae3c  ...!.?..3.j<.C.<
0x0020:  5018 16d0 3e3e   004e ff53 4d42  P...>>.N.SMB
0x0030:  7200   0180      r...
0x0040:     950d  0100 002b 0002  .+..
0x0050:  4c4d 312e 3258 3030 3200 024c 414e 4d41  LM1.2X002..LANMA
0x0060:  4e32 2e31 0002 4e54 204c 4d20 302e 3132  N2.1..NT.LM.0.12
0x0070:  0002 504f 5349 5820 3200 ..POSIX.2.
01:39:02.317447 IP 192.168.222.94.1343 > 192.168.222.33.139: R 155:155(0) ack 7 
win 5840
0x:  4500 0028 ca38 4000 4006 32c6 c0a8 de5e  E..([EMAIL 
PROTECTED]@.2^
0x0010:  c0a8 de21 053f 008b 33de 6a8e 0043 ae3c  ...!.?..3.j..C.<
0x0020:  5014 16d0 0879   Py..



Jan
-- 
ft: http://freshmeat.net/p/chaostables/
-
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-cifs-client] Re: SMB support still missing?

[Jan Engelhardt]

On Feb 8 2007 18:58, Christopher R. Hertel wrote:
>Shirish S Pargaonkar wrote:
>> 
>> So
>> 1) try tcp  connection on  445,
>> then if it works send SMB negprot
>> 2) else try tcp connection on port 139
>> then if it works send nbss request to *SMBSERVER or to the name
>> specified on servernetbiosname
>> (cifs really should do an ASTAT command and list the valid names and
>> find one if that approach fails but we don't have code for this yet)
>
>This is all correct, and also note that W/9x systems do not support the
>"*SMBSERVER" name.
>
>On the other hand, the name was resolved somehow.  The typical work-arounds
>to not knowning the NBT name of the server are:
>1) Use the name you just resolved (in this case, "CL0").
>2) Send a Node Status Query and look for the first unique <20> name.

I'd just do this:

 (1) try 445/tcp
 (2) try 139/tcp
 (3) try 139/tcp with uppercase hostname (mount //hostname/share) as
 default servernetbiosname



Jan
-- 
ft: http://freshmeat.net/p/chaostables/
-
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 take2] smaps: extract pte walker from smaps code

[Matt Mackall]

On Wed, Feb 07, 2007 at 03:29:34PM +0900, Paul Mundt wrote:
> On Tue, Feb 06, 2007 at 10:15:47PM -0800, David Rientjes wrote:
> > Extracts the page table entry walker from the smaps-specific code in
> > fs/proc/task_mmu.c.  This will be used later for clearing the reference
> > bits on pages to measure the number of pages accessed over a time period
> > through /proc/pid/smaps.
> > 
> I like the general idea of this patch set, however..
> 
> > Since the PTE walker is now extracted from the smaps code,
> > smaps_pte_func() is invoked for each PTE in the VMA.  Its behavior is
> > identical to the existing implementation, except it is slightly slower
> > because each PTE now invokes a function call.
> > 
> Perhaps this is something that needs to be looked at more closely and
> made more generic? There are many ranged page table walkers that aren't
> so performance critical that the function call cost would cause too much
> pain. ioremap_page_range() comes to mind, and there's bound to be others.
> This would also help people to get the pte map/unmap right, which seems
> to pop up from time to time as well..

I've been looking at a similar refactoring of other code and I think
the way to go is a callback per block-of-PTEs with start and end
pointers. That gets rid of most of the call indirection overhead.

-- 
Mathematics is the supreme nostalgia of our time.
-
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 0/3] a faster buffered write deadlock fix?

[Nick Piggin]

On Thu, Feb 08, 2007 at 04:38:01PM -0800, Mark Fasheh wrote:
> On Thu, Feb 08, 2007 at 02:07:15PM +0100, Nick Piggin wrote:
> > The problem is that the existing aops interface is crap. "correct, fast,
> > compatible -- choose any 2"
> 
> Agreed. There's lots of problems with the interface (imho), but my biggest
> two issues are the page lock being held on ->prepare_write() /
> ->commit_write() and the fact that the file system only sees the write one
> page at a time
> 
> 
> > So I have finally finished a first slightly-working draft of my new aops
> > op (perform_write) proposal. I would be interested to hear comments about
> > it.  Most of my issues and concerns are in the patch headers themselves,
> > so reply to them.
> 
> I like ->perform_write(). It allows the file system to make re-use of the
> checks in the generic write path, but gives a maximum amount of information
> about the overall operation to be done. There's an added advantage in that
> some file systems (ocfs2 is one of these) want to be more careful about
> ordering page locks, which should be much easier with it.

Yeah, if possible I like a range based interface rather than page
based. As you say it gives the most information with the least constraints.

> If this goes in, it could probably be helpful to me in some of the code I'm
> currently writing which needs to be better about page lock / cluster lock
> ordering and wants to see as much of the (allocating) writes as possible.

I think it would be important to have a non trivial user of this new API
before it goes into mainline. It would be great if you could look at
using it, after it passes some review.

Thanks,
Nick
-
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] fs: add an iovec iterator

[Nate Diller]

On 2/8/07, Nick Piggin <[EMAIL PROTECTED]> wrote:

On Thu, Feb 08, 2007 at 07:49:53PM +, Christoph Hellwig wrote:
> On Thu, Feb 08, 2007 at 02:07:24PM +0100, Nick Piggin wrote:
> > Add an iterator data structure to operate over an iovec. Add usercopy
> > operators needed by generic_file_buffered_write, and convert that function
> > over.
>
> iovec_iterator is an awfully long and not very descriptive name.
> In past discussions we named this thingy iodesc and wanted to pass it
> down all the I/O path, including the file operations.

Hi Christoph,

Sure I think it would be a good idea to shorten the name. And yes, although
I just construct the iterator to pass into perform_write, I think it should
make sense to go much further up the call stack instead of passing all those
args around. iodesc seems like a fine name, so I'll use that unless
anyone objects.


i had a patch integrating the iodesc idea, but after some thought, had
decided to call it struct file_io.  That name reflects the fact that
it's doing I/O in arbitrary lengths with byte offsets, and struct
file_io *fio contrasts well with struct bio (block_io).  I also had
used the field ->nbytes instead of ->count, to clarify the difference
between segment iterators, segment offsets, and absolute bytecount.

FYI, the patch is still in the works and would convert the whole file
I/O stack to use the new structure.  I would like to base it off of
this work as well if this makes it into -mm (as I think it should)

NATE
-
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] fs: add an iovec iterator

[Nick Piggin]

On Thu, Feb 08, 2007 at 07:49:53PM +, Christoph Hellwig wrote:
> On Thu, Feb 08, 2007 at 02:07:24PM +0100, Nick Piggin wrote:
> > Add an iterator data structure to operate over an iovec. Add usercopy
> > operators needed by generic_file_buffered_write, and convert that function
> > over.
> 
> iovec_iterator is an awfully long and not very descriptive name.
> In past discussions we named this thingy iodesc and wanted to pass it
> down all the I/O path, including the file operations.

Hi Christoph,

Sure I think it would be a good idea to shorten the name. And yes, although
I just construct the iterator to pass into perform_write, I think it should
make sense to go much further up the call stack instead of passing all those
args around. iodesc seems like a fine name, so I'll use that unless
anyone objects.


Thanks,
Nick
-
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] 2.6.20 fix for PageUptodate memorder problem (try 2)

[Benjamin Herrenschmidt]

> > Fix threaded user page write memory ordering
> 
> Thanks, I did see that, but I'm sure it must have been prompted by a
> discussion or another proposed patch from IBM. Maybe I'm wrong
> though.

Yes, my initial proposal iirc was to smp_wmb() in set_pte() but after a
discussion with Linus, we ended with open coding them.

Ben.


-
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] Use correct macros in raid code, not raw asm

[H. Peter Anvin]

Neil Brown wrote:


So does this look right (no, I haven't compiled it yet)



No, the whole raid6_*_save_t should be removed.  I'll try to have a 
patch for you later.


-hpa
-
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] 2.6.20 fix for PageUptodate memorder problem (try 2)

[Benjamin Herrenschmidt]

> Fix threaded user page write memory ordering
> 
> Make sure we order the writes to a newly created page
> with the page table update that potentially exposes the
> page to another CPU.
> 
> This is a no-op on any architecture where getting the
> page table spinlock will already do the ordering (notably
> x86), but other architectures can care.


Ah yes, the clear_* ones I knew about as I'm the one who tracked down
that bug on power :-) I though the ones Nick pointed out were different
tho.

Ben.


-
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] Use correct macros in raid code, not raw asm

[Neil Brown]

On Thursday February 8, [EMAIL PROTECTED] wrote:
> Andi Kleen wrote:
> > 
> > It should use kernel_fpu_begin() imho. If someone wants to test
> > it in user space again they can add dummy definitions of that
> > to their user space  header.
> 
> I hadn't seen this thread until now, when Neil pointed me to the thread.
> 
> Using kernel_fpu_begin() ... kernel_fpu_end() is probably indeed the 
> best option.
> 

So does this look right (no, I haven't compiled it yet)

NeilBrown


### Diffstat output
 ./drivers/md/raid6x86.h |   56 ++--
 1 file changed, 12 insertions(+), 44 deletions(-)

diff .prev/drivers/md/raid6x86.h ./drivers/md/raid6x86.h
--- .prev/drivers/md/raid6x86.h 2007-02-09 12:30:32.0 +1100
+++ ./drivers/md/raid6x86.h 2007-02-09 12:36:01.0 +1100
@@ -25,20 +25,17 @@
 
 typedef struct {
unsigned int fsave[27];
-   unsigned long cr0;
 } raid6_mmx_save_t __attribute__((aligned(16)));
 
 /* N.B.: For SSE we only save %xmm0-%xmm7 even for x86-64, since
the code doesn't know about the additional x86-64 registers */
 typedef struct {
unsigned int sarea[8*4+2];
-   unsigned long cr0;
 } raid6_sse_save_t __attribute__((aligned(16)));
 
 /* This is for x86-64-specific code which uses all 16 XMM registers */
 typedef struct {
unsigned int sarea[16*4+2];
-   unsigned long cr0;
 } raid6_sse16_save_t __attribute__((aligned(16)));
 
 /* On x86-64 the stack *SHOULD* be 16-byte aligned, but currently this
@@ -50,7 +47,6 @@ typedef struct {
 
 typedef struct {
unsigned int fsave[27];
-   unsigned long cr0;
 } raid6_mmx_save_t;
 
 /* On i386, the stack is only 8-byte aligned, but SSE requires 16-byte
@@ -58,7 +54,6 @@ typedef struct {
a properly-sized area correctly.  */
 typedef struct {
unsigned int sarea[8*4+3];
-   unsigned long cr0;
 } raid6_sse_save_t;
 
 /* Find the 16-byte aligned save area */
@@ -66,56 +61,29 @@ typedef struct {
 
 #endif
 
-#ifdef __KERNEL__ /* Real code */
-
-/* Note: %cr0 is 32 bits on i386 and 64 bits on x86-64 */
-
-static inline unsigned long raid6_get_fpu(void)
-{
-   unsigned long cr0;
-
-   preempt_disable();
-   asm volatile("mov %%cr0,%0 ; clts" : "=r" (cr0));
-   return cr0;
-}
-
-static inline void raid6_put_fpu(unsigned long cr0)
-{
-   asm volatile("mov %0,%%cr0" : : "r" (cr0));
-   preempt_enable();
-}
-
-#else /* Dummy code for user space testing */
-
-static inline unsigned long raid6_get_fpu(void)
-{
-   return 0xf00ba6;
-}
-
-static inline void raid6_put_fpu(unsigned long cr0)
-{
-   (void)cr0;
-}
-
+#ifndef __KERNEL__
+/* for user-space testing */
+#define kernel_fpu_begin()
+#define kernel_fpu_end();
 #endif
 
 static inline void raid6_before_mmx(raid6_mmx_save_t *s)
 {
-   s->cr0 = raid6_get_fpu();
+   kernel_fpu_begin();
asm volatile("fsave %0 ; fwait" : "=m" (s->fsave[0]));
 }
 
 static inline void raid6_after_mmx(raid6_mmx_save_t *s)
 {
asm volatile("frstor %0" : : "m" (s->fsave[0]));
-   raid6_put_fpu(s->cr0);
+   kernel_fpu_end();
 }
 
 static inline void raid6_before_sse(raid6_sse_save_t *s)
 {
unsigned int *rsa = SAREA(s);
 
-   s->cr0 = raid6_get_fpu();
+   kernel_fpu_begin();
 
asm volatile("movaps %%xmm0,%0" : "=m" (rsa[0]));
asm volatile("movaps %%xmm1,%0" : "=m" (rsa[4]));
@@ -140,14 +108,14 @@ static inline void raid6_after_sse(raid6
asm volatile("movaps %0,%%xmm6" : : "m" (rsa[24]));
asm volatile("movaps %0,%%xmm7" : : "m" (rsa[28]));
 
-   raid6_put_fpu(s->cr0);
+   kernel_fpu_end();
 }
 
 static inline void raid6_before_sse2(raid6_sse_save_t *s)
 {
unsigned int *rsa = SAREA(s);
 
-   s->cr0 = raid6_get_fpu();
+   kernel_fpu_begin();
 
asm volatile("movdqa %%xmm0,%0" : "=m" (rsa[0]));
asm volatile("movdqa %%xmm1,%0" : "=m" (rsa[4]));
@@ -172,7 +140,7 @@ static inline void raid6_after_sse2(raid
asm volatile("movdqa %0,%%xmm6" : : "m" (rsa[24]));
asm volatile("movdqa %0,%%xmm7" : : "m" (rsa[28]));
 
-   raid6_put_fpu(s->cr0);
+   kernel_fpu_end();
 }
 
 #ifdef __x86_64__
@@ -181,7 +149,7 @@ static inline void raid6_before_sse16(ra
 {
unsigned int *rsa = SAREA(s);
 
-   s->cr0 = raid6_get_fpu();
+   kernel_fpu_begin();
 
asm volatile("movdqa %%xmm0,%0" : "=m" (rsa[0]));
asm volatile("movdqa %%xmm1,%0" : "=m" (rsa[4]));
@@ -222,7 +190,7 @@ static inline void raid6_after_sse16(rai
asm volatile("movdqa %0,%%xmm14" : : "m" (rsa[56]));
asm volatile("movdqa %0,%%xmm15" : : "m" (rsa[60]));
 
-   raid6_put_fpu(s->cr0);
+   kernel_fpu_end();
 }
 
 #endif /* __x86_64__ */
-
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] drivers/telephony/ixj: Convert to generic boolean

[Randy Dunlap]

On Thu, 8 Feb 2007 22:39:35 +0100 (MET) Richard Knutsson wrote:

> Convert:
> BOOL  -> bool
> FALSE -> false
> TRUE  -> true
> 
> Change a variable ('mContinue') to boolean from char, since it is used
> as boolean.
> 
> Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>

Looks good to me.  Built on x86_64.

Acked-by: Randy Dunlap <[EMAIL PROTECTED]>

> ---
> Compile-tested with "allyes", "allmod" and "allno" on i386
> Get a few warning-messages, none related to this patch
> Sent on 2007-01-21
> 
> 
> diff --git a/drivers/telephony/ixj.c b/drivers/telephony/ixj.c
> index df4cc1f..58deaac 100644
> --- a/drivers/telephony/ixj.c
> +++ b/drivers/telephony/ixj.c
> @@ -648,9 +648,9 @@ static inline BYTE SLIC_GetState(IXJ *j)
>   return j->pld_slicr.bits.state;
>  }
>  
> -static BOOL SLIC_SetState(BYTE byState, IXJ *j)
> +static bool SLIC_SetState(BYTE byState, IXJ *j)
>  {
> - BOOL fRetVal = FALSE;
> + bool fRetVal = false;
>  
>   if (j->cardtype == QTI_PHONECARD) {
>   if (j->flags.pcmciasct) {
> @@ -659,14 +659,14 @@ static BOOL SLIC_SetState(BYTE byState, IXJ *j)
>   case PLD_SLIC_STATE_OC:
>   j->pslic.bits.powerdown = 1;
>   j->pslic.bits.ring0 = j->pslic.bits.ring1 = 0;
> - fRetVal = TRUE;
> + fRetVal = true;
>   break;
>   case PLD_SLIC_STATE_RINGING:
>   if (j->readers || j->writers) {
>   j->pslic.bits.powerdown = 0;
>   j->pslic.bits.ring0 = 1;
>   j->pslic.bits.ring1 = 0;
> - fRetVal = TRUE;
> + fRetVal = true;
>   }
>   break;
>   case PLD_SLIC_STATE_OHT:/* On-hook transmit */
> @@ -679,14 +679,14 @@ static BOOL SLIC_SetState(BYTE byState, IXJ *j)
>   j->pslic.bits.powerdown = 1;
>   }
>   j->pslic.bits.ring0 = j->pslic.bits.ring1 = 0;
> - fRetVal = TRUE;
> + fRetVal = true;
>   break;
>   case PLD_SLIC_STATE_APR:/* Active polarity 
> reversal */
>  
>   case PLD_SLIC_STATE_OHTPR:  /* OHT polarity 
> reversal */
>  
>   default:
> - fRetVal = FALSE;
> + fRetVal = false;
>   break;
>   }
>   j->psccr.bits.dev = 3;
> @@ -703,7 +703,7 @@ static BOOL SLIC_SetState(BYTE byState, IXJ *j)
>   j->pld_slicw.bits.c3 = 0;
>   j->pld_slicw.bits.b2en = 0;
>   outb_p(j->pld_slicw.byte, j->XILINXbase + 0x01);
> - fRetVal = TRUE;
> + fRetVal = true;
>   break;
>   case PLD_SLIC_STATE_RINGING:
>   j->pld_slicw.bits.c1 = 1;
> @@ -711,7 +711,7 @@ static BOOL SLIC_SetState(BYTE byState, IXJ *j)
>   j->pld_slicw.bits.c3 = 0;
>   j->pld_slicw.bits.b2en = 1;
>   outb_p(j->pld_slicw.byte, j->XILINXbase + 0x01);
> - fRetVal = TRUE;
> + fRetVal = true;
>   break;
>   case PLD_SLIC_STATE_ACTIVE:
>   j->pld_slicw.bits.c1 = 0;
> @@ -719,7 +719,7 @@ static BOOL SLIC_SetState(BYTE byState, IXJ *j)
>   j->pld_slicw.bits.c3 = 0;
>   j->pld_slicw.bits.b2en = 0;
>   outb_p(j->pld_slicw.byte, j->XILINXbase + 0x01);
> - fRetVal = TRUE;
> + fRetVal = true;
>   break;
>   case PLD_SLIC_STATE_OHT:/* On-hook transmit */
>  
> @@ -728,7 +728,7 @@ static BOOL SLIC_SetState(BYTE byState, IXJ *j)
>   j->pld_slicw.bits.c3 = 0;
>   j->pld_slicw.bits.b2en = 0;
>   outb_p(j->pld_slicw.byte, j->XILINXbase + 0x01);
> - fRetVal = TRUE;
> + fRetVal = true;
>   break;
>   case PLD_SLIC_STATE_TIPOPEN:
>   j->pld_slicw.bits.c1 = 0;
> @@ -736,7 +736,7 @@ static BOOL SLIC_SetState(BYTE byState, IXJ *j)
>   j->pld_slicw.bits.c3 = 1;
>   j->pld_slicw.bits.b2en = 0;
>   outb_p(j->pld_slicw.byte, j->XILINXbase + 0x01);
> - fRetVal = TRUE;
> + fRetVal = true;
>   break;
>   case PLD_SLIC_STA

Re: [patch 0/3] 2.6.20 fix for PageUptodate memorder problem (try 2)

[Nick Piggin]

On Fri, Feb 09, 2007 at 12:41:51AM +, Hugh Dickins wrote:
> On Thu, 8 Feb 2007, Nick Piggin wrote:
> > Still no independent confirmation as to whether this is a problem or not.
> 
> I'm trying to convince myself none of your patch is necessary.  Probably
> shall fail.  But how come we've survived for years with such an issue?

Well I'm almost sure that the POWER guys hit this with anonymous pages
being zeroed out then added to process address space -- they would
occasionally see junk (via another thread, I presume).

If that were the case, then I think that a read-vs-read over a hole
(for example) should be buggy in the same way.

> > Updated some comments, added diffstats to patches, don't use
> > __SetPageUptodate as an internal page-flags.h private function.
> 
> Depressed by profusion of PageUptodate_UpperAndlowercasevariants.
> Those rmbs, you really only want them when it says "yes", don't you?

Yeah, any help with naming suggestions would be appreciated. I think
we can get rid of the SetPageUptodate_nowarn variant, by making
SetNewPageUptodate simply do an smp_wmb + __set_bit on all architectures?
This frees us from the extra atomic ops I'd added into the page fault
fastpaths as well.

Yes, we do only need the rmb if it is uptodate, that's a good point.

> > I would like to eventually get an ack from Hugh regarding the anon memory
> > and especially swap side of the equation,
> 
> Plea noted.  I'm pondering.  "Eventually" indeed.  OTOH I expect you're
> right to criticize anon/swap PageUptodate being set where it was needed
> to get by, rather than where it was natural to do so.

Well if I can get you to warm to that aspect of the patch... :) I expect
that using non-atomic bitops might help.

Should I make that change into its own patch?

> > and a glance from whoever put the
> > smp_wmb()s into the copy functions (Was it Ben H or Anton maybe?)
> 
> From: Linus Torvalds <[EMAIL PROTECTED]>
> Date: Thu, 14 Oct 2004 04:00:06 + (-0700)
> Subject: Fix threaded user page write memory ordering
> X-Git-Tag: v2.6.9-final~3
> X-Git-Url: 
> http://127.0.0.1:1234/?p=.git;a=commitdiff_plain;h=538ce05c0ef4055cf29a92a4abcdf139d180a0f9;hp=8c225dbc5a7b13801a8254aae0ccebab8e4bece7
> 
> Fix threaded user page write memory ordering

Thanks, I did see that, but I'm sure it must have been prompted by a
discussion or another proposed patch from IBM. Maybe I'm wrong
though.

Thanks,
Nick
-
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: The who needs reviews anyways [PATCH]

[Roman Zippel]

Hi,

On Fri, 9 Feb 2007, Andreas Schwab wrote:

> Roman Zippel <[EMAIL PROTECTED]> writes:
> 
> > - printf has other side effects, instead stop pretending we support 
> >   something else than bash
> 
> printf is a much better echo, but you need to use it properly as well.
> Either use %s to print a literal string or %b to let it interpret escape
> sequences.

Hmm, I didn't know about %b, which would indeed be another possibility 
here, although I think it would only make a real difference if we decided 
to make (and more importantly keep) all our scripts POSIX clean.

bye, Roman
-
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] Use correct macros in raid code, not raw asm

[H. Peter Anvin]

Andi Kleen wrote:

The code looks like it's designed to be included from userspace for
testing; as it compiles without this include (and has no other
includes), I chose not to add it.

Linus makes a good point, but someone who actually knows the code
should, y'know, test it and stuff...


It should use kernel_fpu_begin() imho. If someone wants to test
it in user space again they can add dummy definitions of that
to their user space  header.


I hadn't seen this thread until now, when Neil pointed me to the thread.

Using kernel_fpu_begin() ... kernel_fpu_end() is probably indeed the 
best option.


-hpa

-
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] ATA convert GSI to irq on ia64

[Jeff Garzik]

Zhang, Yanmin wrote:

If an ATA drive uses legacy mode, ata driver will choose 14 and 15 as the
fixed irq number. On ia64 platform, such numbers are GSI and should be converted
to irq vector.

Below patch against kernel 2.6.20 fixes it.

Signed-off-by: Zhang Yanmin <[EMAIL PROTECTED]>


IA64 should create its own libata-portmap.h, rather than modifying the 
one in asm-generic with arch-specific choices.


powerpc is a current example of this (and currently the only 
non-asm-generic user) found in kernel 2.6.20.


Jeff



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

Re: somebody dropped a (warning) bomb

[David Rientjes]

On Thu, 8 Feb 2007, Linus Torvalds wrote:

> Even gcc DOES DIFFERENT THINGS! Have you even read the docs?
> 
>   By default it is treated as signed int but this may be changed by 
>   the -funsigned-bitfields option.
> 

Yes, I read the 4.1.1 docs:

By default, such a bit-field is signed, because this is
consistent: the basic integer types such as int are signed
types.

That is the whole basis for my argument, when you declare something "int," 
most programmers would consider that to be SIGNED regardless of whether it 
is 32 bits, 13 bits, or 1 bit.

No doubt it is configurable because of the existance of brain-dead 
compilers that treat them as unsigned.
-
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] bugfixes and new hardware support for arcnet driver

[Jeff Morrow]

The modifications and bug fixes noted below were done by Realtime
Control Works and Contemporary Control Systems, Inc, Jan 2005.  They
were incorporated into the 2.6 kernel by Jeff Morrow of Sierra
Analytics, Feb 2007.  <[EMAIL PROTECTED]>

The changes have been tested on a Contemporary Controls PCI20U-4000.

Summary of changes:

Arc-rawmode.c:
 rx():
 - Fixed error in received packet lengths; 256 byte packets were
   being received as 257 bytes packets.

 prepare_tx():
 - Fixed error in transmit length calcs; 257 byte packets were being
   transmitted as 260 byte packets.

com20020.c:
 com20020_check():
 - We now load the SETUP2 register if the 'clockm' parameter is
   non-zero, instead of checking for ARC_CAN_10MBIT. The user is
   now responsible for whether or not SETUP2 is loaded.  If the
   clock multiplier is non-zero, this means that the user wants a
   baud rate greater than 2.5Mbps. This is not possible unless the
   SETUP2 register is present (COM20020D, or COM20022). So, we're
   relying on the user to be smart about what kind of chip he's
   dealing with...

com20020-pci.c
 - Added several entries to com20020pci_id_table[].

Signed-off-by: Jeff Morrow <[EMAIL PROTECTED]>

---
diff -uprN -X linux-source-2.6.18/Documentation/dontdiff 
linux-source-2.6.18/drivers/net/arcnet/arcnet.c 
linux-source-2.6.18.changed/drivers/net/arcnet/arcnet.c
--- linux-source-2.6.18/drivers/net/arcnet/arcnet.c 2006-09-19 
20:42:06.0 -0700
+++ linux-source-2.6.18.changed/drivers/net/arcnet/arcnet.c 
2007-02-08 16:40:50.0 -0800

@@ -41,7 +41,7 @@
  * <[EMAIL PROTECTED]>
  */

-#define VERSION "arcnet: v3.93 BETA 2000/04/29 - by Avery Pennarun et 
al.\n"
+#define VERSION "arcnet: v3.94 BETA 2006/02/08 - by Avery Pennarun et 
al.\n"


 #include 
 #include 
diff -uprN -X linux-source-2.6.18/Documentation/dontdiff 
linux-source-2.6.18/drivers/net/arcnet/arc-rawmode.c 
linux-source-2.6.18.changed/drivers/net/arcnet/arc-rawmode.c
--- linux-source-2.6.18/drivers/net/arcnet/arc-rawmode.c 
2006-09-19 20:42:06.0 -0700
+++ linux-source-2.6.18.changed/drivers/net/arcnet/arc-rawmode.c 
2007-02-08 16:28:29.0 -0800

@@ -94,7 +94,7 @@ static void rx(struct net_device *dev, i

BUGMSG(D_DURING, "it's a raw packet (length=%d)\n", length);

-   if (length >= MinTU)
+   if (length > MTU)
ofs = 512 - length;
else
ofs = 256 - length;
@@ -183,7 +183,7 @@ static int prepare_tx(struct net_device
   length, XMTU);
length = XMTU;
}
-   if (length > MinTU) {
+   if (length >= MinTU) {
hard->offset[0] = 0;
hard->offset[1] = ofs = 512 - length;
} else if (length > MTU) {
diff -uprN -X linux-source-2.6.18/Documentation/dontdiff 
linux-source-2.6.18/drivers/net/arcnet/com20020.c 
linux-source-2.6.18.changed/drivers/net/arcnet/com20020.c
--- linux-source-2.6.18/drivers/net/arcnet/com20020.c   2006-09-19 
20:42:06.0 -0700
+++ linux-source-2.6.18.changed/drivers/net/arcnet/com20020.c 
2007-02-08 16:39:40.0 -0800

@@ -104,7 +104,7 @@ int com20020_check(struct net_device *de
SET_SUBADR(SUB_SETUP1);
outb(lp->setup, _XREG);

-   if (lp->card_flags & ARC_CAN_10MBIT)
+if (lp->clockm != 0)
{
SET_SUBADR(SUB_SETUP2);
outb(lp->setup2, _XREG);
diff -uprN -X linux-source-2.6.18/Documentation/dontdiff 
linux-source-2.6.18/drivers/net/arcnet/com20020-pci.c 
linux-source-2.6.18.changed/drivers/net/arcnet/com20020-pci.c
--- linux-source-2.6.18/drivers/net/arcnet/com20020-pci.c 
2006-09-19 20:42:06.0 -0700
+++ linux-source-2.6.18.changed/drivers/net/arcnet/com20020-pci.c 
2007-02-08 16:24:27.0 -0800

@@ -155,6 +155,7 @@ static struct pci_device_id com20020pci_
{ 0x1571, 0xa00b, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_IS_5MBIT },
{ 0x1571, 0xa00c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_IS_5MBIT },
{ 0x1571, 0xa00d, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_IS_5MBIT },
+{ 0x1571, 0xa00e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT },
{ 0x1571, 0xa201, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT },
{ 0x1571, 0xa202, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT },
{ 0x1571, 0xa203, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT },
@@ -162,6 +163,8 @@ static struct pci_device_id com20020pci_
{ 0x1571, 0xa205, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT },
{ 0x1571, 0xa206, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT },
{ 0x10B5, 0x9050, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT },
+   { 0x14BA, 0x6000, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT },
+   { 0x10B5, 0x2200, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT },
{0,}
 };

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mor

Re: somebody dropped a (warning) bomb

[Linus Torvalds]

On Thu, 8 Feb 2007, David Rientjes wrote:
>
> Maybe you should read my first post, we're talking about gcc's behavior 
> here, not the C standard.

Give it up, David.

Even gcc DOES DIFFERENT THINGS! Have you even read the docs?

By default it is treated as signed int but this may be changed by 
the -funsigned-bitfields option.

So even for gcc, it's just a default. I think you can even change the 
default in the spec file.

Linus
-
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] ATA convert GSI to irq on ia64

[Zhang, Yanmin]

On Thu, 2007-02-08 at 17:17 +0800, Luming Yu wrote:
> sorry, it should be
> #define ATA_PRIMARY_IRQ(dev)  ide_default_irq(0x1F0)
> 
> On 2/8/07, Luming Yu <[EMAIL PROTECTED]> wrote:
> > if use ide_default_irq , then I guess the #if defined can be removed.
> > #define ATA_PRIMARY_IRQ(dev)   isa_irq_to_vector(0x1F0)
ata driver will replace old ide driver, so I don't use ide codes in
ata driver.

> >
> >
> > On 2/8/07, Zhang, Yanmin <[EMAIL PROTECTED]> wrote:
> > > If an ATA drive uses legacy mode, ata driver will choose 14 and 15 as the
> > > fixed irq number. On ia64 platform, such numbers are GSI and should be 
> > > converted
> > > to irq vector.
> > >
> > > Below patch against kernel 2.6.20 fixes it.
> > >
> > > Signed-off-by: Zhang Yanmin <[EMAIL PROTECTED]>
> > >
> > > ---
> > >
> > > diff -Nraup linux-2.6.20/include/asm-generic/libata-portmap.h 
> > > linux-2.6.20_fix/include/asm-generic/libata-portmap.h
> > > --- linux-2.6.20/include/asm-generic/libata-portmap.h   2007-02-08 
> > > 15:13:44.0 +0800
> > > +++ linux-2.6.20_fix/include/asm-generic/libata-portmap.h   
> > > 2007-02-08 15:20:13.0 +0800
> > > @@ -3,10 +3,20 @@
> > >
> > >  #define ATA_PRIMARY_CMD0x1F0
> > >  #define ATA_PRIMARY_CTL0x3F6
> > > +#if defined(__ia64__)
> > > +#define ATA_PRIMARY_IRQ(dev)   isa_irq_to_vector(14)
> > > +#else
> > >  #define ATA_PRIMARY_IRQ(dev)   14
> > > +#endif
> > > +
> > >
> > >  #define ATA_SECONDARY_CMD  0x170
> > >  #define ATA_SECONDARY_CTL  0x376
> > > +#if defined(__ia64__)
> > > +#define ATA_SECONDARY_IRQ(dev) isa_irq_to_vector(15)
> > > +#else
> > >  #define ATA_SECONDARY_IRQ(dev) 15
> > > +#endif
> > > +
> > >
> > >  #endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: somebody dropped a (warning) bomb

[David Rientjes]

On Thu, 8 Feb 2007, Linus Torvalds wrote:

> No it's not.
> 
> You just don't understand the C language. 
> 
> And if you don't understand the C language, you can't say "that's what the 
> int says". It says no such thing.
> 
> The C language clearly says that bitfields have implementation-defined 
> types. So when you see
> 
>   struct dummy {
>   int flag:1;
>   } a_variable;
> 
> if you don't read that as "oh, the sign of 'flag' is implementation- 
> defined", then you simply aren't reading it right.
> 

Maybe you should read my first post, we're talking about gcc's behavior 
here, not the C standard.  My criticism was that any compiler that makes 
a_variable.flag unsigned is brain-dead and I was arguing in favor of gcc 
treating plain int bitfields as signed ints (6.7.2, 6.7.2.1).  This has 
_nothing_ to do with the fact that the standard leaves it implementation 
defined.

Naturally you should define it's signness explicitly in your code since it 
is implementation defined.  That's not the point.

Just because a compiler CAN consider a_variable.flag as unsigned doesn't 
mean it makes sense.  It makes no sense, and thus is brain-dead.
-
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: -mm merge plans for 2.6.21

[Andrew Morton]

On Fri, 9 Feb 2007 11:55:40 +1100
Paul Mackerras <[EMAIL PROTECTED]> wrote:

> Andrew Morton writes:
> 
> > Once a subsystem has a subsystem tree (git or quilt) I basically never
> > merge anything which belongs to that tree.  It's always
> > 
> > originator->mm->subsystemtree->Linus
> > 
> > If the subsystem tree maintainer wants to tell me "I can't be bothered
> > setting up a git pull for that, please merge it for me" then that's fine.
> > 
> > But unless I'm told that, or unless the maintainer is vacationing or totally
> > asleep or unless the fix has some sufficiently high obviousness*importance 
> > product,
> > I'll just keep buffering it up.  
> 
> What about the sort of thing that crosses all archs?  For example, the
> local_t changes?  Particularly in the case where the change has to be
> made in generic code and in all archs at the same time, it makes sense
> to me for you to send the whole batch to Linus at the same time,
> rather than individual arch maintainers all sending their bit at
> varying times.
> 

yup.  It's better of course if the changes aren't both-way dependent and
often we do it that way.  But if they really are that bound together then
I'll stage the patch in -mm, ensure that it doesn't conflict with any
queued-up arch patches and will merge it after the arch trees have gone in.

-
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: somebody dropped a (warning) bomb

[Linus Torvalds]

On Thu, 8 Feb 2007, Linus Torvalds wrote:
> 
> The C language clearly says that bitfields have implementation-defined 
> types.

Btw, this isn't even some "theoretical discussion". LOTS of compilers do 
unsigned bitfields. It may even be the majority. There may (or may not) be 
some correlation with what the default for "char" is, I haven't looked 
into it.

Linus
-
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-cifs-client] Re: SMB support still missing?

[Christopher R. Hertel]

Shirish S Pargaonkar wrote:
:
> This is what Steve had mailed me once, a while ago
> 
> Win9x and Windows ME and OS/2 only listen on port 139
> 
> WindowsNT 4 (?) and later listen on port 445 and port 139.
> 
> When you connect on the older port 139, you are supposed to send a
> RFC1001 (NBSS Session Request to indicate your client netbios name, but
> the problem is that you don't know the target netbios name of the server
> - which is why the either needs to support the fake name "*SMBSERVER" or
> the client needs to specify the "servernetbiosname=" option on
> mount to identify which name on the server to try to connect to.
> 
> So
> 1) try tcp  connection on  445,
> then if it works send SMB negprot
> 2) else try tcp connection on port 139
> then if it works send nbss request to *SMBSERVER or to the name
> specified on servernetbiosname
> (cifs really should do an ASTAT command and list the valid names and
> find one if that approach fails but we don't have code for this yet)

This is all correct, and also note that W/9x systems do not support the
"*SMBSERVER" name.

On the other hand, the name was resolved somehow.  The typical work-arounds
to not knowning the NBT name of the server are:
1) Use the name you just resolved (in this case, "CL0").
2) Send a Node Status Query and look for the first unique <20> name.

The second (as Steve explained to me a long time ago) is less reliable
because there are some applications out there which (incorrectly) register
names with a suffix byte of <20>.

Chris -)-

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/ -)-   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/ -)-   [EMAIL PROTECTED]
OnLineBook -- http://ubiqx.org/cifs/-)-   [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-cifs-client] Re: SMB support still missing?

[Christopher R. Hertel]

Jan Engelhardt wrote:
> On Feb 8 2007 18:29, Christopher R. Hertel wrote:
>> Jan Engelhardt wrote:
>>
>> It does seem to me that it is some sort of name resolution issue, but it may
>> have more to do with the multi-homed nature of your setup.
>>
>> Did you try:
>>
>>  mount.cifs //CL0/c /mnt
> 
> Yes, that one _fails_ with "mount error 112 = Host is down" (though tcpdump
> _does_ show that cifs connects to port 139 and then disconnects using FIN)

It would be interesting to see that capture.

- The client is clearly finding the server (via NBT lookup or DNS
  lookup--doesn't matter, it's being found).

- The client is creating the TCP connection.

- The server (W9x) is closing the connection.  Why?

  + The most likely reason is 0x82: Called Name Not Present

That's my guess, anyway.  My bet is that W9x is being picky about the case
of the CALLED NAME.

It would not surprise me that the NBT name resolution code *does* convert
the case as part of the NBT encoding (that weird string that reads
EDEMDACACACACACACACACACACACACACA).  It would also not surprise me if the NBT
Session Request code *doesn't* convert the case.  The Session Request uses
the un-encoded string (in this case, "cl0").

The Windows 9x implementation of the NBT layer tends to be much more
"correct" than the NT family and its descendants.  As a result, W9x is
pickier about things like exact matches to the CALLED NAME.

That's all a guess, mind you, but it's something more to go on.

Again, the capture would hold the answer.

Chris -)-

--
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/ -)-   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/ -)-   [EMAIL PROTECTED]
OnLineBook -- http://ubiqx.org/cifs/-)-   [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Network: convert network devices to use struct device instead of class_device

[Greg KH]

On Thu, Feb 08, 2007 at 12:29:12PM -0500, Dmitry Torokhov wrote:
> On 2/8/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> >On Thu, 08 Feb 2007 07:43:18 -0500
> >Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >
> >> Linux Kernel Mailing List wrote:
> >> > Gitweb: 
> >http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=43cb76d91ee85f579a69d42bc8efc08bac560278
> >> > Commit: 43cb76d91ee85f579a69d42bc8efc08bac560278
> >> > Parent: 2943ecf2ed32632473c06f1975db47a7aa98c10f
> >> > Author: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> >> > AuthorDate: Tue Apr 9 12:14:34 2002 -0700
> >> > Committer:  Greg Kroah-Hartman <[EMAIL PROTECTED]>
> >> > CommitDate: Wed Feb 7 10:37:11 2007 -0800
> >> >
> >> > Network: convert network devices to use struct device instead of 
> >class_device
> >> >
> >> > This lets the network core have the ability to handle 
> >suspend/resume
> >> > issues, if it wants to.
> >
> >It fixes a non-problem. I would like to see the network core suspend/resume
> >proposal as well. Last time I examined doing network core suspend help,
> >the problem was that the physical device suspend was called before the
> >class device. It is not clear how this change would help.
> 
> If physical devices are registered before class devices then when
> suspending class devices are naturally suspended first. It is still
> not clear to me why we need to convert everythign to struct device, I
> believe I've shown (with patches) that it is possible to integrate
> struct class_device into PM framework and avoid reshuffling half of
> the kernel code.

I don't want to have two separate device trees in the kernel (well, one
big device tree and a bunch of little class_device trees.)  The code
duplication in the class_device code is just too much, and I get
questions all the time as to what the differences are.

With these slow and gradual changes, we are getting a true, unified,
device tree, and it will reduce the amount of code and complexity we
need to maintain and fix in the driver core itself.

And it should also alow for proper power management functionality, using
the changes that Linus put into the driver core about 8 months ago.

Don't worry, I have input patches queued up next for you Dmitry :)

thanks,

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

Re: [PATCH 2.6.20] r8169.c: support RTL8169SC/8110SC

[Jeff Garzik]

Edward Hsu wrote:

This patch is for /driver/net/r8169.c to support RTL8169SC/8110SC,
which is a new Realtek Gigabit PCI Ethernet Controller. RTL8110SC's PCI DID
is 0x8167, while RTL8110S and RTL8110SB share 0x8169.

Signed-off-by: Edward Hsu <[EMAIL PROTECTED]>
--

--- ./drivers/net/r8169_n.c 2007-02-09 01:12:43.0 +0800
+++ ./drivers/net/r8169.c 2007-02-05 02:44:54.0 +0800
@@ -1,29 +1,4 @@
 /*
-
-#
-# Copyright(c) 1999 - 2007 Realtek Semiconductor Corp. All rights reserved.
-#
-# This program is free software; you can redistribute it and/or modify it
-# under the terms of the GNU General Public License as published by the 
Free


Unfortunately this patch has been created backwards:
diff -u file.new file.old
when it should be created from
diff -u ./drivers/net/r8169.c.old \
./drivers/net/r8169.c

Additionally, your patch was word-wrapped by your email program, which 
prevents software from importing the patch into a kernel source tree.




 enum RTL8169_registers {
- MAC0 = 0x00,  /* Ethernet hardware address. */
- MAC4 = 0x04,
- MAR0 = 0x08,  /* Multicast filter. */
+ MAC0 = 0,  /* Ethernet hardware address. */
+ MAR0 = 8,  /* Multicast filter. */
  CounterAddrLow = 0x10,
  CounterAddrHigh = 0x14,
  TxDescStartAddrLow = 0x20,


Let's keep the existing style of code.  The other MAC registers are 
listed in the "0xnn" hexidecimal style.




@@ -282,7 +260,6 @@ enum RTL8169_registers {
  TBI_ANAR = 0x68,
  TBI_LPAR = 0x6A,
  PHYstatus = 0x6C,
- Offset_7Ch = 0x7C,
  RxMaxSize = 0xDA,
  CPlusCmd = 0xE0,
  IntrMitigate = 0xE2,


Is there a better name for this register?  :)



@@ -476,24 +456,14 @@ struct rtl8169_private {
  void (*phy_reset_enable)(void __iomem *);
  unsigned int (*phy_reset_pending)(void __iomem *);
  unsigned int (*link_ok)(void __iomem *);
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)
- struct work_struct task;
-#else
  struct delayed_work task;
-#endif
  unsigned wol_enabled : 1;
 };

 MODULE_AUTHOR("Realtek and the Linux r8169 crew ");
 MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver");
-
-module_param_array(speed, int, &num_speed, 0);
-MODULE_PARM_DESC(speed, "force phy operation. Deprecated by ethtool (8).");
-module_param_array(duplex, int, &num_duplex, 0);
-MODULE_PARM_DESC(duplex, "force phy operation. Deprecated by ethtool 
(8).");

-module_param_array(autoneg, int, &num_autoneg, 0);
-MODULE_PARM_DESC(autoneg, "force phy operation. Deprecated by ethtool 
(8).");

-
+module_param_array(media, int, &num_media, 0);
+MODULE_PARM_DESC(media, "force phy operation. Deprecated by ethtool (8).");
 module_param(rx_copybreak, int, 0);
 MODULE_PARM_DESC(rx_copybreak, "Copy breakpoint for 
copy-only-tiny-frames");

 module_param(use_dac, int, 0);
@@ -505,11 +475,7 @@ MODULE_VERSION(RTL8169_VERSION);

 static int rtl8169_open(struct net_device *dev);
 static int rtl8169_start_xmit(struct sk_buff *skb, struct net_device *dev);
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,19)
-static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance, struct 
pt_regs *regs);

-#else
 static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance);
-#endif
 static int rtl8169_init_ring(struct net_device *dev);
 static void rtl8169_hw_start(struct net_device *dev);
 static int rtl8169_close(struct net_device *dev);


While we understand that RealTek may need to support multiple kernel 
versions, drivers in the official kernel.org kernel typically do not 
contain compatibility code for older kernel versions.




+ if ((tp->mac_version == RTL_GIGA_MAC_VER_11) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_12) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_13) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_14) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_15)) {
+  mc_filter[0] = 0x;
+  mc_filter[1] = 0x;
+ }


Can you help us understand this code change?  This change appears to 
disable multicast on these MAC versions.


Jeff


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

Re: -mm merge plans for 2.6.21

[Paul Mackerras]

Andrew Morton writes:

> Once a subsystem has a subsystem tree (git or quilt) I basically never
> merge anything which belongs to that tree.  It's always
> 
>   originator->mm->subsystemtree->Linus
> 
> If the subsystem tree maintainer wants to tell me "I can't be bothered
> setting up a git pull for that, please merge it for me" then that's fine.
> 
> But unless I'm told that, or unless the maintainer is vacationing or totally
> asleep or unless the fix has some sufficiently high obviousness*importance 
> product,
> I'll just keep buffering it up.  

What about the sort of thing that crosses all archs?  For example, the
local_t changes?  Particularly in the case where the change has to be
made in generic code and in all archs at the same time, it makes sense
to me for you to send the whole batch to Linus at the same time,
rather than individual arch maintainers all sending their bit at
varying times.

Paul.
-
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: Network: convert network devices to use struct device instead of class_device

[Greg KH]

On Thu, Feb 08, 2007 at 07:41:30AM -0800, Stephen Hemminger wrote:
> On Thu, 08 Feb 2007 07:43:18 -0500
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
> 
> > Linux Kernel Mailing List wrote:
> > > Gitweb: 
> > > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=43cb76d91ee85f579a69d42bc8efc08bac560278
> > > Commit: 43cb76d91ee85f579a69d42bc8efc08bac560278
> > > Parent: 2943ecf2ed32632473c06f1975db47a7aa98c10f
> > > Author: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> > > AuthorDate: Tue Apr 9 12:14:34 2002 -0700
> > > Committer:  Greg Kroah-Hartman <[EMAIL PROTECTED]>
> > > CommitDate: Wed Feb 7 10:37:11 2007 -0800
> > > 
> > > Network: convert network devices to use struct device instead of 
> > > class_device
> > > 
> > > This lets the network core have the ability to handle suspend/resume
> > > issues, if it wants to.
> 
> It fixes a non-problem. I would like to see the network core suspend/resume
> proposal as well. Last time I examined doing network core suspend help,
> the problem was that the physical device suspend was called before the
> class device. It is not clear how this change would help.

Now the real device of the network device (ethX and such) will be called
first.  If not, something's wrong...

thanks,

greg k-h
-
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: Network: convert network devices to use struct device instead of class_device

[Greg KH]

On Thu, Feb 08, 2007 at 07:43:18AM -0500, Jeff Garzik wrote:
> Linux Kernel Mailing List wrote:
> >Gitweb: 
> >http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=43cb76d91ee85f579a69d42bc8efc08bac560278
> >Commit: 43cb76d91ee85f579a69d42bc8efc08bac560278
> >Parent: 2943ecf2ed32632473c06f1975db47a7aa98c10f
> >Author: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> >AuthorDate: Tue Apr 9 12:14:34 2002 -0700
> >Committer:  Greg Kroah-Hartman <[EMAIL PROTECTED]>
> >CommitDate: Wed Feb 7 10:37:11 2007 -0800
> >
> >Network: convert network devices to use struct device instead of 
> >class_device
> >
> >This lets the network core have the ability to handle suspend/resume
> >issues, if it wants to.
> >
> >Thanks to Frederik Deweerdt <[EMAIL PROTECTED]> for the arm
> >driver fixes.
> >
> >Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> >---
> > drivers/infiniband/ulp/ipoib/ipoib_main.c |   33 ++--
> > drivers/infiniband/ulp/ipoib/ipoib_vlan.c |   11 +-
> > drivers/net/arm/at91_ether.c  |2 +-
> > drivers/net/arm/etherh.c  |2 +-
> > drivers/net/bonding/bond_sysfs.c  |  287 
> > +---
> > drivers/net/iseries_veth.c|2 +-
> > drivers/net/macb.c|   36 ++--
> > drivers/net/smc911x.c |2 +-
> > drivers/net/smc91x.c  |2 +-
> > drivers/net/wireless/hostap/hostap_main.c |2 +-
> > drivers/net/wireless/orinoco.c|4 +-
> > drivers/net/wireless/orinoco_cs.c |2 +-
> > drivers/net/wireless/spectrum_cs.c|2 +-
> > include/linux/netdevice.h |5 +-
> > net/bridge/br_if.c|2 +-
> > net/bridge/br_sysfs_br.c  |  234 +---
> > net/bridge/br_sysfs_if.c  |2 +-
> > net/core/dev.c|6 +-
> > net/core/net-sysfs.c  |  175 ++
> > net/core/skbuff.c |2 +-
> > 20 files changed, 451 insertions(+), 362 deletions(-)
> 
> It's highly disappointing that this was never discussed on 
> netdev@vger.kernel.org, or even CC'd to me.

It was CCed to David Miller and you and netdev a long time ago (like 8-9
months ago.)  It's been in the -mm tree since then and discussed on lkml
a few times too.

As I got David's ack for it, and he said to push it through my tree, I
didn't think any more of it.

My apologies, I should have consulted you again before doing it.

thanks,

greg k-h
-
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: somebody dropped a (warning) bomb

[Linus Torvalds]

On Thu, 8 Feb 2007, David Rientjes wrote:
> 
> Your struct:
> 
>   struct dummy {
>   int flag:1;
>   } a_variable;
> 
> should expect a_varible.flag to be signed, that's what the int says.  

No it's not.

You just don't understand the C language. 

And if you don't understand the C language, you can't say "that's what the 
int says". It says no such thing.

The C language clearly says that bitfields have implementation-defined 
types. So when you see

struct dummy {
int flag:1;
} a_variable;

if you don't read that as "oh, the sign of 'flag' is implementation- 
defined", then you simply aren't reading it right.

Is it "intuitive"? Nobody ever really called C an _intuitive_ language. C 
has a lot of rules that you simply have to know. The bitfield sign rule is 
just one such rule.

> There is no special case here with regard to type.

Sure there is. Read the spec.

I don't understand why you are arguing. YOU ARE WRONG.

Bitfields simply have implementation-defined signedness. As do enums. As 
does "char". It really is that simple. 

The *real* special case is actually "int" and "long". In many ways, the 
fact that those *do* have a well-specified signedness is actually the 
exception rather than the rule.

Most C types don't, and some you can't even tell (do pointers generate 
"signed" or "unsigned" comparisons? I'll argue that a compiler that 
generates signed comparisons for them is broken, but it tends to be 
something you can only see with a standards- conforming proghram if you 
can allocate memory across the sign boundary, which may or may not be 
true..)

Linus
-
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] 2.6.20 fix for PageUptodate memorder problem (try 2)

[Hugh Dickins]

On Thu, 8 Feb 2007, Nick Piggin wrote:
> Still no independent confirmation as to whether this is a problem or not.

I'm trying to convince myself none of your patch is necessary.  Probably
shall fail.  But how come we've survived for years with such an issue?

> Updated some comments, added diffstats to patches, don't use
> __SetPageUptodate as an internal page-flags.h private function.

Depressed by profusion of PageUptodate_UpperAndlowercasevariants.
Those rmbs, you really only want them when it says "yes", don't you?

> 
> I would like to eventually get an ack from Hugh regarding the anon memory
> and especially swap side of the equation,

Plea noted.  I'm pondering.  "Eventually" indeed.  OTOH I expect you're
right to criticize anon/swap PageUptodate being set where it was needed
to get by, rather than where it was natural to do so.

> and a glance from whoever put the
> smp_wmb()s into the copy functions (Was it Ben H or Anton maybe?)

From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Thu, 14 Oct 2004 04:00:06 + (-0700)
Subject: Fix threaded user page write memory ordering
X-Git-Tag: v2.6.9-final~3
X-Git-Url: 
http://127.0.0.1:1234/?p=.git;a=commitdiff_plain;h=538ce05c0ef4055cf29a92a4abcdf139d180a0f9;hp=8c225dbc5a7b13801a8254aae0ccebab8e4bece7

Fix threaded user page write memory ordering

Make sure we order the writes to a newly created page
with the page table update that potentially exposes the
page to another CPU.

This is a no-op on any architecture where getting the
page table spinlock will already do the ordering (notably
x86), but other architectures can care.
---

diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index 232d8fd..7153aef 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -40,6 +40,8 @@ static inline void clear_user_highpage(s
void *addr = kmap_atomic(page, KM_USER0);
clear_user_page(addr, vaddr, page);
kunmap_atomic(addr, KM_USER0);
+   /* Make sure this page is cleared on other CPU's too before using it */
+   smp_wmb();
 }
 
 static inline void clear_highpage(struct page *page)
@@ -73,6 +75,8 @@ static inline void copy_user_highpage(st
copy_user_page(vto, vfrom, vaddr, to);
kunmap_atomic(vfrom, KM_USER0);
kunmap_atomic(vto, KM_USER1);
+   /* Make sure this page is cleared on other CPU's too before using it */
+   smp_wmb();
 }
 
 static inline void copy_highpage(struct page *to, struct page *from)
-
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: device_destroy

[Greg KH]

On Thu, Feb 08, 2007 at 03:51:08PM +, James Simmons wrote:
> 
> While porting over a few class_devices I discovered a problem with 
> device_destroy. It uses a dev_t which several classes don't use. 
> Should all classes require a dev_t or should we just pass in the device
> itself?

As you don't have a dev_t, then you have a handle to the 'struct device'
itself, right?  Then just call device_unregister(), that's all that
device_destroy() does after it finds the device in the list of devices
associated with the class.

Does this help?

thanks,

greg k-h
-
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: Fw: [BUG][PATCH] fix mempolcy's check on a system with memory-less-node take3

[KAMEZAWA Hiroyuki]

On Thu, 8 Feb 2007 11:28:30 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > @@ -193,9 +197,11 @@
> > break;
> > case MPOL_BIND:
> > policy->v.zonelist = bind_zonelist(nodes);
> > -   if (policy->v.zonelist == NULL) {
> > +   if (IS_ERR(policy->v.zonelist)) {
> > +   void *val = policy->v.zonelist;
> > +   policy->v.zonelist = NULL;
> 
> void *? Ahh. It takes the error code.
> 
> Looks good. But if we are really going down this road of memory-less 
> nodes we may want to audit the kernel for other issues.
> 
> Could you run a series of tests on that machine?
> 
Yes. The program which caused trouble works fine.
I used 'numademo' command in numactl package.
It works fine (reports -EINVAL) with this patch now.

I uses this a system with an empty-node for 5 months.
reported 2 bugs.
- oom-kill's memory less node detection logic.
- mempolicy's NULL access(this)

It works fine in general.
(old RHEL4/linux-2.6.9 kernel doesn't boot on this system.)

-Kame









-
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 0/3] a faster buffered write deadlock fix?

[Mark Fasheh]

On Thu, Feb 08, 2007 at 02:07:15PM +0100, Nick Piggin wrote:
> The problem is that the existing aops interface is crap. "correct, fast,
> compatible -- choose any 2"

Agreed. There's lots of problems with the interface (imho), but my biggest
two issues are the page lock being held on ->prepare_write() /
->commit_write() and the fact that the file system only sees the write one
page at a time


> So I have finally finished a first slightly-working draft of my new aops
> op (perform_write) proposal. I would be interested to hear comments about
> it.  Most of my issues and concerns are in the patch headers themselves,
> so reply to them.

I like ->perform_write(). It allows the file system to make re-use of the
checks in the generic write path, but gives a maximum amount of information
about the overall operation to be done. There's an added advantage in that
some file systems (ocfs2 is one of these) want to be more careful about
ordering page locks, which should be much easier with it.

If this goes in, it could probably be helpful to me in some of the code I'm
currently writing which needs to be better about page lock / cluster lock
ordering and wants to see as much of the (allocating) writes as possible.
--Mark

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

Re: [linux-cifs-client] Re: SMB support still missing?

[Jan Engelhardt]

On Feb 8 2007 18:29, Christopher R. Hertel wrote:
>Jan Engelhardt wrote:
>
>It does seem to me that it is some sort of name resolution issue, but it may
>have more to do with the multi-homed nature of your setup.
>
>Did you try:
>
>  mount.cifs //CL0/c /mnt

Yes, that one _fails_ with "mount error 112 = Host is down" (though tcpdump
_does_ show that cifs connects to port 139 and then disconnects using FIN)

>If mount.cifs is not converting the case, that should fix the problem.
>Curious to know...


Jan
-- 
ft: http://freshmeat.net/p/chaostables/
-
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-cifs-client] Re: SMB support still missing?

[Christopher R. Hertel]

Jan Engelhardt wrote:
> Hi,
> 
> 
> I tried the various suggestions from the last mails, but nothing of 
> that worked. --verbose did not return anything useful. It's the kernel 
> module that returns -EHOSTDOWN.
> 
> ...
> 
> Eventually I found out that this one works:
> 
>   mount.cifs //cl0/c /mnt -o servernetbiosname=CL0
> 
> So what did I change? Casing. Note that "CL0" is entirely uppercase. 
> Although strange, it actually coincides with how LANMAN works. 
> Everything is uppercased in lanman, hostnames, usernames, heck, even 
> plaintext passwords (samba-smbd has a good time trying a ton of 
> combinations in such setups).
> 
> No other options like sec=none or thelike were needed. Login as 
> anonymous worked directly.
> 
> 
> Please consider updating the cifs kernel module to account for the LM 
> oddity of uppercasing things. (Then, smbfs can finally be ripped out I 
> hope.)

...assuming that's really the problem.

It does seem to me that it is some sort of name resolution issue, but it may
have more to do with the multi-homed nature of your setup.

Did you try:

  mount.cifs //CL0/c /mnt

?

If mount.cifs is not converting the case, that should fix the problem.

Curious to know...

Chris -)-


-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/ -)-   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/ -)-   [EMAIL PROTECTED]
OnLineBook -- http://ubiqx.org/cifs/-)-   [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Git backlight subsystem tree

[Greg KH]

On Thu, Feb 08, 2007 at 11:50:23PM +, Richard Purdie wrote:
> Hi Greg,
> 
> On Thu, 2007-02-08 at 13:23 -0800, Greg KH wrote:
> > On Thu, Feb 08, 2007 at 06:32:02PM +, James Simmons wrote:
> > > I CC Greg to explain. The backlight class didn't go away. The way it is 
> > > handled is different.
> > 
> > Have a pointer to the patch so I can help explain better?
> 
> You've been cc'd on the proposed patch a couple of times in this thread
> so it should be in your mailbox now.
> 
> > As a short summary, 'struct class_device' is going away.  Using a
> > 'struct device' in its place is what the conversion should have just
> > done, no functionality change otherwise.
> 
> The backlight class is drivers/video/backlight/backlight.c and if I
> understand things correctly what shows up in sysfs changes.
> 
> At the moment (as I understand the code which could be wrong), the
> backlight functionality is tagged onto an existing device. Taking
> drivers/video/backlight/corgi_bl.c as an example, the corgi_bl device
> exists under /sys/devices/platform/corgi_bl with an associated struct
> device. The backlight code then appends some magic to this to link in
> some class attributes that show up under /sys/class/backlight. There is
> only ever one device.
> 
> By replacing class_device_register() with device_create(), the proposed
> patch appears to generate a second struct device with the original as
> its parent. I'm not sure where it appears in /sys/devices? Having
> another full blown struct device around makes me uneasy as wherever it
> appears, we only have one device, not two.

No, your blacklight "device" is also a device now, not just a
class_device.  You want to show that heirachy properly for a variety of
different reasons (power management being one of the most important.)

> If I had some kind of platform device which had an LED, backlight and
> say battery component and registered with the three appropriate classes
> would that mean four struct devices? Where under /sys/devices do they
> each appear?

Under the main device itself, as they are children of it.

As an example, look at a sound device now on 2.6.20 with
CONFIG_SYSFS_DEPRECATED turned off:

$ tree /sys/class/sound/
/sys/class/sound/
|-- adsp -> ../../devices/pci:00/:00:1b.0/card0/adsp
|-- audio -> ../../devices/pci:00/:00:1b.0/card0/audio
|-- card0 -> ../../devices/pci:00/:00:1b.0/card0
|-- controlC0 -> ../../devices/pci:00/:00:1b.0/card0/controlC0
|-- dsp -> ../../devices/pci:00/:00:1b.0/card0/dsp
|-- mixer -> ../../devices/pci:00/:00:1b.0/card0/mixer
|-- pcmC0D0c -> ../../devices/pci:00/:00:1b.0/card0/pcmC0D0c
|-- pcmC0D0p -> ../../devices/pci:00/:00:1b.0/card0/pcmC0D0p
|-- pcmC0D1p -> ../../devices/pci:00/:00:1b.0/card0/pcmC0D1p
|-- seq -> ../../devices/virtual/sound/seq
|-- sequencer -> ../../devices/virtual/sound/sequencer
|-- sequencer2 -> ../../devices/virtual/sound/sequencer2
`-- timer -> ../../devices/virtual/sound/timer

There are a bunch of mixer and other interfaces, all now real devices
under the proper PCI device (sound added the "card0" intermediate level
also, but you will not have that for your devices.

> Also, it was mentioned that a parent struct device is a requirement and
> this isn't the case for all backlight users. I think this constraint on
> device_create has been removed in more recent code though? 

Yes, if NULL is passed in, it will be created in the
/sys/devices/virtual/CLASS_NAME/ directory.  See the above "seq" and
"timer" devices as an example of that.

Hope this helps,

greg k-h
-
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: somebody dropped a (warning) bomb

[David Rientjes]

On Thu, 8 Feb 2007, Linus Torvalds wrote:

> No, making bitfields unsigned is actually usually a good idea. It allows 
> you to often generate better code, and it actually tends to be what 
> programmers _expect_. A lot of people seem to be surprised to hear that a 
> one-bit bitfield actually often encodes -1/0, and not 0/1.
> 

Your struct:

struct dummy {
int flag:1;
} a_variable;

should expect a_varible.flag to be signed, that's what the int says.  
There is no special case here with regard to type.  It's traditional K&R 
that writing signed flag:1 here is redundant (K&R pg. 211).  Now whether 
that's what you wanted or not is irrelevant.  As typical with C, it gives 
you exactly what you asked for.

You're arguing for inconsistency in how bitfields are qualified based on 
their size.  If you declare a bitfield as int byte:8, then you're going 
to expect this to behave exactly like a signed char, which it does.

struct {
int byte:8;
} __attribute__((packed)) b_variable;

b_variable.byte is identical to a signed char.

Just because a_variable.flag happens to be one bit, you cannot say that 
programmers _expect_ it to be unsigned, or you would also expect 
b_variable.byte to act as an unsigned char.  signed is the default 
behavior for all types besides char, so the behavior is appropriate based 
on what most programmers would expect.

> So unsigned bitfields are not only traditional K&R, they are also usually 
> _faster_ (which is probably why they are traditional K&R - along with 
> allowing "char" to be unsigned by default). Don't knock them.  It's much 
> better to just remember that bitfields simply don't _have_ any standard 
> sign unless you specify it explicitly, than saying "it should be signed 
> because 'int' is signed".
> 

Of course they're faster, it doesn't require the sign extension.  But 
you're adding additional semantics to the language by your interpretation 
of what is expected by the programmer in the bitfield case as opposed to a 
normal variable definition.

> I will actually argue that having signed bit-fields is almost always a 
> bug, and that as a result you should _never_ use "int" at all. Especially 
> as you might as well just write it as
> 
>   signed a:1;
> 
> if you really want a signed bitfield.
> 

How can signed bitfields almost always be a bug?  I'm the programmer and I 
want to store my data in a variable that I define, so I must follow the 
twos-complement rule and allot a sign bit if I declare it as a signed 
value.  In C, you do this with "int"; otherwise, you use "unsigned".

> So I would reall yrecommend that you never use "int a:" AT ALL, 
> because there really is never any good reason to do so. Do it as
> 
>   unsigned a:3;
>   signed b:2;
> 
> but never 
> 
>   int c:4;
> 
> because the latter really isn't sensible.
> 

That _is_ sensible because anything you declare "int" is going to be 
signed as far as gcc is concerned.  "c" just happens to be 4-bits wide 
instead of 32.  But for everything else, it's the same as an int.  I know 
exactly what I'm getting by writing "int c:4", as would most programmers 
who use bitfields to begin with.

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

[PATCH 1/2] NET: Multiple queue network device support

[Kok, Auke]

From: Peter Waskiewicz Jr <[EMAIL PROTECTED]>

Added an API and associated supporting routines for multiqueue network
devices.  This allows network devices supporting multiple TX queues to
configure each queue within the netdevice and manage each queue
independantly.  Changes to the PRIO Qdisc also allow a user to map
multiple flows to individual TX queues, taking advantage of each queue
on the device.

Signed-off-by: Peter Waskiewicz Jr <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---

 include/linux/netdevice.h |   73 
 include/net/sch_generic.h |3 +
 net/Kconfig   |   20 
 net/core/dev.c|   51 
 net/sched/sch_generic.c   |  117 +
 net/sched/sch_prio.c  |  106 ++---
 6 files changed, 364 insertions(+), 6 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 2e37f50..c7f94a8 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -106,6 +106,16 @@ struct netpoll_info;
 #define MAX_HEADER (LL_MAX_HEADER + 48)
 #endif
 
+#ifdef CONFIG_NET_MULTI_QUEUE_DEVICE
+
+struct net_device_subqueue
+{
+   /* Give a lock and a flow control state for each queue */
+   unsigned long   state;
+   spinlock_t  queue_lock cacheline_aligned_in_smp;
+};
+#endif
+
 /*
  * Network device statistics. Akin to the 2.0 ether stats but
  * with byte counters.
@@ -339,6 +349,10 @@ struct net_device
 #define NETIF_F_GEN_CSUM   (NETIF_F_NO_CSUM | NETIF_F_HW_CSUM)
 #define NETIF_F_ALL_CSUM   (NETIF_F_IP_CSUM | NETIF_F_GEN_CSUM)
 
+#ifdef CONFIG_NET_MULTI_QUEUE_DEVICE
+#define NETIF_F_MULTI_QUEUE8192/* Has multiple TX/RX queues */
+#endif
+
struct net_device   *next_sched;
 
/* Interface index. Unique device identifier*/
@@ -532,6 +546,19 @@ struct net_device
struct device   dev;
/* space for optional statistics and wireless sysfs groups */
struct attribute_group  *sysfs_groups[3];
+
+#ifdef CONFIG_NET_MULTI_QUEUE_DEVICE
+   /* To retrieve statistics per subqueue - FOR FUTURE USE */
+   struct net_device_stats* (*get_subqueue_stats)(struct net_device *dev,
+   int queue_index);
+
+   /* The TX queue control structures */
+   struct net_device_subqueue  *egress_subqueue;
+   int egress_subqueue_count;
+   int (*hard_start_subqueue_xmit)(struct sk_buff *skb,
+   struct net_device *dev,
+   int queue_index);
+#endif /* CONFIG_NET_MULTI_QUEUE_DEVICE */
 };
 #define to_net_dev(d) container_of(d, struct net_device, dev)
 
@@ -673,6 +700,52 @@ static inline int netif_running(const struct net_device 
*dev)
return test_bit(__LINK_STATE_START, &dev->state);
 }
 
+#ifdef CONFIG_NET_MULTI_QUEUE_DEVICE
+
+/*
+ * Routines to manage the subqueues on a device.  We only need start
+ * stop, and a check if it's stopped.  All other device management is
+ * done at the overall netdevice level.
+ * Also test the netif state if we're multi-queue at all.
+ */
+static inline void netif_start_subqueue(struct net_device *dev, int 
queue_index)
+{
+   clear_bit(__LINK_STATE_XOFF, &dev->egress_subqueue[queue_index].state);
+}
+
+static inline void netif_stop_subqueue(struct net_device *dev, int queue_index)
+{
+#ifdef CONFIG_NETPOLL_TRAP
+   if (netpoll_trap())
+   return;
+#endif
+   set_bit(__LINK_STATE_XOFF, &dev->egress_subqueue[queue_index].state);
+}
+
+static inline int netif_subqueue_stopped(const struct net_device *dev,
+ int queue_index)
+{
+   return test_bit(__LINK_STATE_XOFF,
+   &dev->egress_subqueue[queue_index].state);
+}
+
+static inline void netif_wake_subqueue(struct net_device *dev, int queue_index)
+{
+#ifdef CONFIG_NETPOLL_TRAP
+   if (netpoll_trap())
+   return;
+#endif
+   if (test_and_clear_bit(__LINK_STATE_XOFF,
+  &dev->egress_subqueue[queue_index].state))
+   __netif_schedule(dev);
+}
+
+static inline int netif_is_multiqueue(const struct net_device *dev)
+{
+   return (!!(NETIF_F_MULTI_QUEUE & dev->features));
+}
+#endif /* CONFIG_NET_MULTI_QUEUE_DEVICE */
+
 
 /* Use this variant when it is known for sure that it
  * is executing from interrupt context.
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index 8208639..8751ba6 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -102,6 +102,9 @@ struct Qdisc_ops
 
int (*dump)(struct Qdisc *, struct sk_buff *);
int (*dump_stats)(struct Qdisc *, struct gnet_dump 
*);
+#ifdef CONFIG_N

[PATCH 2/2] e1000: Implement the new kernel API for multiqueue TX support.

[Kok, Auke]

From: Peter Waskiewicz Jr. <[EMAIL PROTECTED]>

Several newer e1000 chipsets support multiple RX and TX queues. Most
commonly, 82571's and ESB2LAN support 2 rx and 2 rx queues.

Signed-off-by: Peter Waskiewicz Jr. <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---

 drivers/net/Kconfig   |   13 ++
 drivers/net/e1000/e1000.h |   23 +++
 drivers/net/e1000/e1000_ethtool.c |   43 ++
 drivers/net/e1000/e1000_main.c|  269 +++--
 4 files changed, 304 insertions(+), 44 deletions(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index ad92b6a..2d758ab 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1988,6 +1988,19 @@ config E1000_DISABLE_PACKET_SPLIT
 
  If in doubt, say N.
 
+config E1000_MQ
+   bool "Enable Tx/Rx Multiqueue Support (EXPERIMENTAL)"
+   depends on E1000 && NET_MULTI_QUEUE_DEVICE && EXPERIMENTAL
+   help
+ Say Y here if you want to enable multiqueue support for supported
+ e1000 devices.  This will enable both transmit and receive queues
+ on devices that support them.
+
+ In order to fully utilize the Tx queue support, use the SCH_PRIO
+ queueing discipline.
+
+ If in doubt, say N.
+
 source "drivers/net/ixp2000/Kconfig"
 
 config MYRI_SBUS
diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h
index 689f158..cfcdc9d 100644
--- a/drivers/net/e1000/e1000.h
+++ b/drivers/net/e1000/e1000.h
@@ -108,6 +108,10 @@ struct e1000_adapter;
 #define E1000_MIN_RXD   80
 #define E1000_MAX_82544_RXD   4096
 
+#ifdef CONFIG_E1000_MQ
+#define E1000_MAX_TX_QUEUES  4
+#endif
+
 /* this is the size past which hardware will drop packets when setting LPE=0 */
 #define MAXIMUM_ETHERNET_VLAN_SIZE 1522
 
@@ -168,6 +172,12 @@ struct e1000_buffer {
uint16_t next_to_watch;
 };
 
+#ifdef CONFIG_E1000_MQ
+struct e1000_queue_stats {
+   uint64_t packets;
+   uint64_t bytes;
+};
+#endif
 
 struct e1000_ps_page { struct page *ps_page[PS_PAGE_BUFFERS]; };
 struct e1000_ps_page_dma { uint64_t ps_page_dma[PS_PAGE_BUFFERS]; };
@@ -188,9 +198,16 @@ struct e1000_tx_ring {
/* array of buffer information structs */
struct e1000_buffer *buffer_info;
 
+#ifdef CONFIG_E1000_MQ
+   /* for tx ring cleanup - needed for multiqueue */
+   spinlock_t tx_queue_lock;
+#endif
spinlock_t tx_lock;
uint16_t tdh;
uint16_t tdt;
+#ifdef CONFIG_E1000_MQ
+   struct e1000_queue_stats tx_stats;
+#endif
boolean_t last_tx_tso;
 };
 
@@ -218,6 +235,9 @@ struct e1000_rx_ring {
 
uint16_t rdh;
uint16_t rdt;
+#ifdef CONFIG_E1000_MQ
+   struct e1000_queue_stats rx_stats;
+#endif
 };
 
 #define E1000_DESC_UNUSED(R) \
@@ -271,6 +291,9 @@ struct e1000_adapter {
 
/* TX */
struct e1000_tx_ring *tx_ring;  /* One per active queue */
+#ifdef CONFIG_E1000_MQ
+   struct e1000_tx_ring **cpu_tx_ring; /* per-cpu */
+#endif
unsigned int restart_queue;
unsigned long tx_queue_len;
uint32_t txd_cmd;
diff --git a/drivers/net/e1000/e1000_ethtool.c 
b/drivers/net/e1000/e1000_ethtool.c
index 44ebc72..c8c1500 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -105,7 +105,14 @@ static const struct e1000_stats e1000_gstrings_stats[] = {
{ "dropped_smbus", E1000_STAT(stats.mgpdc) },
 };
 
+#ifdef CONFIG_E1000_MQ
+#define E1000_QUEUE_STATS_LEN \
+   (((struct e1000_adapter *)netdev->priv)->num_tx_queues + \
+((struct e1000_adapter *)netdev->priv)->num_rx_queues) \
+   * (sizeof(struct e1000_queue_stats) / sizeof(uint64_t))
+#else
 #define E1000_QUEUE_STATS_LEN 0
+#endif
 #define E1000_GLOBAL_STATS_LEN \
sizeof(e1000_gstrings_stats) / sizeof(struct e1000_stats)
 #define E1000_STATS_LEN (E1000_GLOBAL_STATS_LEN + E1000_QUEUE_STATS_LEN)
@@ -1909,6 +1916,11 @@ e1000_get_ethtool_stats(struct net_device *netdev,
struct ethtool_stats *stats, uint64_t *data)
 {
struct e1000_adapter *adapter = netdev_priv(netdev);
+#ifdef CONFIG_E1000_MQ
+   uint64_t *queue_stat;
+   int stat_count = sizeof(struct e1000_queue_stats) / sizeof(uint64_t);
+   int j, k;
+#endif
int i;
 
e1000_update_stats(adapter);
@@ -1917,12 +1929,29 @@ e1000_get_ethtool_stats(struct net_device *netdev,
data[i] = (e1000_gstrings_stats[i].sizeof_stat ==
sizeof(uint64_t)) ? *(uint64_t *)p : *(uint32_t *)p;
}
+#ifdef CONFIG_E1000_MQ
+   for (j = 0; j < adapter->num_tx_queues; j++) {
+   queue_stat = (uint64_t *)&adapter->tx_ring[j].tx_stats;
+   for (k = 0; k < stat_count; k++)
+   data[i + k] = queue_stat[k];
+   i += k;
+   }
+   for (j = 0; j < adapter->num_rx_queues; j++) {
+   queue_stat = (uint64_t *)&adapter->rx_ring[j]

[PATCH 0/2 REVIEW] Multiple transmit/receive queue kernel

[Kok, Auke]

Hi,

The following two patches are submitted for review. Please provide feedback
and comments as usual.

This set of patches implements a generic API for multiqueue-capable
devices to have network stack support to assign multiple flows into each
queue on the NIC.  It provides an interface for non-multiqueue devices
to coexist in a machine running with both types of devices, as well as
providing a modified queuing discipline to assign multiple flows in the
stack to individual queues on the NIC.  This is necessary to alleviate
more head-of-line-blocking issues with different priority flows, where
today QoS only prevents HOLB within the stack, but not in the device.

Some Intel PRO/1000 adapters support this hardware feature, so this
series includes a patch to the e1000 driver to enable this hardware
feature for those devices. You will need to setup the queue's using tc.
Limited queue statistics are available through ethtool for devices that
support multiple queues.

Regards,

Auke Kok
Peter Waskiewicz Jr.

---
These patches apply against commit b892afd1e60132a981b963929e352eabf3306ba2
of branch 'master' from torvalds/linux-2.6.

You can pull these patches through git:

git-pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 multiqueue

---
Summary:
Peter Waskiewicz Jr <[EMAIL PROTECTED]>:
 NET: Multiple queue network device support
 e1000: Implement the new kernel API for multiqueue TX support.

---
 drivers/net/Kconfig   |   13 +
 drivers/net/e1000/e1000.h |   23 +++
 drivers/net/e1000/e1000_ethtool.c |   43 ++
 drivers/net/e1000/e1000_main.c|  269 +++---
 include/linux/netdevice.h |   73 ++
 include/net/sch_generic.h |3 
 net/Kconfig   |   20 ++
 net/core/dev.c|   51 +++
 net/sched/sch_generic.c   |  117 
 net/sched/sch_prio.c  |  106 ++
 10 files changed, 668 insertions(+), 50 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/

Re: somebody dropped a (warning) bomb

[Linus Torvalds]

On Fri, 9 Feb 2007, J.A. Magallón wrote:
> 
> Thats the point. Mmmm, I think I see it the other way around. I defined
> a variable as 'signed' or 'unsigned', because the sign info matters for me.
> And gcc warns about using a function on it that will _ignore_ or even
> misinterpret that info. Could it be a BUG ? Yes.

Sure. The other way of seeing it is that *anything*  could be a bug.

Could adding 1 to "a" be a bug? Yes. "a" might overflow. So maybe the 
compiler should warn about that too?

So do you think a compiler should warn when you do

int a = i + 1;

and say "warning: Expression on line x might overflow"?

Could it be a BUG? Hell yeah.

Is warning for things that _could_ be bugs sane? Hell NO.

> Linux/x86, gcc 4.1.2-0.20070115:
> werewolf:~> gcc -Wpointer-sign -c t.c
> t.c: In function ÿÿfÿÿ:
> t.c:10: warning: pointer targets in passing argument 1 of ÿÿstrlenÿÿ differ 
> in signedness
> t.c:11: warning: pointer targets in passing argument 1 of ÿÿstrlenÿÿ differ 
> in signedness

Yeah, and that's what I think is crazy.

Is it consistent? Yes. Does it help people? No.

A warning that is consistent is not necessarily a good warning. It needs 
to MAKE SENSE too. And this one doesn't.  I'm sorry if you can't see that.

Linus

[linux-cifs-client] Re: SMB support still missing?

[Jan Engelhardt]

Hi,


I tried the various suggestions from the last mails, but nothing of 
that worked. --verbose did not return anything useful. It's the kernel 
module that returns -EHOSTDOWN.

...

Eventually I found out that this one works:

mount.cifs //cl0/c /mnt -o servernetbiosname=CL0

So what did I change? Casing. Note that "CL0" is entirely uppercase. 
Although strange, it actually coincides with how LANMAN works. 
Everything is uppercased in lanman, hostnames, usernames, heck, even 
plaintext passwords (samba-smbd has a good time trying a ton of 
combinations in such setups).

No other options like sec=none or thelike were needed. Login as 
anonymous worked directly.


Please consider updating the cifs kernel module to account for the LM 
oddity of uppercasing things. (Then, smbfs can finally be ripped out I 
hope.)



Jan
-- 
ft: http://freshmeat.net/p/chaostables/
-
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: The who needs reviews anyways [PATCH]

[Andreas Schwab]

Roman Zippel <[EMAIL PROTECTED]> writes:

> - printf has other side effects, instead stop pretending we support 
>   something else than bash

printf is a much better echo, but you need to use it properly as well.
Either use %s to print a literal string or %b to let it interpret escape
sequences.

Andreas.

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

Re: somebody dropped a (warning) bomb

[J.A. Magallón]

On Thu, 8 Feb 2007 14:03:06 -0800 (PST), Linus Torvalds <[EMAIL PROTECTED]> 
wrote:

> 
> 
> On Thu, 8 Feb 2007, Linus Torvalds wrote:
> > 
> > But THE CALLER CANNOT AND MUST NOT CARE! Because the sign of "char" is 
> > implementation-defined, so if you call "strcmp()", you are already 
> > basically saying: I don't care (and I _cannot_ care) what sign you are 
> > using.
> 
> Let me explain it another way.
> 
> Say you use
> 
>   signed char *myname, *yourname;
> 
>   if (strcmp(myname,yourname) < 0)
>   printf("Ha, I win!\n")
> 
> and you compile this on an architecture where "char" is signed even 
> without the explicit "signed".
> 
> What should happen?
> 
> Should you get a warning? The types really *are* the same, so getting a 
> warning sounds obviously insane. But on the other hand, if you really care 
> about the sign that strcmp() uses internally, the code is wrong *anyway*, 

Thats the point. Mmmm, I think I see it the other way around. I defined
a variable as 'signed' or 'unsigned', because the sign info matters for me.
And gcc warns about using a function on it that will _ignore_ or even
misinterpret that info. Could it be a BUG ? Yes.

> because with another compiler, or with the *same* compiler on another 
> architecture or some other compiler flags, the very same code is buggy.
> 
> In other words, either you should get a warning *regardless* of whether 
> the sign actually matches or not, or you shouldn't get a warning at all 
> for the above code. Either it's buggy code, or it isn't.
> 

In fact, I tried to look for an arch where this gives only _one_ error:

#include 

void f()
{
const unsigned char *a;
const signed char *b;

int la,lb;

la = strlen(a);
lb = strlen(b);
}

and guess, all give _both_ errors.

Linux/x86, gcc 4.1.2-0.20070115:
werewolf:~> gcc -Wpointer-sign -c t.c
t.c: In function ‘f’:
t.c:10: warning: pointer targets in passing argument 1 of ‘strlen’ differ in 
signedness
t.c:11: warning: pointer targets in passing argument 1 of ‘strlen’ differ in 
signedness

OSX ppc, gcc-4.0.1
belly:~> gcc -Wpointer-sign -c t.c
t.c: In function ‘f’:
t.c:10: warning: pointer targets in passing argument 1 of ‘strlen’ differ in 
signedness
t.c:11: warning: pointer targets in passing argument 1 of ‘strlen’ differ in 
signedness

Solaris5.7 Ultra, cc WorkShop Compilers 5.0
den:~> cc -Xa -c t.c   
ucbcc: Warning: "-Xa" redefines compatibility mode from "SunC transition" to 
"ANSI"
"t.c", line 10: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "/usr/include/string.h", line 71
argument : pointer to const uchar
"t.c", line 11: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "/usr/include/string.h", line 71
argument : pointer to const schar

This makes sense.
Someone can try on something psychedelic, like ARM ;) ?

--
J.A. Magallon  \   Software is like sex:
 \ It's better when it's free
Mandriva Linux release 2007.1 (Cooker) for i586
Linux 2.6.19-jam06 (gcc 4.1.2 20070115 (prerelease) 
(4.1.2-0.20070115.1mdv2007.1)) #1 SMP PREEMPT
-
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 header change breaks linux-atm userspace build

[David Miller]

From: Andrew Walrond <[EMAIL PROTECTED]>
Date: Thu, 8 Feb 2007 21:31:25 +

> Sometime between 2.6.18.3 and 2.6.20, this change...
> 
> --- /include/linux/atmarp.h 2007-01-10 16:32:05.0 +
> +++ pkg/linux/include/linux/atmarp.h2007-02-08 20:02:08.0 +
> @@ -34,7 +34,7 @@
>  struct atmarp_ctrl {
> enum atmarp_ctrl_type   type;   /* message type */
> int itf_num;/* interface number (if present) */
> -   uint32_tip; /* IP address (act_need only) */
> +   __be32  ip; /* IP address (act_need only) */
>  };
> 
>  #endif
> 
> was introduced, but __be32 is undefined, so atmarp.h should include 
> linux/types.h

I'll fix this, thanks for reporting.
-
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: [Cbe-oss-dev] [RFC, PATCH] CELL Oprofile SPU profiling updated patch

[Maynard Johnson]

Milton,
Thank you for your comments.  Carl will reply to certain parts of your 
posting where he's more knowledgeable than I.  See my replies below.


-Maynard

Milton Miller wrote:


On Feb 6, 2007, at 5:02 PM, Carl Love wrote:

 


This is the first update to the patch previously posted by Maynard
Johnson as "PATCH 4/4. Add support to OProfile for profiling CELL".


   

 


[snip]



Data collected


The current patch starts tackling these translation issues for the
presently common case of a static self contained binary from a single
file, either single separate source file or embedded in the data of
the host application.   When creating the trace entry for a SPU
context switch, it records the application owner, pid, tid, and
dcookie of the main executable.   It addition, it looks up the
object-id as a virtual address and records the offset if it is non-zero,
or the dcookie of the object if it is zero.   The code then creates
a data structure by reading the elf headers from the user process
(at the address given by the object-id) and building a list of
SPU address to elf object offsets, as specified by the ELF loader
headers.   In addition to the elf loader section, it processes the
overlay headers and records the address, size, and magic number of
the overlay.

When the hardware trace entries are processed, each address is
looked up this structure and translated to the elf offset.  If
it is an overlay region, the overlay identify word is read and
the list is searched for the matching overlay.  The resulting
offset is sent to the oprofile system.

The current patch specifically identifies that only single
elf objects are handled.  There is no code to handle dynamic
linked libraries or overlays.   Nor is there any method to
 

Yes, we do handle overlays.  (Note: I'm looking into a bug right now in 
our overlay support.)



present samples that may have been collected during context
switch processing, they must be discarded.


My proposal is to change what is presented to user space.  Instead
of trying to translate the SPU address to the backing file
as the samples are recorded, store the samples as the SPU
context and address.  The context switch would record tid,
pid, object id as it does now.   In addition, if this is a
new object-id, the kernel would read elf headers as it does
today.  However, it would then proceed to provide accurate
dcookie information for each loader region and overlay.  To
identify which overlays are active, (instead of the present
read on use and search the list to translate approach) the
kernel would record the location of the overlay identifiers
as it parsed the kernel, but would then read the identification
word and would record the present value as an sample from
a separate but related stream.   The kernel could maintain
the last value for each overlay and only send profile events
for the deltas.
 

Discussions on this topic in the past have resulted in the current 
implementation precisely because we're able to record the samples as 
fileoffsets, just as the userspace tools expect.   I haven't had time to 
check out how much this would impact the userspace tools, but my gut 
feel is that it would be quite significant.  If we were developing this 
module with a matching newly-created userspace tool, I would be more 
inclined to agree that this makes sense.  But you give no rationale for 
your proposal that justifies the change.  The current implementation 
works, it has no impact on normal, non-profiling behavior,  and the 
overhead during profiling is not noticeable.



This approach trades translation lookup overhead for each
recorded sample for a burst of data on new context activation.
In addition it exposes the sample point of the overlay identifier
vs the address collection.  This allows the ambiguity to be
exposed to user space.   In addition, with the above proposed
kernel timer vs sample collection, user space could limit the
elapsed time between the address collection and the overlay
id check.
 

Yes, there is a window here where an overlay could occur before we 
finish processing a group of samples that were actually taken from a 
different overlay.  The obvious way to prevent that is for the kernel 
(or SPUFS) to be notified of the overlay and let OProfile know that we 
need to drain (perhaps discard would be best) our sample trace buffer.  
As you indicate above, your proposal faces the same issue, but would 
just decrease the number of bogus samples.  I contend that the relative 
number of bogus samples will be quite low in either case.  Ideally, we 
should have a mechanism to eliminate them completely so as to avoid 
confusion the user's part when they're looking at a report.  Even a few 
bogus samples in the wrong place can be troubling.  Such a mechanism 
will be a good future enhancement.


[snip]


milton
--
[EMAIL PROTECTED]   Milton Miller
Speaking for myself only.

___
Linuxppc-dev mailing list
[EMAIL PROTEC

Re: -mm merge plans for 2.6.21

[Andrew Morton]

On Thu, 8 Feb 2007 18:34:49 -0500
Kyle McMartin <[EMAIL PROTECTED]> wrote:

> On Thu, Feb 08, 2007 at 03:07:10PM -0800, Andrew Morton wrote:
> > I'm getting fed up of holding onto hundreds of patches against subsystem
> > trees, sending them over and over again seeing and nothing happen.  I sent 
> > 242
> > patches out to subsystem maintainers on Monday and look at what's still 
> > here.
> > 
> > parisc-fix-module_param-iommu-permission.patch
> > pa-risc-fix-bogus-warnings-from-modpost.patch
> > use-__u64-rather-than-u64-in-parisc-statfs-structs.patch
> > 
> >  -> kyle
> > 
> 
> Sorry, I thought the mails meant you were dumping to Linus. Will
> merge.

Once a subsystem has a subsystem tree (git or quilt) I basically never
merge anything which belongs to that tree.  It's always

originator->mm->subsystemtree->Linus

If the subsystem tree maintainer wants to tell me "I can't be bothered
setting up a git pull for that, please merge it for me" then that's fine.

But unless I'm told that, or unless the maintainer is vacationing or totally
asleep or unless the fix has some sufficiently high obviousness*importance 
product,
I'll just keep buffering it up.  
-
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 backlight subsystem tree

[Richard Purdie]

Hi Greg,

On Thu, 2007-02-08 at 13:23 -0800, Greg KH wrote:
> On Thu, Feb 08, 2007 at 06:32:02PM +, James Simmons wrote:
> > I CC Greg to explain. The backlight class didn't go away. The way it is 
> > handled is different.
> 
> Have a pointer to the patch so I can help explain better?

You've been cc'd on the proposed patch a couple of times in this thread
so it should be in your mailbox now.

> As a short summary, 'struct class_device' is going away.  Using a
> 'struct device' in its place is what the conversion should have just
> done, no functionality change otherwise.

The backlight class is drivers/video/backlight/backlight.c and if I
understand things correctly what shows up in sysfs changes.

At the moment (as I understand the code which could be wrong), the
backlight functionality is tagged onto an existing device. Taking
drivers/video/backlight/corgi_bl.c as an example, the corgi_bl device
exists under /sys/devices/platform/corgi_bl with an associated struct
device. The backlight code then appends some magic to this to link in
some class attributes that show up under /sys/class/backlight. There is
only ever one device.

By replacing class_device_register() with device_create(), the proposed
patch appears to generate a second struct device with the original as
its parent. I'm not sure where it appears in /sys/devices? Having
another full blown struct device around makes me uneasy as wherever it
appears, we only have one device, not two.

If I had some kind of platform device which had an LED, backlight and
say battery component and registered with the three appropriate classes
would that mean four struct devices? Where under /sys/devices do they
each appear?

Also, it was mentioned that a parent struct device is a requirement and
this isn't the case for all backlight users. I think this constraint on
device_create has been removed in more recent code though? 

Richard

-
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: -mm merge plans for 2.6.21

[Andrew Morton]

On Fri, 9 Feb 2007 00:29:06 +0100 (MET)
Jan Engelhardt <[EMAIL PROTECTED]> wrote:

> 
> On Feb 8 2007 15:07, Andrew Morton wrote:
> 
> >scheduled-removal-of-sa_xxx-interrupt-flags-fixups.patch
> >scheduled-removal-of-sa_xxx-interrupt-flags-fixups-2.patch
> >scheduled-removal-of-sa_xxx-interrupt-flags.patch
> >scheduled-removal-of-sa_xxx-interrupt-flags-ata-fix.patch
> >
> > This removes SA_INTERRUPT and friends, so 1000 external drivers won't
> > compile any more.  I think I'd prefer to find a way to get usage of SA_* to
> > spit a deprecated warning.
> 
> Here's an idea:
> 
> #define SA_INTERRUPT sa_interrupt_with_warning()
> static inline int sa_interrupt_with_warning(void) {
> if(more_or_less_often)
> printk(fat_warning);
> return 0x123456; /* whatever numerical value it is */
> }
> 

Yeah, this seems to work.

--- a/include/linux/interrupt.h~deprecate-sa_interrupt-and-friends
+++ a/include/linux/interrupt.h
@@ -54,17 +54,32 @@
  * Migration helpers. Scheduled for removal in 1/2007
  * Do not use for new code !
  */
-#define SA_INTERRUPT   IRQF_DISABLED
-#define SA_SAMPLE_RANDOM   IRQF_SAMPLE_RANDOM
-#define SA_SHIRQ   IRQF_SHARED
-#define SA_PROBEIRQIRQF_PROBE_SHARED
-#define SA_PERCPU  IRQF_PERCPU
-
-#define SA_TRIGGER_LOW IRQF_TRIGGER_LOW
-#define SA_TRIGGER_HIGHIRQF_TRIGGER_HIGH
-#define SA_TRIGGER_FALLING IRQF_TRIGGER_FALLING
-#define SA_TRIGGER_RISING  IRQF_TRIGGER_RISING
-#define SA_TRIGGER_MASKIRQF_TRIGGER_MASK
+#define emit_old_interrupt_name(old, new)  \
+static inline unsigned __deprecated emit_old_interrupt_name##old(void) \
+{  \
+   return (new);   \
+}
+
+emit_old_interrupt_name(SA_INTERRUPT, IRQF_DISABLED)
+#define SA_INTERRUPT emit_old_interrupt_nameSA_INTERRUPT()
+emit_old_interrupt_name(SA_SAMPLE_RANDOM, IRQF_SAMPLE_RANDOM)
+#define SA_SAMPLE_RANDOM emit_old_interrupt_nameSA_SAMPLE_RANDOM()
+emit_old_interrupt_name(SA_SHIRQ, IRQF_SHARED)
+#define SA_SHIRQ emit_old_interrupt_nameSA_SHIRQ()
+emit_old_interrupt_name(SA_PROBEIRQ, IRQF_PROBE_SHARED)
+#define SA_PROBEIRQ emit_old_interrupt_nameSA_PROBEIRQ()
+emit_old_interrupt_name(SA_PERCPU, IRQF_PERCPU)
+#define SA_PERCPU emit_old_interrupt_nameSA_PERCPU()
+emit_old_interrupt_name(SA_TRIGGER_LOW, IRQF_TRIGGER_LOW)
+#define SA_TRIGGER_LOW emit_old_interrupt_nameSA_TRIGGER_LOW()
+emit_old_interrupt_name(SA_TRIGGER_HIGH, IRQF_TRIGGER_HIGH)
+#define SA_TRIGGER_HIGH emit_old_interrupt_nameSA_TRIGGER_HIGH()
+emit_old_interrupt_name(SA_TRIGGER_FALLING, IRQF_TRIGGER_FALLING)
+#define SA_TRIGGER_FALLING emit_old_interrupt_nameSA_TRIGGER_FALLING()
+emit_old_interrupt_name(SA_TRIGGER_RISING, IRQF_TRIGGER_RISING)
+#define SA_TRIGGER_RISING emit_old_interrupt_nameSA_TRIGGER_RISING()
+emit_old_interrupt_name(SA_TRIGGER_MASK, IRQF_TRIGGER_MASK)
+#define SA_TRIGGER_MASK emit_old_interrupt_nameSA_TRIGGER_MASK()
 
 typedef irqreturn_t (*irq_handler_t)(int, void *);
 
_

For some reason

enum foo {
...
} __deprecated;

doesn't work.
-
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 backlight subsystem tree

[Greg KH]

On Thu, Feb 08, 2007 at 09:54:21PM +, James Simmons wrote:
> 
> > On Thu, Feb 08, 2007 at 06:32:02PM +, James Simmons wrote:
> > > On Thu, 8 Feb 2007, Richard Purdie wrote:
> > > 
> > > > On Thu, 2007-02-08 at 15:28 +, James Simmons wrote:
> > > > > I have some patches that move the backlight away from using the class 
> > > > > stuff. The only problem is the patch requires all backlight devices 
> > > > > to be linked to a real struct device. Right now the acpi backligths 
> > > > > are 
> > > > > not.
> > > > 
> > > > Why would you want to do that?
> > > > 
> > > > The whole point of having this is so that backlights appear as a
> > > > standard interface under /sys/class/backlight.
> > > > 
> > > > An example of why standardised interfaces are good would be someone
> > > > writing an applet for a handheld to control the backlight brightness.
> > > > With the class in place, the applet can easily work with any backlight.
> > > > Without it, it has to be written for each backlight.
> > > > 
> > > > So this is a very strong NAK but I'm curious why you'd want to do it...
> > > 
> > > I CC Greg to explain. The backlight class didn't go away. The way it is 
> > > handled is different.
> > 
> > Have a pointer to the patch so I can help explain better?
> > 
> > As a short summary, 'struct class_device' is going away.  Using a
> > 'struct device' in its place is what the conversion should have just
> > done, no functionality change otherwise.
> 
> diff --git a/drivers/video/backlight/backlight.c 
> b/drivers/video/backlight/backlight.c



Looks good to me.  And it makes the code simpler too :)

thanks,

greg k-h
-
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: somebody dropped a (warning) bomb

[Linus Torvalds]

On Thu, 8 Feb 2007, David Rientjes wrote:
> 
> And a compiler that makes a_variable.flag unsigned would be brain-dead 
> because "int" is always signed.

No, making bitfields unsigned is actually usually a good idea. It allows 
you to often generate better code, and it actually tends to be what 
programmers _expect_. A lot of people seem to be surprised to hear that a 
one-bit bitfield actually often encodes -1/0, and not 0/1.

So unsigned bitfields are not only traditional K&R, they are also usually 
_faster_ (which is probably why they are traditional K&R - along with 
allowing "char" to be unsigned by default). Don't knock them.  It's much 
better to just remember that bitfields simply don't _have_ any standard 
sign unless you specify it explicitly, than saying "it should be signed 
because 'int' is signed".

I will actually argue that having signed bit-fields is almost always a 
bug, and that as a result you should _never_ use "int" at all. Especially 
as you might as well just write it as

signed a:1;

if you really want a signed bitfield.

So I would reall yrecommend that you never use "int a:" AT ALL, 
because there really is never any good reason to do so. Do it as

unsigned a:3;
signed b:2;

but never 

int c:4;

because the latter really isn't sensible.

"sparse" will actually complain about single-bit signed bitfields, and it 
found a number of cases where people used that "int x:1" kind of syntax. 

Just don't do it.

Linus
-
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: finger @finger.kernel.org -> Connection refused

[Justin Piszcz]

On Fri, 9 Feb 2007, Jan Engelhardt wrote:




It appears to have been dead for awhile now, did I miss something?
One of my scripts uses this functionality, which now appears
dead/disabled/offline.

Can anyone provide an update?


kernel.org front page sayz:

Aug 21, 2003: Please don't use finger.kernel.org for any sort of
automatic monitoring. The number of automatic bots hitting this port is
causing the finger daemon to shut down more often than not. The same
information is available from http://www.kernel.org/kdist/finger_banner.

;-)


Jan
--
ft: http://freshmeat.net/p/chaostables/



Thanks!

$ wget -q -O- http://www.kernel.org/kdist/finger_banner
The latest stable version of the Linux kernel is:   2.6.20
The latest snapshot for the stable Linux kernel tree is:2.6.20-git1
The latest 2.4 version of the Linux kernel is:  2.4.34.1
The latest 2.2 version of the Linux kernel is:  2.2.26
The latest prepatch for the 2.2 Linux kernel tree is:   2.2.27-rc2
The latest -mm patch to the stable Linux kernels is:2.6.20-rc6-mm3

Wget it is.

Justin.

-
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: finger @finger.kernel.org -> Connection refused

[Jan Engelhardt]

> It appears to have been dead for awhile now, did I miss something?
> One of my scripts uses this functionality, which now appears
> dead/disabled/offline.
>
> Can anyone provide an update?

kernel.org front page sayz:

Aug 21, 2003: Please don't use finger.kernel.org for any sort of 
automatic monitoring. The number of automatic bots hitting this port is 
causing the finger daemon to shut down more often than not. The same 
information is available from http://www.kernel.org/kdist/finger_banner.

;-)


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

Re: [2.6.20] tifm_7xx1/mmc not working

[Alex Dubov]

I'm aware that there are some weird problems with a 2.6.20. I'm currently 
looking into it.

Besides, I wonder, are tifm and sdhci play nicely together? And then, we do 
know that suspend is
totally broken in the older versions of the driver. So it may be desirable to 
make a test with
sdhci unloaded and machine freshly rebooted (not resumed).


--- Pierre Ossman <[EMAIL PROTECTED]> wrote:

> Alex Dubov is the maintainer of tifm, not me.
> 
> Andreas Steinmetz wrote:
> > Hi,
> > I do have a problem with tifm_7xx1 and 2.6.20. First of all, the device
> > is working with 2.6.18.2 and the out of tree tifm-0.6 release. In this
> > case except for the first card insertion after suspend/reboot I do get
> > the following messages:
> > 
> > tifm_7xx1: sd card detected in socket 3
> > mmcblk0: mmc0:7d7f SD01G 1006080KiB
> >  mmcblk0: p1
> > 
> > With 2.6.20, however, I always do get only the following which is the
> > same as for 2.6.18.2 on first card insert after reboot/suspend:
> > 
> > tifm_7xx1: sd card detected in socket 3
> > 
> > Am I doing something wrong here or is there a problem?
> > 
> > Relevant modules loaded with 2.6.20:
> > 
> > mmc_block   7944  0
> > tifm_sd10824  0
> > tifm_7xx1   7296  0
> > sdhci  17548  0
> > tifm_core   7960  2 tifm_sd,tifm_7xx1
> > mmc_core   24096  3 mmc_block,tifm_sd,sdhci
> > 
> 
> Rgds
> -- 
>  -- Pierre Ossman
> 
>   Linux kernel, MMC maintainerhttp://www.kernel.org
>   PulseAudio, core developer  http://pulseaudio.org
>   rdesktop, core developer  http://www.rdesktop.org
> 



 

Cheap talk?
Check out Yahoo! Messenger's low PC-to-Phone call rates.
http://voice.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: -mm merge plans for 2.6.21

[Kyle McMartin]

On Thu, Feb 08, 2007 at 03:07:10PM -0800, Andrew Morton wrote:
> I'm getting fed up of holding onto hundreds of patches against subsystem
> trees, sending them over and over again seeing and nothing happen.  I sent 242
> patches out to subsystem maintainers on Monday and look at what's still here.
> 
> parisc-fix-module_param-iommu-permission.patch
> pa-risc-fix-bogus-warnings-from-modpost.patch
> use-__u64-rather-than-u64-in-parisc-statfs-structs.patch
> 
>  -> kyle
> 

Sorry, I thought the mails meant you were dumping to Linus. Will
merge.
-
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] drivers/isdn/gigaset: new M101 driver (v2)

[Tilman Schmidt]

This patch adds the line discipline based driver for the Gigaset M101
wireless RS232 adapter. It also improves the documentation a bit.

Signed-off-by: Tilman Schmidt <[EMAIL PROTECTED]>
Signed-off-by: Hansjoerg Lipp <[EMAIL PROTECTED]>

---

This is the second version, improved thanks to the Andrew Morton's
comments on the first one. It is still based on 2.6.20-rc6-mm3 and
depends on consolidate-line-discipline-number-definitions-v2*.patch
in the -mm tree. Please consider for the 2.6.21 queue.

 Documentation/isdn/README.gigaset  |   65 ++
 drivers/isdn/gigaset/Kconfig   |   25 -
 drivers/isdn/gigaset/Makefile  |2 
 drivers/isdn/gigaset/asyncdata.c   |5 
 drivers/isdn/gigaset/common.c  |   20 
 drivers/isdn/gigaset/ev-layer.c|2 
 drivers/isdn/gigaset/ser-gigaset.c |  837 +
 include/linux/gigaset_dev.h|2 
 8 files changed, 916 insertions(+), 42 deletions(-)

diff -purNX dont-diff base/Documentation/isdn/README.gigaset 
local/Documentation/isdn/README.gigaset
--- base/Documentation/isdn/README.gigaset  2006-11-29 22:57:37.0 
+0100
+++ local/Documentation/isdn/README.gigaset 2007-01-20 20:40:43.0 
+0100
@@ -8,29 +8,33 @@ GigaSet 307x Device Driver
  This release supports the connection of the Gigaset 307x/417x family of
  ISDN DECT bases via Gigaset M101 Data, Gigaset M105 Data or direct USB
  connection. The following devices are reported to be compatible:
- 307x/417x:
-Gigaset SX255isdn
-Gigaset SX353isdn
-Sinus 45 [AB] isdn (Deutsche Telekom)
-Sinus 721X/XA
+
+ Bases:
+Siemens Gigaset 3070/3075 isdn
+Siemens Gigaset 4170/4175 isdn
+Siemens Gigaset SX205/255
+Siemens Gigaset SX353
+T-Com Sinus 45 [AB] isdn
+T-Com Sinus 721X[A] [SE]
 Vox Chicago 390 ISDN (KPN Telecom)
- M101:
-Sinus 45 Data 1 (Telekom)
- M105:
-Gigaset USB Adapter DECT
-Sinus 45 Data 2 (Telekom)
-Sinus 721 data
+
+ RS232 data boxes:
+Siemens Gigaset M101 Data
+T-Com Sinus 45 Data 1
+
+ USB data boxes:
+Siemens Gigaset M105 Data
+Siemens Gigaset USB Adapter DECT
+T-Com Sinus 45 Data 2
+T-Com Sinus 721 data
 Chicago 390 USB (KPN)
+
  See also http://www.erbze.info/sinus_gigaset.htm and
   http://gigaset307x.sourceforge.net/
 
  We had also reports from users of Gigaset M105 who could use the drivers
  with SX 100 and CX 100 ISDN bases (only in unimodem mode, see section 
2.4.)
  If you have another device that works with our driver, please let us know.
- For example, Gigaset SX205isdn/Sinus 721 X SE and Gigaset SX303isdn bases
- are just versions without answering machine of models known to work, so
- they should work just as well; but so far we are lacking positive reports
- on these.
 
  Chances of getting an USB device to work are good if the output of
 lsusb
@@ -60,14 +64,28 @@ GigaSet 307x Device Driver
  To get the device working, you have to load the proper kernel module. You
  can do this using
  modprobe modulename
- where modulename is usb_gigaset (M105) or bas_gigaset (direct USB
- connection to the base).
+ where modulename is ser_gigaset (M101), usb_gigaset (M105), or
+ bas_gigaset (direct USB connection to the base).
+
+ The module ser_gigaset provides a serial line discipline N_GIGASET_M101
+ which drives the device through the regular serial line driver. To use it,
+ run the Gigaset M101 daemon "gigasetm101d" (also available from
+ http://sourceforge.net/projects/gigaset307x/) with the device file of the
+ RS232 port to the M101 as an argument, for example:
+gigasetm101d /dev/ttyS1
+ This will open the device file, set its line discipline to N_GIGASET_M101,
+ and then sleep in the background, keeping the device open so that the
+ line discipline remains active. To deactivate it, kill the daemon, for
+ example with
+killall gigasetm101d
+ before disconnecting the device.
 
 2.2. Device nodes for user space programs
  
  The device can be accessed from user space (eg. by the user space tools
  mentioned in 1.2.) through the device nodes:
 
+ - /dev/ttyGS0 for M101 (RS232 data boxes)
  - /dev/ttyGU0 for M105 (USB data boxes)
  - /dev/ttyGB0 for the base driver (direct USB connection)
 
@@ -168,6 +186,19 @@ GigaSet 307x Device Driver
  You can also use /sys/class/tty/ttyGxy/cidmode for changing the CID mode
  setting (ttyGxy is ttyGU0 or ttyGB0).
 
+2.6. M105 Undocumented USB Requests
+ --
+
+ The Gigaset M105 USB data box understands a couple of useful, but
+ undocumented USB commands. These requests are not used in normal
+ operation (for wireless access to the base), but

Re: finger @finger.kernel.org -> Connection refused

[Kyle McMartin]

On Thu, Feb 08, 2007 at 06:27:17PM -0500, Justin Piszcz wrote:
> It appears to have been dead for awhile now, did I miss something?
> One of my scripts uses this functionality, which now appears 
> dead/disabled/offline.
> 

Why not use this instead?
http://www.kernel.org/kdist/finger_banner
-
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: -mm merge plans for 2.6.21

[Jan Engelhardt]

On Feb 8 2007 15:07, Andrew Morton wrote:

>scheduled-removal-of-sa_xxx-interrupt-flags-fixups.patch
>scheduled-removal-of-sa_xxx-interrupt-flags-fixups-2.patch
>scheduled-removal-of-sa_xxx-interrupt-flags.patch
>scheduled-removal-of-sa_xxx-interrupt-flags-ata-fix.patch
>
> This removes SA_INTERRUPT and friends, so 1000 external drivers won't
> compile any more.  I think I'd prefer to find a way to get usage of SA_* to
> spit a deprecated warning.

Here's an idea:

#define SA_INTERRUPT sa_interrupt_with_warning()
static inline int sa_interrupt_with_warning(void) {
if(more_or_less_often)
printk(fat_warning);
return 0x123456; /* whatever numerical value it is */
}


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

[PATCH 2.6.20] r8169.c: support RTL8169SC/8110SC

[Edward Hsu]

This patch is for /driver/net/r8169.c to support RTL8169SC/8110SC,
which is a new Realtek Gigabit PCI Ethernet Controller. RTL8110SC's PCI DID
is 0x8167, while RTL8110S and RTL8110SB share 0x8169.

Signed-off-by: Edward Hsu <[EMAIL PROTECTED]>
--

--- ./drivers/net/r8169_n.c 2007-02-09 01:12:43.0 +0800
+++ ./drivers/net/r8169.c 2007-02-05 02:44:54.0 +0800
@@ -1,29 +1,4 @@
 /*
-
-#
-# Copyright(c) 1999 - 2007 Realtek Semiconductor Corp. All rights reserved.
-#
-# This program is free software; you can redistribute it and/or modify it
-# under the terms of the GNU General Public License as published by the 
Free
-# Software Foundation; either version 2 of the License, or (at your option)
-# any later version.
-#
-# This program is distributed in the hope that it will be useful, but 
WITHOUT
-# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
-# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
-# more details.
-#
-# You should have received a copy of the GNU General Public License along 
with
-# this program; if not, write to the Free Software Foundation, Inc., 59
-# Temple Place - Suite 330, Boston, MA  02111-1307, USA.
-#
-# The full GNU General Public License is included in this distribution in 
the
-# file called LICENSE.
-#
-
-*/
-
-/*
 =
  r8169.c: A RealTek RTL-8169 Gigabit Ethernet driver for Linux kernel 
2.4.x.
  
@@ -76,7 +51,6 @@ VERSION 2.2LK <2005/01/25>
  */

 #include 
-#include 
 #include 
 #include 
 #include 
@@ -95,15 +69,13 @@ VERSION 2.2LK <2005/01/25>
 #include 
 #include 

-#define NODE_ADDRESS_SIZE 6
-
 #ifdef CONFIG_R8169_NAPI
 #define NAPI_SUFFIX "-NAPI"
 #else
 #define NAPI_SUFFIX ""
 #endif

-#define RTL8169_VERSION "6.001.00" NAPI_SUFFIX
+#define RTL8169_VERSION "2.2LK" NAPI_SUFFIX
 #define MODULENAME "r8169"
 #define PFX MODULENAME ": "

@@ -137,12 +109,8 @@ VERSION 2.2LK <2005/01/25>

 /* media options */
 #define MAX_UNITS 8
-static int speed[MAX_UNITS] = { -1, -1, -1, -1, -1, -1, -1, -1 };
-static int num_speed = 0;
-static int duplex[MAX_UNITS] = { -1, -1, -1, -1, -1, -1, -1, -1 };
-static int num_duplex = 0;
-static int autoneg[MAX_UNITS] = { -1, -1, -1, -1, -1, -1, -1, -1 };
-static int num_autoneg = 0;
+static int media[MAX_UNITS] = { -1, -1, -1, -1, -1, -1, -1, -1 };
+static int num_media = 0;

 /* Maximum events (Rx packets, etc.) to handle at each interrupt. */
 static const int max_interrupt_work = 20;
@@ -155,8 +123,8 @@ static const int multicast_filter_limit
 #define MAC_ADDR_LEN 6

 #define RX_FIFO_THRESH 7 /* 7 means NO threshold, Rx buffer level before 
first PCI xfer. */
-#define RX_DMA_BURST 7 /* Maximum PCI burst, '7' is unlimited */
-#define TX_DMA_BURST 7 /* Maximum PCI burst, '7' is unlimited */
+#define RX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */
+#define TX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */
 #define EarlyTxThld  0x3F /* 0x3F means NO early transmit */
 #define RxPacketMaxSize 0x3FE8 /* 16K - 1 - ETH_HLEN - VLAN - CRC... */
 #define SafeMtu  0x1c20 /* ... actually life sucks beyond ~7k */
@@ -182,12 +150,16 @@ static const int multicast_filter_limit
 #define RTL_R32(reg)  ((unsigned long) readl (ioaddr + (reg)))

 enum mac_version {
- RTL_GIGA_MAC_VER_8169 = 0x00,
- RTL_GIGA_MAC_VER_8169S = 0x01,
- RTL_GIGA_MAC_VER_8110S = 0x02,
- RTL_GIGA_MAC_VER_8169SB = 0x04,
- RTL_GIGA_MAC_VER_8110SCd = 0x05,
- RTL_GIGA_MAC_VER_8110SCe = 0x06,
+ RTL_GIGA_MAC_VER_01 = 0x00,
+ RTL_GIGA_MAC_VER_02 = 0x01,
+ RTL_GIGA_MAC_VER_03 = 0x02,
+ RTL_GIGA_MAC_VER_04 = 0x03,
+ RTL_GIGA_MAC_VER_05 = 0x04,
+ RTL_GIGA_MAC_VER_11 = 0x0b,
+ RTL_GIGA_MAC_VER_12 = 0x0c,
+ RTL_GIGA_MAC_VER_13 = 0x0d,
+ RTL_GIGA_MAC_VER_14 = 0x0e,
+ RTL_GIGA_MAC_VER_15 = 0x0f
 };

 enum phy_version {
@@ -207,12 +179,16 @@ static const struct {
  u8 mac_version;
  u32 RxConfigMask; /* Clears the bits supported by this chip */
 } rtl_chip_info[] = {
- _R("RTL8169", RTL_GIGA_MAC_VER_8169, 0xff7e1880),
- _R("RTL8169S/8110S", RTL_GIGA_MAC_VER_8169S, 0xff7e1880),
- _R("RTL8169S/8110S", RTL_GIGA_MAC_VER_8110S, 0xff7e1880),
- _R("RTL8169SB/8110SB", RTL_GIGA_MAC_VER_8169SB, 0xff7e1880),
- _R("RTL8169SC/8110SC", RTL_GIGA_MAC_VER_8110SCd, 0xff7e1880),
- _R("RTL8169SC/8110SC", RTL_GIGA_MAC_VER_8110SCe, 0xff7e1880),
+ _R("RTL8169",  RTL_GIGA_MAC_VER_01, 0xff7e1880),
+ _R("RTL8169s/8110s", RTL_GIGA_MAC_VER_02, 0xff7e1880),
+ _R("RTL8169s/8110s", RTL_GIGA_MAC_VER_03, 0xff7e1880),
+ _R("RTL8169sb/8110sb", RTL_GIGA_MAC_VER_04, 0xff7e1880),
+ _R("RTL8169sc/8110sc", RTL_GIGA_MAC_VER_05, 0xff7e1880),
+ _R("RTL8168b/8111b", RTL_GIGA_MAC_VER_11, 0xff7e1880), // PCI-E
+ _R("RTL

finger @finger.kernel.org -> Connection refused

[Justin Piszcz]

It appears to have been dead for awhile now, did I miss something?
One of my scripts uses this functionality, which now appears 
dead/disabled/offline.


Can anyone provide an update?

Thanks,

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

Re: [PATCH 1/2] Video: fb, add true ref_count atomicity

[Denis Oliver Kropp]

Jiri Slaby wrote:

video/fb, add true ref_count atomicity

Some of fb drivers uses atomic_t in bad manner, since there are still some
race-prone gaps. Use mutexes to protect open/close code sections with
ref_count testing and finally use simple uint.

Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>


Acked-by: Denis Oliver Kropp <[EMAIL PROTECTED]>

--
Best regards,
  Denis Oliver Kropp

.--.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
'--'
-
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/

Sata_via problems in a Vintage2-AE1

[Leopold Palomo Avellaneda]

Dear people,

I have a barebone Asus Vintage2-AE1 [1]. This box has a mobo Asus A8V-MQ. The 
board has:
- the Socket 939 for AMD Athlon 64FX/Athlon 64.
- North Bridge: VIA K8M800  
- South Bridge: VIA VT8251
- VIA Graphics Integrated
- IDE 2 x UltraDMA 133
- 4 x Serial ATA
...

I'm using the bios version 0206. The 0210 doesn't show me the vga card, so I 
don't have graphics mode. I think that is a buggy bios.

The bios is configured with vt8251 in AHCI mode and bios boot up activated, so 
the hd is recognized in the beginning. I don't have any raid, only one hd. 
The hd is a Maxtor 6V250F0.

I'm using a debian etch but the i386 version. The only way that I can use the 
hd is using a 2.6.16 standard kernel with the modifications explained in this 
page [2]. Basically you have to use their ahci.c and sata_via.c. The 
modifications are small from the original code from Mr Jeff Garzik.

I have tried to use the 2.6.18 and 2.6.20rc6 and the result is the same. The  
kernel boots, but when arrives at the ata3, 

scsi2 : ahci
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: qc timeout (cmd 0xec)
ata3.00: failed to IDENTIFY (I/O error, err_mask=0x104)
 repeated some times ...
scsi3 : ahci
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
scsi4 : ahci
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
scsi5 : ahci
ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Done.
Begin: Mounting root file system... ...
Begin: Running /scripts/local-top
ide0: I/O resource 0x3F6-0x3F6 not free.
ide0: ports already in use, skipping probe.
ide1: I/O resource 0x376-0x376 not free.
ide1: ports already in use, skipping probe.
Done.
Begin: Waiting for root file system ...

.

but the /dev/sda doesn't exist so I cannot boot.

using the 2.6.16 with lspci -M I obtain the info attached below. Please, could 
you look on it?

Best regards,

thanks in advance,

Leo


[1] http://www.asus.com/products4.aspx?l1=1&l2=1&l3=381&model=1001&modelmenu=1
[2] http://www.geocities.com/rajahuroman/main.html

lspci -M output:
--
00:00.0 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge
00:00.1 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge
00:00.2 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge
00:00.3 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge
00:00.4 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge
00:00.7 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 
South]
## 00.01:0 is a bridge from 00 to 01-01
00:0f.0 SATA controller: VIA Technologies, Inc. VT8251 AHCI/SATA 4-Port 
Controller
00:0f.1 IDE interface: VIA Technologies, Inc. 
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 07)
00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 
Controller (rev 90)
00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 
Controller (rev 90)
00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 
Controller (rev 90)
00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 
Controller (rev 90)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 90)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8251 PCI to ISA Bridge
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 
AC97 Audio Controller (rev 70)
00:11.7 Host bridge: VIA Technologies, Inc. VT8251 Ultra VLINK Controller
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 7c)
00:13.0 PCI bridge: VIA Technologies, Inc. VT8251 Host Bridge
## 00.13:0 is a bridge from 00 to 02-04
00:13.1 PCI bridge: VIA Technologies, Inc. VT8251 PCI to PCI Bridge
## 00.13:1 is a bridge from 00 to 05-05
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM 
Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Miscellaneous Control
01:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6200] (rev 
a1)
02:00.0 PCI bridge: VIA Technologies, Inc. VT8251 PCIE Root Port
## 02.00:0 is a bridge from 02 to 03-03
02:00.1 PCI bridge: VIA Technologies, Inc. VT8251 PCIE Root Port
## 02.00:1 is a bridge from 02 to 04-04

Summary of buses:

00: Primary host bus
13.1 Bridge to 05-05
13.0 Bridge to 02-04
01.0 Bridge to 01-01
01: Entered via 00:01.0
02: Entered via 00:13.0
00.1 Bridge to 04-04
00.0 Bridge to 03-03
--


-- 
--
Linux User 152692
Catalonia
-
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

Re: The who needs reviews anyways [PATCH]

[Roman Zippel]

Hi,

On Thu, 8 Feb 2007, Linus Torvalds wrote:

> On Thu, 8 Feb 2007, Roman Zippel wrote:
> 
> > I don't quite understand, the Makefile doesn't care anymore about /bin/sh 
> > with this patch, the Makefile checks only for $BASH and /bin/bash 
> 
> Exactly. 
> 
> The point is, neither $BASH nor /bin/bash may be set.

Is that really a problem? I think any system that has bash without 
/bin/bash is simply broken.

> If you run make while running tcsh, "BASH" won't be set. We've always just 
> defaulted to doing /bin/sh. Doesn't really seem to be a problem.

There are chances this is already broken anyway. We call external scripts 
using $(shell $(CONFIG_SHELL) ...), which ignores the "#! ..." setting.

bye, Roman
-
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: -mm merge plans for 2.6.21

[Roland Dreier]

 > infiniband-work-around-gcc-bug-on-sparc64.patch
 > ehca-fix-memleak-on-module-unloading.patch

 >  -> roland

Sorry, I misunderstood your email.  I thought it was just a CC of
stuff you were already merging.  I will handle these patches.

 - R.
-
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: somebody dropped a (warning) bomb

[David Rientjes]

On Thu, 8 Feb 2007, Linus Torvalds wrote:

> Same goes for
> 
>   struct dummy {
>   int flag:1;
>   } a_variable;
> 
> which could make "a_variable.d" be either signed or unsigned. In the 
> absense of an explicit "signed" or "unsigned" by the programmer, you 
> really won't even _know_ whether "flag" can contain the values {0,1} or 
> {-1,0}.
> 
> Normally you wouldn't ever even care. A one-bit bitfield would only ever 
> really be tested against 0, but it really is possible that when you assign 
> "1" to that value, and read it back, it will read back -1. Try it. 
> 
> Those are the three only types I can think of, but the point is, they 
> really don't have any standard-defined sign. It's up to the compiler. 
> 

And a compiler that makes a_variable.flag unsigned would be brain-dead 
because "int" is always signed.  The signed specifier is only useful for 
forcing chars to carry a sign and it's redundant with any other types.  
Using bitfields requires the knowledge of the sign bit in twos-complement 
just like when you use a signed qualifier for any other definition.  
Having inconsistent behavior on whether it is unsigned or signed based on 
how large the bitfield is (i.e. one bit compared to multiple bits) is 
inappropriate.
-
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/

-mm merge plans for 2.6.21

[Andrew Morton]

I'm getting fed up of holding onto hundreds of patches against subsystem
trees, sending them over and over again seeing and nothing happen.  I sent 242
patches out to subsystem maintainers on Monday and look at what's still here.



rtc-pcf8563-detect-polarity-of-century-bit-automatically.patch
ufs-restore-back-support-of-openstep.patch
hugetlb-preserve-hugetlb-pte-dirty-state.patch
md-fix-various-bugs-with-aligned-reads-in-raid5.patch
knfsd-fix-a-race-in-closing-nfsd-connections.patch
md-avoid-possible-bug_on-in-md-bitmap-handling.patch
v9fs_vfs_mkdir-fix-a-double-free.patch
enable-mouse-button-23-emulation-for-x86-macs.patch
mm-show-bounce-pages-in-oom-killer-output.patch
add-install_special_mapping.patch
i386-vdso-use-install_special_mapping.patch
x86_64-ia32-vdso-use-install_special_mapping.patch
powerpc-vdso-use-install_special_mapping.patch
sh-vdso-use-install_special_mappingpatch.patch

  Submitted.

x86-fix-vdso-mapping-for-aout-executables.patch

  a.out executables are presently non-functional.  This patch needs more work.

use-correct-macros-in-raid-code-not-raw-asm.patch
use-correct-macros-in-raid-code-not-raw-asm-include.patch

  -> neilb

acpi-bay-remove-acpi-driver-struct.patch
acpi-bay-driver-warning-fix.patch
acpi-i686-x86_64-fix-laptop-bootup-hang-in-init_acpi.patch
asus_acpi-add-support-for-asus-z81sp.patch
exit-acpi-processor-module-gracefully-if-acpi-is-disabled.patch
toshiba-acpi-use-array_size-macro-when-appropriate.patch
ifdef-acpi_future_usage-acpi_os_readable.patch

  -> lenb

agpgart-allow-drm-populated-agp-memory-types-tidy.patch

  -> davej

arm-imx-serial-fix-tx-buffer-overflows.patch
arm-imx-serial-fix-irq-allocation.patch
amba-pl010-add-reference-to-ep93xx-to-kconfig-help-entry.patch
at91-correct-value-for-at91_rstc_key.patch
arch-arm-use-array_size-macro-when-appropriate.patch

  -> rmk

avr32-fix-build-breakage.patch
arch-avr32-use-array_size-macro-when-appropriate.patch

  -> hskinnemoen

remove-hotplug-cpu-crap-from-cpufreq.patch
rewrite-lock-in-cpufreq-to-eliminate-cpufreq-hotplug-related-issues.patch
ondemand-governor-restructure-the-work-callback.patch
ondemand-governor-use-new-cpufreq-rwsem-locking-in-work-callback.patch
cpu_freq_table-shouldnt-be-a-def_tristate.patch

  -> davej

powerpc-rtas-msi-support.patch

  -> paulus, I guess.  The MSI people still need to argue about this.

fix-gregkh-driver-sys-modules-holders.patch
kobject-kobj-k_name-verification-fix.patch
spider-fix-gregkh-driver-network-device.patch
driver-core-per-subsystem-multithreaded-probing.patch
powerpc-make-it-compile.patch
driver-core-dont-fail-attaching-the-device-if-it.patch
fix-warning-in-device_add_attrs.patch

  -> gregkh

drivers-char-drm-drm_mmc-remove-unused-exports.patch
update-readmedrm-bugzilla-7933.patch
drm-use-array_size-macro-when-appropriate.patch

  -> airlied

avoid-race-when-deregistering-the-ir-control-for-dvb-usb.patch
kthread-api-conversion-for-dvb_frontend-and-av7110.patch
kthread-api-conversion-for-dvb_frontend-and-av7110-fix.patch

  -> mchehab

i2c-tsl2550-support.patch

  -> khali

infiniband-work-around-gcc-bug-on-sparc64.patch
ehca-fix-memleak-on-module-unloading.patch

  -> roland

crash-on-evdev-disconnect.patch
change-incorrect-config_input_atixl-to-config_mouse_atixl.patch
hil-small-fix.patch
wistron-button-support-for-fujitsu-siemens-amilo-d88x0.patch
setstream-param-for-psmouse.patch
input-schedule-removal-of-compaq-touchscreen.patch

  -> dtor

search-a-little-harder-for-mkimage.patch
make-mkcompile_h-use-lang=c-and-lc_all=c-for-cc-v.patch
add-mailmap-for-proper-git-shortlog-output.patch
qconf-immediately-update-integer-and-string-values-in-xconfig-display-take-2.patch
qconf-relocate-search-command.patch
qconf-fix-showing-help-info-on-failed-search.patch
qconf-back-button-behaviour-normalization.patch
kbuild-remove-references-to-deprecated-prepare-all-target.patch
new-toplevel-target-headers_check_all.patch

  kbuild stuff.  Will merge.

sis-warning-fixes.patch
libata-add-a-host-flag-to-indicate-lack-of-iordy.patch
git-libata-all-lib-iomapc-fix-for-config_pci=n.patch

  -> jeff

libata-fix-hopefully-all-the-remaining-problems-with.patch

  Hold.

git-md-accel-fixes.patch
git-md-accel-warning-fixes.patch

  -> dan.j.williams

mips-eisa-registration-with-config_eisa.patch
mips-turbochannel-update-to-the-driver-model.patch
mips-turbochannel-update-to-the-driver-model-fix.patch
mips-turbochannel-support-for-the-decstation.patch
mips-pmag-ba-fb-convert-to-the-driver-model.patch
mips-pmagb-b-fb-convert-to-the-driver-model.patch
mips-dec_esp-driver-model-for-the-pmaz-a.patch
mips-remove-smp_tune_scheduling.patch

  umm, not sure.  I thought Ralf was going to merge these but he got shy. 
  They'll get into 2.6.21 somehow.

mtd_ck804xrom-must-depend-on-pci.patch
mtd-add-missing-kernel-doc-item.patch

  -> dwmw2

8139too-force-media-setting-fix.patch
sundance-change-phy-address-search-from-phy=1-to-phy=0.patch
user-of-the-jiffies-rounding-code-e1000.patch
revert-driver

[PATCH 5/5] sysctl: Hide the sysctl proc inodes from selinux.

[Eric W. Biederman]

Since the security checks are applied on each read and write of a
sysctl file, just like they are applied when calling sys_sysctl, they
are redundant on the standard VFS constructs.  Since it is difficult
to compute the security labels on the standard VFS constructs we just
mark the sysctl inodes in proc private so selinux won't even bother
with them.

Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
 fs/proc/proc_sysctl.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
index bb16a1e..20e8cbb 100644
--- a/fs/proc/proc_sysctl.c
+++ b/fs/proc/proc_sysctl.c
@@ -47,6 +47,7 @@ static struct inode *proc_sys_make_inode(struct inode *dir, 
struct ctl_table *ta
inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME;
inode->i_op = &proc_sys_inode_operations;
inode->i_fop = &proc_sys_file_operations;
+   inode->i_flags |= S_PRIVATE; /* tell selinux to ignore this inode */
proc_sys_refresh_inode(inode, table);
 out:
return inode;
-- 
1.4.4.1.g278f

-
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] fs: add an iovec iterator

[Mark Fasheh]

Hi Nick,

On Thu, Feb 08, 2007 at 02:07:24PM +0100, Nick Piggin wrote:
> Add an iterator data structure to operate over an iovec. Add usercopy
> operators needed by generic_file_buffered_write, and convert that function
> over.

I really like this iterator structure - it brings together some fields that
seem to get passed around seperately, even though they're linked.

Also IMHO, it makes things in filemap.c easer to read...
--Mark

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