Re: [PATCH] Re: [NETPOLL] netconsole: fix soft lockup when removing module
On Tue, Jul 03, 2007 at 11:47:18PM -0700, David Miller wrote: ... > I plan to apply this patch, don't worry about it :) Now I'm really worried! Don't you evere sleep? Good night, Jarek P. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
> > That's why we have the problem of freezing the kernel threads or not. > > That problem is a symptom of the deeper conceptual problem, as is the > problem with FUSE. > > > You want to have all that pain for fuse? > > I'd certainly rather get the drivers right, and maybe have an > occasional deadlock if I miss something, than have a GUARANTEED > deadlock every time I suspend with a FUSE filesystem mounted (which is > pretty much every time, since I use encfs regularly). That's weird, I never had a suspend problem due to a fuse mount, though I have them all the time. And I suspect, that even the sync() thing that suspend does is not the real cause, because sync() actually does nothing in fuse filesystems. So there's something else going on, which obviously has to do with freezing user processes, but it's not clear what. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata_sil, writing bug with multiple cards?
On Wednesday 04 July 2007 05:53:30 Tejun Heo wrote: > [EMAIL PROTECTED] wrote: > > Apologies for the chain-replying to myself, just replying as I think of > > things to try. > > [EMAIL PROTECTED] writes: > >> Here's an odd data point. > >> I just broke that array, formatted all three of those partitions > >> seperately, mounted and did my ISO copy test. > >> All three drives, run one at a time, function fine. No corruption. > > > > Here's another odd one. I did the following: > > # Mount all 3 drives as individuals... > > mount /dev/sda1 /mnt/a > > mount /dev/sdb1 /mnt/b > > mount /dev/sdc1 /mnt/c > > # Copy the same file to all three drives at the same time > > cp KNOPPIX_V5.1.0CD-2006-12-30-EN.iso a/kn10.iso & > > cp KNOPPIX_V5.1.0CD-2006-12-30-EN.iso b/kn10.iso & > > cp KNOPPIX_V5.1.0CD-2006-12-30-EN.iso c/kn10.iso & > > Got massive corruption. > > Hmmm... I don't think this is sata_sil driver bug. cc'ing Andi Kleen > and lkml. Andi, the original thread can be read from > > http://thread.gmane.org/gmane.linux.ide/20213 It seems to be a 32bit system. There is no IOMMU. If it has >2GB or so it might be worth trying booting it with mem=2G and see if it goes away. However if it was the standard VIA DAC issue you should get problems even with a single interface, so probably that's not it either. Most likely it is some sort of hardware bug that we might not be able to do much about. Have you tried contacting SIL or VIA? e.g. if you have some other system with a different chipset it might be useful to test the SIL controllers in those. I would perhaps also try a newer kernel. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: [NETPOLL] netconsole: fix soft lockup when removing module
On Wed, Jul 04, 2007 at 08:41:59AM +0200, Jarek Poplawski wrote: ... > They were done on your request but it looks like Andrew > is waiting on something... Andrew, This time I'm not sorry for my English because I've just found I could speak "Chiefly Midland and Southern U.S.". Jarek P. - 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: [EXT4 set 3][PATCH 1/1] ext4 nanosecond timestamp
Aneesh Kumar K.V wrote:
Mingming Cao wrote:
On Tue, 2007-07-03 at 15:58 +0530, Kalpak Shah wrote:
On Sun, 2007-07-01 at 03:36 -0400, Mingming Cao wrote:
+
+#define EXT4_INODE_GET_XTIME(xtime, inode,
raw_inode) \
+do { \
+(inode)->xtime.tv_sec =
le32_to_cpu((raw_inode)->xtime); \
+if (EXT4_FITS_IN_INODE(raw_inode, EXT4_I(inode), xtime ##
_extra)) \
+ext4_decode_extra_time(&(inode)->xtime, \
+ raw_inode->xtime ## _extra); \
+} while (0)
+
+#define EXT4_EINODE_GET_XTIME(xtime, einode,
raw_inode) \
+do { \
+if (EXT4_FITS_IN_INODE(raw_inode, einode, xtime)) \
+(einode)->xtime.tv_sec =
le32_to_cpu((raw_inode)->xtime); \
+if (EXT4_FITS_IN_INODE(raw_inode, einode, xtime ##
_extra)) \
+ext4_decode_extra_time(&(einode)->xtime, \
+ raw_inode->xtime ## _extra); \
+} while (0)
+
This nanosecond patch seems to be missing the fix below which is
required for http://bugzilla.kernel.org/show_bug.cgi?id=5079
If the timestamp is set to before epoch i.e. a negative timestamp
then the file may have its date set into the future on 64-bit
systems. So when the timestamp is read it must be cast as signed.
Missed this one.
Thanks. Will update ext4 patch queue tonight with this fix.
IIRC in the conference call it was decided to not to apply this patch.
Andreas may be able to update better.
Looking at the git log i understand the core patch got applied to ext4 tree
with the comment
from Andreas. So may be we can apply this patch also.
commit 4d7bf11d649c72621ca31b8ea12b9c94af380e63
Andreas says:
This patch is now treating timestamps with the high bit set as negative
times (before Jan 1, 1970). This means we lose 1/2 of the possible range
of timestamps (lopping off 68 years before unix timestamp overflow -
now only 30 years away :-) to handle the extremely rare case of setting
timestamps into the distant past.
If we are only interested in fixing the underflow case, we could just
limit the values to 0 instead of storing negative values. At worst this
will skew the timestamp by a few hours for timezones in the far east
(files would still show Jan 1, 1970 in "ls -l" output).
That said, it seems 32-bit systems (mine at least) allow files to be set
into the past (01/01/1907 works fine) so it seems this patch is bringing
the x86_64 behaviour into sync with other kernels.
On the plus side, we have a patch that is ready to add nanosecond timestamps
to ext3 and as an added bonus adds 2 high bits to the on-disk timestamp so
this extends the maximum date to 2242.
NOTE: The conference call i mentioned above is http://ext4.wiki.kernel.org/index.php/Ext4_Developer%27s_Conference_Call
-aneesh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 5/5] s390 tlb flush fix.
On Tue, 2007-07-03 at 19:58 +0100, Hugh Dickins wrote:
> On Tue, 3 Jul 2007, Martin Schwidefsky wrote:
> > +
> > +static inline struct mmu_gather *tlb_gather_mmu(struct mm_struct *mm,
> > + unsigned int full_mm_flush)
> > +{
> > + struct mmu_gather *tlb = &get_cpu_var(mmu_gathers);
> > +
> > + tlb->mm = mm;
> > + tlb->fullmm = full_mm_flush || (num_online_cpus() == 1) ||
> > + (atomic_read(&mm->mm_users) <= 1);
> > + tlb->nr_ptes = 0;
> > + tlb->nr_pmds = TLB_NR_PTRS;
> > + if (tlb->fullmm)
> > + __tlb_flush_mm(mm);
> > + return tlb;
> > +}
>
> I'm afraid that mm_users test (and probably some of your other
> mm_users tests) is not good: because this also gets called when
> a file is truncated while it is mapped - the active mm at that
> time is likely not to be one of the mm_users. (Do any other
> arches use mm_users in that way? No: that should be a warning.)
Good catch, that would have caused me some headache. So I need to add a
current->active_mm==mm check if mm_users==1.
> You might do better to make more use of cpu_vm_mask (though I
> didn't see where any bits get cleared from it on s390 at present).
We don't clear any of the bits in cpu_vm_mask. I though about it for a
while and got tangled in race conditions. The cpu_vm_mask optimization
works for short-lived processes which always executed on the same cpu.
> Though it seems sensible to aim for one TLB flush at the beginning
> as you're doing, that's not what other arches do (some have to
> worry about speculative execution, but you don't?), and it
> worries me that you're taking s390 further away into its own
> implementation: which you're surely entitled to do, but then
> we're more likely to screw you over by mistake in future.
We do not have to worry about speculative execution because s390 uses
special instruction to do user access (mvcs, mvcp and mvcos) and the
kernel has its own address space. The compiler doesn't know about these
instruction and cannot "accidentally" access a user space address over
the user page table when it shouldn't.
> Is there perhaps another architecture whose procedures you
> can copy? Changing a pte while another cpu is accessing it
> is not a problem unique to s390.
No, I don't think so. s390 is quite unique with the restriction that you
may not do a set_pte_at .. flush_tlb_xxx while a pte might get accessed
by a different cpu.
> Patches 1-4 looked fine to me, but I believe this 5/5
> is the rationale behind all of them.
Yes, indeed the tlb flush fix and the 1K/2K page tables are my reasons
for all these patches.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
-
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 3/3] ACPI autoloading - Create __mod_acpi_device_table symbol for all acpi drivers.
On Tue, Jul 03, 2007 at 03:15:33AM -0400, Len Brown wrote:
>
> > BTW: I also saw a laptop (IIRC it was a sony) with asus and sony ACPI
> > device.
> > When both drivers got loaded things broke.
> > A solution was to only let the asus driver get active if the device is
> > known. Currently, not sure whether still (I sent a patch a while ago),
> > the Asus driver falls back to a default ("M6N"?) configuration. IMO this
> > is a bit too dangerous and instead a message like "unsupported ASUS
> > model found, please send acpidump to [EMAIL PROTECTED]".
>
> This is pretty scary.
> Can you drop the acpidump output into a bugzilla?
and add myself to the cc-list?
thanks
--
mattia
:wq!
-
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/5] avoid tlb gather restarts.
On Tue, 2007-07-03 at 18:42 +0100, Hugh Dickins wrote: > > If need_resched() is false in the inner loop of unmap_vmas it is > > unnecessary to do a full blown tlb_finish_mmu / tlb_gather_mmu for > > each ZAP_BLOCK_SIZE ptes. Do a tlb_flush_mmu() instead. That gives > > architectures with a non-generic tlb flush implementation room for > > optimization. The tlb_flush_mmu primitive is a available with the > > generic tlb flush code, the ia64_tlb_flush_mm needs to be renamed > > and a dummy function is added to arm and arm26. > > > > Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]> > > Acked-by: Hugh Dickins <[EMAIL PROTECTED]> > > (Looking at it, I see that we could argue that there ought to be a > need_resched() etc. check after your tlb_flush_mmu() in unmap_vmas, > in case it's spent a long while in there on some arches; but I don't > think we have the ZAP_BLOCK_SIZE tuned with any great precision, and > you'd at worst be doubling the latency there, so let's not worry > about it. I write this merely in order to reserve myself an > "I told you so" if anyone ever notices increased latency ;) Hmm, we'd have to repeat the longish if statement to make sure we don't miss a cond_resched after tlb_flush_mmu. I'd rather not do that. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. - 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: [BUGFIX][PATCH] DO flush icache before set_pte() on ia64.
On Wed, 04 Jul 2007 16:31:06 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote: > The only thing I noticed when I looked at the code is that some places > may not have flushed icache when they should have? Did you get them all? I think that I added flush_icache_page() to the place where any flush_(i)cache_xxx is not called and lazy_mmu_prot_update was used instead of them. But I want good review, of course. > Minor nitpick: you have one place where you test VM_EXEC before flushing, > but the flush routine itself contains the same test I think? > Ah, yes...in do_anonymous_page(). my mistake. > Regarding the ia64 code -- I'm not an expert so I can't say whether it > is the right thing to do or not. However I still can't work out what it's > rationale for the PG_arch_1 bit is, exactly. Does it assume that > flush_dcache_page sites would only ever be encountered by pages that are > not faulted in? A faulted in page kind of is "special" because it is > guaranteed uptodate, but is the ia64 arch code relying on that? Should it? (I'm sorry if I misses point.) ia64's D-cache is coherent but I-cache and D-cache is not coherent and any invalidation against d-cache will invalidate I-cache. In my understanding : PG_arch_1 is used for showing "there is no inconsistent data on any level of cache". PG_uptodate is used for showing "this page includes the newest data and contents are valid." ...maybe not used for the same purpose. BTW, a page filled by DMA should have PG_arch_1 :( -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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Miklos Szeredi writes: > That's weird, I never had a suspend problem due to a fuse mount, > though I have them all the time. And I suspect, that even the sync() Well, I don't either, because we don't freeze processes on powerbooks. But I have heard that other people have problems with suspending with a fuse filesystem mounted. Maybe the difference is whether or not the filesystem is writable? > thing that suspend does is not the real cause, because sync() actually > does nothing in fuse filesystems. It's not the filesystem sync method, as I understand it, it's that if there are dirty pages in the page cache for files on the fuse filesystem, the system will initiate a write-out on them and wait for it to finish. But if the fuse userspace is frozen, the write-out will never complete. 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/
[PATCH] i386: es7000 build breakage fix
o Commit 1833d6bc72893265f22addd79cf52e6987496e0f broke the build if
compiled with CONFIG_ES7000=y and CONFIG_X86_GENERICARCH=n
arch/i386/kernel/built-in.o(.init.text+0x4fa9): In function `acpi_parse_madt':
: undefined reference to `acpi_madt_oem_check'
arch/i386/kernel/built-in.o(.init.text+0x7406): In function `smp_read_mpc':
: undefined reference to `mps_oem_check'
arch/i386/kernel/built-in.o(.init.text+0x8990): In function
`connect_bsp_APIC':
: undefined reference to `enable_apic_mode'
make: *** [.tmp_vmlinux1] Error 1
o Fix the build issue. Provided the definitions of missing functions.
o Don't have ES7000 machine. Only compile tested.
arch/i386/mach-es7000/es7000plat.c | 48
include/asm-i386/mach-es7000/mach_apic.h|4 ++
include/asm-i386/mach-es7000/mach_mpparse.h |6 +++
3 files changed, 58 insertions(+)
diff -puN arch/i386/mach-es7000/es7000plat.c~i386-es7000-build-breakage-fix
arch/i386/mach-es7000/es7000plat.c
---
linux-2.6.22-rc7/arch/i386/mach-es7000/es7000plat.c~i386-es7000-build-breakage-fix
2007-07-04 13:49:01.0 +0530
+++ linux-2.6.22-rc7-root/arch/i386/mach-es7000/es7000plat.c2007-07-04
13:49:01.0 +0530
@@ -40,6 +40,7 @@
#include
#include
#include "es7000.h"
+#include
/*
* ES7000 Globals
@@ -174,6 +175,53 @@ find_unisys_acpi_oem_table(unsigned long
}
#endif
+/*
+ * This file also gets compiled if CONFIG_X86_GENERICARCH is set. Generic
+ * arch already has got following function definitions (asm-generic/es7000.c)
+ * hence no need to define these for that case.
+ */
+#ifndef CONFIG_X86_GENERICARCH
+void es7000_sw_apic(void);
+void __init enable_apic_mode(void)
+{
+ es7000_sw_apic();
+ return;
+}
+
+__init int mps_oem_check(struct mp_config_table *mpc, char *oem,
+ char *productid)
+{
+ if (mpc->mpc_oemptr) {
+ struct mp_config_oemtable *oem_table =
+ (struct mp_config_oemtable *)mpc->mpc_oemptr;
+ if (!strncmp(oem, "UNISYS", 6))
+ return parse_unisys_oem((char *)oem_table);
+ }
+ return 0;
+}
+#ifdef CONFIG_ACPI
+/* Hook from generic ACPI tables.c */
+int __init acpi_madt_oem_check(char *oem_id, char *oem_table_id)
+{
+ unsigned long oem_addr;
+ if (!find_unisys_acpi_oem_table(&oem_addr)) {
+ if (es7000_check_dsdt())
+ return parse_unisys_oem((char *)oem_addr);
+ else {
+ setup_unisys();
+ return 1;
+ }
+ }
+ return 0;
+}
+#else
+int __init acpi_madt_oem_check(char *oem_id, char *oem_table_id)
+{
+ return 0;
+}
+#endif
+#endif /* COFIG_X86_GENERICARCH */
+
static void
es7000_spin(int n)
{
diff -puN
include/asm-i386/mach-es7000/mach_apic.h~i386-es7000-build-breakage-fix
include/asm-i386/mach-es7000/mach_apic.h
---
linux-2.6.22-rc7/include/asm-i386/mach-es7000/mach_apic.h~i386-es7000-build-breakage-fix
2007-07-04 13:49:01.0 +0530
+++ linux-2.6.22-rc7-root/include/asm-i386/mach-es7000/mach_apic.h
2007-07-04 13:49:01.0 +0530
@@ -73,6 +73,10 @@ static inline void init_apic_ldr(void)
apic_write_around(APIC_LDR, val);
}
+#ifndef CONFIG_X86_GENERICARCH
+extern void enable_apic_mode(void);
+#endif
+
extern int apic_version [MAX_APICS];
static inline void setup_apic_routing(void)
{
diff -puN
include/asm-i386/mach-es7000/mach_mpparse.h~i386-es7000-build-breakage-fix
include/asm-i386/mach-es7000/mach_mpparse.h
---
linux-2.6.22-rc7/include/asm-i386/mach-es7000/mach_mpparse.h~i386-es7000-build-breakage-fix
2007-07-04 13:49:01.0 +0530
+++ linux-2.6.22-rc7-root/include/asm-i386/mach-es7000/mach_mpparse.h
2007-07-04 13:49:01.0 +0530
@@ -18,6 +18,12 @@ extern int parse_unisys_oem (char *oempt
extern int find_unisys_acpi_oem_table(unsigned long *oem_addr);
extern void setup_unisys(void);
+#ifndef CONFIG_X86_GENERICARCH
+extern int acpi_madt_oem_check(char *oem_id, char *oem_table_id);
+extern int mps_oem_check(struct mp_config_table *mpc, char *oem,
+ char *productid);
+#endif
+
#ifdef CONFIG_ACPI
static inline int es7000_check_dsdt(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: sata_sil, writing bug with multiple cards?
Andi Kleen writes: If it has >2GB or so it might be worth trying booting it with mem=2G Nope, only 1GB of RAM. Most likely it is some sort of hardware bug that we might not be able to do much about. Have you tried contacting SIL or VIA? No, I haven't. Like I mentioned above, the OpenBSD drivers seemed to work, or at least did with similar tests. I would need to run the more extensive checks to be positive, but those take a lot of time, obviously. And downtime for the box, a lot of which isn't really manageable, at the moment. e.g. if you have some other system with a different chipset it might be useful to test the SIL controllers in those. The previous motherboard was an AMD 760 chipset, and it had the same problem. I would perhaps also try a newer kernel. I can certainly try that - I admit 2.6.20.3 is a little old now. This will probably take me a couple days - tomorrow is the 4th of July and a holiday for me. - 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: [info] What's in Jeff's libata-dev inbox?
Jeff Garzik wrote: >>> I have patches from Alan (pata_sis FIFO whack, pata_dma option), Tejun, >>> Albert and Kristen still to be reviewed. Will get to those on Friday, >>> after the July 4th US holiday.tions(-) > > > Just to be more specific, my to-review inbox contains: > > Alan: pata_sis FIFO whack, pata_dma option > > Tejun: PMP patchbomb > > Albert: irq_on/off restructure, irq-driven PIO to wq, minor PIO fixes > Please ignore the "irq-driven PIO to wq" patchset; it's not ready. For the other two patchsets, I'll rediff and resend for your review. -- albert - 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][RESEND] PIE randomization
On Wed, May 23, 2007 at 10:50:24AM +0200, Jiri Kosina wrote:
> From: Jan Kratochvil <[EMAIL PROTECTED]>
>
> This patch is using mmap()'s randomization functionality in such a way
> that it maps the main executable of (specially compiled/linked -pie/-fpie)
> ET_DYN binaries onto a random address (in cases in which mmap() is allowed
> to perform a randomization).
>
> Origin of this patch is in exec-shield
> (http://people.redhat.com/mingo/exec-shield/)
>
> Signed-off-by: Jan Kratochvil <[EMAIL PROTECTED]>
> Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
> Cc: Ingo Molnar <[EMAIL PROTECTED]>
> Cc: Roland McGrath <[EMAIL PROTECTED]>
> Cc: Jakub Jelinek <[EMAIL PROTECTED]>
> -#define BAD_ADDR(x) ((unsigned long)(x) >= TASK_SIZE)
> +#define BAD_ADDR(x) ((unsigned long)(x) >= PAGE_MASK)
...
> @@ -442,8 +491,7 @@ static unsigned long load_elf_interp(str
> goto out_close;
> }
>
> - *interp_load_addr = load_addr;
> - error = ((unsigned long)interp_elf_ex->e_entry) + load_addr;
> + error = load_addr;
...
> if (elf_interpreter) {
> - if (interpreter_type == INTERPRETER_AOUT)
> + if (interpreter_type == INTERPRETER_AOUT) {
> elf_entry = load_aout_interp(&loc->interp_ex,
>interpreter);
> - else
> + } else {
> + unsigned long interp_map_addr; /* unused */
> +
> elf_entry = load_elf_interp(&loc->interp_elf_ex,
> interpreter,
> - &interp_load_addr);
> + &interp_map_addr,
> + load_bias);
> + if (!BAD_ADDR(elf_entry)) {
> + /*
> + * load_elf_interp() returns relocation
> + * adjustment
> + */
> + interp_load_addr = elf_entry;
> + elf_entry += loc->interp_elf_ex.e_entry;
> + }
> + }
> if (BAD_ADDR(elf_entry)) {
> force_sig(SIGSEGV, current);
> retval = IS_ERR((void *)elf_entry) ?
The above highlighted changes are the cause of random segfaults of PIE
binaries. See
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246623
The problem is if ld.so is prelinked to some address in the area where
the kernel actually maps it, particularly if elf_map in load_elf_interp
returns an address one page below its first PT_LOAD segments vaddr.
Then load_addr (it is a load bias actually) returned from load_elf_interp
is 0xf000 (on 32-bit kernels) and BAD_ADDR are all
addresses >= 0xf000 (on i?86).
The fix should be either changing the definition of BAD_ADDR to
e.g. IS_ERR_VALUE(x), or at least changing the if (!BAD_ADDR(elf_entry)) {
above to if (!IS_ERR_VALUE(elf_entry)) {, the second BAD_ADDR can already
stay, because at that place elf_entry is no longer a bias (difference
between actual and preferred load address), but an actual address, where
very high addresses are of course invalid.
Jakub
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
> > That's weird, I never had a suspend problem due to a fuse mount, > > though I have them all the time. And I suspect, that even the sync() > > Well, I don't either, because we don't freeze processes on > powerbooks. But I have heard that other people have problems with > suspending with a fuse filesystem mounted. Maybe the difference is > whether or not the filesystem is writable? > > > thing that suspend does is not the real cause, because sync() actually > > does nothing in fuse filesystems. > > It's not the filesystem sync method, as I understand it, it's that if > there are dirty pages in the page cache for files on the fuse > filesystem, Currently fuse doesn't produce dirty pages. Normal writes are done synchronously, and writable mmap is not supported. So sync() should really be a no-op for fuse. > the system will initiate a write-out on them and wait for it to > finish. But if the fuse userspace is frozen, the write-out will > never complete. Maybe there is some other fs operation being done, possibly not directly, but by waiting for a kernel thread, that does that. It would be nice, if someone who can reproduce the deadlock could debug it. Does sysrq still work during suspend? Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove process freezer from suspend to RAM pathway
Am Mittwoch, 4. Juli 2007 schrieb Benjamin Herrenschmidt: > > > > > > Nope, something's wrong in fuse. You must be able to deal with sync > > > > > > until every task is frozen. > > > > > > > > > > Pipe dream > > > > > > > > Then tell me how you want to avoid that condition. > > > > > > Don't freeze :-) > > > > Then you will have to deal with all syscalls unfrozen tasks can make. > > Yup, and the majority of them is totally harmless. Looks like people > around here have a problem with the idea of writing robust drivers ... The majority is meaningless here. The subsystem works or works not. Reliably failing to work is better than working most of the time. What I am having a problem with is the rest of the system changing its behavior and expecting the drivers to cope with that out of the blue. Oliver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Am Mittwoch, 4. Juli 2007 schrieb Paul Mackerras: > Oliver Neukum writes: > > > USB devices certainly have suspend methods. > > Indeed, and the USB framework has code to know when the host > controller is suspended and avoid trying to send out urbs in that > case. Or at least it did last time I looked at it in any detail; it's > been "just working" - including suspending and resuming, without the > freezer - for quite a while now. And what happens to that IO? I suspended and lost data is not an acceptable behavior. Oliver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Oliver Neukum writes: > > Indeed, and the USB framework has code to know when the host > > controller is suspended and avoid trying to send out urbs in that > > case. Or at least it did last time I looked at it in any detail; it's > > been "just working" - including suspending and resuming, without the > > freezer - for quite a while now. > > And what happens to that IO? I suspended and lost data is not an > acceptable behavior. It's not lost, it's sitting in RAM, and will be sent out when you resume. 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: [PATCH] Two trivial whitespace fixes in lockdep/spinlock code
* Jiri Kosina <[EMAIL PROTECTED]> wrote: > From: Jiri Kosina <[EMAIL PROTECTED]> > > Two trivial whitespace fixes in lockdep/spinlock code > > Cc: Ingo Molnar <[EMAIL PROTECTED]> > Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]> thanks. Acked-by: Ingo Molnar <[EMAIL PROTECTED]> Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata_sil, writing bug with multiple cards?
On Wednesday 04 July 2007 10:17:34 [EMAIL PROTECTED] wrote: > > Most likely it is some sort of hardware bug that we might > > not be able to do much about. Have you tried contacting SIL or VIA? > > No, I haven't. Like I mentioned above, the OpenBSD drivers seemed to work, > or at least did with similar tests. I would need to run the more extensive > checks to be positive, but those take a lot of time, obviously. And > downtime for the box, a lot of which isn't really manageable, at the moment. Perhaps the OpenBSD drivers program the SIL chip in a different way that avoids this problem. > > > e.g. if you have some other system with a different chipset it might > > be useful to test the SIL controllers in those. > > The previous motherboard was an AMD 760 chipset, and it had the same > problem. Ok this means it's likely a SIL issue, not a chipset issue. -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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Am Mittwoch, 4. Juli 2007 schrieb Paul Mackerras: > Oliver Neukum writes: > > > > Indeed, and the USB framework has code to know when the host > > > controller is suspended and avoid trying to send out urbs in that > > > case. Or at least it did last time I looked at it in any detail; it's > > > been "just working" - including suspending and resuming, without the > > > freezer - for quite a while now. > > > > And what happens to that IO? I suspended and lost data is not an > > acceptable behavior. > > It's not lost, it's sitting in RAM, and will be sent out when you > resume. Unfortunately this is not the case. The URB will error out. Oliver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
On Wed, Jul 04, 2007 at 12:11:56AM +0200, Karel Zak wrote:
> mount(8) doesn't include filesystem detection code anymore. You
> have to compile --with-fsprobe={blkid,volume_id}, and libblkid
> (e2fsprogs) or libvolume_id (udev >= v110) is required.
Sorry, but it's really annoying to pull in a filesystem-specific devel
package for that. Having a library is fine, but please move the library
into util-linux so it's always available without another dependency. That
way xfsprogs could for example drop it's own detection library aswell.
> The package build system is now based on autotools. The build system
> supports separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
> SUID_LDFLAGS). For more details see the README file
And this is really dumb. autotools is a completely pain in the ass and
not useful at all for linux-only tools.
-
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.22-rc7] remove duplicate header include line
Hi,
is included twice. This patch removes the duplication.
I've confirmed the binary file with/without patch is completely same.
Thanks,
MUNE
Remove duplicate header include line from arch/i386/kernel/pci-dma.c
Signed-off-by: MUNEDA Takahiro <[EMAIL PROTECTED]>
---
arch/i386/kernel/pci-dma.c |1 -
1 file changed, 1 deletion(-)
Index: linux-2.6.22-rc7/arch/i386/kernel/pci-dma.c
===
--- linux-2.6.22-rc7.orig/arch/i386/kernel/pci-dma.c2007-07-04
17:09:03.0 +0900
+++ linux-2.6.22-rc7/arch/i386/kernel/pci-dma.c 2007-07-04 17:09:14.0
+0900
@@ -12,7 +12,6 @@
#include
#include
#include
-#include
#include
struct dma_coherent_mem {
-
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] net: make net and forcedeth to use kmalloc_node
On Tue, Jul 03, 2007 at 11:58:40AM -0700, Andrew Morton wrote:
> >
> > while (np->put_rx.orig != less_rx) {
> > - struct sk_buff *skb = dev_alloc_skb(np->rx_buf_sz +
> > NV_RX_ALLOC_PAD);
> > + struct sk_buff *skb = dev_alloc_skb_node(np->rx_buf_sz +
> > NV_RX_ALLOC_PAD, dev_to_node(&dev->dev));
>
> If we're going to do this then it would probably make sense to change
> dev_alloc_skb_node() so that it takes a `struct net_device *' rather than a
> bare node-id. That's a call which the net guys will need to make, which is
> why we cc them on our emails.
That thing is called netdev_alloc_skb and already exists. And it's indeed
what they should be using in the rx path.
-
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: [alsa-devel] [PATCH] Improve behaviour of Dreamcast aica ALSA driver in poor resource conditions
At Wed, 4 Jul 2007 00:08:46 +0100,
Adrian McMenamin wrote:
>
> On 03/07/07, Adrian McMenamin <[EMAIL PROTECTED]> wrote:
> > This patch stops the driver from crashing in certain situations (eg if
> > the network fails when NFS mounted), please apply.
> >
>
> Actually, looked at this again and while the previous patch stopped
> the driver from crashing it still locked the sound subsystem. This was
> because INIT_WORK was being called on the same work_struct when the
> device recovered from the network failure. The patch below ensures
> that this does not happen and that instead, PREPARE_WORK is called.
>
> Submitted by: Adrian McMenamin <[EMAIL PROTECTED]>
> Signed-off by: Adrian McMenamin <[EMAIL PROTECTED]>
>
> --- alsa-kernel/sh/aica.c 2007-06-23 15:25:55.0 +0100
> +++ linux-2.6.21/sound/sh/aica.c 2007-07-04 00:01:23.0 +0100
> @@ -68,6 +68,7 @@
> static struct spu_work_holder {
> struct work_struct spu_dma_work;
> void *sspointer;
> + int already_started;
> } spu_working;
>
> static struct workqueue_struct *aica_queue;
> @@ -319,7 +320,13 @@
> dreamcastcard = substream->pcm->private_data;
> /* Use queue to do the heavy lifting */
> spu_working.sspointer = substream;
> - INIT_WORK(&(spu_working.spu_dma_work), run_spu_dma);
> + if (spu_working.already_started == 1) {
> + PREPARE_WORK(&(spu_working.spu_dma_work), run_spu_dma);
> + }
> + else {
> + INIT_WORK(&(spu_working.spu_dma_work), run_spu_dma);
> + spu_working.already_started = 1;
> + }
> queue_work(aica_queue, &(spu_working.spu_dma_work));
> /* Timer may already be running */
> if (unlikely(dreamcastcard->timer.data)) {
Better to initialize at the beginning of the driver initialization.
With this patch, the work struct is reset at each time you open the
PCM, which is inefficient and can be even racy.
Also, it'd be cleaner to move struct spu_work_holder into struct
snd_card_aica. We'll have snd_card_aica pointer via container_of, so
sspointer can be removed (snd_card_aica has substream).
thanks,
Takashi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] net: use numa_node in net_devcice->dev instead of parent
On Tue, Jul 03, 2007 at 05:30:51PM -0700, Yinghai Lu wrote:
> [PATCH 2/4] net: use numa_node in net_devcice->dev instead of parent
>
> Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 27cfe5f..005cc1c 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -217,7 +217,7 @@ nodata:
> struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
> unsigned int length, gfp_t gfp_mask)
> {
> - int node = dev->dev.parent ? dev_to_node(dev->dev.parent) : -1;
> + int node = dev_to_node(&dev->dev);
This looks wrong to me unless the device model has once again changed
silently. When I wrote this code &dev->dev was a device allocated
as part of the netdevice and the parent is the pci (or whatever) device
that has the node information.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sata_sil, writing bug with multiple cards?
Andi Kleen wrote: > On Wednesday 04 July 2007 10:17:34 [EMAIL PROTECTED] wrote: > >>> Most likely it is some sort of hardware bug that we might >>> not be able to do much about. Have you tried contacting SIL or VIA? >> No, I haven't. Like I mentioned above, the OpenBSD drivers seemed to work, >> or at least did with similar tests. I would need to run the more extensive >> checks to be positive, but those take a lot of time, obviously. And >> downtime for the box, a lot of which isn't really manageable, at the moment. > > Perhaps the OpenBSD drivers program the SIL chip in a different way > that avoids this problem. > >>> e.g. if you have some other system with a different chipset it might >>> be useful to test the SIL controllers in those. >> The previous motherboard was an AMD 760 chipset, and it had the same >> problem. > > Ok this means it's likely a SIL issue, not a chipset issue. H... okay. I'll take look at the openBSD driver. I still have no idea what it can be tho. Maybe, FIFO setup? Thanks. -- tejun - 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 3/3] Text Edit Lock - kprobes i386
On Tue, Jul 03, 2007 at 12:38:22PM -0400, Mathieu Desnoyers wrote:
> Kprobes can use the text edit lock to insure mutual exclusion when edition the
> code and make sure the pages are writable.
Linus suggested for splitting ro-data and ro-text; And allow ro-text
only if kprobes is not configured.
Please see the discussion thread, URL given below
http://lkml.org/lkml/2007/6/20/436
This patch below allows to configure and mark the kernel text and
kernel data as read-only separately. Also kernel text
is configured read-only if kprobes is not configured.
Thanks
Prasanna
This patch allows to configure and mark the kernel text and
kernel data as read-only separately.
Signed-off-by: Prasanna S P. <[EMAIL PROTECTED]>
arch/i386/Kconfig.debug |8
arch/i386/mm/init.c | 22 --
2 files changed, 24 insertions(+), 6 deletions(-)
diff -puN arch/i386/Kconfig.debug~mark-kernel-text-data-ro-seperately-i386
arch/i386/Kconfig.debug
---
linux-2.6.22-rc6/arch/i386/Kconfig.debug~mark-kernel-text-data-ro-seperately-i386
2007-07-04 13:45:24.0 +0530
+++ linux-2.6.22-rc6-prasanna/arch/i386/Kconfig.debug 2007-07-04
13:52:31.0 +0530
@@ -56,6 +56,14 @@ config DEBUG_RODATA
portion of the kernel code won't be covered by a 2MB TLB anymore.
If in doubt, say "N".
+config DEBUG_ROTEXT
+ bool "Write protect kernel text"
+ depends on DEBUG_RODATA && !KPROBES
+ help
+ Mark the kernel text as write-protected in the pagetables.
+ Only allow this if kprobes is not configured.
+ If in doubt, say "N".
+
config 4KSTACKS
bool "Use 4Kb for kernel stacks instead of 8Kb"
depends on DEBUG_KERNEL
diff -puN arch/i386/mm/init.c~mark-kernel-text-data-ro-seperately-i386
arch/i386/mm/init.c
---
linux-2.6.22-rc6/arch/i386/mm/init.c~mark-kernel-text-data-ro-seperately-i386
2007-07-04 13:45:24.0 +0530
+++ linux-2.6.22-rc6-prasanna/arch/i386/mm/init.c 2007-07-04
13:51:39.0 +0530
@@ -792,14 +792,11 @@ static int noinline do_test_wp_bit(void)
return flag;
}
-#ifdef CONFIG_DEBUG_RODATA
-
-void mark_rodata_ro(void)
+static inline void mark_rwtext_ro(void)
{
unsigned long start = PFN_ALIGN(_text);
unsigned long size = PFN_ALIGN(_etext) - start;
-#ifndef CONFIG_KPROBES
#ifdef CONFIG_HOTPLUG_CPU
/* It must still be possible to apply SMP alternatives. */
if (num_possible_cpus() <= 1)
@@ -809,9 +806,22 @@ void mark_rodata_ro(void)
size >> PAGE_SHIFT, PAGE_KERNEL_RX);
printk("Write protecting the kernel text: %luk\n", size >> 10);
}
+
+ /*
+* global_flush_tlb() will be called after marking the data as readonly.
+*/
+}
+
+#ifdef CONFIG_DEBUG_RODATA
+
+void mark_rodata_ro(void)
+{
+ unsigned long start = PFN_ALIGN(_etext);
+ unsigned long size = (unsigned long)__end_rodata - start;
+
+#ifdef CONFIG_DEBUG_ROTEXT
+ mark_rwtext_ro();
#endif
- start += size;
- size = (unsigned long)__end_rodata - start;
change_page_attr(virt_to_page(start),
size >> PAGE_SHIFT, PAGE_KERNEL_RO);
printk("Write protecting the kernel read-only data: %luk\n",
_
--
Prasanna S.P.
Linux Technology Center
India Software Labs, IBM Bangalore
Email: [EMAIL PROTECTED]
Ph: 91-80-41776329
-
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: via-rhine: Transmit timed out problem
On 22-06-2007 14:18, Kirill Kuvaldin wrote: > Hi, > > I'm experiencing a strange problem with a via rhine network card on Ubuntu > 7.04 (2.6.20-16-generic #2 SMP). The hardware seemed to come into an > inconsistent state, since rmmod'ing and modprobe'ing the via-rhine driver > back didn't help. > > After the problem had appeared, I could see the following in dmesg: > > [ 8601.971189] irq 21: nobody cared (try booting with the "irqpoll" > option) > [ 8601.971214] [] __report_bad_irq+0x24/0x80 ... > [ 8601.971291] handlers: > [ 8601.971293] [] (usb_hcd_irq+0x0/0x60 [usbcore]) > [ 8601.971311] [] (rhine_interrupt+0x0/0xb80 [via_rhine]) > [ 8601.971324] Disabling IRQ #21 ... > The interrupt seemed to be unhandled and got disabled by the kernel > then. The transmission seemed to time out for some reason (probably, the > hardware got into an inconsistent state?). ... > Is that information sufficient for debug? Let me know if you need > any additional data. Your diagnose seems right but there are at least 2 suspects. I doubt I can debug this, but maybe trying this "irqpoll" could really tell more to somebody. You could probably try to check this without USB (e.g. with kernel parameter "nousb"), too. Regards, Jarek P. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] oops and panic message logging to MTD
On Tue, 2007-07-03 at 12:47 +0300, Jarkko Lavinen wrote: > On Tue, Jun 19, 2007 at 11:00:54AM +0100, Richard Purdie wrote: > > Its not a case of formatting the whole partition. The whole point of > > this code is the following use case: > > > > 1. Device crashes > > 2. Device reboots > > 3. mtdoops partition has a log of why it crashed > > The oops logger uses oops_in_progress variable to detect the begin and the > end of an oops. The end is detected when the first non-oops line comes and > oops_in_progress is false. > > This works if the kernel is still running after the oops and gemerates some > non-oops messages. But if there is no non-oops line following an oops, no > flushing will occur and there won't be a log on flash. There was a printk within bust_spinlocks which flushed the klogd queues and hence flushed the mtd_oops queue too. I've noticed this has recently been removed and replaced with a wait queue [1] and hence the problem mentioned above now exists (but didn't when the driver was developed). [1] http://git.o-hand.com/?p=linux-rpurdie;a=commitdiff;h=e3e8a75d2acfc61ebf25524666a0a2c6abb0620c This raises the question of how to known when the oops has completed. The neatest solution I can see would be to add some kind of optional sync function pointer to struct console. Would that be acceptable? 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: 2.6.22-rc6: NMI oops and long pauses during boot
> First boot hung with oops/bug dump. I did not have a camera ready but it > was an oops-like dump that included die_nmi or something similar about > NMI. > > Second boot booted fine until INIT had started and then came a long > pause (tens of seconds). When I pressed Ctrl-Alt-Del it became alive and > continued the bootup until it noticed the Ctrl-Alt-Del. > > Third boot was similar but the pause appeared before INIT: line and > after mounting root and writeprotecting kernel text and readonly > data. Ctrl-Alt-Del revived it again. Tried it again with 2.6.22-rc7 + todays git. Still the same, this time it waited after loading PC speaker driver and before announcing tsc clocksource as not good enough, and pressing Enter made it continue. Unfortunately I will be away from this computer for about 2 weeks so I can't test anything with it. It's still a regression but not worth holding up 2.6.22 for me if no one other sees it. -- Meelis Roos <[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: 2.6.21.5 june 30th to july 1st date hang?
On Tuesday, 3. July 2007, Chuck Ebbert wrote: > On 07/03/2007 03:28 PM, Chris Friesen wrote: > > Arne Georg Gleditsch wrote: > >> An interesting exercise might be to > >> code up a small program to call adjtimex with timex.status |= STA_INS, > >> to see if this can trigger the problem. > > > > Setting the date to just before midnight June 30 UTC and then running > > the following as root triggered the crash on a modified 2.6.10. Anyone > > see anything wrong with the code below, or is this a valid indication of > > a bug in the leap second code? > > Fixed: > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=comm >itdiff;h=746976a301ac9c9aa10d7d42454f8d6cdad8ff2b > Hi Chris, does that qualify for inclusion into 2.6.21.6? regards, Uli -- --- ROAD ...the handyPC Company - - - ) ) ) Uli Luckas Software Development ROAD GmbH Bennigsenstr. 14 | 12159 Berlin | Germany fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69 url: www.road.de Amtsgericht Charlottenburg: HRB 96688 B Managing directors: Hans-Peter Constien, Hubertus von Streit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[linux-kernel]Why there are so many struct rw_semaphore being defined?
I see struct rw_semaphore is defined in include/linux/rwsem-spinlock.h,in the meanwhile, I also can find it in include/asm-**/rwsem.h,for example,include/asm-i386/rwsem.h,include/asm-x86_64/rwsem.h,why?which one should be used? Thanks Jason Xiao - 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/
Big sized packets have been dropped strangly
Hey Guys, I got a strange problem recently but no ideas, so to post the question here. We have a FPGA what finish ATM AAL5 to ethernet frame, and CPU receives IP packets from it. The interface based on the FPGA (called sar0) has been bound with several IP addresses. When the MTU of the interface is configurated to 1500, trivial packets can be received, but big-sized packets are dropped. If the MTU is increased to 9500, everything is ok except the NFS connection. We mounted with another machine through sar0. When the MTU is 9500, the speed of the NFS becomes very very slow (it almost took 10 minutes to transfer 100KB files). I don't know why it is and how to solve it. Any suggestions are appreciated! Thanks, Gavin - 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-kernel]Why there are so many struct rw_semaphore being defined?
Am Mittwoch, 4. Juli 2007 schrieb jidong xiao: > I see struct rw_semaphore is defined in > include/linux/rwsem-spinlock.h,in the meanwhile, I also can find it in Quote: #ifndef _LINUX_RWSEM_H #error "please don't include linux/rwsem-spinlock.h directly, use linux/rwsem.h instead" #endif > include/asm-**/rwsem.h,for > example,include/asm-i386/rwsem.h,include/asm-x86_64/rwsem.h,why?which > one should be used? This structure is so important to performance that some architectures have version optimized to their features. Regards Oliver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Libata PATA status
> I'd love to try to poke holes in the libata PATA support, but sadly > it doesn't look like any of my systems built-in ATA chipsets are > supported yet. Has anyone started a rewrite of the PPC/PowerMac IDE > driver? The current one is in "drivers/ide/ppc/pmac.c", and supports > these chipsets: I'm not aware of anyone having done any PPC ports yet, although a couple of people have asked and said they would look at it. Currently our coverage is incomplete for some embedded and obscure platforms, of which the macintrash is probably the least 'obscure'. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Libata PATA status
On Tue, 3 Jul 2007 23:04:26 -0400, Kyle Moffett wrote: > Has anyone started a rewrite of the PPC/PowerMac IDE > driver? The current one is in "drivers/ide/ppc/pmac.c", and supports > these chipsets: >OHare ATA >Heathrow ATA >KeyLargo ATA-3 >KeyLargo ATA-4 >UniNorth ATA-6 (IE: Kauai) >K2 ATA-6 >Shasta ATA-6 > > I'd be willing to test drivers for the UniNorth ATA-6 and K2 ATA-6, > as well as possibly the KeyLargo ATA-3/4, depending on what the old > MDD G4 in my closet has. Sadly my libata-foo is insufficient for me > to do anything useful (other than thoroughly testing my backup- > restoration procedure, maybe :-D). And I'd be happy to test a libata pmac driver on Heathrow (Beige G3) and KeyLargo ATA-3/UniNorth ATA-6 (eMac G4). - 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: [Intel IOMMU 01/10] DMAR detection and parsing logic
On Tue, 2007-06-19 at 14:37 -0700, Keshavamurthy, Anil S wrote:
> plain text document attachment (dmar_detection.patch)
> +/**
> + * parse_dmar_table - parses the DMA reporting table
> + */
> +static int __init
> +parse_dmar_table(void)
> +{
> + struct acpi_table_dmar *dmar;
> + struct acpi_dmar_header *entry_header;
> + int ret = 0;
> +
> + dmar = (struct acpi_table_dmar *)dmar_tbl;
> +
> + if (!dmar->width) {
^^^
That goes *splat* on my opteron box.
> + printk (KERN_WARNING PREFIX "Zero: Invalid DMAR haw\n");
> + return -EINVAL;
> + }
> +
> + printk (KERN_INFO PREFIX "Host address width %d\n",
> + dmar->width + 1);
> +
> + entry_header = (struct acpi_dmar_header *)(dmar + 1);
> + while (((unsigned long)entry_header) <
> + (((unsigned long)dmar) + dmar_tbl->length)) {
> + dmar_table_print_dmar_entry(entry_header);
> +
> + switch (entry_header->type) {
> + case ACPI_DMAR_TYPE_HARDWARE_UNIT:
> + ret = dmar_parse_one_drhd(entry_header);
> + break;
> + case ACPI_DMAR_TYPE_RESERVED_MEMORY:
> + ret = dmar_parse_one_rmrr(entry_header);
> + break;
> + default:
> + printk(KERN_WARNING PREFIX
> + "Unknown DMAR structure type\n");
> + ret = 0; /* for forward compatibility */
> + break;
> + }
> + if (ret)
> + break;
> +
> + entry_header = ((void *)entry_header + entry_header->length);
> + }
> + return ret;
> +}
> +
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Oliver Neukum writes: > > It's not lost, it's sitting in RAM, and will be sent out when you > > resume. > > Unfortunately this is not the case. The URB will error out. So the higher-level driver needs to do the sensible thing, i.e., resubmit the URB after resume. It's not rocket science. The data is not lost, it's sitting in RAM, and the higher-level driver will send it out when you resume. If not, then we fix the higher-level driver. Of course with USB there is the interesting question of whether the device is still there when we resume. But if it isn't, the situation is no different to the user asynchronously unplugging the device during operation, and if we lose data in that situation, we can only blame the user. :) 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/
[2.6.21.1] BUG: soft lockup detected on CPU#1
[228719.551711] BUG: soft lockup detected on CPU#1! [228719.551797] [] show_trace_log_lvl+0x1a/0x30 [228719.551901] [] show_trace+0x12/0x14 [228719.551997] [] dump_stack+0x16/0x18 [228719.552090] [] softlockup_tick+0xa6/0xc2 [228719.552187] [] run_local_timers+0x12/0x14 [228719.552288] [] update_process_times+0x72/0xa1 [228719.552387] [] tick_sched_timer+0x53/0xb6 [228719.552488] [] hrtimer_interrupt+0x189/0x1e3 [228719.552588] [] local_apic_timer_interrupt+0x55/0x5b [228719.552694] [] smp_apic_timer_interrupt+0x2a/0x39 [228719.552790] [] apic_timer_interrupt+0x33/0x38 [228719.552886] [] cpu_idle+0x6b/0x85 [228719.552982] [] start_secondary+0xe8/0x30a [228719.553086] [<>] 0x0 [228719.553207] === Folkert van Heusden -- Feeling generous? -> http://www.vanheusden.com/wishlist.php -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.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: New systems: eu.kernel.org
On Tue, 03 Jul 2007 16:16:01 -0700 "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: > Hi all, > > Thanks to HP, ISC and UmeÃ¥ Universitet, kernel.org now has official > servers in Europe. Specifically, we have www1.eu.kernel.org hosted at > ISC Amsterdam, and www2.eu.kernel.org at UMU (UmeÃ¥, Sweden.) They are > collectively accessible as www.eu.kernel.org. > > This is a full service of kernel.org and not a mirror. In the future, > we hope to add some sort of smart DNS to automatically redirect traffic, > as well as additional services in Europe. > First, thanks a lot to all those involved in this. Just a few things at the top of the main page: - the http, ftp and rsync links still point at kernel.org, as the content is also at eu.kernel.org maybe change these. - idem for the 'prepatch', 'snapshot' and '-mm patch' links - idem for the 'current changesets' 'C' links One last thing, is there a git server as well for eu? Thanks again, Sébastien. - 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] libata_acpi: A different strategy for using ACPI information
> Looks fairly reasonable to me. However, I suspect any use of _GTM is > somewhat dangerous (at least after the resume) unless we use the _STM > and _GTF methods in the proper sequence when resuming. (Is that in the > -mm tree now?) Yes - and we only use it in these drivers to check for cable evidence not for anything more serious. > speed we give it is valid, since there is no sane way for the function > to indicate failure. (Thus the problem with the "cram in all possible > values to see what it supports" strategy for determining mode limits..) The spec I have says it'll hand back the mode it actually uses which is effectively a solution for 'failure' - 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: Some NCQ numbers...
Tejun Heo wrote: > Hello, > > Michael Tokarev wrote: >> Well. It looks like the results does not depend on the >> elevator. Originally I tried with deadline, and just >> re-ran the test with noop (hence the long delay with >> the answer) - changing linux elevator changes almost >> nothing in the results - modulo some random "fluctuations". > > I see. Thanks for testing. Here are actual results - the tests were still running when I replied yesterday. Again, this is Seagate ST3250620AS "desktop" drive, 7200RPM, 16Mb cache, 250Gb capacity. The tests were performed with queue depth = 64 (on mptsas), drive write cache is turned off. noop scheduler: BlkSz Trd linRd rndRd linWr rndWr rndR/W 4k 1 12.8 0.3 0.4 0.3 0.1/ 0.1 4 0.3 0.3 0.1/ 0.1 32 0.3 0.3 0.1/ 0.1 8k 1 24.6 0.6 0.9 0.6 0.3/ 0.3 4 0.6 0.6 0.3/ 0.3 32 0.6 0.6 0.3/ 0.3 16k 1 41.3 1.2 1.8 1.1 0.6/ 0.6 4 1.2 1.1 0.6/ 0.6 32 1.2 1.1 0.6/ 0.6 32k 1 58.4 2.2 3.5 2.1 1.1/ 1.1 4 2.3 2.1 1.1/ 1.1 32 2.3 2.1 1.1/ 1.1 128k 1 80.4 8.1 12.5 7.2 3.8/ 3.8 4 8.1 7.2 3.8/ 3.8 32 8.1 7.2 3.8/ 3.8 1024k 1 80.5 33.9 33.8 24.5 14.3/14.3 434.124.6 14.3/14.2 3234.224.6 14.4/14.2 deadline scheduler: BlkSz Trd linRd rndRd linWr rndWr rndR/W 4k 1 12.8 0.3 0.4 0.3 0.1/ 0.1 4 0.3 0.3 0.1/ 0.1 32 0.3 0.3 0.1/ 0.1 8k 1 24.5 0.6 0.9 0.6 0.3/ 0.3 4 0.6 0.6 0.3/ 0.3 32 0.6 0.6 0.3/ 0.3 16k 1 41.3 1.2 1.8 1.1 0.6/ 0.6 4 1.2 1.1 0.6/ 0.6 32 1.2 1.1 0.6/ 0.6 32k 1 57.7 2.3 3.4 2.1 1.1/ 1.1 4 2.3 2.1 1.1/ 1.1 32 2.3 2.1 1.1/ 1.1 128k 1 79.4 8.1 12.5 7.2 3.8/ 3.8 4 8.1 7.3 3.8/ 3.8 32 8.2 7.3 3.9/ 3.8 1024k 1 79.4 33.7 33.8 24.5 14.2/14.2 433.924.6 14.3/14.2 3233.424.4 17.0/10.5 [] >> By the way, Seagate announced Barracuda ES 2 series >> (in range 500..1200Gb if memory serves) - maybe with >> those, NCQ will work better? > > No one would know without testing. Sure thing. I guess I'll set up a web page with all the results so far, in a hope someday it will be more complete (we don't have many different drives to test, but others do). By the way. Both SATA drives we have are single-platter ones (with 500Gb models they've 2 platters, and 750Gb ones are with 3 platters), while all SCSI drives I tested have more than one platters. Maybe this is yet another reason for NCQ failing. And another note. I heard somewhere that Seagate for one prohibits publishing of tests like this, however I haven't signed any NDAs and somesuch when purchased their drives in a nearest computer store... ;) >> Or maybe it's libata which does not implement NCQ >> "properly"? (As I shown before, with almost all >> ol'good SCSI drives TCQ helps alot - up to 2x the >> difference and more - with multiple I/O threads) > > Well, what the driver does is minimal. It just passes through all the > commands to the harddrive. After all, NCQ/TCQ gives the harddrive more > responsibility regarding request scheduling. Oh well, I see :( /mjt - 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 resend] rewrite AF_UNIX garbage collector, fixes race
From: Miklos Szeredi <[EMAIL PROTECTED]>
Throw out the old mark & sweep garbage collector and put in a
refcounting cycle detecting one.
The old one had a race with recvmsg, that resulted in false positives
and hence data loss. The old algorithm operated on all unix sockets
in the system, so any additional locking would have meant performance
problems for all users of these.
The new algorithm instead only operates on "in flight" sockets, which
are very rare, and the additional locking for these doesn't negatively
impact the vast majority of users.
In fact it's probable, that there weren't *any* heavy senders of
sockets over sockets, otherwise the above race would have been
discovered long ago.
The patch works OK with the app that exposed the race with the old
code. The garbage collection has also been verified to work in a few
simple cases.
See comments inside patch for the description of the algorithm.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
---
include/net/af_unix.h |3
net/unix/af_unix.c|6
net/unix/garbage.c| 329 --
3 files changed, 192 insertions(+), 146 deletions(-)
Index: linux-2.6.22-rc6/include/net/af_unix.h
===
--- linux-2.6.22-rc6.orig/include/net/af_unix.h 2007-06-27 22:53:53.0
+0200
+++ linux-2.6.22-rc6/include/net/af_unix.h 2007-06-27 22:53:55.0
+0200
@@ -79,9 +79,10 @@ struct unix_sock {
struct mutexreadlock;
struct sock*peer;
struct sock*other;
-struct sock*gc_tree;
+ struct list_headlink;
atomic_tinflight;
spinlock_t lock;
+ unsigned intgc_candidate : 1;
wait_queue_head_t peer_wait;
};
#define unix_sk(__sk) ((struct unix_sock *)__sk)
Index: linux-2.6.22-rc6/net/unix/af_unix.c
===
--- linux-2.6.22-rc6.orig/net/unix/af_unix.c2007-06-27 22:53:53.0
+0200
+++ linux-2.6.22-rc6/net/unix/af_unix.c 2007-06-27 22:53:55.0 +0200
@@ -592,7 +592,8 @@ static struct sock * unix_create1(struct
u->dentry = NULL;
u->mnt= NULL;
spin_lock_init(&u->lock);
- atomic_set(&u->inflight, sock ? 0 : -1);
+ atomic_set(&u->inflight, 0);
+ INIT_LIST_HEAD(&u->link);
mutex_init(&u->readlock); /* single task reading lock */
init_waitqueue_head(&u->peer_wait);
unix_insert_socket(unix_sockets_unbound, sk);
@@ -1134,9 +1135,6 @@ restart:
/* take ten and and send info to listening sock */
spin_lock(&other->sk_receive_queue.lock);
__skb_queue_tail(&other->sk_receive_queue, skb);
- /* Undo artificially decreased inflight after embrion
-* is installed to listening socket. */
- atomic_inc(&newu->inflight);
spin_unlock(&other->sk_receive_queue.lock);
unix_state_unlock(other);
other->sk_data_ready(other, 0);
Index: linux-2.6.22-rc6/net/unix/garbage.c
===
--- linux-2.6.22-rc6.orig/net/unix/garbage.c2007-06-27 22:53:53.0
+0200
+++ linux-2.6.22-rc6/net/unix/garbage.c 2007-06-27 22:53:55.0 +0200
@@ -62,6 +62,10 @@
* AV 1 Mar 1999
* Damn. Added missing check for ->dead in listen queues scanning.
*
+ * Miklos Szeredi 25 Jun 2007
+ * Reimplement with a cycle collecting algorithm. This should
+ * solve several problems with the previous code, like being racy
+ * wrt receive and holding up unrelated socket operations.
*/
#include
@@ -84,10 +88,9 @@
/* Internal data structures and random procedures: */
-#define GC_HEAD((struct sock *)(-1))
-#define GC_ORPHAN ((struct sock *)(-3))
-
-static struct sock *gc_current = GC_HEAD; /* stack of objects to mark */
+static LIST_HEAD(gc_inflight_list);
+static LIST_HEAD(gc_candidates);
+static DEFINE_SPINLOCK(unix_gc_lock);
atomic_t unix_tot_inflight = ATOMIC_INIT(0);
@@ -122,8 +125,16 @@ void unix_inflight(struct file *fp)
{
struct sock *s = unix_get_socket(fp);
if(s) {
- atomic_inc(&unix_sk(s)->inflight);
+ struct unix_sock *u = unix_sk(s);
+ spin_lock(&unix_gc_lock);
+ if (atomic_inc_return(&u->inflight) == 1) {
+ BUG_ON(!list_empty(&u->link));
+ list_add_tail(&u->link, &gc_inflight_list);
+ } else {
+ BUG_ON(list_empty(&u->link));
+ }
atomic_inc(&unix_tot_inflight);
+ spin_unlock(&unix_gc_lock);
}
}
@@ -131,182 +142,218 @@ void unix_notinflight(struct file *fp)
{
struct sock *s = unix_get_socket(fp);
if(s) {
- a
Re: [Intel IOMMU 01/10] DMAR detection and parsing logic
On Wed, 04 Jul 2007 11:18:56 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-06-19 at 14:37 -0700, Keshavamurthy, Anil S wrote:
> > plain text document attachment (dmar_detection.patch)
>
> > +/**
> > + * parse_dmar_table - parses the DMA reporting table
> > + */
> > +static int __init
> > +parse_dmar_table(void)
> > +{
> > + struct acpi_table_dmar *dmar;
> > + struct acpi_dmar_header *entry_header;
> > + int ret = 0;
> > +
> > + dmar = (struct acpi_table_dmar *)dmar_tbl;
> > +
> > + if (!dmar->width) {
> ^^^
>
> That goes *splat* on my opteron box.
This?
From: "Keshavamurthy, Anil S" <[EMAIL PROTECTED]>
Check for dmar_tbl pointer as this can be NULL on systems with no Intel
VT-d support.
Signed-off-by: Anil S Keshavamurthy <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/pci/dmar.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -puN
drivers/pci/dmar.c~intel-iommu-dmar-detection-and-parsing-logic-fix-intel-dmar-crash-on-amd-x86_64
drivers/pci/dmar.c
---
a/drivers/pci/dmar.c~intel-iommu-dmar-detection-and-parsing-logic-fix-intel-dmar-crash-on-amd-x86_64
+++ a/drivers/pci/dmar.c
@@ -260,6 +260,8 @@ parse_dmar_table(void)
int ret = 0;
dmar = (struct acpi_table_dmar *)dmar_tbl;
+ if (!dmar)
+ return -ENODEV;
if (!dmar->width) {
printk (KERN_WARNING PREFIX "Zero: Invalid DMAR haw\n");
@@ -301,7 +303,7 @@ int __init dmar_table_init(void)
parse_dmar_table();
if (list_empty(&dmar_drhd_units)) {
- printk(KERN_ERR PREFIX "No DMAR devices found\n");
+ printk(KERN_INFO PREFIX "No DMAR devices found\n");
return -ENODEV;
}
return 0;
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Am Mittwoch, 4. Juli 2007 schrieb Paul Mackerras: > Oliver Neukum writes: > > > > It's not lost, it's sitting in RAM, and will be sent out when you > > > resume. > > > > Unfortunately this is not the case. The URB will error out. > > So the higher-level driver needs to do the sensible thing, i.e., > resubmit the URB after resume. It's not rocket science. The data is > not lost, it's sitting in RAM, and the higher-level driver will send > it out when you resume. If not, then we fix the higher-level driver. You cannot simply restart the URB without thinking. The device after resumption may or may not be in the stage you left it. It needs to be rechecked and some settings must be renewed. You cannot simple throw an URB from an arbitrary stage of the protocol at it. Suspension of devices can only happen at some points in the protocol. Oliver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Forcibly remove broken disk from LV
On 04/07/07, Turbo Fredriksson <[EMAIL PROTECTED]> wrote: I have a disk that only gives SCSI errors etc which I want to remove from the VG. But vgreduce only hangs and so does pvremove... If I physically remove the disk, the vg/pv/lv etc isn't accessible so the vgreduce won't work (claims that it can't find any PV's etc). So how do I remove the disk? vgreduce --removemissing should do the trick I'd say. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway
On Wednesday, 4 July 2007 02:34, Matthew Garrett wrote: > On Tue, Jul 03, 2007 at 06:17:04PM -0600, Robert Hancock wrote: > > Matthew Garrett wrote: > > >Leave the process blocked and defer any i/o until after resume. Why does > > >it need to be any more complicated than that? > > > > It gets complicated when this has to be added and TESTED in EVERY > > driver. The implied contract for drivers previously was that their > > device would not get accessed after it was suspended until it had been > > resumed first. This proposed change violates that. > > No, that's only ever been true for ACPI systems. Sorry, but you're mistaken. Some ARM platforms also use the suspend code in kernel/power and the 52xx powerpc too (BTW, I don't know of any ARM platforms that support suspend and don't use it). > It's never been true elsewhere, and it won't be true for anything > implementing any sort of runtime power management. There are not many drivers in the tree supporting that right now. > > I don't think this sort of handling is something that individual drivers > > should have to deal with (at least not ones that are part of a framework > > like USB, libata, etc.) > > I'd agree there. Driver midlayers (where they exist) are the appropriate > place to handle this. So perhaps we should modify them first and we can drop the freezer? Perhaps we can schedule the freezer removal (from the suspend code path), so that people have the time to rework the driver midlayers to take that into account? Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Forcibly remove broken disk from LV
On 04/07/07, Jesper Juhl <[EMAIL PROTECTED]> wrote: On 04/07/07, Turbo Fredriksson <[EMAIL PROTECTED]> wrote: > I have a disk that only gives SCSI errors etc which > I want to remove from the VG. But vgreduce only hangs > and so does pvremove... > > If I physically remove the disk, the vg/pv/lv etc isn't > accessible so the vgreduce won't work (claims that it > can't find any PV's etc). > > So how do I remove the disk? vgreduce --removemissing should do the trick I'd say. Ohh and by the way, pvremove also has a --force option - if needed. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel IOMMU 01/10] DMAR detection and parsing logic
On Wed, 2007-07-04 at 03:04 -0700, Andrew Morton wrote:
> On Wed, 04 Jul 2007 11:18:56 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2007-06-19 at 14:37 -0700, Keshavamurthy, Anil S wrote:
> > > plain text document attachment (dmar_detection.patch)
> >
> > > +/**
> > > + * parse_dmar_table - parses the DMA reporting table
> > > + */
> > > +static int __init
> > > +parse_dmar_table(void)
> > > +{
> > > + struct acpi_table_dmar *dmar;
> > > + struct acpi_dmar_header *entry_header;
> > > + int ret = 0;
> > > +
> > > + dmar = (struct acpi_table_dmar *)dmar_tbl;
> > > +
> > > + if (!dmar->width) {
> > ^^^
> >
> > That goes *splat* on my opteron box.
>
> This?
>
> From: "Keshavamurthy, Anil S" <[EMAIL PROTECTED]>
>
> Check for dmar_tbl pointer as this can be NULL on systems with no Intel
> VT-d support.
>
> Signed-off-by: Anil S Keshavamurthy <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Ah, that does look sane, I'll test it whenever the next -mm comes
around.
-
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 3/3] ACPI autoloading - Create __mod_acpi_device_table symbol for all acpi drivers.
On Wed, 2007-07-04 at 16:33 +0900, Mattia Dongili wrote:
> On Tue, Jul 03, 2007 at 03:15:33AM -0400, Len Brown wrote:
> >
> > > BTW: I also saw a laptop (IIRC it was a sony) with asus and sony ACPI
> > > device.
> > > When both drivers got loaded things broke.
> > > A solution was to only let the asus driver get active if the device is
> > > known. Currently, not sure whether still (I sent a patch a while ago),
> > > the Asus driver falls back to a default ("M6N"?) configuration. IMO this
> > > is a bit too dangerous and instead a message like "unsupported ASUS
> > > model found, please send acpidump to [EMAIL PROTECTED]".
> >
> > This is pretty scary.
> > Can you drop the acpidump output into a bugzilla?
>
> and add myself to the cc-list?
I don't have such a machine, opening a bug does not make much sense.
Acpidump and more info is here:
https://bugzilla.novell.com/show_bug.cgi?id=166920
Thanks,
Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
On Wednesday, 4 July 2007 10:26, Miklos Szeredi wrote: > > > That's weird, I never had a suspend problem due to a fuse mount, > > > though I have them all the time. And I suspect, that even the sync() > > > > Well, I don't either, because we don't freeze processes on > > powerbooks. But I have heard that other people have problems with > > suspending with a fuse filesystem mounted. Maybe the difference is > > whether or not the filesystem is writable? > > > > > thing that suspend does is not the real cause, because sync() actually > > > does nothing in fuse filesystems. > > > > It's not the filesystem sync method, as I understand it, it's that if > > there are dirty pages in the page cache for files on the fuse > > filesystem, > > Currently fuse doesn't produce dirty pages. Normal writes are done > synchronously, and writable mmap is not supported. So sync() should > really be a no-op for fuse. > > > the system will initiate a write-out on them and wait for it to > > finish. But if the fuse userspace is frozen, the write-out will > > never complete. > > Maybe there is some other fs operation being done, possibly not > directly, but by waiting for a kernel thread, that does that. We're going to limit the freezing of kernel threads to the ones that explicitly want to be frozen, so if that's the case, then I think it'll be fixed soon. > It would be nice, if someone who can reproduce the deadlock could > debug it. Agreed. > Does sysrq still work during suspend? Yes, it should work. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: 2.6.22-rcX: hda: lost interrupt
On Fri, Jun 29, 2007 at 10:27:05AM -0400, Jeff Garzik wrote:
> David Chinner wrote:
> >Folks,
> >
> >After updating an x86_64 machine from 2.6.21 to 2.6.22-rc6 and
> >fighting off the where-the-fuck-did-my-serial-console-go blues
> >(legacy_serial.force), I finally discovered why the damn thing
> >wasn't booting - the machine was sitting there in a loop outputting
> >"hda: lost interrupt" over and over again during hardware
> >discovery (hda = dvd drive).
> >
> >It doesn't happen on every boot - more boots hung than failed,
> >though, while I was trying to work out where my serial port
> >went and get some work done.
> >
> >Since I've had the console operative, the boot hangs are
> >basically like:
> >
> >ESB2: IDE controller at PCI slot :00:1f.1
> >ACPI: PCI Interrupt :00:1f.1[A] -> GSI 20 (level, low) -> IRQ20
> >ESB2: chipset revision 9
> >ESB2: not 100% native mode: will probe irqs later
> >ide0: DM-DMA at 0x50a0-0x50a7, BIOS settings: hda:DMA, hdb:pio
> >ide1: DM-DMA at 0x50a8-0x50af, BIOS settings: hda:pio, hdb:pio
> >Probing IDE interface ide0...
> >hda: probing with STATUS(0xa0) instead of ALTSTATUS(0x58)
> >hda: , ATAPI UNKNOWN (type 31) drive
> >hdb: probing with STATUS(0xb0) instead of ALTSTATUS(0x00)
> >hdb: probing with STATUS(0xa1) instead of ALTSTATUS(0x51)
> >hdb: , ATAPI UNKNOWN (type 31) drive
> >hda: set_drive_speed_status: status=0x58 { DriveReady SeekComplete
> >DataRequest }
> >hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
> >hda: set_drive_speed_status: error=0x04 { AbortedCommand }
> >ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> >hda: lost interrupt
> >hda: lost interrupt
> >hda: lost interrupt
> >hda: lost interrupt
> >hda: lost interrupt
> >hda: lost interrupt
> >hda: lost interrupt
> >hda: lost interrupt
> >hda: lost interrupt
> >hda: lost interrupt
> >hda: lost interrupt
>
> What is the behavior under libata?
>
> If you see timeouts/etc. there too, it might be an interrupt routing or
> hardware problem.
Sorry to take so long to get back to this, Jeff.
I think the problem is on my side. It looks like a dodgy initrd
was causing the problems - a statically built kernel detects
the DVD drive without any issues so there may not be a problem
here at all. I'll continue trying to track down why the initrd
was not being built properly...
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
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: Some NCQ numbers...
On Wed, 4 Jul 2007, Michael Tokarev wrote: Tejun Heo wrote: Hello, Michael Tokarev wrote: Well. It looks like the results does not depend on the elevator. Originally I tried with deadline, and just re-ran the test with noop (hence the long delay with the answer) - changing linux elevator changes almost nothing in the results - modulo some random "fluctuations". I see. Thanks for testing. Here are actual results - the tests were still running when I replied yesterday. Again, this is Seagate ST3250620AS "desktop" drive, 7200RPM, 16Mb cache, 250Gb capacity. The tests were performed with queue depth = 64 (on mptsas), drive write cache is turned off. I found AS scheduler to be the premium and best for single-user performance. You want speed? Use AS. http://home.comcast.net/~jpiszcz/sched/cfq_vs_as_vs_deadline_vs_noop.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
handle_futex_death() infinite loop on ARM (fwd)
- Forwarded message from Lennert Buytenhek <[EMAIL PROTECTED]> - Date: Wed, 13 Jun 2007 20:40:40 +0200 From: Lennert Buytenhek <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: handle_futex_death() infinite loop User-Agent: Mutt/1.4.1i Hi, If you're also running into glibc's tst-robust1 test suite test locking up your ARM machine, you're probably running into the fact that asm-arm/futex.h includes asm-generic/futex.h, and asm-generic/futex.h defines futex_atomic_cmpxchg_inatomic() to return -ENOSYS. This causes handle_futex_death() to loop forever. cheers, Lennert - End forwarded message - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
On Wednesday, 4 July 2007 05:29, Paul Mackerras wrote: > Rafael J. Wysocki writes: > > > Still, do you really think that we're ready to drop it _right_ _now_ (I'm > > referring to suspend only) and if so than on what basis (except that you > > don't like it, which falls short of being a techical argument)? > > The basis is that it (the freezer) causes more deadlocks and other > problems than it avoids, so it's a net win to remove it. So, I gather, you're volunteering to handle suspend-related bug reports from the point in which we drop the freezer from the suspend code path? Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Sparc32: random invalid instruction occourances on sparc32 (sun4c)
Hi David, Another related point that may also need to be considered is that I think I am correct in saying that on ARM and on the 64bit platforms, sizeof (unsigned long long) is 16 (128bits). Should the RedZone words be specified as __u64 not the unsigned long long used or does the alignment need to be that of unsigned long long ? Regards Mark Fortescue. On Tue, 3 Jul 2007, David Woodhouse wrote: On Wed, 2007-07-04 at 04:27 +0100, Mark Fortescue wrote: I tried the previous patch and it looks like it fixes the issue however one of the test builds I did caused depmod to use up all available memory (40M - kernel memory) before taking out the kernel with the oom killer. At present, I do not know if it is a depmod issue or a kernel issue. I will have to do some more tests later on to day. That's almost certain to be an unrelated issue. I have looked at the latest patch below and am I am still not sure about two areas. Please take a look at my offering based on your latest patch (included here to it will probably get mangled). Note the change to lines 2178 to 2185. I have also changed/moved the alignment of size (see lines 2197 to 2206) based on your changes. The first looks correct; well spotted. The second is just cosmetic but also seems correct. I might be inclined to make the #define 'RED_ZONE_ALIGN' and use it in the other places too. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Some NCQ numbers...
On Wed, 4 Jul 2007, Justin Piszcz wrote: On Wed, 4 Jul 2007, Michael Tokarev wrote: > Tejun Heo wrote: >> Hello, >> >> Michael Tokarev wrote: >>> Well. It looks like the results does not depend on the >>> elevator. Originally I tried with deadline, and just >>> re-ran the test with noop (hence the long delay with >>> the answer) - changing linux elevator changes almost >>> nothing in the results - modulo some random "fluctuations". >> >> I see. Thanks for testing. > > Here are actual results - the tests were still running when > I replied yesterday. > > Again, this is Seagate ST3250620AS "desktop" drive, 7200RPM, > 16Mb cache, 250Gb capacity. The tests were performed with > queue depth = 64 (on mptsas), drive write cache is turned > off. I found AS scheduler to be the premium and best for single-user performance. You want speed? Use AS. http://home.comcast.net/~jpiszcz/sched/cfq_vs_as_vs_deadline_vs_noop.html Does not include noop-- tested the main three though, renamed :) http://home.comcast.net/~jpiszcz/sched/cfq_vs_as_vs_deadline.html And for the archives: p34-cfq,15696M,77114.3,99,311683,55.,184947,38.6667,79842.7,99,524065,41.,634.033,0.33,16:10:16/64,1043.33,8.3,4419.33,11.6667,2942,17.,1178,10.,4192.67,12.,2619.33,19 p34-as,15696M,76202.3,99,443103,85,189716,34.6667,79552,99,507271,39.6667,607.067,0,16:10:16/64,1153,10,13434,36,2769.67,16.,1201.67,10.6667,3951.33,12,2665.67,19 p34-deadline,15696M,76933.3,98.6667,386852,72,183016,29.6667,79530.7,99,512082,39.6667,678.567,0,16:10:16/64,1230.33,10.,12349,32.,2945,17.,1258,11,8183,22.,2867,20. 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: [ANNOUNCE] util-linux-ng 2.13-rc1
From: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Wed, 4 Jul 2007 09:42:11 +0100
> On Wed, Jul 04, 2007 at 12:11:56AM +0200, Karel Zak wrote:
> > mount(8) doesn't include filesystem detection code anymore. You
> > have to compile --with-fsprobe={blkid,volume_id}, and libblkid
> > (e2fsprogs) or libvolume_id (udev >= v110) is required.
>
> Sorry, but it's really annoying to pull in a filesystem-specific devel
> package for that. Having a library is fine, but please move the library
> into util-linux so it's always available without another dependency. That
> way xfsprogs could for example drop it's own detection library aswell.
I totally agree with Christophe, this dependency is a complete
pain for trying to do util-linux-ng development. I meant to
complain about this myself.
> > The package build system is now based on autotools. The build system
> > supports separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
> > SUID_LDFLAGS). For more details see the README file
>
> And this is really dumb. autotools is a completely pain in the ass and
> not useful at all for linux-only tools.
I second this sentiment as well. It's not like we expect this stuff
to get used on other systems at all, and the only thing it's getting
used for really is to detect the awful external blkid/volume_id
dependencies.
I totally think this stuff can and should be completely eliminated.
-
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] eHEA: Capability flag for DLPAR support
This patch introduces a capability flag that is used by the DLPAR userspace
tool to check which DLPAR features are supported by the eHEA driver.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h |8 +++-
drivers/net/ehea/ehea_main.c | 17 +
2 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index abaf3ac..809e3f2 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,13 @@
#include
#define DRV_NAME "ehea"
-#define DRV_VERSION"EHEA_0065"
+#define DRV_VERSION"EHEA_0066"
+
+/* EHEA capability flags */
+#define DLPAR_PORT_ADD_REM 1
+#define DLPAR_MEM_ADD 2
+#define DLPAR_MEM_REM 4
+#define EHEA_CAPABILITIES (DLPAR_PORT_ADD_REM)
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index bdb5241..f8c0908 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -2923,6 +2923,15 @@ static int check_module_parm(void)
return ret;
}
+static ssize_t ehea_show_capabilities(struct device_driver *drv,
+ char *buf)
+{
+ return sprintf(buf, "%d", EHEA_CAPABILITIES);
+}
+
+static DRIVER_ATTR(capabilities, S_IRUSR | S_IRGRP | S_IROTH,
+ ehea_show_capabilities, NULL);
+
int __init ehea_module_init(void)
{
int ret;
@@ -2937,12 +2946,20 @@ int __init ehea_module_init(void)
if (ret)
ehea_error("failed registering eHEA device driver on ebus");
+ ret = driver_create_file(&ehea_driver.driver,
&driver_attr_capabilities);
+ if (ret) {
+ ehea_error("failed to register capabilities attribute, ret=%d",
ret);
+ ibmebus_unregister_driver(&ehea_driver);
+ goto out;
+ }
+
out:
return ret;
}
static void __exit ehea_module_exit(void)
{
+ driver_remove_file(&ehea_driver.driver, &driver_attr_capabilities);
ibmebus_unregister_driver(&ehea_driver);
}
--
1.5.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-kernel]Why there are so many struct rw_semaphore being defined?
Oliver Neukum wrote: > Am Mittwoch, 4. Juli 2007 schrieb jidong xiao: >> I see struct rw_semaphore is defined in >> include/linux/rwsem-spinlock.h,in the meanwhile, I also can find it in > > Quote: > > #ifndef _LINUX_RWSEM_H > #error "please don't include linux/rwsem-spinlock.h directly, use > linux/rwsem.h instead" > #endif > >> include/asm-**/rwsem.h,for >> example,include/asm-i386/rwsem.h,include/asm-x86_64/rwsem.h,why?which >> one should be used? > > This structure is so important to performance that some architectures > have version optimized to their features. ...but of course we generally include linux/rwsem.h instead of architecture-specific header files. linux/rwsem.h will transparently pull in the optimized variants for us. (It's evident from the source.) -- Stefan Richter -=-=-=== -=== --=-- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] eHEA: Receive SKB Aggregation
This patch enables the receive side processing to aggregate TCP packets within
the HEA device driver. It analyses the packets already received after an
interrupt arrived and forwards these as chains of SKBs for the same TCP
connection with modified header field. We have seen a lower CPU load and
improved throughput for small numbers of parallel TCP connections.
As this feature is considered as experimental it is switched off by default
and can be activated via a module parameter.
Some additional security checks have been added since the last posting.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h | 30
drivers/net/ehea/ehea_main.c | 324 +-
2 files changed, 348 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 809e3f2..5a53b79 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -55,6 +55,7 @@
#define EHEA_MAX_ENTRIES_RQ3 16383
#define EHEA_MAX_ENTRIES_SQ 32767
#define EHEA_MIN_ENTRIES_QP 127
+#define EHEA_LRO_MAX_PKTS 60
#define EHEA_SMALL_QUEUES
#define EHEA_NUM_TX_QP 1
@@ -84,6 +85,8 @@
#define EHEA_RQ2_PKT_SIZE 1522
#define EHEA_L_PKT_SIZE 256/* low latency */
+#define MAX_LRO_DESCRIPTORS 8
+
/* Send completion signaling */
/* Protection Domain Identifier */
@@ -340,6 +343,29 @@ struct ehea_q_skb_arr {
};
/*
+ * Large Receive Offload (LRO) descriptor for a tcp session
+ */
+struct ehea_lro {
+ struct sk_buff *parent;
+ struct sk_buff *last_skb;
+ struct iphdr *iph;
+ struct tcphdr *tcph;
+
+ u32 tcp_rcv_tsecr;
+ u32 tcp_rcv_tsval;
+ u32 tcp_ack;
+ u32 tcp_next_seq;
+ u32 skb_tot_frags_len;
+ u16 ip_tot_len;
+ u16 tcp_saw_tstamp; /* timestamps enabled */
+ u16 tcp_window;
+ u16 vlan_tag;
+ int skb_sg_cnt; /* counts aggregated skbs */
+ int vlan_packet;
+ int active;
+};
+
+/*
* Port resources
*/
struct ehea_port_res {
@@ -368,6 +394,9 @@ struct ehea_port_res {
u64 tx_packets;
u64 rx_packets;
u32 poll_counter;
+ struct ehea_lro lro[MAX_LRO_DESCRIPTORS];
+ u64 lro_desc;
+ struct port_stats p_state;
};
@@ -417,6 +446,7 @@ struct ehea_port {
u32 msg_enable;
u32 sig_comp_iv;
u32 state;
+ u32 lro_max_aggr;
u8 full_duplex;
u8 autoneg;
u8 num_def_qps;
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index f8c0908..5f889af 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include "ehea.h"
#include "ehea_qmr.h"
@@ -52,6 +53,8 @@ static int rq2_entries = EHEA_DEF_ENTRIES_RQ2;
static int rq3_entries = EHEA_DEF_ENTRIES_RQ3;
static int sq_entries = EHEA_DEF_ENTRIES_SQ;
static int use_mcs = 0;
+static int use_lro = 0;
+static int lro_max_pkts = EHEA_LRO_MAX_PKTS;
static int num_tx_qps = EHEA_NUM_TX_QP;
module_param(msg_level, int, 0);
@@ -60,6 +63,8 @@ module_param(rq2_entries, int, 0);
module_param(rq3_entries, int, 0);
module_param(sq_entries, int, 0);
module_param(use_mcs, int, 0);
+module_param(use_lro, int, 0);
+module_param(lro_max_pkts, int, 0);
module_param(num_tx_qps, int, 0);
MODULE_PARM_DESC(num_tx_qps, "Number of TX-QPS");
@@ -77,6 +82,10 @@ MODULE_PARM_DESC(sq_entries, " Number of entries for the
Send Queue "
"[2^x - 1], x = [6..14]. Default = "
__MODULE_STRING(EHEA_DEF_ENTRIES_SQ) ")");
MODULE_PARM_DESC(use_mcs, " 0:NAPI, 1:Multiple receive queues, Default = 1 ");
+MODULE_PARM_DESC(lro_max_pkts, " LRO: Max packets to be aggregated. Default = "
+__MODULE_STRING(EHEA_LRO_MAX_PKTS));
+MODULE_PARM_DESC(use_lro, " Large Receive Offload, 1: enable, 0: disable, "
+"Default = 0");
static int port_name_cnt = 0;
@@ -380,6 +389,297 @@ static int ehea_treat_poll_error(struct ehea_port_res
*pr, int rq,
return 0;
}
+static int try_get_ip_tcp_hdr(struct ehea_cqe *cqe, struct sk_buff *skb,
+ struct iphdr **iphdr, struct tcphdr **tcph)
+{
+ unsigned int ip_hdrlength;
+ struct iphdr *iph;
+
+ /* non tcp/udp packets */
+ if (!cqe->header_length)
+ return -1;
+
+ /* non tcp packet */
+ skb_reset_network_header(skb);
+ iph = ip_hdr(skb);
+ if (iph->protocol != IPPROTO_TCP)
+ return -1;
+
+ ip_hdrlength = ip_hdrlen(skb);
+
+ /* check ip header: packet length */
+ if (iph->tot_len > cqe->num_bytes_transfered - ETH_HLEN)
+ return -1;
+
+ /* check ip header: minimal ip header received */
+ if (ip_hdrlength > iph->tot_len - 20)
+ return -1;
+
+ skb_set_transport_header(skb, ip_hdrlength);
+ *tcph = tcp_hdr(skb);
+
+ /* ch
Re: [PATCH 2/4] net: use numa_node in net_devcice->dev instead of parent
From: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Wed, 4 Jul 2007 09:51:20 +0100
> On Tue, Jul 03, 2007 at 05:30:51PM -0700, Yinghai Lu wrote:
> > [PATCH 2/4] net: use numa_node in net_devcice->dev instead of parent
> >
> > Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
> > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> > index 27cfe5f..005cc1c 100644
> > --- a/net/core/skbuff.c
> > +++ b/net/core/skbuff.c
> > @@ -217,7 +217,7 @@ nodata:
> > struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
> > unsigned int length, gfp_t gfp_mask)
> > {
> > - int node = dev->dev.parent ? dev_to_node(dev->dev.parent) : -1;
> > + int node = dev_to_node(&dev->dev);
>
> This looks wrong to me unless the device model has once again changed
> silently. When I wrote this code &dev->dev was a device allocated
> as part of the netdevice and the parent is the pci (or whatever) device
> that has the node information.
Correct, this change is completely bogus.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway
On Wednesday, 4 July 2007 05:38, Paul Mackerras wrote: > Rafael J. Wysocki writes: > > > Now, please tell me how many driver writers even thought that something > > might try to access their devices after .suspend() had been executed (or > > even whilie it was being executed)? > > Well, I believe that the USB framework copes with this, except > possibly for some corner cases like the example that Alan Stern > posted. The fact that powerbooks suspend and resume without the > freezer implies that the IDE framework, the console code and the > framebuffer code cope correctly (though possibly not all chipset > drivers). Okay, so in fact you don't know. And that's my point in this thread. I won't fight for the freezer for what it's worth, but let's do things in the _right_ _order_. For example, let's make sure that by making the $subject change we won't introduce (too many) regressions and fix the frameworks that don't get it right. Using the problems with FUSE as an argument for making this change immediately doesn't seem to be right to me. > So I think that a lot of the frameworks already get it right. Of > course the quality of the low-level chipset drivers has always been > pretty variable. :) Yes, but that's another issue. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/2] raid5: 65% sequential-write performance improvement, stripe-queue take2
Dan Williams <[EMAIL PROTECTED]> writes: > The write performance numbers are better than I expected and would seem > to address the concerns raised in the thread "Odd (slow) RAID > performance"[2]. The read performance drop was not expected. However, > the numbers suggest some additional changes to be made to the queuing > model. Have you considered supporting copy-xor in MD for non accelerated RAID? I've been looking at fixing the old dubious slow crufty x86 SSE XOR functions. One thing I discovered is that it seems fairly pointless to make them slower with cache avoidance when most of the data is copied before anyways. I think much more advantage could be gotten by supporting copy-xor because XORing during a copy should be nearly free. On the other hand ext3 write() also uses a cache avoiding copy now and for the XOR it would need to load the data from memory again. Perhaps this could be also optimized somehow (e.g. setting a flag somewhere and using a normal copy for the RAID-5 case) -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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Oliver Neukum writes: > You cannot simply restart the URB without thinking. > The device after resumption may or may not be in the stage > you left it. It needs to be rechecked and some settings must be > renewed. You cannot simple throw an URB from an arbitrary > stage of the protocol at it. > Suspension of devices can only happen at some points > in the protocol. Yeah, and? I said "the higher-level driver needs to do the sensible thing". 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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Am Mittwoch, 4. Juli 2007 schrieb Paul Mackerras: > Oliver Neukum writes: > > > You cannot simply restart the URB without thinking. > > The device after resumption may or may not be in the stage > > you left it. It needs to be rechecked and some settings must be > > renewed. You cannot simple throw an URB from an arbitrary > > stage of the protocol at it. > > Suspension of devices can only happen at some points > > in the protocol. > > Yeah, and? > > I said "the higher-level driver needs to do the sensible thing". They can't. Device specific protocols are known to the drivers only. The fact remains, remove the freezer and you need to go through all drivers. Oliver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Rafael J. Wysocki writes: > So, I gather, you're volunteering to handle suspend-related bug reports > from the point in which we drop the freezer from the suspend code path? Ben and I are happy to handle all the ones for the platform we maintain, which currently does suspend without freezing processes. :) 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: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway
Rafael J. Wysocki writes: > Okay, so in fact you don't know. Don't know what exactly? It has been a while since I had my head in the USB code. I assume it's being maintained by competent people. :) > And that's my point in this thread. Well, I'd be interested in hearing from Matthew whether he has actually been using his patch in Ubuntu, and if so, what bug reports he has been receiving related to it? > I won't fight for the freezer for what it's worth, but let's do things in the > _right_ _order_. For example, let's make sure that by making the $subject > change we won't introduce (too many) regressions and fix the frameworks > that don't get it right. > > Using the problems with FUSE as an argument for making this change immediately > doesn't seem to be right to me. I can see your point, but I won't be moving powermac over to use the generic suspend path until the freezer is gone, since I am pretty confident that the drivers we care about behave sensibly, and I have seen a lot of traffic on linux-pm and lkml about problems caused by the freezer. Also, no-one has yet answered my fundamental objection to the freezer, which is that the very kernel threads we would want to freeze are often the same ones that we must not freeze, namely the threads that issue I/O requests in order to satisfy incoming I/O requests. If there was an automatic way to construct the graph of dependencies (including data flows) between tasks, and derive an ordering for freezing that guarantees that all I/Os will get completed without deadlocks, then I could accept the freezer. But we don't have anything like that. 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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Oliver Neukum writes: > They can't. Device specific protocols are known to the drivers only. > The fact remains, remove the freezer and you need to go through > all drivers. The freezer does not actually mean that you don't have to get the drivers right, because kernel threads can issue I/O requests. 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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
On Wednesday, 4 July 2007 12:48, Paul Mackerras wrote: > Rafael J. Wysocki writes: > > > So, I gather, you're volunteering to handle suspend-related bug reports > > from the point in which we drop the freezer from the suspend code path? > > Ben and I are happy to handle all the ones for the platform we > maintain, which currently does suspend without freezing processes. :) I mean all platforms. After all, the $subject change won't affect yours. BTW, does your platform's suspend work on SMP systems? Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Am Mittwoch, 4. Juli 2007 schrieb Paul Mackerras: > Oliver Neukum writes: > > > They can't. Device specific protocols are known to the drivers only. > > The fact remains, remove the freezer and you need to go through > > all drivers. > > The freezer does not actually mean that you don't have to get the > drivers right, because kernel threads can issue I/O requests. Kernel threads do not issue requests for the hell of it. And yes, kernel threads must be aware of suspension. Threads are few, drivers many. Oliver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] net: use numa_node in net_devcice->dev instead of parent
David Miller wrote:
> From: Christoph Hellwig <[EMAIL PROTECTED]>
> Date: Wed, 4 Jul 2007 09:51:20 +0100
>
>> On Tue, Jul 03, 2007 at 05:30:51PM -0700, Yinghai Lu wrote:
...
>> > struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
>> >unsigned int length, gfp_t gfp_mask)
>> > {
>> > - int node = dev->dev.parent ? dev_to_node(dev->dev.parent) : -1;
>> > + int node = dev_to_node(&dev->dev);
>>
>> This looks wrong to me unless the device model has once again changed
>> silently. When I wrote this code &dev->dev was a device allocated
>> as part of the netdevice and the parent is the pci (or whatever) device
>> that has the node information.
>
> Correct, this change is completely bogus.
I've got a question from a network driver writer's perspective: In
drivers which sit on top of a midlayer/ multi-protocol infrastructure,
should dev->dev.parent be the lowlevel's pci_dev.dev or the midlayer's
whatever_abstracted_dev.dev?
(Example: eth1394 network driver sits on top of ieee1394 = FireWire
midlayer, this sits on top of ohci1394 = PCI driver for FireWire
controllers.)
I guess it should be the lowlevel's pci_dev.dev, unless the midlayer
cares to set
set_dev_node(&midlayer_dev.dev, dev_to_node(midlayer_dev.dev.parent));
And either way, for full effect of NUMA awareness in the highlevel
network driver, the midlayer should be NUMA aware too...
--
Stefan Richter
-=-=-=== -=== --=--
http://arcgraph.de/sr/
-
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 -mm 0/3] configfs: Miscellaneous cleanups
Argh, my sendpatchset script got David's address wrong. I've made up for that by sending the patchset separately to him -- didn't want to spam the entire list. On Wed, 4 Jul 2007, Satyam Sharma wrote: > From: Satyam Sharma <[EMAIL PROTECTED]> > > [0/3] configfs: Miscellaneous cleanups > > Simple cleanups for configfs (plus DLM and OCFS2, wherever applicable). > This is diffed against 2.6.22-rc6-mm1. > > [1/3] configfs+dlm: Separate out __CONFIGFS_ATTR into configfs.h > [2/3] configfs+dlm+ocfs2: Convert subsystem semaphore to mutex > [3/3] configfs+dlm: Rename config_group_find_obj and state semantics clearly > > Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> > > Satyam > - 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] .gitignore update
headers_install by default puts headers into usr/include/ . They're auto-generated, so should be ignored. Same for *.orig, *.rej . Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> --- .gitignore |3 +++ usr/.gitignore |1 + 2 files changed, 4 insertions(+) --- a/.gitignore +++ b/.gitignore @@ -45,3 +45,6 @@ series # cscope files cscope.* + +*.orig +*.rej --- a/usr/.gitignore +++ b/usr/.gitignore @@ -5,3 +5,4 @@ gen_init_cpio initramfs_data.cpio initramfs_data.cpio.gz initramfs_list +include - 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] NTP: remove clock_was_set() call to prevent deadlock
Hi, On Tuesday 03 July 2007, Thomas Gleixner wrote: > The clock_was_set() call in seconds_overflow() which happens only when > leap seconds are inserted / deleted is wrong in two aspects: > > 1. it results in a call to on_each_cpu() with interrupts disabled > 2. it is potential deadlock source vs. call_lock in smp_call_function() > > The only possible side effect of the removal might be, that an absolute > CLOCK_REALTIME timer fires 1 second too late, in the rare case of leap > second deletion and an absolute CLOCK_REALTIME timer which expires in > the affected time frame. It will never fire too early. That's a bit of an easy solution and doesn't fix the real problem. The clock_was_set() calls were correct, what's broken is the locking. Why wasn't that fixed instead? I would at least like to see a comment there, why these calls were removed. 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/
[PATCH -mm 1/3] configfs+dlm: Separate out __CONFIGFS_ATTR into configfs.h
From: Satyam Sharma <[EMAIL PROTECTED]>
[1/3] configfs+dlm: Separate out __CONFIGFS_ATTR into configfs.h
fs/dlm/config.c contains a useful generic macro called __CONFIGFS_ATTR
that is similar to sysfs' __ATTR macro that makes defining attributes
easy for any user of configfs. Separate it out into configfs.h so that
other users (forthcoming in dynamic netconsole patchset) can use it too.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Cc: Joel Becker <[EMAIL PROTECTED]>
Cc: David Teigland <[EMAIL PROTECTED]>
---
fs/dlm/config.c |8
include/linux/configfs.h | 16
2 files changed, 16 insertions(+), 8 deletions(-)
---
diff -ruNp a/fs/dlm/config.c b/fs/dlm/config.c
--- a/fs/dlm/config.c 2007-06-28 17:32:57.0 +0530
+++ b/fs/dlm/config.c 2007-07-03 16:56:35.0 +0530
@@ -133,14 +133,6 @@ static ssize_t cluster_set(struct cluste
return len;
}
-#define __CONFIGFS_ATTR(_name,_mode,_read,_write) { \
- .attr = { .ca_name = __stringify(_name),\
- .ca_mode = _mode, \
- .ca_owner = THIS_MODULE },\
- .show = _read, \
- .store = _write, \
-}
-
#define CLUSTER_ATTR(name, check_zero)\
static ssize_t name##_write(struct cluster *cl, const char *buf, size_t len) \
{ \
diff -ruNp a/include/linux/configfs.h b/include/linux/configfs.h
--- a/include/linux/configfs.h 2007-06-28 17:33:19.0 +0530
+++ b/include/linux/configfs.h 2007-07-03 16:56:35.0 +0530
@@ -130,6 +130,22 @@ struct configfs_attribute {
mode_t ca_mode;
};
+/*
+ * Users often need to create attribute structures for their configurable
+ * attributes, containing a configfs_attribute member and function pointers
+ * for the show() and store() operations on that attribute. They can use
+ * this macro (similar to sysfs' __ATTR) to make defining attributes easier.
+ */
+#define __CONFIGFS_ATTR(_name, _mode, _show, _store) \
+{ \
+ .attr = { \
+ .ca_name = __stringify(_name), \
+ .ca_mode = _mode, \
+ .ca_owner = THIS_MODULE,\
+ }, \
+ .show = _show,\
+ .store = _store, \
+}
/*
* If allow_link() exists, the item can symlink(2) out to other
-
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 -mm 4/9] netconsole: Introduce netconsole_netdev_notifier
From: Satyam Sharma <[EMAIL PROTECTED]>
[4/9] netconsole: Introduce netconsole_netdev_notifier
To update fields of underlying netpoll structure at runtime on
corresponding NETDEV_CHANGEADDR or NETDEV_CHANGENAME notifications.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Cc: Keiichi Kii <[EMAIL PROTECTED]>
Cc: Takayoshi Kochi <[EMAIL PROTECTED]>
---
drivers/net/netconsole.c | 36
1 file changed, 36 insertions(+)
---
diff -ruNp a/drivers/net/netconsole.c b/drivers/net/netconsole.c
--- a/drivers/net/netconsole.c 2007-07-03 21:51:40.0 +0530
+++ b/drivers/net/netconsole.c 2007-07-03 22:02:11.0 +0530
@@ -81,6 +81,37 @@ static struct netconsole_target default_
},
};
+/* Handle network interface device notifications */
+static int netconsole_netdev_event(struct notifier_block *this,
+ unsigned long event,
+ void *ptr)
+{
+ struct net_device *dev = ptr;
+ struct netconsole_target *nt = &default_target;
+
+ if (!(event == NETDEV_CHANGEADDR || event == NETDEV_CHANGENAME))
+ goto done;
+
+ if (nt->np.dev == dev) {
+ switch (event) {
+ case NETDEV_CHANGEADDR:
+ memcpy(nt->np.local_mac, dev->dev_addr, ETH_ALEN);
+ break;
+
+ case NETDEV_CHANGENAME:
+ strlcpy(nt->np.dev_name, dev->name, IFNAMSIZ);
+ break;
+ }
+ }
+
+done:
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block netconsole_netdev_notifier = {
+ .notifier_call = netconsole_netdev_event,
+};
+
static void write_msg(struct console *con, const char *msg, unsigned int len)
{
int frag, left;
@@ -123,6 +154,10 @@ static int __init init_netconsole(void)
if (err)
goto out;
+ err = register_netdevice_notifier(&netconsole_netdev_notifier);
+ if (err)
+ return err;
+
register_console(&netconsole);
printk(KERN_INFO "netconsole: network logging started\n");
@@ -135,6 +170,7 @@ static void __exit cleanup_netconsole(vo
struct netconsole_target *nt = &default_target;
unregister_console(&netconsole);
+ unregister_netdevice_notifier(&netconsole_netdev_notifier);
netpoll_cleanup(&nt->np);
}
-
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 -mm 6/9] netconsole: Update documentation for multiple target support
From: Satyam Sharma <[EMAIL PROTECTED]> [6/9] netconsole: Update documentation for multiple target support ... and add a few useful general purpose tips as well while we're at it. Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> Cc: Keiichi Kii <[EMAIL PROTECTED]> Cc: Takayoshi Kochi <[EMAIL PROTECTED]> --- Documentation/networking/netconsole.txt | 18 ++ 1 file changed, 18 insertions(+) --- diff -ruNp a/Documentation/networking/netconsole.txt b/Documentation/networking/netconsole.txt --- a/Documentation/networking/netconsole.txt 2007-04-26 08:38:32.0 +0530 +++ b/Documentation/networking/netconsole.txt 2007-07-02 11:44:53.0 +0530 @@ -34,6 +34,12 @@ Examples: insmod netconsole netconsole=@/,@10.0.0.2/ +It also supports logging to multiple remote agents by specifying +parameters for the multiple agents separated by semicolons and the +complete string enclosed in "quotes", thusly: + +modprobe netconsole netconsole="@/,@10.0.0.2/;@/eth1,[EMAIL PROTECTED]/" + Built-in netconsole starts immediately after the TCP stack is initialized and attempts to bring up the supplied dev at the supplied address. @@ -44,6 +50,18 @@ WARNING: the default target ethernet set ethernet address to send packets, which can cause increased load on other systems on the same ethernet segment. +TIP: some LAN switches may be configured to suppress ethernet broadcasts +so it is advised to explicitly specify the remote agents' MAC addresses +from the config parameters passed to netconsole. + +TIP: to find out the MAC address of 10.0.0.2, you may try using: +ping -c 1 10.0.0.2 ; /sbin/arp -n | grep 10.0.0.2 + +TIP: in case the remote logging agent is on a separate LAN subnet than +the sender, it is suggested to try specifying the default gateway's +(you may use /sbin/route -n to find out) MAC address as the remote MAC +address instead. + NOTE: the network device (eth1 in the above case) can run any kind of other network traffic, netconsole is not intrusive. Netconsole might cause slight delays in other traffic if the volume of kernel - 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 -mm 1/9] netconsole: Cleanups, codingstyle, prettyfication
From: Satyam Sharma <[EMAIL PROTECTED]>
[1/9] netconsole: Cleanups, codingstyle, prettyfication
(1) Remove unwanted headers.
(2) Mark __init and __exit as appropriate.
(3) Various trivial codingstyle and prettification stuffs.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Cc: Keiichi Kii <[EMAIL PROTECTED]>
Cc: Takayoshi Kochi <[EMAIL PROTECTED]>
---
drivers/net/netconsole.c | 55 +++
1 file changed, 27 insertions(+), 28 deletions(-)
---
diff -ruNp a/drivers/net/netconsole.c b/drivers/net/netconsole.c
--- a/drivers/net/netconsole.c 2007-04-26 08:38:32.0 +0530
+++ b/drivers/net/netconsole.c 2007-07-03 20:27:17.0 +0530
@@ -35,35 +35,32 @@
/
#include
-#include
#include
#include
#include
-#include
#include
#include
-#include
-#include
#include
MODULE_AUTHOR("Maintainer: Matt Mackall <[EMAIL PROTECTED]>");
MODULE_DESCRIPTION("Console driver for network interfaces");
MODULE_LICENSE("GPL");
-static char config[256];
-module_param_string(netconsole, config, 256, 0);
+#define MAX_PARAM_LENGTH 256
+#define MAX_PRINT_CHUNK1000
+
+static char config[MAX_PARAM_LENGTH];
+module_param_string(netconsole, config, MAX_PARAM_LENGTH, 0);
MODULE_PARM_DESC(netconsole, " [EMAIL
PROTECTED]/[dev],[tgt-port]@/[tgt-macaddr]\n");
static struct netpoll np = {
- .name = "netconsole",
- .dev_name = "eth0",
- .local_port = 6665,
- .remote_port = ,
- .remote_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff},
+ .name = "netconsole",
+ .dev_name = "eth0",
+ .local_port = 6665,
+ .remote_port= ,
+ .remote_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff},
};
-static int configured = 0;
-
-#define MAX_PRINT_CHUNK 1000
+static int configured;
static void write_msg(struct console *con, const char *msg, unsigned int len)
{
@@ -75,7 +72,7 @@ static void write_msg(struct console *co
local_irq_save(flags);
- for(left = len; left; ) {
+ for (left = len; left;) {
frag = min(left, MAX_PRINT_CHUNK);
netpoll_send_udp(&np, msg, frag);
msg += frag;
@@ -86,12 +83,12 @@ static void write_msg(struct console *co
}
static struct console netconsole = {
- .name = "netcon",
- .flags = CON_ENABLED | CON_PRINTBUFFER,
- .write = write_msg
+ .name = "netcon",
+ .flags = CON_ENABLED | CON_PRINTBUFFER,
+ .write = write_msg,
};
-static int option_setup(char *opt)
+static int __init option_setup(char *opt)
{
configured = !netpoll_parse_options(&np, opt);
return 1;
@@ -99,28 +96,30 @@ static int option_setup(char *opt)
__setup("netconsole=", option_setup);
-static int init_netconsole(void)
+static int __init init_netconsole(void)
{
- int err;
+ int err = 0;
- if(strlen(config))
+ if (strnlen(config, MAX_PARAM_LENGTH))
option_setup(config);
- if(!configured) {
- printk("netconsole: not configured, aborting\n");
- return 0;
+ if (!configured) {
+ printk(KERN_INFO "netconsole: not configured, aborting\n");
+ goto out;
}
err = netpoll_setup(&np);
if (err)
- return err;
+ goto out;
register_console(&netconsole);
printk(KERN_INFO "netconsole: network logging started\n");
- return 0;
+
+out:
+ return err;
}
-static void cleanup_netconsole(void)
+static void __exit cleanup_netconsole(void)
{
unregister_console(&netconsole);
netpoll_cleanup(&np);
-
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 -mm 2/9] netconsole: Code simplification
From: Satyam Sharma <[EMAIL PROTECTED]>
[2/9] netconsole: Code simplification
(1) Extract netpoll_parse_options() out of option_setup(), and into
init_netconsole() itself. So "configured" variable is redundant and
can be removed.
(2) With this change, option_setup() is not required for modular netconsole.
(3) The (!np.dev) check in write_msg() is bogus (always false), because:
np.dev is set by netpoll_setup(), which is called by the target init
code in init_netconsole() _before_ register_console() => write_msg() cannot
be triggered unless netpoll_setup() returns with success. And that will not
happen if netpoll_setup() failed to set np.dev. Also np.dev cannot go from
under us while netconsole is loaded. This is because netpoll_setup() grabs
a reference for us on that dev. So let's remove the pointless check.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Cc: Keiichi Kii <[EMAIL PROTECTED]>
Cc: Takayoshi Kochi <[EMAIL PROTECTED]>
---
drivers/net/netconsole.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
---
diff -ruNp a/drivers/net/netconsole.c b/drivers/net/netconsole.c
--- a/drivers/net/netconsole.c 2007-07-03 21:45:16.0 +0530
+++ b/drivers/net/netconsole.c 2007-07-03 21:45:37.0 +0530
@@ -53,6 +53,16 @@ static char config[MAX_PARAM_LENGTH];
module_param_string(netconsole, config, MAX_PARAM_LENGTH, 0);
MODULE_PARM_DESC(netconsole, " [EMAIL
PROTECTED]/[dev],[tgt-port]@/[tgt-macaddr]\n");
+#ifndefMODULE
+static int __init option_setup(char *opt)
+{
+ strlcpy(config, opt, MAX_PARAM_LENGTH);
+ return 1;
+}
+
+__setup("netconsole=", option_setup);
+#endif
+
static struct netpoll np = {
.name = "netconsole",
.dev_name = "eth0",
@@ -60,16 +70,12 @@ static struct netpoll np = {
.remote_port= ,
.remote_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff},
};
-static int configured;
static void write_msg(struct console *con, const char *msg, unsigned int len)
{
int frag, left;
unsigned long flags;
- if (!np.dev)
- return;
-
local_irq_save(flags);
for (left = len; left;) {
@@ -88,26 +94,19 @@ static struct console netconsole = {
.write = write_msg,
};
-static int __init option_setup(char *opt)
-{
- configured = !netpoll_parse_options(&np, opt);
- return 1;
-}
-
-__setup("netconsole=", option_setup);
-
static int __init init_netconsole(void)
{
int err = 0;
- if (strnlen(config, MAX_PARAM_LENGTH))
- option_setup(config);
-
- if (!configured) {
+ if (!strnlen(config, MAX_PARAM_LENGTH)) {
printk(KERN_INFO "netconsole: not configured, aborting\n");
goto out;
}
+ err = netpoll_parse_options(&np, config);
+ if (err)
+ goto out;
+
err = netpoll_setup(&np);
if (err)
goto out;
-
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 -mm 2/3] configfs+dlm+ocfs2: Convert subsystem semaphore to mutex
From: Satyam Sharma <[EMAIL PROTECTED]>
[2/3] configfs+dlm+ocfs2: Convert subsystem semaphore to mutex
Convert the su_sem member of struct configfs_subsystem to a struct mutex,
as that's what it is. Also convert all the users and update
Documentation/configfs.txt and Documentation/configfs_example.c accordingly.
[ This patch touches three different trees (configfs, dlm and ocfs2)
and I thought of splitting this up, but I guess there's little point in
splitting into smaller patches that won't even build without each other. ]
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Cc: Joel Becker <[EMAIL PROTECTED]>
Cc: Mark Fasheh <[EMAIL PROTECTED]>
Cc: David Teigland <[EMAIL PROTECTED]>
---
Documentation/filesystems/configfs/configfs.txt | 20 --
Documentation/filesystems/configfs/configfs_example.c |2 -
fs/configfs/dir.c | 16 +++---
fs/dlm/config.c | 10 -
fs/ocfs2/cluster/nodemanager.c|2 -
include/linux/configfs.h |5 +---
6 files changed, 26 insertions(+), 29 deletions(-)
---
diff -ruNp a/Documentation/filesystems/configfs/configfs_example.c
b/Documentation/filesystems/configfs/configfs_example.c
--- a/Documentation/filesystems/configfs/configfs_example.c 2007-04-26
08:38:32.0 +0530
+++ b/Documentation/filesystems/configfs/configfs_example.c 2007-07-03
18:38:28.0 +0530
@@ -453,7 +453,7 @@ static int __init configfs_example_init(
subsys = example_subsys[i];
config_group_init(&subsys->su_group);
- init_MUTEX(&subsys->su_sem);
+ mutex_init(&subsys->su_mtx);
ret = configfs_register_subsystem(subsys);
if (ret) {
printk(KERN_ERR "Error %d while registering subsystem
%s\n",
diff -ruNp a/Documentation/filesystems/configfs/configfs.txt
b/Documentation/filesystems/configfs/configfs.txt
--- a/Documentation/filesystems/configfs/configfs.txt 2007-06-28
17:31:57.0 +0530
+++ b/Documentation/filesystems/configfs/configfs.txt 2007-07-03
18:38:28.0 +0530
@@ -292,18 +292,18 @@ tells configfs to make the subsystem app
struct configfs_subsystem {
struct config_group su_group;
- struct semaphoresu_sem;
+ struct mutexsu_mtx;
};
int configfs_register_subsystem(struct configfs_subsystem *subsys);
void configfs_unregister_subsystem(struct configfs_subsystem *subsys);
- A subsystem consists of a toplevel config_group and a semaphore.
+ A subsystem consists of a toplevel config_group and a mutex.
The group is where child config_items are created. For a subsystem,
this group is usually defined statically. Before calling
configfs_register_subsystem(), the subsystem must have initialized the
group via the usual group _init() functions, and it must also have
-initialized the semaphore.
+initialized the mutex.
When the register call returns, the subsystem is live, and it
will be visible via configfs. At that point, mkdir(2) can be called and
the subsystem must be ready for it.
@@ -315,7 +315,7 @@ subsystem/group and the simple_child ite
shows a trivial object displaying and storing an attribute, and a simple
group creating and destroying these children.
-[Hierarchy Navigation and the Subsystem Semaphore]
+[Hierarchy Navigation and the Subsystem Mutex]
There is an extra bonus that configfs provides. The config_groups and
config_items are arranged in a hierarchy due to the fact that they
@@ -326,19 +326,17 @@ and config_item->ci_parent structure mem
A subsystem can navigate the cg_children list and the ci_parent pointer
to see the tree created by the subsystem. This can race with configfs'
-management of the hierarchy, so configfs uses the subsystem semaphore to
+management of the hierarchy, so configfs uses the subsystem mutex to
protect modifications. Whenever a subsystem wants to navigate the
-hierarchy, it must do so under the protection of the subsystem
-semaphore.
+hierarchy, it must do so under the protection of the subsystem mutex.
-A subsystem will be prevented from acquiring the semaphore while a newly
+A subsystem will be prevented from acquiring the mutex while a newly
allocated item has not been linked into this hierarchy. Similarly, it
-will not be able to acquire the semaphore while a dropping item has not
+will not be able to acquire the mutex while a dropping item has not
yet been unlinked. This means that an item's ci_parent pointer will
never be NULL while the item is in configfs, and that an item will only
be in its parent's cg_children list for the same duration. This allows
-a subsystem to trust ci_parent and cg_children while they hold the
-semaphore.
+a subsystem to trust ci_parent and cg_children while t
[PATCH -mm 0/3] configfs: Miscellaneous cleanups
From: Satyam Sharma <[EMAIL PROTECTED]> [0/3] configfs: Miscellaneous cleanups Simple cleanups for configfs (plus DLM and OCFS2, wherever applicable). This is diffed against 2.6.22-rc6-mm1. [1/3] configfs+dlm: Separate out __CONFIGFS_ATTR into configfs.h [2/3] configfs+dlm+ocfs2: Convert subsystem semaphore to mutex [3/3] configfs+dlm: Rename config_group_find_obj and state semantics clearly Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> Satyam - 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 -mm 9/9] netconsole: Support dynamic reconfiguration using configfs
From: Satyam Sharma <[EMAIL PROTECTED]>
[9/9] netconsole: Support dynamic reconfiguration using configfs
This patch introduces support for dynamic reconfiguration (adding, removing
and/or modifying parameters of netconsole targets at runtime) using a
userspace interface exported via configfs.
Issues and brief design overview:
(1) Kernel-initiated creation / destruction of kernel objects is not
possible with configfs -- the lifetimes of the "config items" is managed
exclusively from userspace. But netconsole must support boot/module params
too, and these are parsed in kernel and hence netpolls must be setup from
the kernel. I initially thought of extending configfs with this functionality
(item creation/destroy by kernel subsystems) but Joel Becker pointed me to
the locking and refcounting complexities such a project would entail.
After more discussion, Joel suggested the idea to separately manage the
lifetimes of the two kinds of netconsole_target objects, those created while
parsing boot/module options and those created via configfs mkdir(2) from
userspace, in my driver itself. That adds a little bit of complexity and
redundancy (multiple item creation and destruction points) in this driver.
Note that the latter type (configfs-created netconsole_targets) can be
modified / updated / destroyed at runtime from userspace but the former
(param string created) cannot, as they are not exposed through our configfs
namespace. However, this is not really a problem and is similar to current
behaviour in any case.
(2) Enhancing the semantics of the "enabled" attribute. In the original
patchset submitted, "enabled" was just an on / off knob to switch logging
to particular targets on or off in the console->write() function itself.
But there is a problem. The original patchset had interface device name
as a read-only attribute and assumed ioctl()'s were to be used to create
new targets. This worked only because ioctl()'s deal with full structures
and we can fill out the structure members (including local interface) in
the special userspace program that implements that ioctl(). But configfs
does this with simple mkdir's that can be run off the shell -- and the
corresponding kernel object is created as result of the mkdir(2) call
chain in our driver subsystem. But at that point we don't really know
what interface device should the netpoll be attached.
So, let's solve it this way: newly-created netconsole_target's are not
automatically enabled, and their parameters are not parsed (and the
netpoll_setup() not called). Then, the user may set values to the
various attributes, ending with setting "1" to "enabled" itself. The
netpoll_setup() is then called on the set parameters in the context of
_this_ write(2) on the "enabled" attribute.
The upside of this solution is that existing netconsole_targets can be
reconfigured to be attached to newly-come-up interfaces, that might not
have even existed when netconsole was loaded, or even when the targets
were originally created. Also, we are able to completely get rid of the
custom ioctl()'s based solution.
(3) Ultra-paranoid configfs attribute show() and store() operations, with
sanity and input range checking, using only safe string primitives, and
compliant with the recommendations in Documentation/filesystems/sysfs.txt.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Cc: Keiichi Kii <[EMAIL PROTECTED]>
Cc: Takayoshi Kochi <[EMAIL PROTECTED]>
---
drivers/net/Kconfig | 10
drivers/net/netconsole.c | 601 +--
2 files changed, 596 insertions(+), 15 deletions(-)
---
diff -ruNp a/drivers/net/Kconfig b/drivers/net/Kconfig
--- a/drivers/net/Kconfig 2007-07-04 13:56:32.0 +0530
+++ b/drivers/net/Kconfig 2007-07-04 13:58:03.0 +0530
@@ -3030,6 +3030,16 @@ config NETCONSOLE
If you want to log kernel messages over the network, enable this.
See for details.
+config NETCONSOLE_DYNAMIC
+ bool "Dynamic reconfiguration of logging targets (EXPERIMENTAL)"
+ depends on NETCONSOLE && SYSFS && EXPERIMENTAL
+ select CONFIGFS_FS
+ help
+ This option enables the ability to dynamically reconfigure target
+ parameters (interface, IP addresses, port numbers, MAC addresses)
+ at runtime through a userspace interface exported using configfs.
+ See for details.
+
config NETPOLL
def_bool NETCONSOLE
diff -ruNp a/drivers/net/netconsole.c b/drivers/net/netconsole.c
--- a/drivers/net/netconsole.c 2007-07-04 12:06:47.0 +0530
+++ b/drivers/net/netconsole.c 2007-07-04 13:53:14.0 +0530
@@ -41,6 +41,8 @@
#include
#include
#include
+#include
+#include
MODULE_AUTHOR("Maintainer: Matt Mackall <[EMAIL PROTECTED]>");
MODULE_DESCRIPTION("Console driver for network interfaces");
@@ -69,6 +71,9 @@ static LIST_HEAD(target_list);
/* This needs to be a spinlock because write_msg() cannot sleep */
static DEFINE_SPINLOCK(t
[PATCH -mm 7/9] netconsole: Support multiple logging targets
From: Satyam Sharma <[EMAIL PROTECTED]>
[7/9] netconsole: Support multiple logging targets
This patch introduces support for multiple targets:
Let's keep this out of CONFIG_NETCONSOLE_DYNAMIC as well -- this is useful
even in the default case and (including the infrastructure introduced in
previous patches) doesn't really add too many bytes to module text. All the
complexity (and size) comes with the dynamic reconfigurability / userspace
interface patch, and so it's plausible users may want to keep this enabled
but that disabled (say to avoid a dep on CONFIG_CONFIGFS_FS).
Brief overview:
We maintain a target_list (and corresponding lock). Get rid of the static
"default_target" and introduce allocation and release functions for our
netconsole_target objects (but keeping sure to preserve previous behaviour
such as default values). During init_netconsole(), ";" is used as the
separator to identify multiple target specifications in the input boot/module
option string, and sent off to netpoll_parse_options(), and then finally
netpoll's are setup. During exit, the target_list is torn down and all items
released.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Cc: Keiichi Kii <[EMAIL PROTECTED]>
Cc: Takayoshi Kochi <[EMAIL PROTECTED]>
---
drivers/net/netconsole.c | 193 +++
1 file changed, 145 insertions(+), 48 deletions(-)
---
diff -ruNp a/drivers/net/netconsole.c b/drivers/net/netconsole.c
--- a/drivers/net/netconsole.c 2007-07-04 03:05:32.0 +0530
+++ b/drivers/net/netconsole.c 2007-07-04 12:03:01.0 +0530
@@ -63,6 +63,12 @@ static int __init option_setup(char *opt
__setup("netconsole=", option_setup);
#endif
+/* Linked list of all configured targets */
+static LIST_HEAD(target_list);
+
+/* This needs to be a spinlock because write_msg() cannot sleep */
+static DEFINE_SPINLOCK(target_list_lock);
+
/*
* Why no net_dev_is_up() in netdevice.h? The kernel could lose a lot of
* weight if only netdevice.h had the good sense to export such a function.
@@ -75,52 +81,99 @@ static inline int net_dev_is_up(struct n
/**
* struct netconsole_target - Represents a configured netconsole target.
+ * @list: Links this target into the target_list.
* @dev_status:Tracks whether the underlying interface is up or down.
* @np:The netpoll structure for this target.
*/
struct netconsole_target {
+ struct list_headlist;
int dev_status;
struct netpoll np;
};
-static struct netconsole_target default_target = {
- .np = {
- .name = "netconsole",
- .dev_name = "eth0",
- .local_port = 6665,
- .remote_port= ,
- .remote_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff},
- },
-};
+/*
+ * Allocate new target and setup netpoll for it.
+ * Caller must then add this to target_list itself.
+ */
+static struct netconsole_target *alloc_target(char *target_config)
+{
+ int err = -ENOMEM;
+ struct netconsole_target *nt;
+
+ /* Allocate and initialize with defaults */
+ nt = kzalloc(sizeof(*nt), GFP_KERNEL);
+ if (!nt) {
+ printk(KERN_ERR "netconsole: failed to allocate memory\n");
+ goto fail;
+ }
+
+ nt->np.name = "netconsole";
+ strlcpy(nt->np.dev_name, "eth0", IFNAMSIZ);
+ nt->np.local_port = 6665;
+ nt->np.remote_port = ;
+ memset(nt->np.remote_mac, 0xff, ETH_ALEN);
+
+ /* Parse parameters and setup netpoll */
+ err = netpoll_parse_options(&nt->np, target_config);
+ if (err)
+ goto fail;
+
+ err = netpoll_setup(&nt->np);
+ if (err)
+ goto fail;
+
+ nt->dev_status = net_dev_is_up(nt->np.dev);
+
+ return nt;
+
+fail:
+ kfree(nt);
+ return ERR_PTR(err);
+}
+
+/*
+ * Cleanup netpoll for given target and free it.
+ * Caller must have removed this from target_list already.
+ */
+static void free_target(struct netconsole_target *nt)
+{
+ netpoll_cleanup(&nt->np);
+ kfree(nt);
+}
/* Handle network interface device notifications */
static int netconsole_netdev_event(struct notifier_block *this,
unsigned long event,
void *ptr)
{
+ unsigned long flags;
+ struct netconsole_target *nt;
struct net_device *dev = ptr;
- struct netconsole_target *nt = &default_target;
if (!(event == NETDEV_UP || event == NETDEV_DOWN ||
event == NETDEV_CHANGEADDR || event == NETDEV_CHANGENAME))
- goto done;
+ goto done;
- if (nt->np.dev == dev) {
- switch (event) {
- case NETDEV_UP:
- case NETDEV_DOWN:
- nt->dev_status = net_dev_is_up(nt->np.dev);
- break;
[PATCH -mm 3/9] netconsole: Introduce netconsole_target
From: Satyam Sharma <[EMAIL PROTECTED]>
[3/9] netconsole: Introduce netconsole_target
Introduce a wrapper structure over netpoll to represent targets
configured in netconsole. This will get extended with other members in
further patches.
Ok, so the original patchset did this along with (and inside the #ifdef)
of CONFIG_NETCONSOLE_DYNAMIC itself. I decided otherwise, and was able
to drastically cut down on the #ifdef-complexity of final netconsole.c.
Also, struct netconsole_target would be required for multiple targets
support also, and not just dynamic reconfigurability. Previously these
two things were coupled, but I want to de-link that. (more on this later)
Note that this patch in itself looks quite redundant / stupid, but it is
purposefully made this way, so further patches are much more readable.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Cc: Keiichi Kii <[EMAIL PROTECTED]>
Cc: Takayoshi Kochi <[EMAIL PROTECTED]>
---
drivers/net/netconsole.c | 34 --
1 file changed, 24 insertions(+), 10 deletions(-)
---
diff -ruNp a/drivers/net/netconsole.c b/drivers/net/netconsole.c
--- a/drivers/net/netconsole.c 2007-07-03 21:16:41.0 +0530
+++ b/drivers/net/netconsole.c 2007-07-03 21:35:32.0 +0530
@@ -63,24 +63,35 @@ static int __init option_setup(char *opt
__setup("netconsole=", option_setup);
#endif
-static struct netpoll np = {
- .name = "netconsole",
- .dev_name = "eth0",
- .local_port = 6665,
- .remote_port= ,
- .remote_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff},
+/**
+ * struct netconsole_target - Represents a configured netconsole target.
+ * @np:The netpoll structure for this target.
+ */
+struct netconsole_target {
+ struct netpoll np;
+};
+
+static struct netconsole_target default_target = {
+ .np = {
+ .name = "netconsole",
+ .dev_name = "eth0",
+ .local_port = 6665,
+ .remote_port= ,
+ .remote_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff},
+ },
};
static void write_msg(struct console *con, const char *msg, unsigned int len)
{
int frag, left;
unsigned long flags;
+ struct netconsole_target *nt = &default_target;
local_irq_save(flags);
for (left = len; left;) {
frag = min(left, MAX_PRINT_CHUNK);
- netpoll_send_udp(&np, msg, frag);
+ netpoll_send_udp(&nt->np, msg, frag);
msg += frag;
left -= frag;
}
@@ -97,17 +108,18 @@ static struct console netconsole = {
static int __init init_netconsole(void)
{
int err = 0;
+ struct netconsole_target *nt = &default_target;
if (!strnlen(config, MAX_PARAM_LENGTH)) {
printk(KERN_INFO "netconsole: not configured, aborting\n");
goto out;
}
- err = netpoll_parse_options(&np, config);
+ err = netpoll_parse_options(&nt->np, config);
if (err)
goto out;
- err = netpoll_setup(&np);
+ err = netpoll_setup(&nt->np);
if (err)
goto out;
@@ -120,8 +132,10 @@ out:
static void __exit cleanup_netconsole(void)
{
+ struct netconsole_target *nt = &default_target;
+
unregister_console(&netconsole);
- netpoll_cleanup(&np);
+ netpoll_cleanup(&nt->np);
}
module_init(init_netconsole);
-
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 -rc7 1/1] netpoll: Fix a leak-n-bug in netpoll_cleanup()
From: Satyam Sharma <[EMAIL PROTECTED]>
[1/1] netpoll: Fix a leak-n-bug in netpoll_cleanup()
93ec2c723e3f8a216dde2899aeb85c648672bc6b applied excessive duct tape to
the netpoll beast's netpoll_cleanup(), thus substituting one leak with
another, and opening up a little buglet :-)
net_device->npinfo (netpoll_info) is a shared and refcounted object and
cannot simply be set NULL the first time netpoll_cleanup() is called.
Otherwise, further netpoll_cleanup()'s see np->dev->npinfo == NULL and
become no-ops, thus leaking. And it's a bug too: the first call to
netpoll_cleanup() would thus (annoyingly) "disable" other (still alive)
netpolls too. Maybe nobody noticed this because netconsole (only user
of netpoll) never supported multiple netpoll objects earlier.
This is a trivial and obvious one-line fixlet.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
[ Andrew, this is diffed against 2.6.22-rc7 but applies successfully to
the 2.6.22-rc6-mm1 tree also. ]
---
net/core/netpoll.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
diff -ruNp a/net/core/netpoll.c b/net/core/netpoll.c
--- a/net/core/netpoll.c2007-07-02 22:11:21.0 +0530
+++ b/net/core/netpoll.c2007-07-03 16:28:10.0 +0530
@@ -782,7 +782,6 @@ void netpoll_cleanup(struct netpoll *np)
spin_unlock_irqrestore(&npinfo->rx_lock, flags);
}
- np->dev->npinfo = NULL;
if (atomic_dec_and_test(&npinfo->refcnt)) {
skb_queue_purge(&npinfo->arp_tx);
skb_queue_purge(&npinfo->txq);
@@ -796,6 +795,7 @@ void netpoll_cleanup(struct netpoll *np)
kfree_skb(skb);
}
kfree(npinfo);
+ np->dev->npinfo = NULL;
}
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm 5/9] netconsole: Introduce dev_status member
From: Satyam Sharma <[EMAIL PROTECTED]>
[5/9] netconsole: Introduce dev_status member
Introduce a new member in netconsole_target that tracks the status (up or
down) of the underlying interface network device that the specific logging
target netpoll is attached to.
We then join this up with the just-introduced net_device notifier, and
introduce NETDEV_UP and NETDEV_DOWN notifications. By disabling the target
when the corresponding local interface is down, we save the overhead of
unnecessarily disabling interrupts and calling into the netpoll stack in
console->write().
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Cc: Keiichi Kii <[EMAIL PROTECTED]>
Cc: Takayoshi Kochi <[EMAIL PROTECTED]>
---
drivers/net/netconsole.c | 42 +++---
1 file changed, 31 insertions(+), 11 deletions(-)
---
diff -ruNp a/drivers/net/netconsole.c b/drivers/net/netconsole.c
--- a/drivers/net/netconsole.c 2007-07-03 22:05:51.0 +0530
+++ b/drivers/net/netconsole.c 2007-07-04 03:04:45.0 +0530
@@ -63,11 +63,23 @@ static int __init option_setup(char *opt
__setup("netconsole=", option_setup);
#endif
+/*
+ * Why no net_dev_is_up() in netdevice.h? The kernel could lose a lot of
+ * weight if only netdevice.h had the good sense to export such a function.
+ * Oh well ...
+ */
+static inline int net_dev_is_up(struct net_device *net_dev)
+{
+ return ((net_dev->flags & IFF_UP) == IFF_UP);
+}
+
/**
* struct netconsole_target - Represents a configured netconsole target.
+ * @dev_status:Tracks whether the underlying interface is up or down.
* @np:The netpoll structure for this target.
*/
struct netconsole_target {
+ int dev_status;
struct netpoll np;
};
@@ -89,11 +101,17 @@ static int netconsole_netdev_event(struc
struct net_device *dev = ptr;
struct netconsole_target *nt = &default_target;
- if (!(event == NETDEV_CHANGEADDR || event == NETDEV_CHANGENAME))
- goto done;
+ if (!(event == NETDEV_UP || event == NETDEV_DOWN ||
+ event == NETDEV_CHANGEADDR || event == NETDEV_CHANGENAME))
+ goto done;
if (nt->np.dev == dev) {
switch (event) {
+ case NETDEV_UP:
+ case NETDEV_DOWN:
+ nt->dev_status = net_dev_is_up(nt->np.dev);
+ break;
+
case NETDEV_CHANGEADDR:
memcpy(nt->np.local_mac, dev->dev_addr, ETH_ALEN);
break;
@@ -118,16 +136,16 @@ static void write_msg(struct console *co
unsigned long flags;
struct netconsole_target *nt = &default_target;
- local_irq_save(flags);
-
- for (left = len; left;) {
- frag = min(left, MAX_PRINT_CHUNK);
- netpoll_send_udp(&nt->np, msg, frag);
- msg += frag;
- left -= frag;
+ if (nt->dev_status) {
+ local_irq_save(flags);
+ for (left = len; left;) {
+ frag = min(left, MAX_PRINT_CHUNK);
+ netpoll_send_udp(&nt->np, msg, frag);
+ msg += frag;
+ left -= frag;
+ }
+ local_irq_restore(flags);
}
-
- local_irq_restore(flags);
}
static struct console netconsole = {
@@ -154,6 +172,8 @@ static int __init init_netconsole(void)
if (err)
goto out;
+ nt->dev_status = net_dev_is_up(nt->np.dev);
+
err = register_netdevice_notifier(&netconsole_netdev_notifier);
if (err)
return err;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH -mm 0/9] netconsole: Multiple targets and dynamic reconfigurability
From: Satyam Sharma <[EMAIL PROTECTED]> [0/9] netconsole: Multiple targets and dynamic reconfigurability This patchset is a rework of the original idea and patches posted by Keiichi Kii and Takayoshi Kochi at: http://lkml.org/lkml/2007/6/13/72 [ I had initially thought about only modifying Keiichi's patches to incorporate the suggested stuff, sysfs+ioctl->configfs conversion, etc, but the changes became too much and I ultimately ended up rewriting the patchset. This also gave the flexibility to make other changes possible. Keiichi, Takayoshi, kindly review this, and if OK, please give your Signed-off-by:'s to the patches herein. ] This patchset depends upon the earlier netpoll fixlet and the configfs cleanup patches. Diffed against 2.6.22-rc6-mm1. [1/9] netconsole: Cleanups, codingstyle, prettyfication [2/9] netconsole: Code simplification [3/9] netconsole: Introduce netconsole_target [4/9] netconsole: Introduce netconsole_netdev_notifier [5/9] netconsole: Introduce dev_status member [6/9] netconsole: Update documentation for multiple target support [7/9] netconsole: Support multiple logging targets [8/9] netconsole: Update documentation for dynamic reconfigurability [9/9] netconsole: Support dynamic reconfiguration using configfs Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> About this patchset: What? Support multiple remote logging targets in netconsole. Also, ability to dynamically add or remove targets or modify parameters (IP, port, remote MAC address) of targets at runtime, from userspace, using configfs. Why? >From Keiichi Kii's original post: [...] current netconsole is not flexible. For example, if you want to change ip address for logging agent, in the case of built-in netconsole, you can't change config except for changing boot parameter and rebooting your system, or in the case of module netconsole, you need to remove it and reload with different parameters. [...] and we have been losing serial console port with PCs and Servers. (... and especially laptops, I would add.) The patchset is heavily commented and verbosely changelogged, so hope you have as much fun reading and reviewing it as I had writing it :-) Kindly review and comment. Satyam - 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 -mm 8/9] netconsole: Update documentation for dynamic reconfigurability
From: Satyam Sharma <[EMAIL PROTECTED]> [8/9] netconsole: Update documentation for dynamic reconfigurability Add myself to parties interested in receiving bug reports, and give lots of examples. Also fix some whitespace inconsistencies I introduced earlier. Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> Cc: Keiichi Kii <[EMAIL PROTECTED]> Cc: Takayoshi Kochi <[EMAIL PROTECTED]> --- Documentation/networking/netconsole.txt | 70 +++- 1 file changed, 68 insertions(+), 2 deletions(-) --- diff -ruNp a/Documentation/networking/netconsole.txt b/Documentation/networking/netconsole.txt --- a/Documentation/networking/netconsole.txt 2007-07-04 03:12:25.0 +0530 +++ b/Documentation/networking/netconsole.txt 2007-07-04 12:24:44.0 +0530 @@ -3,6 +3,10 @@ started by Ingo Molnar <[EMAIL PROTECTED] 2.6 port and netpoll api by Matt Mackall <[EMAIL PROTECTED]>, Sep 9 2003 Please send bug reports to Matt Mackall <[EMAIL PROTECTED]> +and Satyam Sharma <[EMAIL PROTECTED]> + +Introduction: += This module logs kernel printk messages over UDP allowing debugging of problem where disk logging fails and serial consoles are impractical. @@ -13,6 +17,9 @@ the specified interface as soon as possi capture of early kernel panics, it does capture most of the boot process. +Sender and receiver configuration: +== + It takes a string configuration parameter "netconsole" in the following format: @@ -38,7 +45,7 @@ It also supports logging to multiple rem parameters for the multiple agents separated by semicolons and the complete string enclosed in "quotes", thusly: -modprobe netconsole netconsole="@/,@10.0.0.2/;@/eth1,[EMAIL PROTECTED]/" + modprobe netconsole netconsole="@/,@10.0.0.2/;@/eth1,[EMAIL PROTECTED]/" Built-in netconsole starts immediately after the TCP stack is initialized and attempts to bring up the supplied dev at the supplied @@ -46,6 +53,64 @@ address. The remote host can run either 'netcat -u -l -p ' or syslogd. +Dynamic reconfiguration: + + +Dynamic reconfigurability is a useful addition to netconsole that enables +remote logging targets to be dynamically added, removed, or have their +parameters reconfigured at runtime from a configfs-based userspace interface. + +To include this feature, select CONFIG_NETCONSOLE_DYNAMIC when building the +netconsole module (or kernel, if netconsole is built-in). + +Some examples follow (configfs is mounted at the /config mountpoint, say). + +To add a remote logging target (target names can be arbitrary): + + cd /config/netconsole/ + mkdir target1 + +Note that newly created targets have default parameter values (as mentioned +above) and are disabled by default -- they must first be enabled by writing +"1" to the "enabled" attribute (usually after setting parameters accordingly) +as described below. + +To remove a target: + + rmdir /config/netconsole/othertarget/ + +The interface exposes these parameters of a netconsole target to userspace: + + id Unique identifier for this target (read-only) + enabled Is this target currently enabled? (read-write) + dev_nameLocal network interface name(read-only) + local_ipSource IP address to use(read-write) + remote_ip Remote agent's IP address (read-write) + local_port Source UDP port to use (read-write) + remote_port Remote agent's UDP port (read-write) + local_mac Local interface's MAC address (read-only) + remote_mac Remote agent's MAC address (read-write) + +The "enabled" attribute is also used to control whether the parameters of +a target can be updated or not -- you can modify the parameters of only +disabled targets (i.e. if "enabled" is 0). + +To update a target's parameters: + + cat enabled # check if enabled is 1 + echo 0 > enabled # disable the target (if required) + echo eth2 > dev_name # set local interface + echo 10.0.0.4 > remote_ip # update some parameter + echo cb:a9:87:65:43:21 > remote_mac # update more parameters + echo 1 > enabled # enable target again + +Note that you can even update the local interface dynamically. This is +especially useful if you want to use interfaces that have newly come up +and didn't even exist when netconsole was loaded / initialized. + +Miscellaneous notes: + + WARNING: the default target ethernet setting uses the broadcast ethernet address to send packets, which can cause increased load on other systems on the same ethernet segment. @@ -55,7 +120,8 @@ so it is advised to explicitly specify t from the config parameters passed to netconsole. TIP: to find out the MAC address of 10.0.0.2, you may try using: -p
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
On Jul 4 2007 00:11, Karel Zak wrote: >newgrp: > add support for /etc/gshadow > check result from getgrnam() more carefully Hm, gshadow looks like it is really obsolete. (There is no such file anymore in suse releases since a long while. Previously, gshadow was filled with all the groups that existed.) Jan -- - 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] NTP: remove clock_was_set() call to prevent deadlock
On Wed, 2007-07-04 at 13:06 +0200, Roman Zippel wrote: > Hi, > > On Tuesday 03 July 2007, Thomas Gleixner wrote: > > > The clock_was_set() call in seconds_overflow() which happens only when > > leap seconds are inserted / deleted is wrong in two aspects: > > > > 1. it results in a call to on_each_cpu() with interrupts disabled > > 2. it is potential deadlock source vs. call_lock in smp_call_function() > > > > The only possible side effect of the removal might be, that an absolute > > CLOCK_REALTIME timer fires 1 second too late, in the rare case of leap > > second deletion and an absolute CLOCK_REALTIME timer which expires in > > the affected time frame. It will never fire too early. > > That's a bit of an easy solution and doesn't fix the real problem. The > clock_was_set() calls were correct, what's broken is the locking. Why wasn't > that fixed instead? > I would at least like to see a comment there, why these calls were removed. We can not fix the locking that late in the cycle. I doubt that we can fix it at all, as smp_call_function _must_ run with interrupts enabled, therefor it can not run in interrupt context. It needs to run from thread context only. tglx - 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] CFS scheduler, -v18
Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> ah. That indeed makes sense. It seems like the xterm doesnt process the
> Ctrl-C/Z keypresses _at all_ when it is 'spammed' with output. Normally,
> output 'spam' is throttled by the scroll buffer's overhead. But in
> Vegard's case, the printout involves a \r carriage return:
>
>printf("%ld\r", 1000 * clock() / CLOCKS_PER_SEC);
>
> which allows xterm-spam (attached) to easily flood the xterm (without
> any scrolling that would act as a throttle) and the xterm to flood Xorg.
>
> I suspect we need the help of an xterm/Xorg expert? (maybe Keith can
> give us further pointers? I can reproduce the problem on a T60 with i940
> and Core2Duo running Fedora 7 + Xorg 7.1.)
Xorg seems to have a couple of starvation issues. e.g. I found
the Gantt view in icemon during a busy compile session can starve all
other X clients for tenths of seconds.
-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: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway
On Wednesday, 4 July 2007 12:58, Paul Mackerras wrote: > Rafael J. Wysocki writes: > > > Okay, so in fact you don't know. > > Don't know what exactly? How many drivers will be adversely affected by the $subject change. > It has been a while since I had my head in the USB code. I assume > it's being maintained by competent people. :) I'm not talking about USB. > > And that's my point in this thread. > > Well, I'd be interested in hearing from Matthew whether he has > actually been using his patch in Ubuntu, and if so, what bug reports > he has been receiving related to it? Me too. > > I won't fight for the freezer for what it's worth, but let's do things in > > the > > _right_ _order_. For example, let's make sure that by making the $subject > > change we won't introduce (too many) regressions and fix the frameworks > > that don't get it right. > > > > Using the problems with FUSE as an argument for making this change > > immediately > > doesn't seem to be right to me. > > I can see your point, but I won't be moving powermac over to use the > generic suspend path until the freezer is gone, since I am pretty > confident that the drivers we care about behave sensibly, and I have > seen a lot of traffic on linux-pm and lkml about problems caused by > the freezer. They are mostly related to kernel threads, that we've already agreed no to freeze (except for the ones that want that, but they will be responsible for getting everything right). The initial patches for that are in -mm and more will come. > Also, no-one has yet answered my fundamental objection to the freezer, > which is that the very kernel threads we would want to freeze are > often the same ones that we must not freeze, namely the threads that > issue I/O requests in order to satisfy incoming I/O requests. See above. We're moving away from freezing kernel threads. > If there was an automatic way to construct the graph of dependencies > (including data flows) between tasks, and derive an ordering for > freezing that guarantees that all I/Os will get completed without > deadlocks, then I could accept the freezer. But we don't have > anything like that. No we don't. Still, my position is this: 1) The freezer (in the modified form, with the freezing of kernel threads limited to the ones that want to be frozen) is needed for hibernation. 2) The freezer is generally not needed for suspend, _but_ there are drivers in the tree that rely on it being used. Thus, at some point in time we can remove the freezer from the suspend code path, _but_ no sooner than we are sure that the majority of drivers is prepared for that. 3) In the meantime, if there are freezer-related problems, they should be fixed rather than used as arguments for immediate removal of it, because of 2). Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm 3/3] configfs+dlm: Rename config_group_find_obj and state semantics clearly
From: Satyam Sharma <[EMAIL PROTECTED]>
[3/3] configfs+dlm: Rename config_group_find_obj and state semantics clearly
[ Ok, this might sound like a gratuitous patch, but I believe there are
good reasons for it. ]
Configfs being based upon sysfs code, config_group_find_obj() is probably
so named because of the similar kset_find_obj() in sysfs. However,
"kobject"s in sysfs become "config_item"s in configfs, so let's call it
config_group_find_item() instead, for sake of uniformity, and make
corresponding change in the users of this function.
BTW a crucial difference between kset_find_obj and config_group_find_item
is in locking expectations. kset_find_obj does its locking by itself, but
config_group_find_item expects the *caller* to do the locking. The reason
for this: kset's have their own locks, config_group's don't but instead
rely on the subsystem mutex. And, subsystem needn't necessarily be around
when config_group_find_item() is called.
So let's state these locking semantics explicitly, and rectify the comment,
otherwise bugs could continue to occur in future, as they did in the past
(refer commit d82b8191e238 in gfs2-2.6-fixes.git).
[ I also took the opportunity to fix some bad whitespace and
double-empty lines. ]
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Cc: Joel Becker <[EMAIL PROTECTED]>
Cc: David Teigland <[EMAIL PROTECTED]>
---
fs/configfs/item.c | 18 --
fs/dlm/config.c |2 +-
include/linux/configfs.h |8 ++--
3 files changed, 11 insertions(+), 17 deletions(-)
---
diff -ruNp a/fs/configfs/item.c b/fs/configfs/item.c
--- a/fs/configfs/item.c2007-06-28 17:32:57.0 +0530
+++ b/fs/configfs/item.c2007-07-03 19:42:00.0 +0530
@@ -183,27 +183,25 @@ void config_group_init(struct config_gro
INIT_LIST_HEAD(&group->cg_children);
}
-
/**
- * config_group_find_obj - search for item in group.
+ * config_group_find_item - search for item in group.
* @group: group we're looking in.
* @name: item's name.
*
- * Lock group via @group->cg_subsys, and iterate over @group->cg_list,
- * looking for a matching config_item. If matching item is found
- * take a reference and return the item.
+ * Iterate over @group->cg_list, looking for a matching config_item.
+ * If matching item is found take a reference and return the item.
+ * Caller must have locked group via @group->cg_subsys->su_mtx.
*/
-struct config_item *config_group_find_obj(struct config_group *group,
- const char * name)
+struct config_item *config_group_find_item(struct config_group *group,
+ const char *name)
{
struct list_head * entry;
struct config_item * ret = NULL;
-/* XXX LOCKING! */
list_for_each(entry,&group->cg_children) {
struct config_item * item = to_item(entry);
if (config_item_name(item) &&
-!strcmp(config_item_name(item), name)) {
+ !strcmp(config_item_name(item), name)) {
ret = config_item_get(item);
break;
}
@@ -215,4 +213,4 @@ EXPORT_SYMBOL(config_item_init);
EXPORT_SYMBOL(config_group_init);
EXPORT_SYMBOL(config_item_get);
EXPORT_SYMBOL(config_item_put);
-EXPORT_SYMBOL(config_group_find_obj);
+EXPORT_SYMBOL(config_group_find_item);
diff -ruNp a/fs/dlm/config.c b/fs/dlm/config.c
--- a/fs/dlm/config.c 2007-07-03 18:52:25.0 +0530
+++ b/fs/dlm/config.c 2007-07-03 19:43:57.0 +0530
@@ -752,7 +752,7 @@ static struct space *get_space(char *nam
return NULL;
mutex_lock(&space_list->cg_subsys->su_mtx);
- i = config_group_find_obj(space_list, name);
+ i = config_group_find_item(space_list, name);
mutex_unlock(&space_list->cg_subsys->su_mtx);
return to_space(i);
diff -ruNp a/include/linux/configfs.h b/include/linux/configfs.h
--- a/include/linux/configfs.h 2007-07-03 18:52:25.0 +0530
+++ b/include/linux/configfs.h 2007-07-03 19:46:56.0 +0530
@@ -85,12 +85,10 @@ struct config_item_type {
struct configfs_attribute **ct_attrs;
};
-
/**
* group - a group of config_items of a specific type, belonging
* to a specific subsystem.
*/
-
struct config_group {
struct config_item cg_item;
struct list_headcg_children;
@@ -98,13 +96,11 @@ struct config_group {
struct config_group **default_groups;
};
-
extern void config_group_init(struct config_group *group);
extern void config_group_init_type_name(struct config_group *group,
const char *name,
struct config_item_type *type);
-
static inline struct config_group *to_config_group(struct config_item *item)
{
return item ? contain
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Rafael J. Wysocki writes: > > > So, I gather, you're volunteering to handle suspend-related bug reports > > > from the point in which we drop the freezer from the suspend code path? > > > > Ben and I are happy to handle all the ones for the platform we > > maintain, which currently does suspend without freezing processes. :) > > I mean all platforms. After all, the $subject change won't affect yours. Well, I can't commit to handling all bug reports, but I am happy to help out where I can... 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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Rafael J. Wysocki writes: > BTW, does your platform's suspend work on SMP systems? Yes; currently we require userspace to offline all cpus other than the boot cpu before initiating the suspend. The main difficulty is actually that SMP powermacs that can suspend tend to have video cards that get powered off in suspend. We know how to re-initialize one (the Radeon RV100 QW) but not others. That's an orthogonal issue to the issues we have been discussing, though. 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: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway
Rafael J. Wysocki writes: > They are mostly related to kernel threads, that we've already agreed no to > freeze (except for the ones that want that, but they will be responsible for > getting everything right). The initial patches for that are in -mm and more > will come. Serious question: which kernel threads would actually want to be frozen? Threads that do no I/O at all don't care about suspend/resume and don't need to be frozen in any case. Threads that issue I/O requests in order to service incoming I/O requests can't be frozen because of the possibility of deadlock. Which leaves threads that do I/O just for the fun of it. :) What am I missing? > > Also, no-one has yet answered my fundamental objection to the freezer, > > which is that the very kernel threads we would want to freeze are > > often the same ones that we must not freeze, namely the threads that > > issue I/O requests in order to satisfy incoming I/O requests. > > See above. We're moving away from freezing kernel threads. I believe the distinction between threads and user processes is a false one, because user processes can now do things that were formerly only doable by kernel threads. > > If there was an automatic way to construct the graph of dependencies > > (including data flows) between tasks, and derive an ordering for > > freezing that guarantees that all I/Os will get completed without > > deadlocks, then I could accept the freezer. But we don't have > > anything like that. > > No we don't. > > Still, my position is this: > > 1) The freezer (in the modified form, with the freezing of kernel threads > limited to the ones that want to be frozen) is needed for hibernation. > > 2) The freezer is generally not needed for suspend, _but_ there are drivers > in the tree that rely on it being used. Thus, at some point in time we can Do you know which drivers they are? I'm happy to help hack things into shape. > remove the freezer from the suspend code path, _but_ no sooner than we are > sure that the majority of drivers is prepared for that. > > 3) In the meantime, if there are freezer-related problems, they should be > fixed rather than used as arguments for immediate removal of it, because of > 2). I don't know how you can make the freezer completely deadlock-free while still providing the guarantee that some drivers currently need, without constructing the dependency graph I mentioned. 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: Libata PATA status
Hi Alan, Am Wednesday 04 July 2007 11:21 schrieben Sie: > > I'd love to try to poke holes in the libata PATA support, but sadly > > it doesn't look like any of my systems built-in ATA chipsets are > > supported yet. Has anyone started a rewrite of the PPC/PowerMac IDE > > driver? The current one is in "drivers/ide/ppc/pmac.c", and supports > > these chipsets: I'm using pata-cmd64x for a few month now on my G3 powermac. So far no problems except it only runs in UDMA/25 mode instead of UDMA/33 as the ide driver does. And of course - no cdrom or zip because they are connected to the Heathrow controller... scsi0 : pata_cmd64x scsi1 : pata_cmd64x ata1: PATA max UDMA/25 cmd 0xfd63d090 ctl 0xfd63d082 bmdma 0xfd63d050 irq 0 ata2: PATA max UDMA/25 cmd 0xfd63d070 ctl 0xfd63d062 bmdma 0xfd63d058 irq 0 ata1.00: ata_hpa_resize 1: sectors = 312581808, hpa_sectors = 312581808 ata1.00: ATA-7: SAMSUNG SP1654N, BV100-50, max UDMA/100 ata1.00: 312581808 sectors, multi 16: LBA48 pata_cmd64x: active 3 recovery 1 setup 1. ata1.00: ata_hpa_resize 1: sectors = 312581808, hpa_sectors = 312581808 ata1.00: configured for UDMA/25 scsi 0:0:0:0: Direct-Access ATA SAMSUNG SP1654N BV10 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7 sd 0:0:0:0: [sda] Attached SCSI disk > I'm not aware of anyone having done any PPC ports yet, although a couple > of people have asked and said they would look at it. Currently our > coverage is incomplete for some embedded and obscure platforms, of which > the macintrash is probably the least 'obscure'. > > Alan Marc -- "It is a noble cause that we defend and not particular interests." Lord Arthur Ponsonby, "Falsehood in Wartime: Propaganda Lies of the First World War", 1928 - 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/
finding "dead" CONFIG variables: an ongoing 5-year mission ...
as i'm sure a few folks are aware, i occasionally run a script to scan the tree, looking for potentially "dead" CONFIG variables -- that is, variables of the form CONFIG_FUBAR for which there is no corresponding FUBAR in any Kconfig file. i know there are some cleanups queued for post-2.6.22, and i'm going to run the script again after andrew releases what's queued in his tree, but if anyone is interested in checking any part of the tree before then, the script i use is here: http://fsdev.net/wiki/index.php?title=Misspelled_CONFIG_variables yes, it generates a number of false positives (would you folks *please* stop using a prefix of "CONFIG_" for your non-Kconfig variables?? argh. :-) but sometimes the output is informative: $ dead_config.sh fs == BEFS_RW == fs/befs/linuxvfs.c:776:#ifndef CONFIG_BEFS_RW fs/befs/linuxvfs.c:782:#endif /* CONFIG_BEFS_RW */ ... == HAS_COMPAT_EPOLL_EVENT == fs/compat.c:2112:#ifdef CONFIG_HAS_COMPAT_EPOLL_EVENT fs/compat.c:2155:#endif /* CONFIG_HAS_COMPAT_EPOLL_EVENT */ fs/compat.c:2182:#ifdef CONFIG_HAS_COMPAT_EPOLL_EVENT == KDB_MODULES == fs/xfs/linux-2.6/xfs_buf.h:414:#ifdef CONFIG_KDB_MODULES fs/xfs/linux-2.6/xfs_buf.c:1871:#ifdef CONFIG_KDB_MODULES == NCPFS_DEBUGDENTRY == fs/ncpfs/ncplib_kernel.c:729:#ifdef CONFIG_NCPFS_DEBUGDENTRY == XFS_DEBUG == fs/xfs/xfs.h:21:#ifdef CONFIG_XFS_DEBUG fs/xfs/Makefile-linux-2.6:23:ifeq ($(CONFIG_XFS_DEBUG),y) ... etc etc ... $ dead_config.sh drivers ... == 68328_SERIAL_UART2 == drivers/serial/68328serial.h:184:#ifndef CONFIG_68328_SERIAL_UART2 ... == ALMA_ANS == drivers/serial/68328serial.c:109:#if defined(CONFIG_M68EZ328ADS) || defined(CONFIG_ALMA_ANS) || defined(CONFIG_DRAGONIXVZ) ... == BLK_DEV_MAC_MEDIABAY == drivers/ide/legacy/macide.c:80:#ifdef CONFIG_BLK_DEV_MAC_MEDIABAY drivers/ide/legacy/macide.c:131:#ifdef CONFIG_BLK_DEV_MAC_MEDIABAY ... and on and on and tediously on. i'll do a more complete run during the next merge window, but feel free to check things out for yourself before then. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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/
